モデル評価設計

モデル評価は単一スコアの採点ではなく、用途ごとの失敗条件を評価データセット・評価指標・判定基準・比較対象・再現可能な実行記録へ固定し、リリース前評価と運用中評価を接続する設計として扱う。モデル更新、prompt/RAG/tool変更、judge変更、評価データ変更を同一の評価runとして混同しない。

評価runごとに MODEL_ID / MODEL_VERSION / SYSTEM_PROMPT_HASH / RETRIEVAL_CONFIG / TOOLSET_VERSION / DECODING_CONFIG / EVAL_DATASET_VERSION / METRIC_VERSION / JUDGE_MODEL_VERSION を記録する。モデルだけを比較するrunでは周辺条件を固定し、アプリ全体を比較するrunでは変更点を明示する。

本番ユースケースから代表例、境界例、既知事故、拒否すべき入力、長文・多言語・曖昧入力、tool/RAG依存例を分層して採る。平均値だけでなくslice別に結果を残す。ground truthが定義できる課題はreferenceを保持し、主観評価はrubricと判定例をversion管理する。

• deterministic/computation-based: exact match、F1、BLEU/ROUGE等、構造検証、schema遵守、tool call一致。
• model-based pointwise: groundedness、relevance、safety、instruction following等をrubricで採点。
• pairwise: candidateとbaselineを同一入力で比較し、勝敗・tie・理由を保存。
• human review: 高リスク、judge不一致、曖昧rubric、重大回帰を人手へ送る。
• operational: latency、cost、timeout、tool error、retrieval miss等を品質指標と別軸で測る。

judgeは真値ではない。judge model/version、rubric、prompt、sampling条件を固定し、可能なら人手判定との一致を校正する。candidate名や順序でbiasが生じ得るため、pairwiseでは順序入替やblind化を検討する。judge更新時は過去runとの直接比較可能性を再確認する。

全体平均だけでPASSさせない。critical sliceには個別thresholdを置き、重大失敗は件数上限またはゼロ許容とする。baseline比較では総合改善でも安全slice悪化を隠さない。threshold変更は評価結果を見た後に都合よく動かさず、変更理由と承認者を残す。

評価runは release candidate に紐付ける。PASSはこのdataset/version/rubric/thresholdに対するPASSであり、一般的安全性や万能性の証明ではない。モデル・prompt・RAG corpus・tool schema・policyの変更で評価の再実行条件を定義する。

offline evalで拾えない分布変化を本番sample、incident、user feedbackから回収し、失敗例をeval datasetへ昇格する。本番ログを無加工で評価セットへ入れず、PII/機密、重複、label品質、train/eval contaminationを確認する。

単一ベンチマーク総合点だけの採用、dataset変更後の旧runとの同列比較、judge更新後のmetric version据置、pairwise win rateだけで重大slice退行を見逃すこと、評価promptへの正解・内部情報漏えい、本番事故の未還流、モデル更新後の再評価欠落。

EVAL_RUN_ID / TARGET_SYSTEM_ID / MODEL_ID / MODEL_VERSION / EVAL_DATASET_ID / VERSION / DATASET_SLICE / METRIC_ID / VERSION / JUDGE_MODEL / VERSION / BASELINE_ID / RUN_CONFIG_HASH / PER_CASE_RESULT / SLICE_METRICS / AGGREGATE_METRICS / THRESHOLD_SET_VERSION / DECISION / FAILURE_CASE_LOCATOR / RUN_TIMESTAMP / OWNER / READBACK_STATUS。

Google CloudのGen AI evaluationは、固定datasetと複数metricをEvalTaskで評価し、experiment runとしてconfiguration/resultを追跡する設計を持つ。pointwise/pairwiseのmodel-based metric、computation-based metric、custom metricを分離できる。pairwise結果ではcandidate/baseline win rateとper-row choice/explanationを保持でき、評価結果はsummary metricsとper-row metricsとして取得できる。

providerの評価サービスは評価実行基盤であり、組織固有の合否基準を自動的に正当化しない。組織はユースケース、リスク、法務・安全要件に応じてdataset、slice、threshold、human escalationを別途定義する。モデル評価結果を本番品質の保証へ一般化しない。

organization固有のcritical slice、threshold、zero-tolerance条件。LLM judgeと人手判定の許容不一致率。closed model/backend更新時の再現性境界。production distribution driftに対するsampling頻度。domain別のtrain/eval contamination検出精度。UNKNOWNやjudge不一致を推測でPASSにしない。

モデル評価は、対象modelだけでなくdataset、slice、metric、judge、baseline、run configurationをversion固定して比較する。全体平均だけで合否を決めず、重大sliceの回帰を独立して確認する。providerの評価サービスは実行基盤であり、組織固有の安全性や適合性を自動的に証明するものではない。