1. 設問とシナリオ
あなたのチームは、カスタマーサポートの会話を要約するAI機能を準備しています。妥当な要約が複数存在する可能性があり、人間によるアノテーションは高コストで、単一の自動スコアでは顧客の問題が実際に解決されたかどうかを判断できません。リリースすべきか、誰向けにリリースすべきか、そして失敗後にどのように改善・収束させるかを決定する評価アプローチを設計してください。
2. 面接官が見ているポイント
- モデルのスコアを挙げる前に、ユーザータスクと許容できない失敗を明確に定義しているか。
- オフラインテスト、人手によるレビュー、オンラインの行動、安全性の監視を組み合わせているか。
- 先行指標（Leading signals）、遅行結果（Lagging outcomes）、ガードレールが衝突した際に、それらを切り分けて整理できているか。
- 評価セット、リスク許容度、人間へのエスカレーション、ロールバックをプロダクトの仕組みとして落とし込めているか。
3. 確認すべき質問
- 出力はドラフト（下書き）、推奨事項、または自動的かつ不可逆的なアクションのどれですか？
- 成功とは、対応時間の短縮、初回解決率（FCR）の向上、またはクレームの減少のどれを意味しますか？
- プライバシー、コンプライアンス、または顧客への危害を引き起こす可能性があり、遮断が必要なエラーはどれですか？
- ターゲットユーザー、言語、業界、データ分布は評価サンプルと一致していますか？
4. 30秒で答えるフレームワーク
まずタスクとリスクを定義し、その上で代表的な評価セットを構築します。タスクの成果、出力の品質、信頼性と安全性、コストとレイテンシの4つのレイヤーを測定します。単一の正解ラベルがない場合、専門家によるペア比較の選好度やPass/Failルールを用いて自動シグナルを調整し、オンライン実験、ユーザーフィードバック、人間へのエスカレーションを継続的な監視に組み込みます。リリース判定基準は階層化します。厳格なガードレールに違反した場合はロールアウトを即座に停止し、品質とビジネス価値の双方が基準値をクリアした場合のみ展開を拡大します。
5. ステップ別の解決策
ステップ1：「優れた出力」を観察可能なタスクに変換する
入力、ユーザーのアクション、望ましい成果を書き出します。要約タスクとは「参照回答に似せること」ではなく、オペレーターが利用可能な時間内で顧客のニーズを見つけ、適切な次のステップを約束し、機密情報の漏洩を防げるかどうかです。成果ごとに許容範囲と明確な失敗例を定義します。
ステップ2：階層化された評価セットを構築する
異なる言語、顧客タイプ、会話の長さ、エッジケースをサンプリングします。ドメインエキスパートに複数の正解を許容するルーブリック（評価基準）を用いてもらい、重要な事実、脱落、トーン、プライバシーを個別にスコアリングします。固定された回帰テストセットと、データ分布の変化を捉えるための最新サンプルの両方を保持します。根拠が不十分な場合は、無理にラベルを作るのではなく不確実性を記録します。
ステップ3：メトリクスとガードレールを組み合わせる
プライマリメトリクスには、タスク完了率、初回解決率、または編集後採用率などが考えられます。品質レイヤーでは、事実の正確性、カバレッジ、引用の完全性を確認します。ガードレールでは、有害なコンテンツ、プライバシー漏洩、バイアス、エスカレーション、クレームを監視します。コスト、レイテンシ、レビュー工数によって持続可能性を判断します。各メトリクスの分母、サンプリング期間、失敗条件をドキュメント化します。
ステップ4：評価をリリース判定に結び付ける
まずオフラインでの回帰テストを実行し、その後、可逆的な小規模コホートに公開します。厳格なガードレールの違反は機能の停止を意味します。品質やビジネス成果が低い場合は、プロンプト、検索（Retrieval）、モデル、インターフェースの各レイヤーで原因を診断します。オンラインでの失敗事例や人間のフィードバックを評価セットにフィードバックし、メトリクスが依然として実際のリスクを反映しているかを確認します。リスクの高いアクションには、人間による確認とキルスイッチ（強制停止機能）を用意しておきます。
6. 回答例
私は単一の自動スコアを最終回答として扱いません。ユーザータスク、許容可能なエラー、不可逆的なリスクを定義した上で、実際の分布に即した評価セットを固定します。複数の回答が成立する場合はペア比較を用い、ドメインエキスパートがルーブリックに従って事実、カバレッジ、トーン、プライバシーを評価します。
>
リリース前には、タスクの成果、出力品質、信頼性と安全性、コスト、レイテンシを測定します。タスク完了率をプライマリシグナルとし、プライバシー漏洩、有害コンテンツ、重大な事実誤認を厳格なガードレールとします。オフライン回帰テストと、リスクの高いアクションに対する人間による確認を含む小規模な実験を実施します。結果が基準に達しない場合は、データ、検索、モデル、インターフェースの各観点で失敗を分類し、評価セットを更新した上で、展開拡大、ロールバック、または停止を選択します。
7. よくある間違い
- ユーザータスクと失敗の影響を定義せずに、正解率や平均スコアのみを報告すること。
- 都合よく集めた単一のサンプルを、すべての言語、顧客、エッジケースを代表するものとして扱うこと。
- 誤った回答によって生じたクレームや手戻りを無視して、クリック数の増加のみを成功と呼ぶこと。
- リリース前にのみ評価を行い、本番環境のドリフト、フィードバック、評価セットの陳腐化を無視すること。
- 人間へのエスカレーション、ロールバック、キルスイッチを用意せずに、不確実な出力を自動実行すること。
8. 追加の質問と回答
追加質問1：人手によるアノテーションの予算が10分の1に減ったらどうしますか？
リスクによって層別化し、影響度が大きく意見が分かれやすいケースに予算を集中させます。リスクが低いケースには、サンプリングレビュー、ペア比較、ユーザーフィードバックを活用します。「不確実」というラベルを保持し、サンプリングエラーを追跡します。ラベル数を減らしても、同じ確実性が無償で得られるわけではありません。
追加質問2：タスク完了率は上がったが、プライバシーリスクも上がった場合はどうしますか？
プライバシーはベネフィットメトリクスよりも優先度の高いガードレールです。展開の拡大を停止し、影響を受ける入力と出力を特定・隔離した上で、墨消し（マスキング）、検索権限、またはプロンプトポリシーを修正します。ガードレールが回復し、回帰テストを通過した後にのみ再リリースします。
追加質問3：メトリクスが陳腐化していないことをどのように示しますか？
本番環境の失敗、人間へのエスカレーション、ユーザーからの申し立てを、言語、コホート、バージョンごとに分類して評価セットにフィードバックします。ドメインエキスパートにルーブリックを定期的に見直してもらい、メトリクスと実際の結果の乖離を記録します。乖離が大きくなった場合は、メトリクスを変更するか、古い判定基準への依存をやめます。