精度改善をAIに任せる前に、評価を設計する

生成AI開発の工数の多くは、精度改善の試行錯誤に消える。それなら、評価と改善のループもAIに回させればよい。私たちは実際にそれを試した。結論を先に言うと、自律的な改善は成り立たなかった。原因はモデルではなく、評価の側にあった。

この記事の要点

• 「正解との不一致」は、モデルの誤りとは限らない。正解データや評価ロジックの誤りも混ざる
• AIに任せるのは「判決」ではなく「失敗の整理」。どの入口で直すかは人が決める
• 評価データの分割、正規化、明細の対応づけ、LLM評価器の校正を先に整えると、AIは強力な加速装置になる

実験：構造化抽出の改善ループをAIに回させる

題材は、業務文書から必要な項目を抽出する構造化抽出の開発だ。検証済みの文書14件、計275項目を正解データ（Ground Truth）として用意した。

そのうえで、評価→分析→改善→再評価のサイクルをAIに回させた。AIが失敗ケースを分析し、プロンプトの修正案を作り、効果を測る。人は結果を見るだけ、という構想だった。

うまくいかなかった4つの理由

1. 正解データがいつも正しいとは限らない。出力が正解と一致しなくても、モデルが間違っているとは限らない。正解そのものの誤りもあれば、問題の定義が曖昧で複数の解釈が成り立つこともある。「不一致は失敗」という前提で渡すと、AIは正しい出力まで「直そう」とする。

2. 改善案が局所最適に寄る。AIは、目の前の失敗ケースを直す方向に強く引っ張られる。特定のサンプル向けのパッチが増え、ある項目のスコアは0.53から0.93まで上がった。一方、別の項目は0.26から0.41にとどまった。

3. プロンプトが開発用のデータに過剰に合う。失敗例を見ながらプロンプトを直すと、その例にだけ効く指示が積み重なる。機械学習でいう過学習と同じことが、プロンプトでも起きる。改善に使ったデータで測ったスコアは、本番での精度を表さない。

4. 根本原因がプロンプトの外にある。「1000」と「1,000.0」を同じ値とみなすか。複数の明細行をどう対応づけるか。こうした評価ロジックやパイプライン側の問題を、AIはプロンプトの修正で解こうとした。道具がプロンプトしかなければ、すべてがプロンプトの問題に見える。

AIに任せるのは「判決」ではなく「失敗の整理」

振り返ると、私たちが作るべきだったのは、放置できる自動改善機械ではなかった。人の判断を増幅する仕分けの仕組みだった。

失敗ケースを集め、似たものをまとめ、原因の候補を並べる。そこまではAIが速い。そのうえで、各失敗をどの入口で直すかを人が決める。

この仕分けを入れるだけで、「プロンプトをいじっても上がらない」という停滞は大きく減る。

評価設計の5つの要点

この実験の後、私たちは案件の初期に評価の土台を先に作るようにしている。要点は次の5つだ。

1. 開発用と検証用を分ける。改善のために見てよいデータと、最後に精度を測るデータを分ける。検証用はAIにも開発者にも見せない
2. 項目の型ごとに指標を変える。IDやコードは完全一致、数値は許容誤差付きの一致、日付は正規化したうえでの一致、自由記述は意味の近さで測る。全項目を一つの正答率にまとめると、弱点が見えなくなる
3. 正規化を評価の前に置く。桁区切り、全角と半角、元号と西暦、単位の表記をそろえてから比べる。これを怠ると、モデルは正しいのに点数が低いという状態が生まれる
4. 明細行は対応づけてから比べる。請求書の明細のような行の集合は、並び順で比べると一行のずれが全行の不一致に広がる。行どうしの類似度から最適な対応を求める割当問題として解き、そのうえで項目を比べる
5. LLMによる評価は人と校正してから使う。自由記述の採点をLLMに任せるなら、一部を人が採点し、一致率（Cohenのκなど）を確かめてから使う。評価器もまた、評価されるべき部品である

これらを回帰テストとして自動化し、変更のたびに全項目を回す。一つの項目を上げた代わりに別の項目を下げていないかを、毎回確かめるためだ。

評価が明確なら、AIは加速装置になる

評価が曖昧なまま改善を任せると、AIは曖昧な目標に向かって高速に走る。評価が明確であれば、修正案の作成、並列での試行、結果の比較をAIに任せられる。

何を「正しい」と定義するか、どの失敗をどの問題として扱うかは、業務を知る人が決める。それ以外の反復は、AIに渡す。この分担を設計に組み込むことが、生成AI開発を速く、確実にする。