measure: hybrid retrieval degrades to dense-only for Japanese queries, and top-k is crowded by same-file duplicates

[liplus-lin-lay]

目的

「思想のわりに検索結果がいまいち」という体感に対し、本番で実測できた具体的な原因を 2 件記録する。どちらも graph 層とも拡張の積み重ねとも独立した、単独で効いている要因。

確認済みの事実 1 — 日本語クエリで sparse 側が機能していない

本番 MCP に対し fusion を切り替えて同一クエリを実行した。

クエリ	fusion	sparse_candidates	dense_candidates
判断の記録は状態形式で書く	sparse_only	0	0
判断の記録は状態形式で書く	dense_only	0	5
decision structure write skill（英語）	sparse_only	3	0
判断（単語 1 つ）	sparse_only	3	0

英語クエリと日本語 1 語は sparse で引ける。日本語の句になった途端 0 になる。

原因は migrations/0001_fts5_init.sql の自然文側トークナイザ。

tokenize = 'porter unicode61 remove_diacritics 2',

unicode61 は日本語の語境界を分割せず、空白・句読点で区切られるまでの仮名漢字の連なりを 1 トークンとして扱う。porter は英語ステマーなので日本語には作用しない。結果として、日本語文書は「区切り記号で挟まれた塊」単位でしか索引されず、句としてのクエリは完全一致しない限り当たらない。

影響: wiki / docs / issue 本文 / PR 本文は大半が日本語。それらに対する日本語クエリでは hybrid が実質 dense 単独で動いており、RRF に融合する相手がいない。設計上は BM25 + dense の二本立てだが、日本語では一本しか立っていない。

なお diff 側の search_docs_code_fts は trigram なので日本語でも部分一致が効く。壊れているのは自然文側だけ。

確認済みの事実 2 — top-k が同一ファイルの重複で埋まる

上記 dense_only の 5 件の内訳:

rank	type	実体
1	diff	skills/evolution-decision-structure-write/SKILL.md (2df5052)
2	diff	docs/5.-Notifications.md (4e4f22a)
3	doc	skills/evolution-decision-structure-write/SKILL.md
4	diff	docs/F.-Behavior-First.md (4e4f22a)
5	diff	skills/evolution-decision-structure-write/SKILL.md (601aa38)

5 枠のうち 3 枠が同一ファイル（doc 1 + 別コミットの diff 2）。同じ内容が doc surface と複数の diff リビジョンとして別行で索引され、同一プールで順位を争っている。

dense_score も 0.585 / 0.577 / 0.573 / 0.572 / 0.571 と平坦で、順位の分離がほとんど起きていない。

影響: top_k の数字ほど情報の幅がない。呼び出し側から見た実効的な多様性は名目の半分以下になりうる。

制約

• 記録が目的。ここでは修正方針を確定しない
• 事実 1 と 事実 2 は原因も対処も別軸なので、着手時は分割する

想定変更箇所

• 事実 1: migrations/0001_fts5_init.sql の自然文側トークナイザ、および再索引経路
• 事実 2: src/mcp.ts の融合・整列段（同一実体の集約規則）

備考

この 2 件はどちらも retrieval のランキング以前の層にある。グラフ伝播や結合重みの学習を上に載せても解消しない。検索エンジンの比較検証を行う場合、この 2 点を揃えないと比較条件が成立しない点に注意。

[liplus-lin-lay]

なぜこの欠陥が CI を通り抜けたか（追加調査）

FTS 層にはテストが存在する。src/fts.workers.test.ts の構成:

• fts D1: upsert + query (natural-language / porter)
• indexes a diff row (code tokenizer) and matches an identifier substring
• fts D1: tokenizer isolation — 更新・削除をまたいで反対側のトークナイザが健全であることを確認

機構としては妥当な網羅で、0005_fts5_tokenizer_isolation.sql の migration 適用まで見ている。

ただし fixture がすべて英語である（"healthy natural tokenizer"、識別子の部分一致など）。日本語の文字列を投入して検索するケースが一件も無い。

本番 corpus は wiki / docs / issue 本文 / PR 本文とも大半が日本語。したがって:

• テストは「トークナイザが動くこと」を検証している
• 検証していないのは「何に対して動くか」
• 結果、sparse 側が実データに対して機能していない状態で CI は緑を維持し続けた

欠陥はコードの誤りではなく、fixture の言語が実データの言語と一致していないことによって不可視化されていた。テストはコードの語彙（英語）から書かれており、corpus の語彙からは書かれていない。

完了条件への追加

事実 1 の修正にあたり、以下を満たさないと同じ経路で再発する。

• 日本語の句（単語 1 つではなく、助詞を含む複数語の句）を投入し、sparse 側が候補を返すことを assert する test を追加する
• 英語 fixture のみの test は、この assert の代替にならない

本 issue の調査で使った本番実測（fusion=sparse_only で日本語句 0 件 / 英語 3 件 / 日本語 1 語 3 件）を、そのまま fixture の形に落とせる。

[liplus-lin-lay]

@
事実1（日本語クエリで sparse 側が候補を返さない）は #182 / #183 で解消した。本番データでの実測は #183 (comment) に記録した。

本 issue の再現クエリ 判断の記録は状態形式で書く で、既定の hybrid が sparse_candidates: 11 / dense_candidates: 15 を返し、1位は本 issue 自身（sparse_rank: 1）。nat index 単体（fusion: sparse_only / type: doc）でも sparse_candidates: 3。英語クエリの非退行も確認済み。

残るスコープは事実2（top-k が同一ファイルの重複で埋まる）のみ。
@

[liplus-lin-lay]

@
両事実の分割が完了したので本 issue を閉じる。「記録が目的。ここでは修正方針を確定しない」という当初の役割は果たした。

	分割先	状態
事実1（日本語クエリで sparse が機能しない）	#182 / PR #183	解消済み。本番実測は #183 (comment)
事実2（top-k が同一実体の重複で埋まる）	#189	未着手。2026-08-01 に再実測し、重複の 3 軸に整理した

事実2 は #189 で数字を取り直した。dense 軸の再現は本 issue 記載時と完全に同一（同じ 5 件、同じスコア、幅 0.014）で、事実1 の修正は事実2 に影響していない。加えて本 issue に記載していなかった重複軸が 2 つ見つかっている（issue と PR のような作業単位の重複、Li+ source が各 user repo の .claude/ に複製されていることによる repo 横断の重複）。

事実1 の修正から派生した別件として #186（トークンを AND 連結するため長いクエリで sparse が 0 件に落ちる）を起票済み。本 issue の「日本語では二本立てのうち一本しか立っていない」という指摘は、クエリ長の軸では未解決のまま残っている。
@