技術要約：LLMエージェントのための統一コンテキスト進化（Unified Context Evolution）

問題提起

大規模言語モデル（LLM）エージェントは、推論と環境からのフィードバックを交互に行うことで、多段階のインタラクティブなタスクを解くことに長けている。しかし、決定的な限界が依然として存在する。各タスクのエピソードは通常、固定されたコンテキスト（システム指示、数発のデモンストレーションなど）から始まるため、特定のタスク中に発見された戦略や洞察は、その場限りのものとなる。タスクが終了すると、これらの発見は失われてしまう。

この「忘却」問題に対する既存のアプローチは、大きく2つのカテゴリーに分類されるが、いずれも重大な欠点がある。

1. 強化学習（RL）： 勾配降下法を通じてモデルの重みを更新する手法。効果的ではあるが、モデルのパラメータへのアクセスと膨大な計算インフラを必要とするため、クローズドソースのLLMには適用できない。
2. タスク内適応： 言語による自己批判（Reflexion）や反復的な洗練（Self-Refine）などの手法。これらは単一のタスク内でのパフォーマンスを向上させるが、タスク終了時には改善内容は破棄される。
3. タスク横断的知識ライブラリ： タスク間で知識を蓄積するシステムだが、多くの場合、知識を型のないプール（あらゆる洞察を混在させる）として保存したり、単一の知識形式（スキルのみ、あるいはワークフローのみなど）に焦点を当てたりしている。さらに、これらのシステムは、知識の品質を繰り返しの使用を通じて追跡するのではなく、一度限りの評価に依存することが多い。

解決すべき核心的な課題は、基礎となるLLMの重みを更新することなく、いかにして異なる機能的な知識タイプを区別し、使用を通じて品質を追跡し、ライブラリの最も弱い領域に対して動的に生成リソースを割り当てる、持続的で進化する知識ライブラリを維持するかである。

手法：統一コンテキスト進化（Unified Context Evolution: UCE）

著者らは、エージェントのコンテキスト自体が学習の場となる、勾配フリーのフレームワークであるUnified Context Evolution (UCE) を提案する。UCEは、エージェントの経験を、進化する**進化可能コンテキストユニット（Evolvable Context Units: ECU）**のライブラリへと外部化する。

1. 進化可能コンテキストユニット（ECU）

ライブラリは、経験を、機能的に補完し合う4つの型の知識エントリーへと分解する：

• Memory（記憶）： 単一のタスクインスタンス内での試行錯誤を通じて発見された、環境メカニズムに関する事実的な記述（例：「シンクベイスンは、蛇口を操作することなくアイテムを洗浄できる」）。
• Strategy（戦略）： 特定のタスクタイプ内における分岐点のための、条件付き決定ルール（IF-THEN）（例：「もし『置く（put）』が失敗したら、容器を開けて再試行する」）。
• Workflow（ワークフロー）： 特定のタスクタイプに対して一般化された、標準的な実行シーケンス（例：「ターゲットを探す $\to$ 変形させる $\to$ 容器に配置する」）。
• Skill（スキル）： 異なるタスクタイプに適用可能な、再利用可能な多段階のサブ操作（例：「容器を探す、容器を開ける、ターゲットを取る」）。

各ECUは、$(z_e, \tau_e, w_e, c_e, f_e)$ のタプルである。ここで、$z_e$ は型、$\tau_e$ は適用可能なタスクタイプ、$w_e$ は検索条件、$c_e$ は注入される内容、$f_e$ は適合度スコアを表す。

2. ライフサイクルと検索

フレーム構組は、5つのフェーズからなる進化サイクルによって動作する：

• Evaluate（評価）： エージェントを保持された評価セット上で、現在のライブラリを用いて実行する。成功率は記録されるが、データリークを防ぐため、適合度スコアは更新されない。
• Collect（収集）： エージェントを分離された収集セット上で実行する。軌跡（トラジェクトリ）が保存され、結果に基づいて適合度スコアが更新される。
• Schedule（スケジューリング：知識収穫スケジューリング - KYS）： ライブラリの状態（カバー範囲のギャップ、適合度の分布）を分析し、4つのECUタイプに対して生成予算（$B$）を割り当てる。ライブラリが最も弱い部分（例：未カバーのタスクタイプや平均適合度が低いタイプ）を優先する。
• Generate（生成）： 型特有のジェネレータが、収集された軌跡から候補となるECUを蒸留する。極めて重要な点として、ジェネレータは**リシャッフル・テスト（reshuffle test）**を使用して、インスタンス固有の観察事項（例：「ジャガイモはカウンター1にある」）を排除し、一般化可能なメカニズム（例：「冷蔵庫は閉まっている時に機能する」）を抽出する。また、高適合度および低適合度のECUからの品質フィードバックを利用して生成をガイドする。
• Cleanup（クリーンアップ）： 低価値または冗長なECUを削除する。ラプラス平滑化された適合度スコア（$f_e = \frac{s_e + 1}{u_e + 2}$）は、累積的な成果のクレジット $s_e$ と使用回数 $u_e$ に基づいて、経験的な貢献度を追跡する。

検索は意思決定時に行われる。リトリーバは、タスク記述に対する意味的類似性、タスクタイプの不一致によるブースト、およびECUの適合度に基づいてECUをスコアリングする。上位$K$個のECUが、型ごとに専用のセクションへ注入される。

主な貢献

1. 型定義された知識表現： エージェントの経験を、4つの異なる、機能的に補完し合う型（Memory, Strategy, Workflow, Skill）へと分解するECUの導入。これらはそれぞれ独立した生成条件と検索境界を持つ。
2. 統一コンテキスト進化フレームワーク： 動的に生成リソースを割り当てるための知識収穫スケジューリング（KYS）と、一度限りの抽出ではなく繰り返しの適用を通じて品質を追跡する使用ベースの適合度スコアを備えた、完全なライフサイクル管理システム。
3. 実証的検証： UCEがインタラクティブなベンチマークにおいてエージェントの性能を大幅に向上させ、蓄積された知識ライブラリが、モデルの再学習なしに異なる推論バックボーン（例：ReAct, Plan-and-Act, NoThinking）間で転移可能であることを実証した。

実験結果

本フレームワークは、2つのテキストベースのインタラクティブ・ベンチマーク、ALFWorld（家庭内タスク）およびWebShop（オンラインショッピング）を用いて評価された。

• 性能向上：
  • ALFWorld： UCEは、全体の成功率を（ReActベースラインの）**75.4%から、ピーク時には96.3%**へと向上させた。特に「見る（Look）」のような弱いタスクタイプにおいて顕著な改善が見られた（50.0% $\to$ 100.0%）。
  • WebShop： UCEは、平均タスクスコアを**45.1%から61.3%へ、購入成功率を30.0%から42.0%**へと向上させた。
• 転移可能性： UCEによって生成されたECUライブラリは、代替のアクター・バックボーンへ正常に転移した。例えば、UCEライブラリを「Plan-and-Act」バックボーンに適用したところ、成功率は73.1%から97.8%へと上昇した。
• アブレーション研究：
  • ALFWorldにおいて、Workflow（ワークフロー）のECU単体で大部分の利得を占めており、このドメインにおいては手順的なスケルトンが非常に効果的であることが示唆された。
  • WebShopにおいては、単一のECUタイプが全ライブラリの性能に匹敵することはない。ショッピングタスクには、Workflow（手順的ガイダンス）、Strategy（ナビゲーションの罠からの回復）、Memory（ページメカニズムに関する事実）の組み合わせが必要であり、マルチタイプ・アプローチの必要性が浮き彫りになった。
• 統計的有意性： 両方のベンチマークにおいて、ReActベースラインに対する改善は統計的に有意であった（$p < 0.05$）。

意義と主張

本論文は、UCEが、特に重みの更新が不可能なクローズドソースモデルにおいて、強化学習に代わる実用的な勾配フリーの選択肢を提供すると主張している。コンテキストを学習可能で進化する実体として扱うことで、UCEは、孤立したタスク実行と持続的な学習との間の溝を埋めるものである。

著者らは、知識の型を区別し、使用を通じて品質を追跡する能力が、すべての洞察を等価に扱う、あるいはライブラリの成熟度に基づいて生成リソースを適応させることに失敗している従来のクロスタスク知識システムの制限に対処していることを強調している。結果は、インタラクティブなタスクにおいて、「何をすべきか（検索されたコンテキスト）」が「どのように行動するか（推論バックボーン）」と同じくらい重要であり、構造化され進化するライブラリが、経験から導き出された「どのように知るか」を効果的に捉え、再利用できることを示唆している。

論文は将来の展望については控えめであり、現在のECUタイプは手作業で設計されたものであること、また、より大きなタスクセットや連続的なアクション空間（例：AndroidWorld）へのスケーラビリティは依然として未解決の課題であることを述べている。また、現在の評価が特定のモデルペアと離散的なアクション空間に依存しており、フレームワークの設計とジェネレータの能力の分離については今後の調査課題であることも認めている。