search: default call does not steer a literal-token query toward the sparse axis

[smileygames]

観測（2026-08-21）

#1562 という literal を探して search を query だけで叩いた。返ってきた10件のうち、正解（Refs #1562 を含む commit 2bf5ed5）は sparse_rank 1 / rerank 0.987 で実際に最上位に居た。にもかかわらず、同じ結果集合に dense 側が引いた release エントリ（v1.0.5 / v1.1.2 / v1.0.6）や無関係な PR が混ざっており、呼び出し側（AI）は正解を素通りして「意味検索なので番号は引けない」と誤結論した。

同じ索引・同じ対象に対し、パラメータを与えると曖昧さが消える:

query: "1562", fusion: "sparse_only", type: "diff", repo: "Liplus-Project/liplus-language", top_k: 3

3件が返り、rerank は 0.9617 / 0.0007 / 0.0007。先頭とそれ以外の差が3桁あり、読み違えようがない。

欠陥の所在

道具は正しく動いている。description も4モードとフィルタを網羅しており、記述の欠落ではない。問題は既定の呼び方が literal クエリに対して最悪の見え方をすることにある。

• query のみの呼び出しは dense と sparse を RRF で融合するため、literal トークン1個のクエリでは dense 側が意味的に近いだけの行を大量に持ち込む。
• 応答には fusion / sparse_candidates / sparse_rank が出ているが、「このクエリは literal なので sparse_only のほうが鋭い」と示す信号は無い。
• 呼び出し側は 18 個あるパラメータのうち query 1つしか使わずに済んでしまい、既定の結果だけで能力を判断してしまう。

検討の方向（未確定）

• description の冒頭を機構（BGE-M3 / RRF / reranker）ではなく用途→パラメータの対応から始める。「exact な文字列がある → fusion: "sparse_only"」「期間で舐めたい → sort + since/until」など。
• 応答側で steering する案: query が短い literal（数値のみ、#N、SHA 断片）と判定できるとき、hint フィールドで sparse 軸を案内する。
• 射程外の明示: 探しているものが commit から参照されている場合、git log --grep のほうが厳密かつ安価である。索引が優位なのは commit から参照されない issue（起票のみ・議論のみ）や、本文の意味的な引き当てである。道具の縁を description に書くと誤用が減る。

補足

本 issue は「使えなかった」ではなく「既定の呼び方だと能力が過小に見える」という報告である。パラメータを与えた場合の挙動は上記のとおり良好であり、索引の内容にも問題は無い。