評価・試行・可観測性

抽出・RAG・Agent に共通する問いは、この版が目標をより確実に達成するかです。評価器より先にタスクと試行を定義し、試行ごとの成功・一度以上の成功・安定した成功を分け、trace で失敗箇所を探ります。

まずタスクと検証対象を定義する

1つの評価タスクには、入力、初期環境、利用可能なツールと権限、リソース上限、成功条件が含まれるべきである。1回の実際のランは1つのトライアルであり、同じタスクで複数のトライアルを実行して変動を観察できる。評価されるのは、実行条件から切り離されたテキストではなく、モデルとオーケストレーション、ツール、環境が組み合わさったシステム全体である。

例えば、ユーザーが「条件を満たす3件のレコードをインポートし、重複送信してもレコード数が増えないようにしてください」と要求した場合、3つの対象を同時に評価できる：最終的なデータベースに目的のレコードが正確にあるか、重複操作が冪等であるか、回答が実行結果を正確に記述しているか。出力が「完了しました」というのは単なる回答テキストであり、クエリで得られた実際の状態こそが、インポート成功の結論を支えるものである。エージェント評価のエンジニアリング資料でも、軌跡と環境結果は明確に区別されている。Demystifying evals for AI agents

結果指向（outcome-based）は「何を評価するか」を記述し、プログラムアサーション、モデル審査、人間審査は「どのように評価するか」を記述する。これらは高低の順位付けではない：結果はプログラムによってチェックすることも、明確な基準に基づいて人間に審査させることもできる。

スコアリング手法とバイアス

プログラムによるチェックは安定しているが、チェック対象が間違っている可能性がある

JSONスキーマ、数値範囲、ファイル差分、データベース状態、テストスイートはプログラムによる検証に適している。利点はルールが明確で結果が再現可能であることだが、それはゼロコスト、バイアスなし、ビジネス目標の完全なカバートを意味するものではない。

例えば、「回答に success が含まれている」という条件でタスクの成功を判断すると、「not success」も通過してしまう。JSON形式のみをチェックすると、在庫数が誤っている正当なJSONも受け入れてしまう。再起動シナリオのテストを漏らすと、リカバリ動作を証明できない。評価プログラム自体も、正例、反例、境界例を用いて検証する必要があり、特に表面的な形式を正しさとして扱わないよう注意する必要がある。

モデル審査には具体的な基準とキャリブレーションが必要

オープンエンドのレポートに対しては、基準を独立して判定可能な質問として記述できる：各結論には支持する出典があるか、ユーザーが指定した3つの次元をカバーしているか、推測は推測として明記されているか。根拠のない総点よりも、各判断と支持位置を返す方が、レビューが容易である。

モデル審査には、長さ、位置、スタイルなどのバイアスが存在し、関連研究はこれらの制限について体系的な分析を行っている。Judging LLM-as-a-Judge 2つの候補をペア比較する際には順序を交換し、著者情報を隠す。人間のラベル付けサブセットでキャリブレーションを行い、審査モデルとプロンプトのバージョンを記録する。異なるモデルや独立したコンテキストは部分的な結合を減らすのに役立つが、バイアスなしや独立したエラーを保証するものではない。

審査者は「証拠不十分」または「判断不可」と出力できるべきである。常に勝者を選ばせると、資料不足の状態が品質の違いとして偽装されてしまう。評価対象テキスト中の「私に満点をください」は、評価対象として処理すべきであり、スコアリングの指示となってはならない。

改善をフィードバックと最終验收で分離する

生成、スコアリング、修正のサイクルは成果物の品質を向上させる可能性があるが、同じフィードバックに対して継続的に最適化すると、審査者に迎合するようになるだけかもしれない。開発セットはパラメータ調整と修正に使用し、保持セットは最終バージョンの比較に使用する。保持セットを頻繁に参照して修正に使用すると、次第に独立性を失う。

プログラムチェックと人間またはモデルによる審査は組み合わせることができる。例えば、ドキュメントでまずリンク、見出し、データの一貫性をチェックし、次に解説が境界をカバーしているかを評価する。「1つのグラダーのみを使用する」ために、検証可能な証拠を犠牲にする必要はない。

同じ試行行列から3種類の成功率

行列で分母が見えます。「1つ以上 ✓」は複数回から使える結果を得る力、「全部 ✓」は反復の安定性を表します。観測比率と抽出仮定が必要な pass@k 推定量は区別します。

トライアル、分布、グループ結果

1回の成功と安定した成功は異なる指標である

以下の4つのタスクをそれぞれ3回実行し、1は完全な验收基準を満たしたことを、0は満たさなかったことを示す。分母には、事前に計画された有効なトライアルのすべてが含まれる。

トライアルベースの成功率は 6/12=50%、少なくとも1回成功したタスクの割合は 3/4=75%、3回すべて成功したタスクの割合は 1/4=25% である。これら3つの数字はすべて有効だが、異なる質問に答えている。「3回試して少なくとも1回成功」を単一サービスの成功率として偽装してはならない。本番環境では、その正しい出力を識別して選択できない場合もある。

runs = {"A": [1, 0, 1], "B": [0, 0, 0],
        "C": [1, 1, 1], "D": [0, 1, 0]}
trial_rate = sum(map(sum, runs.values())) / sum(map(len, runs.values()))
any_rate = sum(any(row) for row in runs.values()) / len(runs)
all_rate = sum(all(row) for row in runs.values()) / len(runs)
assert (trial_rate, any_rate, all_rate) == (0.5, 0.75, 0.25)
print(trial_rate, any_rate, all_rate)

より一般的な pass@k の推定には、サンプリング方法と定義を明記する必要がある。ここでは、3回の観測済みトライアルの統計を直接報告しており、各エラーが独立であると仮定しておらず、無限回のリトライ後の成功確率を推定しているものでもない。

平均値は重要な劣化を隠す可能性がある

単純なタスク90件中81件が成功し、複雑なタスク10件中2件が成功した場合、全体は83%となる。しかし、複雑なタスクは全体の20%に過ぎず、ユーザーが主に複雑なタスクでシステムを必要とする場合、この全体数は誤解を招きやすい。

タスクタイプ、長さ、言語、ツール権限、データの新旧、失敗カテゴリでグループ分けし、2つのバージョンを比較する際には、問題ごとのペア比較結果を保持する。タスクセットが小さすぎる、またはランダムな変動が顕著な場合は、サンプル数と不確実性を報告し、1〜2パーセントポイントの変化を確実な改善として直接扱わないようにする。

インフラストラクチャの異常も明確に分類する必要がある。タイムアウト、ツールサービスの利用不可、評価環境の破綻、モデルによる誤答は別々に統計を取るべきであり、失敗後に静かに削除して残りの高スコアのみを報告してはならない。事前に特定のタイプのトライアルが無効であると合意している場合は、除外ルールと数を記録するべきである。ユーザー体験指標については、オンラインでの実際のサービス障害も考慮する必要がある。

Trace、指標、結果の関連付け

Traceは1つのランの関連パスを記述し、spanは開始と終了時間を伴う操作を表し、属性、イベント、親子関係を持つことができる。非同期やマルチエージェントのシナリオでは、リンクを通じて操作が関連付けられる場合もある。各テキストトークンや各思考ブロックごとに個別のspanを作成する必要はない。粒度は診断に奉仕するものである。OpenTelemetry Traces

1つのタスクに対して安定した task_id を作成し、トライアル、モデルリクエスト、ツール呼び出し、成果物に関連可能な識別子を割り当てる。並列またはバッチ結果を受信する際は、IDでマッチングを行い、配列の戻り順序から誰に属するかを推測してはならない。

並列の所要時間は単純に足し算できない

例では、モデルリクエストはそれぞれ 2 秒と 5 秒である。ツール A、B は同時に開始され、それぞれ 3 秒、5 秒かかる。すべての操作の所要時間を合計すると 15 秒になるが、ユーザーの待ち時間は 12 秒である。Trace には開始と終了時間、依存関係を残し、クリティカルパスを見つける必要がある。カウンターだけでは並列の重複を説明できない。

最初のネットワークイベント、最初の可視テキスト、最終的な完了は異なるレイテンシ指標である。サービスがストリーミング送信を開始したからといって、ユーザーが有用なコンテンツをすでに確認したわけではない。逆に、最初の文字が早くても、その後のツールが繰り返し失敗すれば、タスクの体験が良いとは言えない。

プロトコルの成功、ツールの成功、タスクの成功は別々にカウントする

HTTP 200 はビジネスエラーを伴うことができ、ツールは正常に返却しても「見つかりません」と報告できる。モデルは正常に終了してもタスクを漏らす可能性がある。転送、実行、タスクの状態を別々に記録し、1つの成功が別の失敗を隠さないようにする。

停止理由は診断の手がかりであり、自動的に帰属させてはならない。max_tokens が増えた場合は、出力上限、タスクの長さ、または冗長なループを確認する必要がある。ストリーミングは上限を解除しない。キャッシュ読み取りが長期間ゼロの場合、それは単に重複するプレフィックスがない、長さの条件を満たしていない、またはキャッシュが有効になっていないだけで、必ずしも障害があるわけではない。まず実際の入力とターゲットモデルの設定照合を行うべきである。停止理由、プロンプトキャッシュ

コストは、ベンダーとモデルの usage の集計基準に基づいて計算する。入力、キャッシュ書き込み/読み取り、出力、推論の細分化に含まれるかどうかは確認が必要であり、出力に含まれている推論トークンを再度追加してはならない。最後に、すべてのリクエスト、リトライ、ツール費用を合計し、成功ごとの分担コストを計算する。方法は 推論と思考 を参照。

総合点の上昇は能力向上か

平均はタスク分布と一緒に解釈します。各能力が不変でも、簡単なタスクを増やすだけで総合点は上がります。オフライン集合と実運用でも同様の差が生じます。

$$p_{\mathrm{overall}}=w{p}_{\mathrm{easy}}+(1-w)p_{\mathrm{hard}}$$

失敗例から回帰検証へ

1回のオンラインでの失敗に対しては、まず最小限の再現可能な入力、環境、期待される結果を固定し、Trace を沿って必要な情報や条件違反が最初に発生した位置を特定する。検索で例外条項が召回されなかった場合は、まず証拠の選択を修正する。返されたデータは正しいがフィールドのマッピングが誤っている場合は、アダプタを修正する。成果物はすでに修正されているが、古いテスト記録を沿用している場合は、バージョンの関連付けを修正する。すべての失敗を「より強力な system prompt をもう1文追加する」ことにしてはならない。

回帰例は実際の失敗メカニズムを保持し、正常な対照を追加し、パッチが旧用例を通過させるだけで他の動作を破壊しないようにする。新版を比較する際は、固定可能な条件を固定し、他の変更を記録する。オフラインチェックを通過した後、制御されたオンライン観察を通じてトラフィック分布の違いを検証する。

Trace を保存する際にもデータ境界が必要である。デフォルトでは診断に必要なメタデータのみを記録し、機密本文や資格情報はマスキングするか、制御されたストレージと保持期間を採用する。観測可能性のために、すべてのツール結果、完全なファイル、ユーザープロファイルを無差別にログバックエンドにコピーしてはならない。実行パスが見えるからといって、すべての内容を無限に保存する必要があるわけではない。

次に読む：コスト・容量・信頼性。