初めに
Agentがコードを書き、最後に「問題ありません」と報告する。
ただ、そのAgent自身が見落とした問題を、自分で見つけられるとは限りません。
そこで、作成する役割と、検証する役割を分ける方法を考えます。
この記事では、別のAgentが成果物と根拠を確認する仕組みを「交差検証」と呼びます。機械学習のデータを分割するk-fold交差検証とは別の話です。
1. 関連する設計は、Evaluator-Optimizer
生成役が成果物を作り、評価役がフィードバックし、生成役が修正する。
この構成は、Evaluator-Optimizerと呼ばれます。Anthropicも、評価基準が明確で、反復による改善を期待できるワークフローとして紹介しています。
複数の評価役を置く場合は、確認する観点を分けます。
| 役割 | 確認すること |
|---|---|
| 作成Agent | 要件に沿って成果物を作る |
| 要件レビューAgent | 要件の抜け、仕様との不一致 |
| 根拠確認Agent | 出典との一致、数値、適用条件 |
| 実行テスト | 実際の動作、期待値との一致 |
名前を変えたAgentに同じ質問をするだけでなく、何を検証するかを具体化します。
2. レビュー役には、依頼と原資料も渡す
作成Agentの回答だけを渡すと、その回答に書かれていない要件や根拠を確認できません。
レビュー役には、次を渡します。
- 元の依頼と受け入れ条件
- 検証対象の成果物
- 原資料、または参照先
- 利用可能なテスト結果
たとえば、資料ベースの回答を検証するプロンプトです。
依頼、回答案、原資料を照合してください。
確認項目：
- 質問に答えているか
- 主張が原資料で裏付けられるか
- 数値、対象、適用条件が一致するか
- 未確認の内容を断定していないか
指摘ごとに、対象箇所・根拠・修正案を返してください。
確認できない点は「未確認」としてください。
「厳しくレビューして」より、照合対象と判断基準を示す方が、結果を扱いやすくなります。
3. 合意だけで、正解と決めない
複数のAgentが同じ答えを出しても、それだけで正しさは証明できません。
同じモデルや同じ資料を使えば、同じ誤りを共有する可能性があります。別モデルに変えても、独立性が保証されるわけではありません。
実装では、次の工夫が考えられます。
- 最初の検証では、他の評価役の判定を見せない
- 根拠確認と要件確認で、チェック項目を変える
- 意見が割れたら、原資料や実行結果へ戻る
多数決を使う場合も、票数と客観的な根拠を区別します。
4. 自動テストと人の判断も組み合わせる
コードならテスト、データなら件数や制約、引用なら原文との一致を確認できます。
Anthropicも、Agent評価ではコードによる判定、モデルによる判定、人による評価を組み合わせる方法を紹介しています。
レビューAgentの「合格」は、設定した観点で問題を見つけなかったという判定です。成果物全体の正しさとは区別して扱います。
5. 検証を増やした効果も測る
Agentを増やすと、時間とコストも増えます。指摘が間違っていて、正しい成果物を修正してしまう場合もあります。
まずは、既知の誤りを含むサンプルで、誤りの検出率・誤指摘率・処理時間を比較します。修正回数にも上限を設けます。
交差検証は、複数のAgentに納得してもらうことが目的ではありません。要件、原資料、実行結果を使って、成果物を確かめるための設計です。