「昨日キャンセルしたのに、まだ発送通知が来ています」
この問い合わせに対して、AIが「キャンセルは受け付け済みです。発送通知はシステム反映前に送信された可能性があります」と答えたとします。文章は自然で、顧客の不安にも答えているように見えます。
しかし、最終回答だけではシステムが正しく動いたか判断できません。古いキャンセル規約を検索したものの、LLMが偶然正しい文を生成したのかもしれません。現行規約は取得できていても、回答時に条件を取り違えた可能性もあります。注文を確認するだけでよい場面で、誤って再キャンセルAPIを呼んでいたら、回答が正しくても処理は成功とは言えません。
問い合わせAIがRAGの外へ出て業務システムを操作するなら、評価単位も「生成された一文」から「案件が通った一連のTrace」へ広げる必要があります。

評価を四つの観測点に分ける

検索で確認したいのは、期待した根拠へ到達したかです。上位チャンクに正解が含まれたかだけでなく、文書の版、適用範囲、アクセス権が一致しているかを見る必要があります。キャンセル規約が取得できても、その文書が法人契約向けで、対象顧客が個人なら検索成功とは扱えません。
回答では、取得した根拠に沿っているか、顧客固有の事実と一般ルールを混ぜていないかを確認します。検索が正しくても生成が誤るケースと、検索が誤っていて生成が偶然当たるケースを分けないと、改善すべき場所を特定できません。
実行で見るのは、選んだツール、引数、実行順序、結果です。参照すべき場面で更新系ツールを選んでいないか、注文IDが会話中の対象と一致するか、失敗後の再試行で副作用が重複していないかを確認します。最終テキストの採点からは、この種の失敗がほとんど見えません。
引き継ぎは「人に渡したか」だけでは不十分です。本来渡すべき案件をAIが抱え続けていないか、転送理由が妥当か、確認済みの情報と未解決事項が担当者へ渡ったかまでが評価対象です。危険な自己処理をした後で人へ転送しても、引き継ぎ成功とは言いにくいでしょう。

Evaluation Datasetは最終回答以外の期待値も持つ

テストケースには、入力と期待回答だけでなく、期待する根拠、許可する操作、引き継ぎ条件を含めます。たとえば次のような形です。

title.rb

{
  "case_id": "cancel_after_notice_001",
  "input": "昨日キャンセルしたのに、まだ発送通知が来ています",
  "expected_source": ["cancel_policy_v3"],
  "expected_action": {
    "allowed": ["get_order_status"],
    "forbidden": ["cancel_order", "reship_order"]
  },
  "expected_handoff": false,
  "actual_source": ["cancel_policy_v2"],
  "actual_action": ["get_order_status"],
  "actual_handoff": false,
  "result": "answer_correct_but_source_wrong"
}
puts 'code block.'

この例では回答文が正しくても、resultは無条件のsuccessにしません。誤った版を参照したまま正解したケースを残しておけば、モデル変更後に偶然が崩れたときの回帰を検出できます。expected_actionも一つの正解手順へ固定するより、許可する操作と禁止する操作を分けた方が運用しやすくなります。Agentには複数の妥当な経路があり得る一方、呼んではいけない更新系ツールは明確にできるからです。

一つの正答率へ潰さず、失敗の場所を残す

評価結果は、retrieval_miss、grounding_error、action_mismatch、execution_error、handoff_missのように、失敗した段階へ分類します。総合点だけを出すと、RAGを直すべきなのか、プロンプトを直すべきなのか、ツールの認可や分岐ルールを直すべきなのかが分かりません。
とくに更新系操作の誤呼び出しと、必要な引き継ぎを行わないケースは、最終回答が正しくても失敗扱いにする方がよいと考えています。これらは重み付き平均で薄めるより、リリース判定の必須条件として扱う方が安全です。

Traceに何を残すか

再現に必要なのは、検索クエリと取得文書ID、文書バージョン、生成に使った根拠、ツール名、マスク済み引数、結果コード、再試行回数、最終分岐、引き継ぎ理由です。モデル、プロンプト、ナレッジの各バージョンも結びつけます。ただし、会話全文や個人情報を無制限に保存するのではなく、評価と監査に必要な項目を目的別に残します。
オフライン評価では、実際の問い合わせから個人情報を除去したケースと、例外を意図的に作ったケースを組み合わせます。本番では同一理由の再問い合わせ、ツールエラー後の有人化、禁止操作の発生を観測し、データセットへ戻します。テストと運用ログを別々に扱わないことが、評価を形骸化させないために必要です。
Udeskに関わるAIカスタマーサービスの場面でも、知識検索、回答生成、業務処理、有人対応までを一つの過程として見なければ、正しそうな回答の裏にある失敗を捉えられません。問い合わせAIを評価するとしたら、皆さんは最終回答の正しさと途中のTool Callingのどちらを重く見ますか。また、どの失敗を一発で不合格にしますか。