AIエージェントの回答精度が上がらないのはモデルのせいか？ recall 2.3/10の統制実験で切り分けた

仕上げは AI との協働でやっています。事実と表現は著者本人が確認しています。

TL;DR

• 何が問題か: AIエージェントの回答が浅いとき、原因がモデルの性能なのか、読ませている文脈の設計なのかを切り分ける手段がなく、なんとなく新しいモデルに乗り換えて様子を見る、という高くつく試行錯誤になりがちだ
• どう解決するか: 正解基準(一次情報を全部読んで答えるAI)と審判(同一モデル・同一ルーブリックで採点するAI)を固定し、取得エージェントのモデルのみを入れ替える統制実験を組む。結果が同点なら、失敗はモデル非依存で構造起因だと判定できる
• できると何が嬉しいか: モデルの乗り換えに時間と費用を使う前に、投資すべきが「モデル選定」なのか「文脈の出典設計」なのかを、数時間の実験で先に判定できる

AIエージェントの回答が浅いとき、疑うべきはモデルか文脈か

recall平均2.3/10。

社内の案件管理データを対象に、AIエージェントに実務タスクを答えさせる仕組みを動かしてみたときの数字だ。2.3/10ということは、答えに含まれているべき情報のうち7割以上が抜け落ちていたことになる。

recall 2.3/10という数字の前に立つと、まず疑われるのはモデルの性能の方だ。手元で動かしていたのはClaude Sonnetで、もっと新しい世代や別ベンダーのモデルに替えれば数字は上がるのではないか、という見立てが自然に立つ。ただしモデルの乗り換えには検証の手間もコストもかかる。乗り換える前に、原因がモデルにあるのか、読ませている文脈の設計にあるのかを先に切り分けたいと考えた。

そこで、取得側のモデルのみを他社の別モデルに交換し、同じ条件で採点をやり直すことにした。正解基準と審判を固定したまま、原因をモデルと文脈のどちらに寄せられるかを実験で確認する組み方だ。

取得モデルのみを交換する統制実験をどう設計したか

題材は、複数の案件の状態を1行サマリにまとめた案件台帳(YAML形式の状態ヘッダファイル)だ。案件ごとにフェーズ・最終接触日・課題の有無などを短く記録している。

この台帳のみを読んで答えるAIと、メール・議事録・課題管理といった一次情報まで自由に読めるAI(正解基準)の2系統を用意し、同じ実務タスク3本に答えさせた。

• 会議準備資料の作成
• 案件の現状とブロッカーの整理
• PoCの次アクションの提案

採点は別のAIエージェントに任せた。正解基準の回答と、台帳のみを読んだAIの回答を突き合わせ、recall(網羅率)・precision(的中率)・効率・鮮度誤りの4観点でスコアを出す、LLM-as-a-Judge(AIを審判役にする評価手法)方式だ。

統制実験として固定した部分と、交換した部分を分けると次のようになる。

固定したのは正解基準AIと審判AIの2箇所。動かしたのは取得AIのモデルのみ、という組み方になっている。実験プロトコルを簡略化したYAMLに起こすとこうなる。

experiment: retrieval_model_swap
fixed:
  ground_truth_agent:
    role: 一次情報(メール/議事録/課題管理)を自由に読んで回答する
    model: pinned  # 実験を通して固定
  judge_agent:
    role: 正解基準と突合してスコアを出す
    model: pinned  # 実験を通して固定(取得AIとは別モデル)
    rubric: [recall, precision, efficiency, freshness_error]
variable:
  retrieval_agent:
    role: 案件台帳(YAML)のみを読んで回答する
    input_scope: ledger_only  # 一次情報へのアクセス無し
    model:
      - claude-sonnet
      - codex  # OpenAI系。ここのみを差し替える
tasks:
  - meeting_prep
  - status_and_blockers
  - poc_next_action

審判に渡すプロンプトは、実際の構造を簡略化するとこの形になる。

あなたは審判です。以下の[正解基準の回答]と[検証対象の回答]を比較し、
4つの観点でそれぞれ0〜10点を付けてください。

- recall: 正解基準に含まれる主張のうち、検証対象が拾えていた割合
- precision: 検証対象の主張のうち、正解基準と矛盾しない割合
- efficiency: 同じ精度をより少ない前提情報で導けているか
- freshness_error: 古い情報を最新の状態として断定していないか

[正解基準の回答]
{ground_truth_answer}

[検証対象の回答]
{candidate_answer}

出力形式: JSON { "recall": int, "precision": int, "efficiency": int, "freshness_error": int, "根拠": str }

ここで開示しておきたいことがある。審判に使ったモデルはClaude系だ。取得AIをClaude SonnetからCodexに替えたとき、審判が同系統のモデルへ甘い点を付けている可能性は排除できない。ただしこの実験の核心は「点数が同じだったこと」ではなく「見落とした項目とその見落とし方まで一致したこと」にある。採点バイアスがあったとしても、審判が指摘した具体的な見落とし箇所(次章で扱う)がモデルをまたいで一致した事実までは説明できない。

台帳のみを読んだAIのrecallはなぜ2.3/10まで落ちたのか(実験で検証)

予測: 案件台帳には案件ごとの状態が1行で要約されている。フェーズ・最終接触日・課題の有無が書いてあれば、実務タスク3本くらいには十分答えられるはずだと考えていた。

結果: recall平均は2.3/10だった。実在するブロッカーが3件あった案件で、台帳のみを読んだAIは「ブロッカーなし」と断定した。別の案件では、実際には送付済みの見積を「未送付」と報告した。

解析: 台帳の1行サマリには、どの一次情報を根拠にその状態になったのかという出典が書かれていない。台帳を書いた側が過去のある時点でメモした内容を、AIはそのまま最新の事実として受け取っていた。台帳の記述と現実がズレていたのではなく、台帳の記述には最初から「いつ・何を根拠にした記述か」という情報が欠けていて、AIにはそのズレを検知する材料そのものが渡っていなかった。

取得モデルをOpenAI系に交換したら、recallは変わるのか(実験で検証)

予測: recallの低さがモデルの読解力や推論力に起因するなら、取得AIを別系統のモデルに替えれば、少なくともいくらかの改善は出るはずだと予測していた。

結果: 取得AIをClaude SonnetからCodex(GPT系)に交換し、同じ台帳・同じ3タスク・同じ審判で再実行したところ、recall平均は2.3/10で同点だった。しかも、見落とした項目とその見落とし方まで一致していた。

タスク	審判の指摘(Claude・台帳のみ)	審判の指摘(Codex・台帳のみ)
案件の現状とブロッカー	実在するブロッカー3件を「なし」と断定	同一のブロッカー3件を「なし」と断定
会議準備資料	送付済みの見積を「未送付」と誤報告	同一の見積を「未送付」と誤報告
PoCの次アクション	台帳の古い記述を出典確認なしで採用	同一の記述を出典確認なしで採用
3タスク平均recall	2.3/10	2.3/10

解析: 2つのモデルは学習データも推論の癖も別物のはずなのに、同じ入力から同じ欠落を再現した。欠落の原因が個々のモデルの読解力ではなく、両モデルに共通して渡っていた入力(出典のない1行サマリ)の側にあったことを意味している。審判バイアスの懸念は残るが、点数の一致ではなく「どの主張を見落としたか」という具体的な中身まで一致した以上、これはモデル性能の差ではなく構造の問題だと判定していいと考えている。この結果は、どちらのモデルが優秀かという比較の話ではない。両方が同点になったこと自体が、原因の所在を教えてくれている。

「最終更新日が新しい」ヘッダは本当に新しい情報なのか(実験で検証)

予測: 台帳のヘッダには最終更新日が記録されている。更新日が新しいものから優先して読ませれば、少なくとも鮮度の判断だけは機械的に安全になるはずだと考えていた。

結果: 更新日が新しいヘッダのうち4件は、日付だけ新しく中身は古いまま止まっていた。フェーズ以外の項目を更新した際に日付が連動して書き換わり、記述内容そのものは古いままだった。

解析: 更新日は「ファイルに最後に触った日」を記録しているだけで、「その記述の根拠が最後に確認された日」を記録していない。この2つは別の情報のはずが、同じ1つのタイムスタンプに押し込められていた。だから「新しく見えるのに実は古い記述」は更新日ベースの鮮度検知では検出できない。検知できるとしたら、その記述がどの一次情報を参照しているかという出典側から辿るしかない。

recallが同点なら、直すのはモデルでなく文脈の出典設計だ

3つの実験を通して見えたのは、この失敗はモデルの選び方では直らない、という一点だ。ClaudeとCodexという別ベンダー・別世代のモデルが、同じ入力に対してまったく同じ欠落を再現した以上、投資先はモデル選定ではない。

やることは3つに絞っている。1つ目は、台帳の各主張に一次情報への出典を義務づけることだ。「ブロッカーなし」と書くなら、どの議事録のどの日付を根拠にしたかを併記させる。2つ目は、台帳の手動更新をやめて、実作業のログから機械的に書き戻す経路に変えることだ。人が思い出して書く1行は、書いた瞬間から陳腐化が始まる。3つ目は、参照ログを取って「一次情報にはあるのに、台帳にも回答にも一度も現れていない情報」を検知することだ。これは更新日では見つからない種類の欠落で、参照の有無でしか見つけられない。

モデルを乗り換える前に、この3つのどれかが手元で満たせているかを先に確認した方が、結果的に安くつくと思っている。

参考

• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv:2306.05685) — LLM-as-a-JudgeがGPT-4クラスで人間の選好と80%以上一致する一方、position bias・verbosity bias・self-enhancement biasなどの限界を報告した論文。本記事で審判バイアスを開示した理由は、この論文が指摘するself-enhancement biasの懸念に対応するためだ