技術要約：プロベナンス（由来）分析によるLLMエージェントのミスアライメント防止

問題提起

大規模言語モデル（LLM）エージェントが、単なる対話型アシスタントから、不可逆的なアクション（例：送金、ファイルの変更）を実行可能な自律型システムへと進化するにつれ、その行動がユーザーの意図と一致していることを保証することが極めて重要になっています。本論文は、**ミスアライメント（不整合）**を、エージェントの提案されたツール呼び出しがユーザーの意図から逸脱する現象として定義しています。これは必ずしも悪意によるものではなく、ユーザーのリクエストに対する誤解や正当化されない仮定に起因するものです。

既存の実行時ガードレールは、多くの場合、単一のLLMプロンプトがアクションの許可可否を評価する**「LLM-as-a-judge（審判としてのLLM）」**パラダイムに依存しています。著者らは、このアプローチにはアライメントに関する推論のための体系的なフレームワークが欠けており、その結果、判断の不一致、主観的な根拠、および監査の困難さを招くと主張しています。さらに、サンドボックス化のような従来の安全対策は、事象の影響を限定するものであり、初期段階のミスアライメントされたアクション自体を防ぐものではありません。また、事後検証では、不可逆的なツールの呼び出しを取り消すことはできません。

メソドロジー

1. 概念的フレームワーク：プロベナンスに基づくガードレール

プロベナンス分析（アーティファクトの起源と派生履歴の研究）に着想を得て、著者らは、アクションがエージェントのコンテキスト内に追跡可能な証拠によって支持されている場合にのみ、アライメントされているとみなすフレームワークを提案しています。このコンテキストには、ユーザーのクエリ（$q$）、ツールのドキュメント（$d$）、およびインタラクション履歴（$h$）が含まれます。

本フレームワークは、ミスアライメントの検出を3つの異なるタイプに分類することで形式化しており、それぞれが特定のプロベナンス関係の確立における失敗に対応しています。

• ツールレベルのミスアライメント： エージェントがタスクとは無関係なツールを選択すること。
  • プロベナンス・チェック： 選択されたツール（$t$）のドキュメント（$d_t$）は、サブタスク（$s$）に対して関連性があり（RelevantTo）、かつそのサブタスクがユーザーのクエリ（$q$）に**寄与している（ContributesTo）**か？
• パラメータレベルのミスアライメント： エージェントが正しいツールを選択しているが、コンテキストに基づかないパラメータを割り当てていること。
  • プロベナンス・チェック： パラメータの割り当て（$a$）は、クエリまたは履歴に現れる事実的な証拠（$e$）から**派生可能（DerivedFrom）か？ また、インスタンス化されたツール（$t$ と $a$）は、サブタスク（$s$）を対処可能（CanAddress）**か？
  • 注記： 本フレームワークは、直接的なプロベナンス追跡を必要とする「派生可能なパラメータ」と、直接的なプロベナンス追跡を必要としない「生成的なパラメータ」（例：メール本文のドラフト作成）を区別しています。
• 解釈レベルのミスアライメント： 複数の妥当な解釈が存在する場合に、エージェントが未指定のクエリに対して恣意的に一つの解釈にコミットすること。
  • プロベナンス・チェック： 提案されたアクションは、コンテキストを考慮した上で、プロベナンス的に許容される唯一の候補か？ もし複数の異なるアクションがコンテキストによって支持されている場合、そのクエリは未指定の状態であり、明確化なしに一つに決定することはミスアライメントとなります。

2. 実装：ProvenanceGuard

著者らは、このフレームワークを、ツールの呼び出しを実行前に遮断するマルチステージの実行時パイプラインである ProvenanceGuard として実装しました。単一ステップの「LLM-as-a-judge」とは異なり、ProvenanceGuardは意思決定を以下の3つの連続したステージに分解します。

1. ステージI（ツールレベル）： 環境を変更するツールをフィルタリングし、選択されたツールがエージェントの現在のサブタスク計画に関連しているかを確認します。
2. ステージII（パラメータレベル）： どのパラメータが派生可能であるかを特定し、それらの値がコンテキストに遡って追跡可能であるか、およびツールをサブタスクのために正しくインスタンス化しているかを確認します。
3. ステージIII（解釈レベル）： バイアスを避けるためにエージェントが選択したアクションを明示せずに、他のプロベナンス許容可能なアクションが存在するかをLLMに問いかけます。もし複数存在する場合、それは正当化されない仮定に基づいているため、アクションはブロックされます。

システムは、特定のプロベナンス関係（例：RelevantTo、DerivedFrom）を評価するためにLLMを使用しますが、その推論プロセスを、包括的なプロンプトよりも明示的かつ監査可能な構造にします。

主な貢献

1. ミスアライメントの分類学： ツールレベル、パラメータレベル、および解釈レベルのミスアライメントに関する形式的な区別。
2. プロベナンスに基づくフレームワーク： アクションとコンテキストの間の追跡可能な依存関係を、特定のバイナリ関係を通じて形式化した、ツール呼び出しをコンテキストに接地させるための概念モデル。
3. ProvenanceGuard： 実行時ガードレールとして機能する、フレームワークのマルチステージ・パイプライン実装。
4. ベンチマーク： Agent-SafetyBenchおよびWorkBenchの2つのベンチマーク、および手動で注釈付けされたAgent-SafetyBenchのトレースを含む10個のバックボーンLLMを用いた評価。

実験結果

著者らは、ProvenanceGuardを DirectPrompt Baseline（標準的なLLM-as-a-judge）および Single-step Provenance Prompt（フレームワークの概念をシングルパスで使用するProvePrompt）と比較評価しました。

• ミスアライメント検出（エラー率）：
  • Agent-SafetyBench（未指定性に焦点を当てたもの）において、ProvenanceGuardはミスアライメントされたトレースにおけるエラー率を、42.9%（ベースライン）から**1.8%**に減少させました。
  • WorkBench において、エラー率は**32.1%から17.3%**に低下しました。
  • マルチステージ設計（ProvenanceGuard）は、シングルステップのバリアント（ProvePrompt）を一貫して上回り、特にAgent-SafetyBenchにおいて顕著であり、推論プロセスを分解することの価値を示唆しています。
• 介入コスト（偽陽性／不要な介入）：
  • Agent-SafetyBench（アライメントされたトレース）において、ProvenanceGuardはベースラインと比較して、不要な介入を統計的に有意に増加させることはありませんでした。
  • WorkBench（タスク成功トレース）において、ProvenanceGuardは介入率を30.5%（ベースライン）から12.8%へと大幅に減少させました。これは、正しいアクションの進行を許可する精度において、ベースラインよりも優れていることを示しています。

重要性と主張

本論文は、構造化されたプロベナンスに基づく推論が、LLMエージェントを保護するための効果的かつ実用的な基盤を提供すると主張しています。その重要性は以下の点にあります。

• 体系的な推論： 主観的で包括的な判断から、アクションとコンテキストの間の明示的で監査可能な依存関係に基づくフレームワークへと移行すること。
• 未指定への対処： 標準的な安全フィルターが見逃しがちな、エージェントが未指定のクエリに対して正当化されない仮定を行うリスクに特に対処すること。
• バランスの取れた性能： マルチステージ・アプローチは、エージェントの有効なタスクをブロックするという過度なコストを負うことなく、ミスアライメントされたアクションに対して高い検出精度を実現しています。

著者らは、本フレームワークは純粋に生成的なパラメータ（自由形式のテキスト生成など）におけるミスアライメントを検出できず、またエージェント自身の計画（これも理論的にはミスアライメントしている可能性がある）に依存しているものの、エージェント型システムにおける不可逆的でコンテキストに接地していないアクションを防ぐための堅牢なメカニズムを提供すると結論付けています。