評価のフィードバック設計による自律改善型システムの構築について 【Evals / LLM-as-judge】

本番稼働から数ヶ月が経ったAIシステムが「なんとなく動いている」状態に入ると、改善の手がかりが見えなくなります。そのとき問うべきは「このシステムは何を正解として評価しているか」です。評価の仕組みなきシステムは、改善ではなく感覚で運用されます。

Evals（評価セット）とは、AIシステムの出力品質を測定するためのテストケース集です。Anthropicの定義では、evalは「タスク・試行・採点ロジック・会話記録」の4要素で構成されます。採点方法には「コードベース（正規表現・スキーマ一致など）」「モデルベース（LLMが採点する）」「人間による評価」の三種があります。この三つは排他的ではなく、組み合わせて使うものです。

「LLMが採点する」手法は、LLM-as-a-judge（LLMを審判として使う）と呼ばれます。この概念を体系化したのは、Lianmin Zhengらが2023年のNeurIPS（Datasets and Benchmarks Track）で発表した論文「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」（arXiv: 2306.05685）です。GPT-4などの強力なLLMを「審判」として使い、他のLLMの出力品質を評価する手法を実証した研究で、GPT-4が人間の判断と約85%一致し、人間同士の一致率（約81%）を上回ることを示しました。

LLM-as-a-judgeは強力ですが、限界もあります。採点者（judge）となるモデル自身が持つ偏りが採点に反映される点です。長い回答を短い回答よりも高く評価する傾向、自身が生成したような回答スタイルを好む傾向、特定の話題での知識の偏り——これらが採点に入り込みます。このため、LLM-as-a-judgeのみで評価を完結させるのは危険です。採点基準をルーブリック（明示的な採点基準）として事前に定義すること、サンプルについては人手評価との照合を定期的に行うことが必要です。

「自律改善型システム」という言葉について、正確に位置づけておきます。AIシステムが自動的に自分自身を改善するわけではありません。評価結果をプロンプト・検索インデックス・ルールの改善に戻す改善サイクルそのものは人間が設計し、人間が回します。「自律改善」とは、この改善サイクルのうち自動化できる部分——具体的には評価の実行、採点、結果の集計、傾向の検出——を機械に任せることで、改善の頻度と速度を上げることです。

設計の実践として、評価セットは失敗事例から構築することを勧めます。本番ログの中で「ユーザーが再質問した」「出力を使わなかった」と推測できる事例を中心に、20〜50件から始めます。この数は少なく見えますが、設計の議論をするには十分です。大量のテストケースを作る前に、「何を正解とするか」の定義をチームで合わせる作業が先です。

評価の結果をどの改善に戻すかは、失敗の種類によって決まります。指示の理解が誤っている場合はシステムプロンプトの見直し。参照した文書が不適切だった場合はRAGの検索設定や文書整備の見直し。判断の基準がずれている場合は few-shot 事例の追加や更新。この三つのフィードバック先を明示しておくことで、改善の議論が具体的になります。

評価は一度設計すれば終わりではなく、業務の変化・ユーザーの使い方の変化とともに更新が必要です。評価セットが古くなると、改善の指標が実態から乖離します。評価セットをどの頻度で見直すかを設計の段階で決めておかなければ、運用は止まります。

参考

• Lianmin Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena," NeurIPS 2023. https://arxiv.org/abs/2306.05685
• Anthropic: "Demystifying evals for AI agents" (2026-01-09) https://anthropic.com/engineering/demystifying-evals-for-ai-agents
• GitHub: openai/evals https://github.com/openai/evals