docs(embedding): record issue #35 relevance-floor investigation (negative result)

[Platonenkov]

Summary

Investigates #35 (semantic search misses Platforms/Windows/App.xaml.cs for auto-lock queries on the wallet corpus). Reproduced both reported phrasings and measured the chunk's actual cosine similarity directly against Ollama, bypassing MinCosineSimilarity entirely.

Finding: this is not a threshold-calibration bug.

• what fires when the auto-lock timeout elapses -> the relevant chunk (OnAppWindowChanged) scores 0.4184 -- 0.13 below the 0.55 floor, squarely inside the noise band (0.3321-0.5402) the floor was measured against, not a borderline miss.
• how does the app lock on resume -> the same chunk scores 0.5880 for the same file/chunk, comfortably above the floor. (This phrasing's ranking/crowding was already fixed by fix(search): cap per-file hits so a small limit spans more files #34.)

The method body (OnAppWindowChanged) never mentions "lock", "auto", or "timeout" -- it only calls GetAuthStateProvider()?.OnAppSleep()/OnAppResume() on window minimize/restore. RoslynChunker.BuildEmbedText already prepends the file's path as a lexical signal (File: {path}), but that doesn't help here: the path (Platforms/Windows/App.xaml.cs) has no lock/timeout vocabulary either. This is a genuine, phrasing-sensitive content gap in one chunk's embedding, not a systemic miscalibration -- lowering the floor far enough to admit 0.4184 would re-admit several of the genuinely off-topic queries the 0.55 default was measured against (noise tops out at 0.5402).

Decision

Left MinCosineSimilarity (0.55) unchanged. No relative-floor or below-floor-backfill redesign was implemented either: both would need their own measurement against the golden suite to justify, and neither is evidenced to help this specific case (the gap to the top hit for this query is also large, not a near-miss). Recorded the full measurement and reasoning as a <remarks> addendum on EmbeddingOptions.MinCosineSimilarity, matching how the constant's original derivation is already documented there, so the data point survives for whoever revisits this threshold next.

What this costs: the miss described in #35 remains -- a query phrased exactly as "what fires when the auto-lock timeout elapses" still won't surface this one Windows-only wiring file. The underlying auto-lock feature is still found via more central chunks (AuthService.SetAutoLockDate, IAuthService docs), and the cross-platform-completeness framing ("how does the app lock on resume") already clears the floor and (post-#34) ranks reasonably. Any fix for the narrower miss belongs on the indexing/chunking side (e.g. enriching platform-glue chunks with cross-referenced call-target context) -- a larger, separate change, not attempted here for lack of measurement.

Test plan

• dotnet build CodeIndexMcp.slnx -c Release -- clean, 0 warnings/errors
• dotnet test CodeIndexMcp.slnx -c Release --no-build -- 419/419 passed (360 CodeIndex.Core.Tests + 59 CodeIndex.Server.Tests), no regressions (expected: doc-only change)
• Reproduced both code_search: relevant chunk falls below the relevance floor for some natural-language phrasings #35 queries live against the wallet index via code_search/path_filter, matching the measured scores' pass/fail pattern exactly

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 4bca1534-1456-4da5-b405-b2009db7e833

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[Platonenkov]

Добавил обобщение в README, в раздел «Known limitations» — ваш разбор его вполне заслуживает, а комментарий к константе видит мейнтейнер, решающий двигать ли 0.55, но не пользователь, решающий каким инструментом искать.

Формулировка такая: код, участвующий в фиче только тем, что вызывает её, здесь почти невидим. Похожесть считается по собственному тексту чанка, поэтому методу, который делает своё дело не называя его, не на чем совпасть. Grep берёт это в два шага — найти символ, потом найти вызывающих — а у эмбеддинга второго шага нет. Это граница возможностей, а не настройка.

И это же объясняет разрыв покрытия из бенчмарка (82% против 88%): платформенные ветки, альтернативные реализации и параллельные пути — ровно те формы, которые участвуют не называя.

Отдельно ценю два решения в вашей работе. Первое — вы отказались вводить относительный порог и добор подпороговых с пометкой, потому что для обоснования именно этого случая данных не хватало; предложить непроверенное было бы легче, чем сказать «недостаточно измерений». Второе — вы поймали ошибку в моём тексте issue: я написал path_filter с обратными слэшами, а сравнение идёт по путям с прямыми, так что буквальный вариант не совпал бы ни с чем. Вывод от этого не изменился, но заметить стоило.