精度改善の前に測る：パイプライン各段階の通過件数を可視化する

「精度が低い」という結果を見たとき、真っ先に疑いたくなるのはモデルの性能やプロンプトの書き方です。しかし複数段階からなるパイプラインでは、モデルにたどり着く前の組み立て・フィルタリング段階で対象がすでに絞り込まれてしまっていることがあります。今回はベンチマークの検出率が伸びなかった原因を調べたところ、真因がモデルではなく処理上限値だったという事例を紹介します。

問題：検出率が伸びない

既知のバグを集めたベンチマークを実行したところ、検出できた件数が想定よりかなり少ないという結果になりました。原因調査というと、まず疑いたくなるのは「使っているモデルの性能不足」や「プロンプトの質」ですが、今回の真因はそこではありませんでした。

真因：詳細解析段階の処理上限

パイプラインの詳細解析フェーズには、「一度に渡すファイル数の上限」を定める定数が設定されていました。対象ファイルの一部しかこの上限を通過できず、詳細解析に一度も回されていなかったのです。つまり、検出漏れの相当数は、モデルがバグを見逃したのではなく、そもそも見る機会すら与えられていなかったことになります。

調査の型：各段階の通過件数を数える

この結論に至ったのは、いきなりプロンプトやモデル選定を疑うのではなく、パイプラインの各段階でどれだけの対象が通過しているかを実測で追ったからです。「検出率が低い」という結果だけを見て対策を打つのではなく、入口の件数・各フェーズの通過件数・最終的な検出件数を並べて機械的に確認することが有効でした。

修正

上限値を見直し、対象がすべて詳細解析まで到達するように修正しました。この修正自体は小さな変更ですが、検出率への影響は大きく、ボトルネックの特定が的確であれば修正コストは小さくて済むという典型例です。

実装チェックリスト / 調査順

• 「精度が低い」という現象を見たとき、真っ先にモデルやプロンプトを疑わない。まずパイプラインの各段階を疑う。
• 入口の件数・各フェーズの通過件数・最終出力件数を並べて書き出し、どこで最も減っているかを機械的に確認する。
• 件数を絞る処理上限値やフィルタ条件がある箇所は、それが意図した設計値か、単なる初期実装の名残かを確認する。
• ボトルネックの候補が複数ある場合は、影響が大きそうな段階から順に実測で切り分ける。
• 修正後は同じベンチマークで再度計測し、通過件数と最終検出件数の両方が改善したことを確認する。

モデルやプロンプトの調整は目につきやすく手を出しやすい一方、効果測定に時間がかかるうえ再現性も低くなりがちです。対して、パイプラインの各段階の通過件数を数えるという作業は機械的で、原因の切り分けが速く済みます。精度改善に着手する前に、まず「どこで何件通っているか」を可視化する価値は高いといえます。

次の一歩として、自分の多段パイプラインについても、各段階の入力件数・出力件数を一度ログに出してみることをお勧めします。