Retrievalシステムは特定の形で壊れる。チャンクサイズの変更、embeddingモデルの更新、rerankerの閾値変更 — これらのいずれもが、集計メトリクスには影響を与えないまま、狭いクエリ範囲のprecisionをサイレントに低下させる可能性がある。
Retrieval regression probeは、そのスライスが本番環境に到達する前に検出するための手段だ。
Retrieval Regression Probeとは何か
Retrieval regression probeは、デプロイ前に毎回retrieval layerに対して実行する固定クエリセットだ。各クエリには期待するドキュメントIDのセットがある。Probeはprecision@k — 上位k件の取得ドキュメントのうち期待セットと一致する割合 — を測定し、precisionが定義済みの閾値を下回った場合にデプロイを失敗させる。
汎用ベンチマークではない。ランダムサンプルでもない。すでに本番障害を引き起こしたクエリを厳選したセットを、決定論的に実行し、合否という二値の結果を得るものだ。
目的は狭い：既知の失敗モードがリグレッションしていないことを確認すること。
最小限のProbeを構築する
10〜15件のクエリから始める。最も深刻な失敗パターンをカバーするには十分であり、probeが遅くなったりメンテナンスコストが高くなったりしない。
Step 1: 実際の障害からクエリを収集する。 本番ログから取得する。システムがそのクエリに対して事実として誤ったもっともらしいドキュメントを取得した場合、または正しいドキュメントが上位k件の外にランクされた場合を探す。これらがprobe候補だ。合成クエリを作成してはいけない — 実際にシステムを壊す分布を反映しない。
Step 2: 期待するドキュメントIDを記録する。 各クエリについて、上位k件の結果に含まれるべきドキュメントを特定する。これらを期待IDのリストとして保存する。クエリに複数の許容できる回答がある場合は、単一IDではなくセットとしてエンコードする。
Step 3: ノイズバンドを定義する。 意味のある変更がなくても、Precision@kはデプロイをまたいでわずかに変動する。ノイズに反応せず、実際のドリフトにフラグを立てる閾値を設定する。一般的な出発点：最後の正常なデプロイで確立したベースラインからprecision@5が10パーセントポイント以上低下した場合に失敗とする。実際のretrieval layerの安定性に基づいて調整する。
Step 4: 実行を自動化する。 ProbeはCIパイプラインのpre-deployステップとして実行すべきだ。失敗した場合、デプロイは進まない。文書化された例外なしに手動オーバーライドは行わない。
候補プールの拡大がProbeの挙動に与える影響
多くのretrieval architectureは2段階のアプローチを使用する：候補プールを生成する高速なlexicalまたはdense retrievalパス、続いて上位kを返す前にプールを並び替えるreranker。
候補プールを拡大すること — たとえば12から30候補へ — は一般的なチューニング手法だ。直感は正しい：rerankerにより多くの素材を与えれば、正しいドキュメントを浮上させる可能性が高まる。
しかし、プールの拡大はprobeが検出し集計メトリクスが検出しないエッジケースを生む。
何が起きるかを示す：
- 一般的なクエリではrecallが向上する。 正しいドキュメントが候補プールに入る頻度が増える。平均的にrerankerのprecisionが上がる。
- 曖昧なクエリではノイズが増加する。 12件ではなく30件の候補があると、rerankerはトピック的には近いが特定のクエリに対して事実として誤ったドキュメントをより多く見ることになる。本番障害を引き起こしやすい曖昧なクエリでは、rerankerのprecisionが低下する可能性がある。
- Probeは曖昧なケースを検出する。 Probeのクエリは実際の障害から収集されているため、クエリ分布の曖昧な側に偏っている。平均precision@5を4ポイント改善する候補プールの拡大が、同時に12件のprobeクエリのうち3件でprecisionをリグレッションさせる可能性がある。集計メトリクスはこれを隠す。Probeはこれを表面化する。
これがregression probeの核心的な価値だ：平均的な挙動ではなく、システムの既知の弱点に対して敵対的に構築されている。
Probeが失敗したときの対処
Probeの失敗は危機ではない。システムが正しく機能している証拠だ。
Probeが失敗した場合：
- どのクエリがリグレッションしたか、どの程度かを特定する。
- リグレッションが候補プール（retrieval stage）にあるのか、rerankerの出力（ranking stage）にあるのかを確認する。Probeクエリのrerank前とrerank後の両方のランキングをログに記録する。
- リグレッションが意図した変更の副作用なのか、意図しない結果なのかを判断する。
- デプロイ前にリグレッションを修正するか、トレードオフを明示的に文書化してprobe閾値を根拠コメントとともに更新する。
Step 4をスキップしてはいけない。Probeは、その閾値がドリフトへの累積的な許容ではなく意図的な決定を反映している場合にのみ有用だ。
運用上の規律
Retrieval regression probeは一度構築すれば終わりではない。メンテナンスが必要だ：
- 本番環境に新しい失敗モードが現れたら新しいクエリを追加する。
- 対象ドキュメントがコーパスから削除されたらクエリを廃止する。
- コーパスが再構成されたら期待IDセットを見直す。
誠実にメンテナンスされた15件のクエリは、ローンチ時に一度実行した包括的なベンチマークよりも多くのリグレッションを検出する。
地味で、一貫していて、デプロイ前に実行する。それがretrieval systemを信頼できる状態に保つパターンだ。
AIシステムの構築や監査を行っており、retrieval architectureと評価設計について話し合いたい場合は、会話を始める →