Copilot StudioエージェントのAIモデル移行を実行し検証する

以下のセクションは、積極的なアップグレードであれ退職対応であれ、すべてのモデル変更に適用されます。 まずゲートを定義し、現在のモデルからベースラインを取得し、その後フェーズを進めます。

移行受容ゲートの定義

候補モデルを評価する前に受容基準を定義し、 評価 が単なるスコアの集合ではなく決定を生み出せるようにしましょう。 次の内容を含めます。

  • 最低合格率
  • ビジネスクリティカルなシナリオにおける必須合格率
  • 集計スコアに関係なく移行を妨げる重大な障害
  • 許容されるレイテンシおよび信頼性の分散
  • 安全性、コンプライアンス、地域処理承認
  • 許容される消費量またはコストへの影響
  • 所有者と許可承認者の承認が必要です

同じエージェント構成、テストデータ、テストセット、ユーザープロファイル、環境の前提を用いて、現在モデルと候補モデルを比較します。 平均スコアに頼るのではなく、個別の回帰分析を調査しましょう。

モデルの出力は確率的です。 変動が意思決定に影響を与える場合は、重要なシナリオを複数回実行しましょう。

再利用可能な評価基準を確立する

モデルを変更する前に、エージェントのビジネスクリティカルおよび高頻度シナリオを表すテストセットを作成しましょう。 テストセットを現在の本番モデルと比較してベースラインを確立します。

テストチャットとエージェント評価の両方を活用しましょう:

利用可能なテスト方法は エージェントのハーネスによって異なるため、テストセットを設計する前に必ず確認してください。 詳細は 「あなたのエージェントが支持する検査方法を確認する」をご覧ください。

エージェント全体の挙動を評価する

現在のモデルと合流率が似ているからといって、代替モデルを承認しないでください。

以下の分野をカバーしてください。 それぞれの挙動はモデルが変わると頻繁に変化するため、ある領域を省略したテストセットでは回帰を検出できません。

評価領域 モデルチェンジが壊すもの チェック方法
回答の質 エージェントが最も頻繁に受ける質問の関連性、完全性、正確さ、明確さ、一貫性。 一般的な品質
地に足がつきと知識 モデルは設定された知識ソースではなく訓練データから回答したり、引用を削除したり、不完全または矛盾するソースを異なる方法で扱ったりします。 一般的な品質
棄権 モデルは、問題範囲外の質問に答え、減少やエスカレーションを進めるのではありません。 一般的な品質、または「 応答 済み」と 「拒否 済み」ラベル付きのカスタム
次の手順 モデルが確実に従っていた指示、例えばエスカレーションルール、境界線、禁止行動、または必須の免責事項などは省略されます。 必要なフレーズのキーワードマッチ、または命令固有のラベルを持つカスタム
固定値と出力フォーマット 電話番号、コード、IDなどの正確な値は言い換えられたり、発明されたり、出力の形状が変化し、下流のパーサやチャネル統合を壊したりします。 正確な一致、または必要なフォーマットのキーワードマッチ
工具の選択と拘束 モデルは別のツールを選択したり、呼び出さない、またはツールが不要なときにツールを呼び出したりします。 期待されるツールやトピックを使い、活動マップのレビューも含めて
ツール入力とシーケンス パラメータの抽出、フォーマット、デフォルト設定が異なったり、マルチツールタスクのステップが順序変更、統合、削除されたりします。 すべての工具を使った工具の使用と、全体的な品質
確認と故障処理 モデルは、結果的な行動の前に確認を求めるのをやめたり、ツールエラーが報告されるのではなく異なる形で表面化されるのをやめます。 確認ラベル付きのカスタムで、予想されるエラー言語のキーワードマッチも可能です
マルチターン挙動 前のターンの文脈が失われたり再解釈されたり、明確化、トピック変更、回復の扱い方が異なります。 会話テストセットにおける一般的な品質
混沌と対立的な入力 誤字や断片、意図の不明瞭さの扱いが弱い、またはプロンプト注入やロールオーバーライドの試みに対する異なる応答。 一般的な品質に加え、カスタムラベル( 拒否 ラベル)と コンプリエイド(コンプリメイド )も含まれます
安全性とコンプライアンス 有害なコンテンツの取り扱い、データアクセス、権限、地域処理、責任あるAI要件。 カスタムラベルと責任あるAIレビュー
遅延と信頼性 応答時間、タイムアウト、変動性、失敗コール、そして代表的な条件下での再試行。 評価では報告されていません。 テストチャットや本番監視で測定しましょう。
消費とコスト 代表的なシナリオにおけるCopilotクレジット消費やその他のモデル関連コスト。 評価では報告されていません。 容量と消費の報告で測定してください。
言語とチャンネル 対応言語、ユーザープロファイル、デプロイチャネル間の品質と挙動。 重要な言語、ユーザープロファイル、チャネルごとにテストセットを実行してください

特に指示追従とレイテンシーに注意してください。 候補モデルは回答の質を向上させることがありますが、応答が遅くなったり、ツール選択の挙動が変わったり、以前のモデルで信頼できた指示の失敗を招いたりします。

担当のエージェントが対応している検査方法を確認してください

エージェントが利用できる検査方法は、そのハーネスによって異なります。

詳細については、以下を参照してください。

テストセットの構築と保守

  • まずはビジネスに重要なハッピーパスや大量のリクエストをカバーし、その後に難しいケースを扱います:エッジケース、敵対的な入力、拒否またはエスカレーションすべきリクエスト、ツールの故障、長時間の会話、多言語リクエストなどです。
  • 実際の交通から始めましょう。 分析のテーマや録音された会話は、作り話よりも代表的なテストケースを生み出します。
  • ポリッシュよりもカバレッジを重視しましょう。 不完全なケースの大きなセットは、完璧に表現された少数のケースよりも多くの回帰を検出します。
  • まず現在のモデルを評価し、その後候補者を評価します。 移行が安全かどうかを示すのは、絶対的な数字ではなく比較です。
  • エージェントのセットはソース管理に残し、モデル変更ごとに変更せずに再実行してください。
  • セットをリスクエリアごとに分けてください。 標準ハーネスで駆動されるテストセットは最大100のテストケースを保持するため、知識の正確性、ツールの挙動、安全に敏感なシナリオごとに別々のセットを使用しましょう。
  • 結果をエクスポートします。 評価結果は89日間保持されるため、移行時の各モデルのスコアをCSVにエクスポートしてください。
  • 本番のインシデントやユーザーフィードバックを新しい回帰テストに変換します。

エージェント 評価の設計と運用化について詳しく学びましょう。

Note

エージェント評価はAIの倫理や安全性の問題ではなく、正確性やパフォーマンスを測定します。 エージェントはすべてのテストケースに合格しても、不適切な回答を出すことがあります。 評価と並行して 責任あるAIレビュー とコンテンツ安全フィルターを活用しましょう。

定期的な評価の自動化

Copilot StudioはPower Platform APIを通じて評価を実行することをサポートしているため、モデル検証をリリースワークフローや継続的統合パイプラインに統合できます。 大規模なエージェントエステートにとっては、自動化が繰り返しの候補者テストを手動ではなく持続可能にします。 Power Platform APIによる評価の自動化について詳しく学びましょう。

モデル変更によって影響を受けるエージェントのアーティファクトを更新する

モデルの変更がモデル設定だけに影響することは稀です。 該当するプロバイダーのガイダンスを管理するエージェントのアーティファクトに翻訳し、すべての変更を評価ベースラインと照らして検証します。 再検査されていない修復は推測に過ぎません。

アーティファクト 典型的な変化
エージェントの指示 暗黙の期待を明示し、前モデルで書かれた回避策を削除し、境界やエスカレーションルール、禁止された行動を明確に再定めし、矛盾する指示を解決し、エージェントがどれだけ独立した行動を取るべきかを調整します。
トピック命令とノード命令 トピックレベルで同じ処理を適用し、生成回答ノードが期待通りに動作するかを確認しましょう。
ツールおよびアクションの説明 明瞭さを高めるように書き直してください。 この記述はモデルがツールを呼び出すかどうか、いつ呼び出すかを判断するために読み取るものであり、曖昧な記述は過剰呼びと不足呼びの両方を引き起こします。
入力および出力パラメータの記述 パラメータ生成が正しく保たれるように、フォーマット、単位、例、必要または任意の意味論を厳格に整えましょう。
ナレッジ ソースの構成 出典の選択、スコープ、接地指示を再確認し、引用の挙動を確認してください。
レスポンス書式指示 必要な構造、長さ、免責事項、正確な値を明示的に再記してください。新しいモデルではデフォルトの冗長さが変わるためです。
確認および安全ゲート 具体的な確認要件を明確にしてから、その後の行動を取ること。
下流の消費者 Power Automateフロー、適応カード、チャネル統合、エージェント出力を読み取るパーサーを更新してください。
テストセット自体 移行中に発見された新たな故障パターンを加えましょう。

移行フェーズ

以下のフェーズでは、前のセクションを実行順に並べました。 単一エージェントのモデル変更の作業計画として活用しましょう。その変更が積極的であれ退職によるものであれ。

フェーズ0:準備

  1. 候補モデルが 前提 条件(一般利用可能またはデフォルト)、地域内で利用可能、クロスジオポスチャー、管理者対応、エージェントの目的に合った適切な使用カテゴリに適合していることを確認しましょう。
  2. モデル提供者のアップグレードガイダンスを読み 、指示や工具の変更点に注意してください。
  3. 在庫、記録環境、所有者、重要度から影響を受けたエージェントを特定します。
  4. エージェントのハーネスがどの評価テスト方法をサポートしているか確認してください。
  5. 移行受理ゲートを定義し承認します。

フェーズ1:現行モデルの基準化

  1. 回帰テストセットを構築したり更新したりして、ビジネスに重要な高頻度シナリオをカバーします。
  2. テストセットを現在の本番モデルと照らして ベースラインを確立します。 これは現在のモデルがまだ有効であるうちに行ってください。モデルが変わった後はベースラインを再構築できなくなるからです。
  3. レイテンシとCopilotクレジット消費は別々に記録してください。 評価では報告されません。
  4. 保存期間を超えて記録を保存するために、結果をCSVにエクスポートしてください。

フェーズ2:非生産環境での候補者評価

  1. Copilot Studioのガイダンスに従い、アプリケーションライフサイクル管理およびエージェントテストのための非本番版エージェントを準備してください。 環境を本番環境として構成します:

    • 同じエージェント命令、トピック、知識設定、ツール、フロー、コネクター、言語、セキュリティ前提を使いましょう。
    • 代表的なテストアイデンティティとコネクションを活用しましょう。
    • 同じデータポリシーと関連する管理者の管理を適用してください。
    • 地域ごとの利用可能性や、地域間でのデータ移動が必要かどうかを確認してください。
    • テストと本番の間に結果に影響を与える可能性のある違いを記録してください。

  2. モデルを変えましょう。 エージェントの 概要 ページにアクセスし、 モデル セクションで候補の主要モデルを選択してください。 ディープ・レーティング、生成的レスポンス、プロンプトビルダー用の別々の設定が存在するので、エージェントがこれらの機能を使っているか、また変更が必要かを確認してください。

  3. 同じテストセットを変更せずに候補モデルに対して再実行します。

  4. 2つの実行を受け入れゲートと比較して改善点や回帰点を特定しましょう。

  5. テストチャットでオーケストレーションを質的にチェックし、アクティビティマップを使ってどのツールがどの順序で、どのパラメータで選ばれたかを確認しましょう。

  6. 候補者のレイテンシーと消費量を測定し、ベースラインと比較してください。

フェーズ 3: 修復

  1. モデル変更の影響を受けたエージェントのアーティファクトを更新し、その後、修復されたエージェントに対してテストセットを再実行します。 「 評価主導のトリアージと修復を用いてエージェントを改善する」で詳しく学びましょう。
  2. 受け入れゲートを満たすまで反復し、候補モデルが適さないと結論づけてその理由を文書化します。 アップグレードしない決断は正当でエビデンスに基づく結果です。

フェーズ4:承認および展開

  1. エージェントオーナーやリリース承認者から承認の承認を得て、クロスジオや外部モデルが関わる場合は安全性やコンプライアンスの承認も含まれます。
  2. 確立されたALMプロセスを通じて展開し、 テスト から本番環境へとソリューションを推進します。 本番エージェントを手動で編集しないでください。
  3. チャンネルが許可するタイミングで展開を進めてください。 まずはパイロットのオーディエンスや単一のチャネルに公開し、その結果を観察し、その後に広げていく。

フェーズ5:監視とクロージング

  1. 受理ゲートに対して生産の動作を監視してください。
  2. 新たに発見された失敗パターンを回帰テストセットに追加します。
  3. 移行は、受理基準が本格的に満たされたままでないと閉じません。
  4. 評価証拠と移行決定記録を監査 や次のライフサイクルイベントのために保存します。

Important

モデル変更のロールバックパスは、以前に検証済みのソリューションバージョンを再デプロイすることで、設定トグルよりも遅いです。 この違いが 、フェーズ2 の評価ゲートが非常に重要な理由です。 展開前に回帰を検出する方が、後で逆転させるよりもコストが安いです。

移行後の監視

モデルのライフサイクル作業は展開後も継続されます。 モニター:

  • エージェント評価結果とクリティカルシナリオの合格率。
  • 本来の分析、書き起こし、活動、エラー、ユーザーフィードバック。
  • 指示に従う失敗やツール選択の失敗。
  • 遅延、タイムアウト、そして信頼性についてです。
  • 消費は変わります。
  • 安全性、コンプライアンス、地域ごとの処理上の懸念。

本番監視で新たな故障パターンが特定された場合、回帰テストセットに代表的なケースを追加します。 この手法は次のモデル評価を向上させ、本番環境での学習を持続可能な品質基準に変えます。

環境レベルのテレメトリーは 、各エージェント呼び出しに用いられるモデルを含むアプリケーションインサイトに至るまでOpenTelemetryのGenAIを発信します。 実際にどのモデルの生産トラフィックで動作するかを確認し、移行前後のツール選択や信頼性を比較するために使ってください。

  • Last updated on