新しいレーンを本番前に別マシンでdry-runし、被覆率を実測する

  • #自動化
  • #検証
  • #source-grounding

今回やったこと

検索改善案を本番へ流す前に、別マシン上のdry-runで候補データを通し、判定に使う被覆率の分布を測った。対象は、元記事から抽出した要素が計画書にどの程度残っているかを確認するレーンである。ここでの目的は、閾値を先に決めて正当化することではない。実際の正例と負例を見て、閾値がどの範囲を通し、どの範囲を保留にするかを確かめることだ。

この記録は scripts/lib/source_grounding.py と scripts/measure_source_grounding.py、およびレーン手順書に残る実装・測定記録をもとにしている。対象データは正例10件を各3回測定した計30回で、正例の被覆率は最小10%、中央値25%、最大65%だった。最大値だけを見れば高い閾値を置けそうに見えるが、最小値は当初の想定35%を大きく下回る。正例のばらつきを見ずに閾値を決めると、正常な記事まで落とす可能性がある。

平均や上限だけで閾値を決めない

実測では負例の被覆率が5%で、正例の下限10%との差は1ヒットだった。この差は明確な境界ではない。そこで MIN_COVERAGE は0.10から0.05へ変更され、被覆率だけで誤って正例を拒否する状況を避けた。値を下げることは、それ単独で合格を増やす設計ではない。判定処理では、二段目の判定を使えない場合は UNJUDGED として保留し、PASSにしない。さらに適用時には対象10件すべてのPASSが必要とされている。

観測項目実測・設定読み取れること
正例の測定回数10件 × 3回1例だけの分布ではない
正例の被覆率最小10%、中央値25%、最大65%代表値と下限に差がある
負例の被覆率5%正例下限との差は小さい
MIN_COVERAGE0.10から0.05へ被覆率だけで正例を落としにくくする
二段目の判定不能UNJUDGED判定不能をPASSに変えない

この調整は「閾値を下げれば安全」という意味ではない。低い閾値を通過条件に直結させず、判定不能を独立した状態として扱うことで、取りこぼしを減らす変更と誤通過を抑える仕組みを両立させている。指標を緩める時ほど、その後段に何がPASSを決めるのかを確認する必要がある。

dry-runを本番前の設計材料にする

今回の手順は、対象を本番適用しない環境で実データに近い入力を流し、各回の結果を集計し、閾値と判定経路を見直すというものだった。measure_source_grounding.py は測定結果を集約するためのスクリプトで、source_grounding.py には閾値や UNJUDGED の扱いが実装されている。プランを生成できたかだけでなく、その後の検証がどの状態で止まるかまでを合わせて読むと、dry-runは単なる動作確認より設計判断に近い。

別マシンでの実測には、実行環境や判定モデルの差が結果に混ざる制約がある。測定値をそのまま別のレーンへ移すのではなく、対象の入力、正例と負例の構成、繰り返し回数、判定不能時の扱いを一緒に記録する。そうすれば後から閾値を再調整するときに、数字だけを引き継ぐ誤りを避けられる。

この事例で持ち帰れるのは、最初に置いた閾値を守ることではなく、その閾値がどの観測に支えられているかを問い直すことだ。正例の最小値と負例の最大値が近いなら、単一の数値で完全に分離できる前提を捨て、複数段の判定や保留状態を設ける。保留がPASSへ化けないことまで実装で確認してから、本番適用の判断へ進める。

環境・バージョン

測定対象の実行環境と各ツールのバージョンは、参照したリポジトリ資料に記載がないため特定していない。実装・測定コードは上記のリポジトリ内ファイルを参照。

更新履歴

  • 2026-10-02: 初稿

訂正履歴