最初に正解表を確認する

LLMによる評価器は、指示に沿っているか、説明が分かりやすいかなどを多数確認するときに役立ちます。処理の完了は実システムの記録で確認でき、曖昧な規程は業務専門家が先に判断します。点数が何の失敗を検出できるかを確かめます。

事例の時点と利用者の条件に沿って、何が正しい結果か説明できるようにします。方針やAPI契約、承認済みの判断に識別子と版を付け、有効日と例外を記録します。正解表には必須要素、許容する表現や操作、禁止事項、根拠不足で保留する条件も書けます。過去と現在のどちらの正解も扱うなら、事例の前提に日付を入れます。

架空の交換規程で、正解表に一律七日とあったとします。ある会員区分には商品条件を満たせば十四日とする承認済み規程があります。両モデルが一般条項を引用し七日と答え、評価器が合格としました。業務担当者が版、会員区分と商品の条件を確認し、正解表を修正します。同じ根拠を使った事例を特定し、旧モデルと候補を修正した同じ基準で評価します。

根拠が矛盾したり例外が未決定だったりすれば事例は判定不能にします。根拠不足で人に引き継ぐことが承認済みの業務要件なら、分からないと答えるのは適切な動作です。正解を定義できない事例と、製品が適切に保留する事例を分けます。要件とテストのトレーサビリティを使って根拠と変更を結びつけられます。

判定に合う評価方法を選ぶ

説明が良くても取引は失敗している場合があります。返金を伴うなら、応答品質とともに承認、金額、決済台帳を確認します。データベースや試験ツールで確定できることはコードで判定し、説明の自然さや十分さは根拠を示してモデルに任せられます。影響が大きい違反は他の点数と合算せず、独立した失敗条件にできます。Anthropicはコード、モデル、人による評価の役割と、人によるモデル評価の調整を説明しています。Anthropicのエージェント評価資料[1]

モデル、プロンプト、採点基準、参照資料、引数、結果パーサーの版と実行時刻を記録します。項目別の判定と根拠を保存します。採点時に取得する資料は版を固定し、何をモデルに渡したか残します。呼び出しやパースの失敗は製品の失敗と区別し、再実行を元の実行に結びつけます。成功した実行だけ残すと比較が変わります。

採点する回答と評価指示の境界を構造化し、回答に指示らしい内容が含まれた場合も試験します。評価器が扱えるツールや資料を必要な範囲に絞ります。人が確認するときは、評価器の判定理由と実際の回答にある根拠を照合します。期待結果の確認にはAI生成テストケースのレビューも参考になります。

回答元を伏せ、順序を入れ替える

比較時は提供元やモデル名など、判定に不要な情報を伏せます。同じ業務の二つの回答を同じ基準で評価し、次に順序を入れ替えます。内部記録に回答の識別子を残し、同点と順序による不一致を分けます。Zhengらは2023年にMT-Benchなどの条件で提示順と冗長さの影響を調べ、順序を入れ替える方法を提案しました。自分の回答を選びやすい可能性は示しましたが、限定された標本で確定していません。Zhengらの原論文[2]

同じ承認済みの例外を含む架空の回答二つを考えます。一方は一段落、もう一方は条件を四回繰り返します。点数が違えば長さと必須の内容を別に見ます。並べ替えても常に最初が勝つなら優劣を保留します。同じ回答を二回選んでも、専門家が重要な規程の欠落を見つければ理由を調べます。順序や反復の試験は評価の安定性を示し、正しさは根拠で確かめます。

書式をそろえた試験では形式の影響を調べられます。編集によって意味も変わると点数差の原因を特定しにくくなります。製品比較には元の回答を使い、偏りの試験には事実を保持した別版にIDを付けます。自己選好が疑われるときは出所を伏せ、複数の作成元の回答を均衡させ、専門家も同じ基準で評価します。

サービスの仕組み

正常系の先にある例外も検証 — 実装された動作から要件を復元し、入力、権限、外部呼出しの例外経路を実行して確認します。

評価体制の監査表

品質報告を承認する前に、評価担当者に次の証拠を求めます。総合点とともに標本数、判定不能の件数、誤って合格にした重大な失敗を確認します。

監査する項目確認する問い証拠と対応
業務の正解承認済みの方針と状態が事例に合うか根拠ID、有効日、判定者、誤った参照を使う事例一覧
採点基準必須条件と表現品質を独立に見られるか条件ごとの合否例と重大失敗の定義
再現性同じモデルとプロンプトを使ったか実行ごとの版、返り値、根拠、呼び出し失敗
順序・長さ・出所同じ内容が位置や長さで優先されないか並べ替え、長さの試験、匿名化、不一致
人との一致重要な誤りを見逃していないか業務別の照合標本、合意結果、重大な誤合格
データの独立性調整例やデータが混ざっていないかアクセス履歴、資料の版、完全一致・類似例の点検、交換判断
結果解釈判定と測定を再現できるか合格、失敗、判定不能の分母、除外、残存リスクと担当者

架空の照合データ100件で、専門家が20件を失敗と判定したとします。評価器は15件を失敗とし、5件を合格にしました。専門家が合格にした80件のうち、78件は合格、2件は失敗としました。総合一致は93件で93%です。一方、専門家が失敗とした20件中5件を見逃したので、この集合での誤合格率は25%です。無断の支払いなど重大な例が一件でもあれば、その業務での採用を保留します。

人の判定も割れます。二人の業務専門家が独立に判定と根拠を記録し、意見が割れた場合は基準や正解を確定する担当が結論と相違を残します。自動化が難しい事例の人手コストも見込みます。複数の評価器が同じ資料や曖昧な基準を使えば、同じ誤りを起こします。多数決の結果は人の判定とも照合します。

判定が割れた事例の記録票

保留事例はIDと直接の観測に基づいて分析します。評価器、正解表、データ、製品のどれを直すか決めてから、影響する結果を調べます。

記録項目例または記録方法
事例ID、業務、根拠の版交換E-104、会員区分、方針3.2、適用時点
各回答と業務状態元の出力の参照、根拠、実際の承認、人の介入
人の初期判定と合意役割、根拠、不一致、最終判定者と日付
評価器の判定両方の順序、項目別の値と理由、応答の妥当性
原因と修正対象製品、正解表、曖昧な基準、順序や長さ、評価システム、保留
再評価範囲影響する標本、基準、版、担当者、旧版・候補の再実行条件

開発・最終評価・回帰データに異なる役割を持たせる

開発用事例はプロンプトや検索設定の調整に使います。正解を繰り返し参照した結果は新規業務の能力推定に使いにくくなります。最終評価用はリリース判断まで独立して保存します。結果を参照した調整を重ねるなら開発用と明記し、別の評価事例を確保します。回帰用は既知の失敗の再発を確認し、開発チームが期待結果を知っていても機能します。Googleの責任あるAI評価資料[3]とAnthropicのエージェント評価[1]では開発、独立検証、回帰試験に異なる役割があります。

文章が違っても同じ問い合わせを要約した入力が複数の評価集合に入ることがあります。出所、顧客、資料、シナリオ群で分け、正規化した文章やハッシュで完全重複を、類似度や標本確認で言い換えを調べます。合成データにも原典を記録します。公開ベンチマークの研究では学習データとの重複の可能性を調べています。提供元の学習データをすべて見られない場合は、確認した範囲と限界を残し、独立した業務事例を追加します。Dengらのベンチマーク汚染研究[4]、NISTの生成AIプロファイル[5]

新しいモデルの点数が上がったときは評価器と根拠が共通かを確認します。変更があれば、固定した同じ回答群を旧条件と新条件で測って原因を特定します。最終評価用事例が使われたり重複したりした場合は結果を訂正し、予備の事例を使います。改善した失敗の種類と、引き続き人の判定が必要な範囲を標本とともに報告します。