Versioned 評価 datasets and reproducible PoV→本番環境 gates

CANDIDATE_ID: ORPHAN-RESCUE-EA734-20261019-C1 EVIDENCE_AS_OF: 2026-10-19 JST

PoV（概念実証）で一度高い評価値が出たことは、本番昇格の十分条件ではありません。再現可能な昇格判定には、評価データセット、対象モデル／エージェント、プロンプト・ツール・検索構成、評価器、判定閾値、実行環境を同じ評価単位として版管理し、同じ組合せを再実行できる必要があります。Microsoft Foundryは、評価用JSONL/CSVをプロジェクト内のversioned datasetとして登録し、複数のevaluation runやCI/CD品質ゲートで再利用する構成を公式に提供しています。一方、データセットを版管理しただけでは、モデル、プロンプト、ツール、検索インデックス、評価器や閾値まで固定されたことにはなりません。本番昇格の再現性は、これらをまとめた評価manifestと、runごとの結果・差分・承認記録で担保する設計が必要です。

最低限、次を一つの評価manifestに束ねます。

• dataset: dataset ID/name、version、内容hash、生成・抽出元、作成日時、利用範囲。
• target: model/deployment/agent ID、model revisionまたは取得可能なversion識別子、system/developer prompt、tool定義、retrieval/index/configurationの識別子。
• evaluator: evaluator名、version、model-based evaluatorならjudge model/deployment、rubric、column mapping、評価prompt、集約方法。
• gate: metricごとの閾値、必須ケース、重大失敗の即時reject条件、baselineとの比較規則。
• run: run ID、実行日時、SDK/API version、region、主要依存version、結果artifact locator。

このmanifest自体をimmutableな版として保存し、PoV時と本番昇格時の差分を機械的に比較できるようにします。

Microsoft Foundryの現行ドキュメントでは、JSONL/CSVをアップロードしてversioned datasetを作成し、複数のevaluation runで再利用する方法が推奨されています。安定した回帰セットを持つことで、モデルやプロンプトの変更前後を同じ問題集合で比較できます。また、production traceからcurated, versioned datasetを生成する経路も提供されています。

ただし、一つの固定データセットだけを長期に使うと、本番分布の変化、新しい失敗パターン、既知テストへの過適合を見逃します。したがって、少なくとも「固定回帰セット」と「直近本番traceから更新する代表セット」を分け、更新時には新versionとして追加し、旧versionを消さずに比較可能にします。synthetic datasetは事前検証や希少ケース補完には使えますが、本番分布の代表性を自動的に証明するものではありません。

評価結果はデータセットだけでなく評価器に依存します。Microsoft Foundryではdataset fieldをevaluatorへcolumn mappingして評価し、GoogleのGen AI evaluation系でもdatasetとmetric/evaluatorの組合せで評価を実行します。model-based judgeを使う場合、judge model、rubric、prompt、temperature等の実行条件が変わればスコアの意味も変わり得ます。

したがって、評価器変更を「同じテストの継続」と扱わず、evaluator revisionとして記録します。閾値を変更した場合も同様です。新評価器へ移行するときは、旧評価器と新評価器を同じ固定セットへ並走させ、判定差分を確認してから昇格ゲートを切り替えます。

推奨する昇格判定は次の順です。

• manifest completeness: dataset/target/evaluator/gate/runの識別子が揃っている。
• deterministic checks: schema、tool contract、必須出力、禁止出力、権限境界など機械判定可能な条件を先に評価する。
• quality/safety eval: 固定回帰セットと代表セットの双方で評価する。
• baseline comparison: 現行production baselineに対し、主要metricだけでなく重大ケース単位のregressionを確認する。
• failure review: 平均値で埋もれる重大失敗を個別に確認する。重大な権限逸脱、誤操作、機密漏えい等は平均scoreで相殺しない。
• approval/readback: 使用したmanifest、結果、差分、承認者、承認時刻を保存し、昇格対象が評価対象と同一であることをreadbackする。

昇格後も同じmanifest lineageを残し、incidentや品質劣化時に「どのdataset/evaluator/targetで通過したか」を追跡できるようにします。

LLM/agent評価は、同じ入力でも完全に同じ出力になるとは限りません。外部tool、検索index、provider-side model update、model-based judgeも変動要因です。そのため「再現可能」は常にbit-for-bit同一出力を意味しません。重要なのは、入力・対象・評価器・閾値・依存条件を識別可能にし、許容する確率的変動を含めて同じ判定手順を再実行できることです。

providerが内部model revisionを公開しない場合、その内部状態を推測で固定したことにしてはいけません。取得可能なmodel/deployment ID、実行日時、region、API/SDK version等を記録し、provider-side revisionはOPEN_UNKNOWNとして残します。

• dataset versionだけ固定し、prompt/tool/retrieval/evaluatorが無記録のため、再実行結果の差を説明できない。
• judge modelやrubricを変更したのに同じmetric系列として比較する。
• 平均scoreだけで昇格し、重大な少数ケースのregressionを見逃す。
• synthetic datasetだけで本番代表性を主張する。
• production traceから作ったdatasetに機密情報・個人情報・権限外データが混入する。
• evaluation targetと実際にdeployするartifact/configurationが異なる。
• thresholdを結果を見た後で変更し、過去runと同じgateとして扱う。

評価manifestには少なくとも dataset_ref, dataset_hash, target_ref, prompt/config refs, tool/schema refs, retrieval/index refs, evaluator refs, gate thresholds, run environment, result locator を持たせます。CI/CDではmanifestを入力として評価を起動し、結果artifactとmanifest hashを保存します。本番昇格処理は「評価PASS」だけでなく、deploy対象のhash/configが評価manifestのtargetと一致することを確認してから進めます。

評価datasetをproduction traceから作る場合は、sampling条件、除外条件、redaction/de-identification、label/ground-truth作成方法、アクセス権を記録します。評価データ自体も本番データと同じ情報管理対象になり得るため、保持期間と削除手順を定めます。

Microsoft Foundryがversioned datasetと再利用可能なevaluation runを提供することは、全評価依存関係を自動的にimmutable化することを意味しません。Googleの評価サービスもdatasetとmetricsを用いた反復評価を提供しますが、異なるprovider間でdataset/evaluator/run metadataの完全なportable manifestが標準化されていることは、今回確認した資料からは立証できません。また、model-based evaluatorのscoreはjudge/model/rubricに依存し、絶対的な品質保証ではありません。

• provider横断で互換な評価manifestの標準仕様。
• providerが公開しない内部model revisionを含む完全な再現性。
• model-based evaluatorのversion driftをprovider横断で同一尺度へ補正する方法。
• 組織・用途ごとの妥当な昇格閾値と重大失敗許容値。
• production trace由来datasetの代表性を保証する一般的手法。

「versioned evaluation datasetを使えば本番品質が保証される」とは書きません。安全な表現は、「評価データ、対象構成、評価器、閾値、実行条件を版管理し、同じ判定手順を再実行できる状態を作ることで、PoVから本番昇格までの判断を追跡・比較しやすくする」です。再現性は評価手続の再実行可能性を指し、provider内部状態や確率的出力の完全同一を保証しません。

• Microsoft Learn, “Evaluate existing datasets with Microsoft Foundry SDK”, accessed 2026-10-19. Versioned JSONL/CSV datasets are reusable across evaluation runs and recommended for production testing / CI/CD workflows: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/cloud-evaluation-datasets
• Microsoft Learn, “Evaluation datasets in Microsoft Foundry”, accessed 2026-10-19. Reusable stable datasets support regression testing, CI/CD quality gates, and comparison across runs: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/evaluation-datasets
• Microsoft Learn, “Convert agent traces into evaluation datasets”, accessed 2026-10-19. Production traces can be converted into curated, versioned evaluation datasets: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/traces-to-dataset
• Microsoft Learn, “Introduction to cloud evaluation with Microsoft Foundry SDK”, accessed 2026-10-19. Evaluation binds dataset fields to evaluators and supports reusable dataset name/version inputs: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/cloud-evaluation
• Google Cloud, “Gen AI evaluation service overview / Run an evaluation”, accessed 2026-10-19. Evaluation runs combine evaluation datasets with metrics/evaluators; large-scale runs can persist inference/evaluation data to Cloud Storage: https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview and https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/run-evaluation