AI品質の評価(Evals)

上級

What you'll learn

実用最小限の eval を構築する — 明確な合格基準を持つ 20〜100 件の実際の入力からなるゴールデンセット
タスクごとに正しいメトリクスを選ぶ: 決定論的チェック、LLM-as-judge、または人間レビュー
eval をゲートとして実行する — すべてのプロンプト変更、モデル交換の前後、そして CI で
リグレッションを局所化するために、最後だけでなくすべての段階(検索、ツール呼び出し、最終回答)をスコアリングする

AI の上に何かを出荷するなら、evals こそがそれが機能していることを知る方法であり、変更が改善だったのか改悪だったのかを知る方法です。それがなければ手探りで飛んでいます: あるケースを助けるプロンプトの微調整が、密かに他の10ケースを壊しかねません。Evals は「雰囲気ベース」の反復を測定可能なループに変えます。

実用最小限の eval

始めるのにフレームワークは要りません。ループ全体は4ステップです:

Guided walkthrough1 of 4

20〜100件の実際の入力と、正しいまたは許容できる出力(または合格とみなすものの明確な基準)。簡単なケース、トリッキーなケース、そして本番ですでに痛い目を見たエッジケースを網羅しましょう。

メトリクスの選び方

すべての質問が同じテストに値するわけではありません。メトリクスをタスクに合わせましょう:

タスクタイプ	メトリクス	コスト	信頼性
構造化出力(JSON、SQL)	スキーマ検証、完全一致	無料	高
コード生成	書かれたテストを実行	安	高
抽出(日付、エンティティ)	文字列含む/正規表現	無料	高
分類	精度、適合率、再現率	無料	高
要約、下書き、トーン	ルーブリック付き LLM-as-judge	中	中 — 較正必須
高リスクの記述、安全性	サンプル上の人間レビュー	高	最高

3つの経験則:

可能な場合は決定論的チェック。 答えが「このスキーマに合う有効な JSON」または「コードがこれらのテストを通過する」なら、LLM に尋ねない — チェックするだけ。
ファジーな品質には LLM-as-judge。 有用性、トーン、事実性 vs ソース。安価で速いが、バイアス(長さ、位置、自己選好)がある。数値を信頼する前に、サンプルで人間の評価に対してジャッジを検証しましょう。
最高リスクのスライスには人間。 リリースあたり10件の人間グレードでも0より勝る。

LLM-as-judge starter rubric

You are grading assistant responses against a source document.

For each response, output a JSON object with these fields:
- grounded: true if every factual claim is supported by the source, else false
- complete: true if the response answers all parts of the question, else false
- concise: true if the response contains no filler or repetition, else false
- overall_score: 1-5 (1 = unusable, 5 = ship it)
- reasoning: one sentence explaining the score

Do not consider length. Do not consider whether the response comes first or second.

<source>{{SOURCE}}</source>
<question>{{QUESTION}}</question>
<response>{{RESPONSE}}</response>

Return only the JSON, no preamble.

いつ実行するか

プロンプトやモデルの変更の前後。 例外なし。ゴールデンセットの全ポイントは、安全だと思った変更を捕まえることです。
モデル移行のとき。 新しいモデルは振る舞いを変えます — 時に静かに。モデル ID を切り替える前に eval を実行しましょう。エラーと移行を参照。
本番システムでは CI 内で。 緑の eval をマージゲートに変えます。リグレッションはユーザーに見られる前に捕まえられます。
報告されたバグごとに。 失敗ケースをゴールデンセットに追加しましょう。セットはシステムと共に成長します。

最終回答だけでなく、すべての段階を評価する

RAG とエージェントでは、単一の「最終回答」スコアは物事がどこで壊れているかを隠します。リグレッションが1箇所に着地するよう、各段階を別々にスコアリングしましょう:

段階	チェックすべき事項
検索	top-k は答えを含むドキュメントを含んでいたか?
ツール選択	エージェントはこのターンに正しいツールを選んだか?
ツール引数	引数は良く形成され、正しかったか?
最終回答	ゴールデン基準に一致するか?

検索スコアが下がったが最終回答スコアが安定しているとき、それが検索リグレッションであり、プロンプト問題ではないことがわかります。その種の局所化こそ、eval を単なるスコアリングではなく、実際にデバッグに有用にするものです。

よくある間違い

回答を生成したのと同じモデルでグレード。 自己選好バイアスがスコアを膨らませる。ジャッジには異なるモデルを — さらに良いのは異なるファミリーを — 使いましょう。
「正しい」答えを漏らすジャッジプロンプト。 ジャッジがゴールド回答を見たら、それに一致することを報酬とする理由を見つけます。類似性ではなく基準でジャッジしましょう。
1日目に凍結されたゴールデンセット。 セットは本番が驚かせるたびに成長すべき。停滞したセットは過去を測ります。
タスクではなく eval に最適化。 すべてのケースが合格するまで小さなセットに対してプロンプトを調整すると、過学習した可能性があります。反復中に決して見ない ~20% のケースを検証スライスとして保持しましょう。

理解度チェック

0/4

実用最小限の eval とは何か?
決定論的チェックを LLM-as-judge より優先すべきときは?
RAG エージェントで、なぜ各段階を別々にスコアリングするのか?
eval セットに過学習したことを示す赤旗は?

Key takeaways

20〜100 件の実際の入力 + 合格基準 + 一度に1変数 = 動作する eval ループ。
決定論的 > LLM-judge > 人間 — タスクが許す最も安いメトリクスを選ぶ。
パイプラインでは最終回答だけでなく、すべての段階をスコアリングする。
ゴールデンセットは報告されたバグごとに成長する。停滞したセットは過去を測る。

次に

Evaluating Your AI Agent — より深いプレイブック: 軌跡スコアリング、LLM-judge 較正、CI ゲート
ハルシネーションとその減らし方
API でのエージェント構築
モデルとプロバイダーの選択

実用最小限の eval​

メトリクスの選び方​