検索（リトリーバル）をどう評価しているか：ゴールデンセット、リークのない行、そして実行を拒むベンチマーク

社内のナレッジシステム「Cortex」は、私たちのリポジトリで働くコーディング エージェントにコンテキストを提供しています。ルール、過去の決定、痛い目を見て 学んだこと。検索の仕組みへの変更は、定着する前に必ずひとつのベンチマークを 通ります。この記事はそのベンチマークのマニュアルです。数字そのものではなく、 数字に意味を持たせている3つの判断について書きます。

ひとつだけ覚えて帰るなら、これです。検索ベンチマークの仕事の大半は、 それを信用しないべきときを決めることにある。

1. ゴールデンセットは、すでにあった判定から作る

テスト用のクエリは手で書いていません。Cortexはエージェントにコンテキストを 渡すたびに、エージェントが取り組んでいたタスクを記録します。エージェントは 作業を終えると、受け取った各項目にhelped、noise、wrongのいずれかを 付けます。記録されたタスクとその判定の組は、そのまま関連性の判定です。 つまりゴールデンセットは、このログを判定として読むことで作られています。

現在のセットは35プロジェクトにまたがる433件のクエリで、有用と判定された 文書が738件、ノイズと判定された文書が252件あります。ここまでに4つの フィルターが必要でした。どれも、それがないと指標が嘘をつくから存在します。

• 常に提供される項目は除外する。 ルールはランキングを通らずにすべての ブリーフに入ります。これをヒットとして数えると、検索がやっていないことの 手柄を検索に与えてしまいます。
• クエリには少なくとも1件の正例が必要。 すべてがノイズだった提供からは、 良い文書がどこにあるべきだったかが何も分かりません。
• 正例がまだ存在していること。 廃止された文書はもうインデックスにありません。 それを返せと検索に求めると、できないことのせいで再現率が下がります。
• 繰り返されたタスクは1回だけ数える。 エージェントは同じタスクを複数の セッションで実行します。重複を残すと情報を増やさずにサンプルだけが膨らみ、 頻度の高いものに二重の重みがかかります。

ひとつだけバイアスが残ります。後で自分をだまさないよう、書き留めてあります。 ラベルがあるのは、一度でも提供されたものだけ。 もっと良い文書が存在していても、 一度もブリーフに入らなかったなら誰も判定しておらず、このベンチマークはそれを 見つけたことを評価できません。クリックデータの古典的な問題です。このセットは、 同じペアの上で2つのランキングを比較するためのもので、変更を判断するにはそれで 十分です。絶対的な品質の数字を主張するためのものではありません。

2. 判断に使ってよいのは1行だけ

ベンチマークは同じ検索のいくつかの構成を出力しますが、主要指標はそのうち 1つだけです。

Cortexには本番の結果を良くする機能が2つあります。見つかった文書に関連する 文書を引き込むグラフのホップと、過去に役立った文書のランクを上げる ブーストです。どちらも、ゴールデンセットの元になっているのと同じ helped / noiseの判定から学習しています。

これらをオンにして測るのは、答えが入った状態で試験を受けるようなものです。 あるクエリで役立った文書はブーストされ、ベンチマークがそのクエリを投げると、 その文書を見つけたことでブーストが評価されてしまいます。

そこで、行は次のようになっています。

行	グラフ	ブースト	用途
core	オフ	オフ	判断用。 構造上ラベルを見ていない
+ グラフ	オン	オフ	参考
+ グラフ + ブースト	オン	オン	今ユーザーが見ているもの — 参考のみ
+ グラフ + ブースト（誠実版）	オン	オン（そのクエリ自身の提供から来た判定を除く）	参考

最後の行は部分的なleave-one-outです。各クエリについて、そのクエリの提供から 来た判定を除いてブーストを計算します。部分的であることは明言しておきます。 グラフのエッジの重みはテーブルに保存されていて、クエリごとに「学習を取り消す」 ことはできないため、グラフ側には拡散したリークが少し残ります。強かった直接の リークはなくなりました。

検索への変更はcoreで判断します。ブーストのある行でだけ良く見えるなら、 良いことは証明されていません。

3. ベンチマークは測ることを拒む

もし最初からやり直すなら、真っ先に作るのがこの部分です。チェックは4つ あります。2つでは、ベンチマークは数字を出す代わりに停止してエラーで終了します。 残りの2つでは数字を出しますが、上に警告を付けます。どれも、かつて数字を出し、 その数字が間違っていたことから生まれました。

検索のコンポーネントが落ちている。 Cortexはハイブリッドです。語彙側（BM25）と 密ベクトル側（埋め込み）を融合しています。片方が失敗しても、検索はもう片方で 答え続けます。本番では良い振る舞いですが、ベンチマークにとっては毒です。 以前、埋め込みサーバーが止まった状態で30分間「ハイブリッド検索」を測っていた ことがあり、それは語彙検索だけでした。今は毎回の実行前にプローブ用のクエリを 送り、すべての側が応答したかを確認します。応答しなかった側があれば停止します。

  コンポーネント停止: dense
  システムは黙って劣化するため、測定は別のものを測ることになる。

それでも測るには、意図して入力しなければならないフラグが必要です。

ここにはもうひとつ教訓がありました。このチェックは、コンポーネントが自分は 落ちていると言える場合にしか機能しません。私たちの語彙側は自分のエラーを 握りつぶして空のリストを返していて、検索からは「探したが何もなかった」と 区別がつきませんでした。貢献はゼロなのに、正常だと報告し続けていたのです。 実験のために語彙側をオフにしたとき、偶然これに気づきました。その実行は正常と 表示され、top-24の再現率0.443を報告していましたが、実際には埋め込みだけを 測っていて、その値は0.371でした。空の結果を返すフォールバックは、上品な 劣化ではありません。偽の緑です。

ゴールデンセットが古い。 テストセットは、作られた日に存在した文書に対して 判定されています。コーパスが増えてもセットが増えなければ、新しい文書は正解と して数えられる答えを増やさずに、競争相手だけを増やします。これを学んだのは、 埋め込みインデックスを最新化して238件の文書が加わり、何も悪くなっていない のにtop-24の再現率が0.374から0.362に下がったときでした。今のゴールデン セットには、いつ作られたか、そのときのコーパスの大きさはいくつだったかを 記したファイルが付いています。30日を過ぎるとベンチマークは実行を拒みます。 その後コーパスが5%以上動いていれば警告します。セットの作り直しは再インデックス の一部です。

2回の実行の間にコーパスが動いた。 誰かが測定している最中にも、文書は Cortexに承認されていきます。あるとき2回の実行の間に3件が承認され（193件から 196件）、top-5の再現率が0.332から0.377に動きました。私たちはコーパスを見る前に、 午後いっぱいベクトルデータベースと埋め込みサーバーを疑っていました。新しい文書の ひとつは、まさに測定中の変更についてのものでした。今は各実行がコーパスの フィンガープリントを保存し、フィンガープリントの異なる実行どうしの比較には 先頭に警告が付きます。

比較が対応付けられていない。 2回の実行はクエリごとに比較し、差分に対して 95%信頼区間を取ります。区間がゼロをまたぐなら、平均が何を言おうと結果は 「区別できない」です。これは間違えて学びました。平均を比べて、語彙検索の改善を 「recall@5が+27%、recall@24が+22%、ノイズ−36%」と発表したのです。当時の 56クエリで対応のある検定をすると、持ちこたえたのはひとつだけでした。 top-5の再現率が+0.102、区間は+0.033〜+0.172。判断そのものは正しかった。 発表した大きさは正しくありませんでした。

コストと、それで手に入るもの

どのチェックも巧妙ではありません。それぞれ数行です。プローブのクエリ、日付の 確認、件数、対応のある差分。それで手に入るのは、ベンチマークから出てくる数字が、 過去に私たちをだましたやり方をすでにくぐり抜けているという保証です。

全体に2つの限界があります。このテストセットが測っているのは、クエリに似ている ものではなく、エージェントがタスクに役立つと判断したものです。これは多くの 公開検索ベンチマークよりも厳しく、別の目標です。そして信頼区間の幅はサンプル 次第です。56クエリでは、おおよそ0.07を超える効果しか検出できませんでした。 だからこそ、ゴールデンセットを大きくすることが、ほかのすべてに対していちばん 効く変更でした。

ベンチマークが言うのは、変更が効いたかどうかです。次に何を試すか、どんな結果が 出たらそれをやめるかは別のプロセスで、 検索で次に何を試すかをどう決めているか に書きました。

自分で作るなら、信じたい最初の結果が出る前に、チェックを書いてください。