What Prompts Don't Say: Understanding and Managing Underspecification in LLM Prompts

以下は、Yang らによる論文「What Prompts Don't Say: Understanding and Managing Underspecification in LLM Prompts」の詳細な技術的サマリーです。

1. 問題定義：プロンプトの未特定化

本論文は、信頼性の高い大規模言語モデル（LLM）アプリケーション構築において、重要でありながらしばしば見落とされている課題として「プロンプトの未特定化（prompt underspecification）」を特定しています。

• 定義: 未特定化とは、プロンプトから必須要件が省略され、複数の妥当だが矛盾する行動結果が可能になる状態を指します。
• 核心的な問題: 開発者はしばしば LLM に共通感覚を用いて「隙間を埋める」ことを依存しますが、この振る舞いは脆弱です。
  • 不安定性: 明示的に指定された要件と比較して、未指定の要件は、基盤モデルまたはプロンプトが変更された際にリグレッション（失敗）する可能性が2 倍高いです。
  • 「過剰指定」の罠: 単にプロンプトに考えられるすべての要件を追加することは、実用的な解決策ではありません。指示追従能力の限界により、LLM は長く複雑な制約リストの処理に苦しみ、19 個の要件を指定した場合、少ない要件を指定した場合と比較して19% の精度低下を招きます。
• 結果: これは予測不可能なユーザー体験（例：旅行アドバイザーがビザ要件や天候について警告しないなど）をもたらし、堅牢な LLM アプリケーションの維持を困難にします。

2. 手法

著者らは、旅行アドバイス、製品説明生成、コード解説という 3 つの代表的なタスクを含む体系的な実証分析を実施しました。

• データキュレーション:
  • 既存の現実世界のプロンプトの分析、潜在的な失敗モードのブレインストーミング、モデル出力のエラー分析という 3 つの引き出し方法を用い、タスクあたり60 の妥当な要件（合計 180 以上の要件）をキュレーションしました。
  • これらの要件の異なる部分集合を含むプロンプトを生成（バランスの取れたカバレッジを確保するための循環設計を使用）することで、8,400 のデータポイントを構築しました。
• 評価フレームワーク:
  • バリデーター: モデル出力が特定の要件を満たしているか検証するための自動化されたバリデーター（Python スクリプトまたは LLM-as-a-judge）を開発しました。人間の検証は、LLM バリデーターと95.6% の一致を示しました。
  • テストされたモデル: Llama-3.3-70B、gpt-4o、o3-mini など、さまざまなモデルで評価を行いました。
  • 指標: 異なるプロンプト構成およびモデル更新における満足度（精度）と分散（安定性）を測定しました。

3. 主要な実証的知見

この研究は、いくつかの直感に反するが重要な洞察をもたらしました。

1. LLM は推測できるが、信頼性は低い:

   • LLM は未指定の要件を**41.1%**の確率で正常に推論します。
   • しかし、この推測は非常に一貫性がないため、同じ未指定要件に対しても、異なるプロンプトやモデルバージョンは著しく異なる結果をもたらします（未指定の場合の標準偏差は8.9%、指定された場合は0.8%）。
   • リグレッションリスク: モデルが更新されると、未指定の要件は指定された要件よりもはるかに頻繁にリグレッションします。例えば、モデル更新後、未指定要件の**5.9%が精度で 20% 以上低下しましたが、指定された要件ではわずか3.0%**でした。

2. 「指示追従」のボトルネック:

   • LLM は要件が分離されている場合に最もよく機能します。
   • 指定された要件の数が増えるにつれ、平均精度は低下します。19 個の要件を指定すると、gpt-4o の精度は85.0%、Llama-3.3-70B では**79.7%**まで低下しました。
   • これはトレードオフを示唆しています：過剰指定はモデルを圧倒し、未指定は不安定なデフォルトに依存します。

3. 標準的なオプティマイザーの失敗:

   • 特定の要件を考慮しない既存のプロンプトオプティマイザー（OpenAI の静的オプティマイザーや DSPy の COPRO など）は、一貫性のないまたは無視できる程度の改善しか提供しません。これらは、モデルがデフォルトで既に追従している要件と、明示的な指示を必要とする要件を区別することにしばしば失敗します。

4. 提案される解決策

著者らは、未特定化を管理するための二管のアプローチを提案しています。

A. 要件認識型プロンプト最適化

テキストを盲目的に最適化するのではなく、著者らは要件セットを明示的に考慮するメカニズムを導入します。

1. COPRO-R（要件認識フィードバック）: 要件固有のバリデーターをフィードバック信号として使用することで、既存のオプティマイザーを強化します。これにより、オプティマイザーは一般的な「良さ」スコアを最適化するのではなく、特定の失敗を修正するように導かれます。
2. ベイズオプティマイザー（選択戦略）: 要件の選択をハイパーパラメータ最適化問題として扱う新規アプローチです。木構造パラゼン推定量（TPE）を使用して、どの要件を明示的に指定し、どの要件を暗黙的（モデルのデフォルト振る舞いに依存）に留めるかを決定します。
   • 結果: この戦略により、トークン使用量が**41–45%削減され、平均して4.8%**の精度向上が達成されました。これは、モデルが既に追従している冗長な要件（例：グローバルなフォーマット規則）を効果的に特定します。

B. 体系的な管理プロセス

最適化を超えて、本論文はエンジニアリングライフサイクルの変更を提唱しています。

• 能動的発見: 場当たり的な試行錯誤を超え、体系的な要件引き出し（例：合成データを用いてエッジケースを見つけるなど）へ移行します。
• 継続的モニタリング: モデルまたはプロンプトが変更された際のドリフトを検出するために、追跡対象のすべての要件（指定済みおよび未指定）のバックグラウンド検証を実装します。
• バリデーターの整合性: プロンプトを評価するために使用されるバリデーター自体が堅牢であり、人間の意図と整合していることを保証します。

5. 主要な貢献

1. 特徴付け: LLM における未指定要件の不安定性を定量化した、初の包括的な実証研究。
2. 脆弱性の証拠: 未指定要件は、指定された要件と比較してモデル更新時に2 倍リグレッションしやすいことを実証。
3. 新しい最適化パラダイム: 要件認識型プロンプト最適化を導入し、どのように指定するかと同じくらい、何を指定するかの最適化も重要であることを示した。
4. エンジニアリングフレームワーク: 信頼性の高い LLM アプリケーション開発を支援するための、要件の発見、キュレーション、監視のための構造化プロセスを提案。

6. 意義

本論文は、直感に基づく「職人芸」としてのプロンプトエンジニアリングのパラダイムを、体系的なエンジニアリング分野へと転換させます。

• 開発者にとって: いくつかの例をテストする「雰囲気チェック」アプローチへの警告と、厳格な要件管理の必要性を浮き彫りにします。
• 研究者にとって: 安定性を最大化しトークン使用量を最小化するための、明示的指定と暗黙的推論のバランスを取るという新しい最適化目標を特定します。
• 産業界にとって: モデルが更新された際に静かに破綻しない、より堅牢でコスト効果が高く保守性の高い LLM アプリケーションを構築するための具体的なメカニズム（ベイズ要件選択）を提供します。

要約すると、本論文は、LLM アプリケーションの信頼性は、モデルを混乱させる過剰指定や、脆弱なデフォルトに依存する未指定のどちらによっても達成できないと主張しています。その代わり、データ認識型最適化と継続的モニタリングに支えられた「金髪姫（ジャスト・ミックス）」アプローチが必要です。