第5章 評価と改善

学習目標

• 成功基準を観察可能な合格条件のあるルーブリックに変え、致命的な誤りを別に定める。
• 実際の分布と境界事例を反映したテストセットを作り、改善用と確認用に分ける。
• 基準ごとにコード・人・LLMから採点方法を選び、LLM評価者を人の判定で校正する。
• 同じセットで変更前後を比較し、回帰を探し、グループ別に結果を読む。
• 失敗を種類と発生段階で分類し、次の修正を決める。

はじめに

海外営業チームが使う社内翻訳アシスタントのプロンプトに、誰かが「より自然に訳すこと」という1行を加えました。チーム長は、結果を数件ざっと読み、文章がずっと滑らかになったと満足しました。1か月後、契約書類の確認で問題が明らかになりました。納品期限を表す表現が、「まで」と「から」で逆になった翻訳が何件も見つかり、いずれも修正前には正しく訳せていた種類の文でした。チーム長がざっと見た数件には、期限を表す表現が1つもありませんでした。チームは、自分たちに落ち度はないと感じていました。明らかによくなった結果を見ていたからです。問題は、何を見たかではなく、何を見なかったかでした。評価とは、まさに、その見なかった部分を見えるようにする仕組みです。OpenAIの評価のベストプラクティスも、「うまく動いているようだ」を評価戦略にすることを、代表的なアンチパターンに挙げています。

この章では、その感覚を数値に変える方法を扱います。成功基準を評価項目とルーブリックに移し、テストセットを作って改善用と確認用に分け、基準ごとに採点方法を選びます。続いて、LLM評価者の限界を管理し、変動性を測り、同じセットで変更前後を比較し、回帰を管理し、失敗を分類して次の修正を決める、という順序です。最後に、エージェントのように複数の段階を経るシステムの評価方法を見ます。「さらに深く」では、得点と現実の隔たり、人による採点の一貫性を扱います。

重要な概念

評価は同じ試験で受け直すこと

生徒が勉強法を変えた後、実力が伸びたかどうかを知るには、同じ難易度の試験でもう一度確かめる必要があります。毎回違う問題をいくつか解き、「よくできた気がする」と感じることは、評価ではありません。プロンプトも同じです。固定したテストセットで変更前後を比較して初めて、改善なのか回帰なのかがわかります。OpenAIのガイドは、プロンプトを変えたりモデルを更新したりするときは、評価スイートで動作を測定するよう勧めています。また、評価のベストプラクティスは、早い段階から頻繁に評価する「評価駆動開発」を勧めています。

成功基準を評価項目にする

Anthropicのドキュメントは、よい成功基準は、具体的であり（「よい性能」ではなく「正確な感情分類」）、測定可能で、達成可能で、業務に関連していなければならないと説明しています。また、大半のタスクでは、複数の基準を一緒に見る必要があると付け加えています。正確さだけでなく、一貫性、口調、個人情報の保護、コンテキストの活用、遅延、費用も基準になりえます。

項目化するときに、致命的な誤りも決めます。平均にまとめると、口調の得点が高い回答は金額を誤っても通るかもしれません。金額、日付、禁止された約束など、1つでも誤れば使えない項目は加重平均から分け、1つでも失敗なら不合格とします。

ルーブリックの書き方

第1章の成功基準を採点表に移したものが、ルーブリックです。よいルーブリックでは、項目ごとに、何を見れば合格なのかが明確です。Anthropicのドキュメントが挙げる例は、「回答の最初の文に会社名がなければならず、なければ自動的に不正解とする」というものです。

作成の原則は次のとおりです。

1. 観察可能な条件にする。 「親切」ではなく「謝罪表現と解決方法が両方ある」とする。
2. 尺度を狭くする。 正誤や1〜5点など判定が明確な出力にする。1〜100点ではむしろ曖昧になる。
3. 点数ごとに基準事例を付ける。 1〜5点の尺度なら、3点の実例と4点の実例を1つずつ添え、採点者が同じ点数の意味を共有できるようにする。
4. 1項目で1つだけ問う。 「正確で簡潔か」は2項目に分ける。
5. 必要なら複数のルーブリックを使う。 Anthropicは1基準でも全体を見るために複数が要る場合があるとしている。

テストセットを作る

Anthropicは評価設計に3原則を示しています。

1. タスクに合わせる。 実際の分布を反映し、境界事例も入れる。
2. 可能なら自動化する。 選択式、文字列一致、コード・LLM採点など、自動採点できる問題を設計する。
3. 量を優先する。 少数の問題を精密に人手で採点するより、多少評価シグナルが弱くても多数の問題を自動採点するほうがよい。

境界事例としては、無関係な入力や存在しない入力、長すぎる入力、不適切または有害なユーザー入力、人でも判断が分かれる曖昧な事例を入れます。OpenAIのドキュメントは、典型的な事例、境界事例、攻撃的な事例を一緒に入れるよう勧め、データの入手元として、運用データ、過去のデータ、専門家が作成したデータ、合成データなどを挙げています。また、開発中にログを残しておくと、よい評価事例を掘り起こせるとも付け加えています。

最初に用意する規模を、恐れる必要はありません。Anthropicのエージェント評価の記事は、実際の失敗から抽出した20〜50個の課題から始めるよう勧めています。同社のマルチエージェント調査システムも、実際の利用から抽出した20個前後の質問で評価を始めたと説明しています。小さく始め、失敗が起きるたびに増やします。モデルに基準事例を与え、テスト事例をさらに作らせることもできますが、合成事例は人が確認してから入れ、運用データは個人情報を削除するか、仮名に置き換えます。

改善用セットと確認用セットを分ける

同じセットを見ながらプロンプトを修正し続けると、プロンプトは、そのセットの事例だけにうまく合うように変わっていきます。試験問題を先に見て勉強した生徒の得点が、実力を表さないのと同じです。そのため、セットを2つに分けます。

第2章で見たように、few-shot例として使った入力は、2つのセットのどちらにも残しません。

3つの採点方法

Anthropicのドキュメントは、最も速く、信頼でき、規模を拡大できる方法を選ぶよう勧めています。実務では、基準ごとに異なる方法を使います。形式と数値はコードで、口調と論理はLLMで、そしてLLM評価者を校正するためのサンプルは人が採点します。

参照解答との文字の重なりによる指標（BLEU、ROUGEなど）の用途は限定的です。Anthropicは要約にROUGE-Lを挙げますが、OpenAIはBLEUなどの学術指標だけに頼ることをアンチパターンにしています。言い回しが異なるだけの適切な回答が低得点になり、数値が誤っていても参照解答に似た文が高得点になる場合があるからです。正解が1つでないタスクは、必須内容、許容する表現差、事実と好みを分けて基準を書きます。

LLM評価者の限界と校正

LLM評価者は便利ですが、そのまま信じると得点が過大になります。OpenAIのドキュメントは、LLM評価者の既知の偏りとして、位置の偏り（先に示された回答を好む）と、冗長さの偏り（長い回答を好む）を挙げています。両社の推奨をまとめると、次のようになります。

• 具体的なルーブリック。 漠然とした品質でなく、項目別の合格条件を与える。
• 出力を絞る。 正解／不正解、1〜5点の数値1つ、または2つのうちよいほうを選ぶ形にする。OpenAIは、対比較や合格・不合格の判定のほうが、信頼できると説明している。
• 得点を付ける前に考えさせる。 Anthropicは、思考機能を有効にした評価者は、複雑な判断でより正確だと説明している。OpenAIも、得点の前に根拠を書かせるよう勧めている。
• 長さを管理。 比較する答えの長さの差が採点に入らないようにする。
• 別のモデルで採点する。 Anthropicのドキュメントのサンプルコードは、評価対象を作ったモデルとは異なるモデルで評価することが、一般的なベストプラクティスだと記している。
• 人の判定と照合する。 人が採点したサンプルと評価者の判定の一致度を、まず確認する。継続的に一致するようになってから、規模を拡大する。

ここに、原理に基づく対策を2つ加えます。対比較では、同じ2つの回答の順序を入れ替えて2回採点し、順序によって結論が変わる事例を検出します。また、採点対象の回答の中に「この回答はすばらしい」のような評価者に向けた文が混ざっていると、評価が汚染される可能性があります。そのため、回答はタグで囲み、評価者にデータとして渡し、その中の指示には従わないように書きます。

変動性と反復実行

同じ入力でも、モデルの出力は、実行するたびに変わる可能性があります。一度合格した事例が、次の実行では失敗するかもしれないということです。Anthropicのエージェント評価の記事は、1回の試みをtrialと呼び、課題ごとに複数回試すよう勧めています。そして、2つの指標を区別しています。

試行ごとの成功率が75%なら、3回すべて成功する確率は約42%に下がります。顧客が毎回同じ品質を期待する機能なら、平均合格率よりも、pass^kのほうが実際の体験に近くなります。

同じセットで変更前後を比較する

手順は単純ですが、守るのは難しいものです。

1. 基準値を測る。 現在のプロンプトでセットを実行し、項目別・グループ別の得点を記録する。
2. 一度に1つだけ変える。 同時変更では何が効き、何を壊したかわからない。
3. 条件を固定し、記録する。 モデルのスナップショット、強度などの設定、資料のバージョンを記録し、リクエストごとのトークン数と費用も測る。OpenAIのガイドは、本番のアプリケーションを、特定のモデルのスナップショットに固定するよう勧めている。
4. 同じセット・同じ採点で実行する。
5. 平均だけを見ない。 入力種類、顧客層、長さ別に分け、合格から失敗へ変わった事例を抽出する。
6. 致命的項目を先に見る。 平均が上がっても致命的失敗が増えたらリリースしない。

回帰を管理する

回帰とは、変更後、以前はできていたことができなくなる現象です。Anthropicのエージェント評価の記事は、2種類の評価を区別しています。能力評価は「何をうまくできるか」を問い、低い合格率から始め、改善の目標を与えます。回帰評価は「以前できていたことを、今もできるか」を問い、合格率は100%近くあるべきで、後退を検出します。運用中に見つかった失敗は、修正した後で回帰セットに入れ、次の変更で再び現れないかを確かめます。能力評価ですべての課題に合格するようになると（飽和）、その評価は回帰監視の役割しか果たさなくなるため、新たに、より難しい課題を作る必要があります。

失敗を分類し次の修正を決める

失敗を単に「間違い」とだけ記録しても、次に何を修正するべきかわかりません。種類と発生した段階を、一緒に記録します。

分類後は頻度と深刻さを掛けて優先順位を決めます。まれな致命的失敗を、頻繁だが軽い失敗より先に直す場合もあります。次の修正は1つに絞り、正すべき事例と壊してはいけない事例を先に書きます。

エージェント評価：結果と記録

エージェントは、何度ものツール呼び出しを経て作業するため、最終的な回答だけを見ても、失敗の原因はわかりません。Anthropicのエージェント評価の記事は、課題（task、入力と成功基準が定められた1つの試験）、試行（trial、1回の実行）、採点器（grader）、記録（transcript、出力・ツール呼び出し・推論を含む全体の記録）、結果（outcome、試行後の環境の最終状態）を区別しています。予約エージェントが「予約した」と言うことと、予約記録が実際にデータベースに存在することは、異なります。採点は、結果に基づいて行います。

同じ記事は、経路ではなく、結果を採点するよう勧めています。エージェントが、設計者の予想しなかった正当な経路を見つけることもあるためです。記録と得点を数多く読んで初めて、採点器が適切に動作しているかがわかります。また、行動が起こるべき事例と、起こってはいけない事例を、両方入れる必要があります。検索すべき事例しかなければ、何でも検索するエージェントができてしまいます。OpenAIの評価のベストプラクティスも、ツールの選択、ツールの引数の正確さ、エージェント間の引き継ぎを、別々に評価するよう案内しています。ツール呼び出しの回数とトークン数は、結果とは別に、費用の指標として測ります。構造を変える前に、まず、どこで失敗するかを測定します。

さらに深く

得点が現実を表せないとき

評価の得点は上がるのに、利用者の不満は変わらないことがあります。原因は、たいてい3つのうちのどれかです。評価セットが実際の入力分布から離れた（新商品、新しい顧客層）か、ルーブリックが利用者の実際の不便を測っていないか、同じセットで長く修正し続けたために、そのセットに過学習したかです。対策は、運用上の指標（再問い合わせ率、相談員への引き継ぎ率、利用者の評価）を、定期的に評価の得点と並べて見ることです。両者が食い違えば、不満の事例を集めて評価セットに加え、ルーブリックに抜けている基準がないかを調べます。自動指標を人のフィードバックで校正しないことも、OpenAIのドキュメントが挙げるアンチパターンの1つです。

人の採点の一貫性

LLM評価者を人の判定で校正するには、まず人の判定が一貫していなければなりません。採点者ごとに同じ回答にまったく異なる点数を付けるなら、その点数では、何も校正できません。OpenAIのドキュメントは、人による評価を改善する方法として、点数の段階ごとの例を示すこと、合格・不合格の基準を設けること、複数の採点者の合意を使うことを勧めています。実務では、次のことも加えます。

1. 広い尺度を5段階か合否に狭める。
2. 項目を分け、一度に1つ判断させる。
3. 点数ごとに基準事例を付け、採点する前に、数件を一緒に採点してみて、基準を合わせる。
4. 一部を2人で重複採点して一致率を測る。偶然の一致も考慮する指標（Cohenのカッパなど）ならさらに厳密である。
5. 不一致例を集め、ルーブリックの文を直す。

実務の場面

はる薬局：平均が上がっても配布を止めた理由

薬局チェーン「はる薬局」は、処方情報に基づいて服薬案内文の下書きを作り、すべての案内文を薬剤師が最終確認してから、患者に渡しています。改善チームのオ薬剤師は、案内文が長すぎるという意見を聞き、プロンプトに「5行以内」を追加しようとしています。以前なら、数件を取り出して読んでみて、そのままリリースしたかもしれませんが、今回は、まず評価を準備しました。

1. セット作成。 過去3か月の実際の処方の種類の分布に合わせて80件を抽出し、薬が6種類以上ある処方、小児の処方、服用方法が特殊な処方など、境界事例20件を加えた。個人情報はすべて削除した。このうち30件は、確認用として別に固定した。
2. ルーブリック。 服用時刻・用量が処方と一致するか、注意事項が抜けていないかを致命的項目に定め、原文照合のコードで採点した。分量（5行以内）もコードで測った。わかりやすさは、生成に使っていない別のモデルに1〜5点で採点させ、点数ごとに基準事例を付けた。この評価者は、薬剤師2人が採点した20件と先に照合し、判定が一致することを確かめた。
3. 基準値と比較。 現在のプロンプトで基準値を測った後、「5行以内」という1点だけを変えた版を、同じセットで3回ずつ実行した。

結果は、全体の平均が上がりました。分量の合格率と、わかりやすさの得点が、両方ともよくなりました。しかし、グループ別に分けて見ると、薬が6種類以上ある処方で、注意事項の欠落が大きく増えていました。致命的項目の失敗です。5行に薬6種類を収めようとして、注意事項を削ってしまったのです。

チームの1人が、「平均が上がったのでリリースし、その種類だけ後で直そう」と言いました。オ薬剤師は断りました。致命的項目の失敗が増えた変更は、平均とは無関係にリリースしない、という基準をあらかじめ決めていたためです。オ薬剤師は、ルールを「基本は5行、薬が5種類を超える場合は薬ごとに1行ずつ増やし、注意事項は減らさない」に変え、もう一度測定しました。改善用セットで回帰がなくなったことを確かめた後、固定しておいた確認用30件で最終判断を行い、結果が同じだったためリリースしました。注意事項が抜けていた事例は、回帰セットに加えました。

そらねゲームズ：翻訳評価者を人に合わせる

モバイルゲーム会社「そらねゲームズ」は、ゲーム内のお知らせとアイテム説明を4言語に翻訳するために、モデルを使っています。翻訳の品質は、別のモデルが「優・並・不十分」の3段階で採点してきており、ほぼすべての翻訳が「優」を得ていました。ところが、現地の運営チームから問題が報告されました。一部の翻訳で、{item_name}、{count}のような変数のプレースホルダーが抜けたり、翻訳されたりし、ゲーム画面に崩れた文章が出ていました。アイテム説明の数値が変わった例もありました。評価者は、こうした翻訳にも「優」を付けていました。

ローカライズチーム長のイムさんは、評価の仕組みを作り直しました。まず、人の基準から確かめました。ネイティブの確認担当者3人に、同じ翻訳30件を採点してもらうと、同じ翻訳に「優」と「不十分」が同時に付くことが、少なくありませんでした。人同士でも、基準が異なっていたのです。

イムさんは、1つの総合得点を、4つの項目に分けました。

意味の正確さと自然さについては、確認担当者3人が一緒に基準事例を選び、20件を共同で採点しながら基準を合わせました。その後、50件を2人ずつ重複して採点し、一致率が十分に高くなったことを確かめてから、この人の判定とLLM評価者の判定を比較しました。最初は、評価者が、原文よりも長く説明した翻訳に、自然さの得点を甘く付ける傾向が見られました。イムさんは、評価者の指示に「原文にない説明が加わったら、意味の正確さは不合格」という基準と例を入れ、得点を付ける前に根拠を書かせました。翻訳結果はタグで囲み、評価者にデータとして渡しました。

「評価者をもっと高いモデルに変えればよいのでは」という提案もありました。イムさんは、その前にルーブリックから修正しました。プレースホルダーと数値の問題は、どのモデルで採点してもコードより正確にはできず、意味の正確さの問題は、基準が曖昧であることが原因だったためです。新しい仕組みで、評価者と人の判定の一致度が十分になって初めて、リリース前に毎回、自動で評価を実行し始めました。プレースホルダーの誤りは、リリース前にすべて検出され、失敗した翻訳は種類別に分類されて、次のプロンプト修正の根拠となりました。

間違えやすいポイント

• 数件を読んで判断する。 少数のサンプルでは、特定の入力グループでだけ起こる回帰を見落とします。固定されたセットが必要です。
• 平均が上がれば、改善だ。 グループ別に分けて見なければ、少数の種類での悪化を見落とします。致命的項目は、平均とは別に見ます。
• 同じモデルに採点させてもよい。 生成モデルと異なるモデルで採点するのが、一般的なベストプラクティスです。どちらの場合も、人の判定で校正する必要があります。
• 尺度を広げれば、精密になる。 1〜100点は、基準をさらに曖昧にします。正解／不正解や1〜5点のように、具体的な出力のほうが適しています。
• 同じセットで修正し続けても、得点は実態を表す。 そのセットに過学習します。確認用のセットを、別に取り分けて固定します。
• 一度合格すれば、安定している。 出力は、実行するたびに変わる可能性があります。一貫性が重要なら、複数回実行してみます。
• エージェントが成功したと言えば、成功だ。 採点は発言ではなく、環境の最終状態に基づいて行います。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Anthropic — Define success criteria and build evaluations：成功基準、設計原則、境界事例、採点比較、LLM採点の要点を読む。
• OpenAI — Evaluation best practices：手順、データ源、偏りと対策、アンチパターンを読む。
• OpenAI — Evals：構成要素と終了予定を確認する。
• Anthropic — Demystifying evals for AI agents：課題・試行・採点器・記録・結果、pass@kとpass^k、能力・回帰評価を読む。
• OpenAI — Prompt engineering：スナップショット固定と評価スイートの推奨を確認する。

セルフチェック

5-1. Anthropicが比較する3つの採点方法と、それぞれ長所・限界を1つずつ挙げてください。

5-2. 顧客案内文生成の評価項目を5つ書き、致命的項目を選んで理由を書いてください。

5-3. セットに入れる境界事例を4種類挙げ、運用ログを使う際の注意を1つ書いてください。

5-4. 毎回、同じ評価セット全体を見て失敗を直してきました。得点を信頼できなくなる理由と解決策を書いてください。

5-5. 判断を伴う項目を採点するLLM評価者を、新しく導入しようとしています。数千件の採点を任せる前に行う校正の手順を順番に書き、評価者への指示文に入れる対策を2つ付け加えてください。

5-6. 1試行の成功率80%の応対ボットがあります。同じ顧客依頼を2回とも成功させる確率を求め、平均合格率より実体験に近い場合を説明してください。

5-7. 先週の失敗事例60件を分類すると、根拠のない数値25件、形式崩れ5件、多条件の判断誤り18件、その他12件でした。次の修正1つを選ぶ手順と、頻度だけで選べない場合を1つ挙げてください。

実習課題