変更した構成と期待結果の変更を分ける

モデル名やプロンプトが一行変わるだけで、検索、ツールの引数、保留の判断に影響することがあります。同じモデルでも、索引、埋め込み、方針、ツールのスキーマ、採点器が変われば評価対象は変わります。モデルID、プロンプトと実行設定、検索構成、ツール、権限、評価データや採点基準の版を、現行と候補で記録します。

以前の結果を使う前に、どの構成で実行したか確かめます。リージョン、アカウント、機能フラグ、障害時の経路が違えば同じモデルで処理されたとは限りません。APIが実際のモデルIDを返すなら記録し、別名の裏にある版を確認できない場合はそれを明記します。出力が一致しなくても、判断基準と条件を説明できるようにします。

方針改定とモデル変更が重なるなら、維持すべき動作と新しい要件を分けます。旧方針で両方を比較する評価と、新方針への適合を試す評価を記録します。リスクに基づく回帰テストの範囲を併用すると、小さな変更でも影響の大きい経路を見つけられます。

影響に応じて再検証の範囲を選ぶ

一つの変更が複数のケース群に関わることがあります。回答を短くするだけでも期限や例外が省かれる場合があります。試験しなかった範囲と、既存の証拠を確認して再利用した範囲を分けます。

変更した構成想定される影響再評価と証拠
モデル・推論設定・出力長分類、必須情報、構造化出力、ツール選択同じ入力と引数、例外と保留を反復、遅延と費用
プロンプト・テンプレート指示の優先順位、言語・書式、承認状態の表現変更箇所に触れるケース、権限と顧客への表示
検索索引・分割・順位有効な文書、版、例外、出典必須根拠、制限資料の除外、モデル入力と出典
ツールスキーマ・方針・権限許可される操作と引数、再試行、処理結果拒否、送金や送信、外部への変更と復旧
採点器・正解表・分類基準点数の意味と比較可能性同じ回答を再採点、人の判定と不一致、基準の変更
提供終了・ルーティング変更旧版の利用可能性、代替構成の挙動提供状況を確認し、代替モデルや手動経路を試す

検索やツールが変わる場合も、同等の試験データで現行構成を動かします。本番の索引を使えない場合は承認済みの文書で権限と条件を再現します。副作用を確かめるために、実際の送金やメール送信をしない試験用テナントを使います。モデルの「送信した」という回答に加え、試験記録の宛先と内容を確認します。 Anthropic — Demystifying evals for AI agents[1]

サービスの仕組み

実行結果の信頼を保つ保守 — 変更に強い識別子で実行し、失敗原因を分類・修正して結果を再検証します。

同じケースを対にして比較する

Aを現行、Bを候補とし、質問、権限、注文状態、時刻、ツール応答、期待結果を揃えます。同じ分母で改善と退行を見られます。新方針が適用されるケースは変更目標に、維持すべき動作は回帰に置きます。異なる事例で点数だけを比べると、難易度と構成の差を区別しにくくなります。

開発中に繰り返し確認するケースとは別に、最終判断用のデータを確保します。同じ注文や条件を言い換えただけのデータは両方に混ざらないよう、資料源や業務パターンごとに点検します。過去に起きた重大な失敗も回帰の対象に残します。開発評価と独立した評価の区別はGoogleのモデルとシステムの安全評価[2]に説明があります。

応答が変動する場合は、影響の大きいケースを同じ条件で反復します。ケース数と実行数を分け、20件を一度ずつ実行し、そのうち4件をさらに3回ずつなら、20ケースで32回の実行です。重大な失敗が一度でも起きれば条件と結果を残します。未実行やタイムアウトを別に記録し、成功応答だけを分母に残さないようにします。

モデル、プロンプト、検索をまとめて変えるなら、まず全体として合格かを確認できます。原因を調べるときは現行モデルに候補プロンプトを適用するなど、変更を分けて実行します。新しいスキーマが必須なら比較できない組み合わせと、残った不確実性を記録します。

精度が上がっても公開を保留する架空事例

架空のサポート部門で、問い合わせの分類と、根拠となる方針がない場合の保留を試します。業務責任者は分類の改善と、根拠がない返金・約束を確定しないことを求めます。両方を同じ試験ケースで実行し、異なる業務の分母は分けます。

確認項目現行A候補B変化
分類に成功した件数、100ケース8894A成功・B失敗2件、A失敗・B成功8件、差し引き6件増
根拠不足で正しく保留、20ケース2016A成功・B失敗4件、100%から80%へ
根拠のない確定、同じ20ケース04候補で新たに発生し、公開基準を満たさない

分類が向上した種類を確認しても、根拠のない確約が4件あれば保留します。ケースごとに両モデルに渡した文書や方針を確認します。ツールの失敗を承認と解釈したなら、状態を受け渡す仕様を直します。分類だけで候補を使う場合は、根拠確認や確約が従来どおりかを改めて試します。

分類の6件差はその試験で得た結果です。実際の業務の分布、同じ注文や顧客から生まれた関連ケース、まれな重大事故を踏まえます。差が僅か、または評価者の意見が割れる場合は試験を補い、業務責任者が確認します。差の小ささだけで重大な失敗を容認しません。

シャドー試験と限定カナリアで得られる証拠は異なる

シャドー試験では本番相当の入力を候補に渡し、回答を顧客に伝えたり、実際の送金・送信・書き込みをしたりしません。実行しようとした操作と引数を記録し、ツールは隔離した代替に接続します。入力の個人情報を受け取る権限や保存条件も確認します。経路、形式、遅延を確認できても顧客が受け取った結果は観測されません。

限定カナリアでは実際のトラフィックの一部を候補に流します。会話の途中で構成が変わらないよう、同じ処理単位を決めます。影響を抑えられる種類から始め、件数、遅延、成果、有人引き継ぎを観測します。停止条件と担当者を決め、少数では見つからない失敗のために否定試験も維持します。 Google SRE — Canarying Releases[3]

供給元が旧モデルの提供を終えたり、別名の参照先を変えたりする場合があります。公式情報を確認し、実際に戻せるか試します。利用できなくなる場合は、検証済みの別構成、自動判定の停止、手動対応キューなどを用意します。すでに行った処理はロールバックできるデプロイの設計に沿って照合します。供給元の告知例にOpenAI APIのDeprecations[4]があります。

判定会議に持ち込む比較記録

記録する項目内容
変更目的と固定した条件改善目標、差分、共通の入力と方針、避けられない構成差
構成と基準の識別子モデル、プロンプト、検索、ツール、権限、データ、採点の版
試験範囲と分母ケース数、実行数、成功、失敗、未実行、判定不能
改善と退行同じケースIDの差分、必要な処置、公開の保留理由
運用確認と拡大シャドー・カナリアの範囲、業務結果、責任者、停止基準
復旧と代替検証済み構成と確認時刻、実行中の仕事の担当

公開後の点数は、質問、資料、判定基準の変化で動きます。稼働構成を観測期間や対象につなげ、新しい使われ方で起きた失敗を承認済みの回帰ケースにします。資料や評価基準の変更をモデルと同じ記録に残します。Google Cloudの生成AIのデプロイと運用[5]は継続的な評価と監視を扱います。