ハイブリッド検索が単独検索より悪化した原因はRRFの融合単位だった

FTSとベクトル検索を組み合わせれば、単独検索より良くなるとは限りません。今回、ハイブリッド検索のRecall@5、MRR、primary-source Top-3率が両ベースラインより悪化しました。原因は検索器の組み合わせそのものではなく、RRFで何を同一結果として融合するかでした。

合意が消える条件

2つの検索器が同一文書の別チャンクを返し、chunk ID融合では合意を取りこぼした。

チャンクIDを融合キーにすると、同じ文書を指していてもチャンクが違えば別結果として扱われます。そのため、FTSとベクトル検索が文書レベルでは一致していても、RRFには一致として積み上がりません。chunk IDのまま融合すると同一文書への合意を数えられなかったことが、調査で確認されました。

説明用の例（観測された順位記録ではありません）: FTSがdoc-A / chunk-3、doc-B / chunk-1を返し、ベクトル検索がdoc-A / chunk-7、doc-C / chunk-2を返したとします。chunk ID融合ではdoc-A / chunk-3とdoc-A / chunk-7は別候補のままです。document ID融合なら両方をdoc-Aへ集約し、回答に使う根拠チャンクを1件残せます。

今回の構成では、各検索器の返却単位がチャンクであり、その識別子を融合キーにも使っていました。検索器が同じ文書の別チャンクを返す条件では、この設計のままでは文書レベルの合意を表せません。

比較した変更と結果

比較前は、FTSとベクトル検索をchunk IDでRRF融合していた。
変更後は、document IDで順位を融合し、各文書から根拠を示すチャンクを1件残した。
固定クエリと同一コーパスで、Recall@5、MRR、primary-source Top-3率を集計して比較した。
Recall@5は0.557から0.777、MRRは0.484から0.748、Top-3率は0.44から0.84へ改善した。

融合キーをdocument IDへ変えると、別チャンクとして返った結果も文書レベルでは同じ候補として扱えます。一方で回答に使う根拠まで文書単位に粗くしないよう、各文書から根拠を示すチャンクを1件残しました。変更後は、融合単位の修正に追加した回帰テストを含む31件のリポジトリテストが通過しました。これは同一コーパスでの指標改善とは別に、変更後の実装が回帰していないことを確認する結果です。

自分の検索で確かめる手順

FTSとベクトル検索の上位結果を確認し、同じ文書の別チャンクが両方の検索器から返っているかを調べます。比較対象のコーパスと固定クエリ集合は変えません。
融合キーをchunk IDからdocument IDへ切り替え、文書ごとに根拠チャンクを1件残します。同じ固定クエリ・同一コーパスでRecall@5、MRR、primary-source Top-3率を再集計します。
融合前後で3指標を比較します。今回の比較では、Recall@5 0.557→0.777、MRR 0.484→0.748、Top-3率 0.44→0.84でした。

まとめ

RRFで融合すべき単位は、検索器が返す最小単位と常に同じではありません。検索器間で同じ文書の異なるチャンクが返るなら、文書IDで合意を集約してから根拠チャンクを残す構成を、固定条件のベンチマークで検証する価値があります。

制約

この結果は単一のコーパスとクエリ集合に基づきます。本番利用者成果は未測定です。また、後続の0.850/0.840/0.88評価は別系譜として扱い、この比較結果と混同しません。