# AIエージェントをソフトウェアに組み込むプラクティス
# Critic/Judge & Sampling-Aggregation|独立検証と多数決
🎯 LLMの出力を、同じLLMに「正しい?」と聞いていませんか?
生成と検証を別系統にするだけで、自己確認バイアスを断ち切り、出力の信頼性を構造的に高められます。
🔥 解決する課題
LLMは確率的に出力が揺れ、事実と異なる内容をもっともらしく生成します。生成と検証を同一のモデル・プロンプトに任せると、生成時のバイアスが検証にも引き継がれます。法律文書のドラフトを生成したLLMに「この文書は正しいか」と尋ねても、自分の生成物に肯定的に評価しがちです。これが「自己確認バイアス」です。
💡 提案パターン
2つの手法を組み合わせます。まず、生成系とは別のモデル・別のプロンプト・決定論的コードで出力を検証する「Critic/Judge」。次に、同じ入力からN個の候補を生成し、スコアリングや多数決で最良を選ぶ「Sampling-Aggregation」。両者を組み合わせると「N個生成 → Judgeが各候補を評価 → 最高スコアを採用」となります。コストはN倍になるため、リクエスト価値と失敗コストが高い経路に限定して適用します。
✅ 選定条件
使うとき:
- 誤った出力がそのまま下流に流れると実害がある(契約書・医療要約・金融レポートなど)
- 1回の生成に追加コストをかける経済合理性がある
- 出力品質を客観的に評価できる基準がある
使わないとき:
- 多少の誤りが許容されるカジュアルな対話 → ガードレールで十分
- レイテンシが極めて厳しい(数百ミリ秒以内)
- 評価基準が主観的で定量化困難(創作文章の「面白さ」など)
⚠️ 落とし穴
- JudgeがGeneratorと同じバイアスを持つ場合があります。同じモデル・同じ知識で評価すると同じ種類の誤りを見逃します。異なるモデルファミリを使うか、決定論的チェックをJudgeの一部に組み込んでください
- Nを増やしてもコストは線形に増えますが、品質向上は逓減します。N=1とN=3の差は大きいですが、N=3とN=5の差は小さいことが多いです。まずN=3から始めてください
- Judgeのプロンプトに評価基準を明示してください。「正しいか」だけでは曖昧な判断になります。事実性・論理的整合性・スキーマ適合など具体的な軸を与えてください
🔧 実装方針
- Generator(候補生成)とJudge(評価)を別々のモデルまたは別プロンプトで構成し、同一系統による自己確認バイアスを構造的に排除します
- N個の候補生成は並列実行し、レイテンシの増加を最小限に抑えます
- Judgeの出力はスコアと理由を含む構造化データとして定義し、集約ロジック(最高スコア選択・多数決)を決定論的コードで実装します
- 全候補がJudgeの品質閾値を下回った場合のフォールバック(再生成上限・人間エスカレーション)を事前に設計しておきます
- 決定論的チェック(スキーマ検証・値域チェック・データベース照合)をJudgeの一部として組み込み、LLM判定だけに頼らない検証層を構築します
#
AIエージェント# #
ソフトウェアアーキテクチャ#