When the Database Fails: Prompting LLM Dialogue Agents for Safe Recovery in Task-Oriented Dialogue

テクニカル・サマリー：データベースが失敗する場合：タスク指向型対話における安全なリカバリのためのLLM対話エージェントへのプロンプティング

問題提起

ホテルの予約、レストランの検索、移動手段の手配などをユーザーに支援するタスク指向型対話（TOD）システムは、通常、LLMが意図を抽出し、バックエンドデータベースにクエリを投げ、その結果に基づいた応答を生成するというパイプラインに依存している。このパイプラインは、データベースの境界において脆弱である。実世界のデプロイメントにおいては、バックエンドの失敗、具体的には空の結果（一致するレコードなし）、誤ったドメインの返却（不適切なドメインからのデータ）、およびAPIエラー（タイムアウトやサーバー故障）が発生すると、LLMエージェントが流暢ではあるが安全ではない応答を生成してしまうことがよくある。エージェントは失敗を認める代わりに、データベースによって裏付けられていない施設名、確認事項、あるいは予約詳細を捏造（ハルシネーション）してしまうことが多い。先行研究は、一般的なエージェントのツール失敗やユーザー行動によるストレス要因に焦点を当てることが多かったが、再学習を行うことなくプロンプトのみによるリカバリ戦略を分離して評価した、TODシステムにおける実行時のデータベース実行故障に関する制御された評価は欠けていた。

メソドロジー

著者らは、構造的に異なる2つのデータセット、MultiWOZ 2.2（5ドメイン）とSGD（20ドメイン）にわたってリカバリ戦略を評価するための、制御されたフォールト注入フレームワークを提案している。

• フォールト注入： 各テスト対話に対し、システムは最初のユーザー発話を取り出し、以下の4つのデータベース条件のいずれかを合成的に注入する：

  1. Clean（正常）： 有効な結果（サニティ・ベースライン）。
  2. Empty Result（空の結果）： 一致なし（正しいアクション：失敗を認め、制約の緩和を提案する）。
  3. Wrong Domain（誤ったドメイン）： 不適切なドメインからの結果（正しいアクション：不一致を検出し、ユーザーに確認する）。
  4. API Error（APIエラー）： タイムアウトまたは503エラー（正しいアクション：謝罪し、再試行を求める）。
     注：最初の発話を使用することで、マルチターンにおける状態追跡による混同を避け、即時的なリカバリ挙動を分離している。

• リカバリ戦略： 本研究では、固定されたデコーディング温度（0.2）を用いて、6つのオープンウェイトモデルファミリー（DeepSeek-R1, Gemma-2, Llama-3, Mistral, Phi-3, Qwen-2.5）に対して3つのプロンプティング戦略を比較している：

  1. Naive（素朴な手法）： 特殊な指示を与えず、生のデータベースレスポンスをそのまま渡す。
  2. Inform（情報提供型）： ハルシネーションを起こさないこと、および失敗を正直に認めることを明示的に指示する。
  3. Guided-Retry（ガイド付きリトライ）： データベースのステータスフィールドに基づいた構造化された決定手順であり、失敗ごとの明示的な指示と、施設名、予約リファレンス、または確認詳細の捏造に対する厳格な禁止を提示する。

• 指標：

  • Hallucination Rate (HR / ハルシネーション率)： 非クリーンなターンのうち、エージェントがDBレスポンスに存在しない結果を捏造した割合。
  • Appropriate Action Rate (AAR / 適切なアクション率)： 失敗タイプごとの正解（グラウンドトゥルース）の正しいアクションに一致した割合。
  • Commitment Safety Rate (CSR / コミットメント安全性率)： 明示的な偽のコミットメント（例：捏造された予約リファレンス）を含まない非クリーンなターンの割合。この指標は、ヒューマンアノテーターによって検証されている（Fleiss' $\kappa = 0.7672$）。
  • User Friction Score (UFS / ユーザー摩擦スコア)： ハルシネーションやサイレント失敗にペナルティを与える複合スコア。

主要な結果

本研究は、構造化されたプロンプティングが堅牢性を大幅に向上させる一方で、ハルシネーションを完全に排除するものではないことを明らかにしている。

• 全体的なパフォーマンス： Guided-Retry戦略は、すべてのモデルにおいてNaiveおよびInformベースラインを一貫して上回っている。

  • MultiWOZにおいて、Guided-Retryは平均ハルシネーション率（HR）を30.5%（Naive）から**15.3%へと減少させ（50%の削減）、AARを83.0%**に向上させた。
  • SGDにおいて、HRは**20.9%から12.2%へと減少（42%の削減）し、AARは83.9%**に達した。
  • これらの改善は、すべてのモデルにおいて統計的に有意である（$p < 0.001$）。

• モデルの差異：

  • DeepSeek-R1は、Guided-Retry下で最も低いHR（MultiWOZで5.8%）を達成した。
  • Phi-3は顕著な例外であった。これはInform戦略下よりもGuided-Retry下でパフォーマンスが悪化しており（HR 35.2% vs 31.0%）、構造化されたリカバリ指示を確実に従うことができないことを示唆している。

• 失敗タイプの分析：

  • **Wrong-domain retrieval（誤ったドメインの検索）**は、最も困難な失敗ケースであることが判明した。Guided-Retryを用いても、残存するハルシネーションが高く（MultiWOZで20.8%、SGDで17.0%）、モデルが不一致を検知するのではなく、誤ったドメインの語彙を採用してしまう傾向があることを示している。
  • APIエラーは、構造化されたプロンプティングによる恩恵が最も明確であり、両方のデータセットにおいてHRが約25パーセントポイント減少した。

• 残存するハルシネーション： 改善は見られるものの、モデルとデータセット全体で**6～37%**という相当な残存ハルシネーション率が残っており、プロンプトレベルのリカバリだけでは完全な堅牢性を確保するには不十分であることを示している。

意義と貢献

本論文は、主に以下の4つの貢献を行っている：

1. 制御されたフレームワーク： ユーザー行動によるストレス要因から、実行時のデータベース実行故障を分離した、MultiWOZおよびSGDのためのフォールト注入フレームワーク。
2. プロンプティングの評価： 再学習、追加の推論呼び出し、または大幅なエンジニアリングのオーバーヘッドなしに、単一の構造化されたシステムプロンプトの追加によってハルシネーションを42～50%削減できることを示す評価。
3. 指標： コミットメント安全性率（CSR）を含む、失敗リカバリのための自動および人間によって検証された指標のセット。
4. 経験的知見： 構造化されたプロンプティングはハルシネーションを減少させるものの、非自明な残存率（6～37%）を残し、特に誤ったドメインの失敗が最も持続的な課題であることを示す知見。

著者らは、Guided-Retryは全体として最も安全な挙動をもたらし、TODの堅牢性を向上させるための実用的かつ低コストな介入策であるが、完全な解決策ではないと結論付けている。残存するハルシネーションの存在は、プロンプトレベルのリカバリが、堅牢な実世界のデプロイメントのために他の手段によって補完される必要があることを示唆している。