初めに

Agentがコードを書き、最後に「問題ありません」と報告する。

ただ、そのAgent自身が見落とした問題を、自分で見つけられるとは限りません。

そこで、作成する役割と、検証する役割を分ける方法を考えます。

この記事では、別のAgentが成果物と根拠を確認する仕組みを「交差検証」と呼びます。機械学習のデータを分割するk-fold交差検証とは別の話です。

1. 関連する設計は、Evaluator-Optimizer

生成役が成果物を作り、評価役がフィードバックし、生成役が修正する。

この構成は、Evaluator-Optimizerと呼ばれます。Anthropicも、評価基準が明確で、反復による改善を期待できるワークフローとして紹介しています。

複数の評価役を置く場合は、確認する観点を分けます。

名前を変えたAgentに同じ質問をするだけでなく、何を検証するかを具体化します。

作成Agentの回答だけを渡すと、その回答に書かれていない要件や根拠を確認できません。

レビュー役には、次を渡します。

たとえば、資料ベースの回答を検証するプロンプトです。

依頼、回答案、原資料を照合してください。

確認項目：
- 質問に答えているか
- 主張が原資料で裏付けられるか
- 数値、対象、適用条件が一致するか
- 未確認の内容を断定していないか

指摘ごとに、対象箇所・根拠・修正案を返してください。
確認できない点は「未確認」としてください。

「厳しくレビューして」より、照合対象と判断基準を示す方が、結果を扱いやすくなります。

複数のAgentが同じ答えを出しても、それだけで正しさは証明できません。

同じモデルや同じ資料を使えば、同じ誤りを共有する可能性があります。別モデルに変えても、独立性が保証されるわけではありません。

実装では、次の工夫が考えられます。

多数決を使う場合も、票数と客観的な根拠を区別します。

コードならテスト、データなら件数や制約、引用なら原文との一致を確認できます。

Anthropicも、Agent評価ではコードによる判定、モデルによる判定、人による評価を組み合わせる方法を紹介しています。

レビューAgentの「合格」は、設定した観点で問題を見つけなかったという判定です。成果物全体の正しさとは区別して扱います。

Agentを増やすと、時間とコストも増えます。指摘が間違っていて、正しい成果物を修正してしまう場合もあります。

まずは、既知の誤りを含むサンプルで、誤りの検出率・誤指摘率・処理時間を比較します。修正回数にも上限を設けます。

交差検証は、複数のAgentに納得してもらうことが目的ではありません。要件、原資料、実行結果を使って、成果物を確かめるための設計です。