• 自己進化するAI Agentについてのサーベイ論文。長いのでかいつまんで。

• Self-Evolving AI Agentsの構成要素は以下
• システム入力 (I): 最適化を導くタスク記述、コンテキスト情報、または入出力ペア
• エージェントシステム (A): 最適化の対象となるコアシステムで、さまざまなコンポーネントを持つ単一または複数のエージェントで構成される
• 環境 (E): 評価指標またはLLMベースの評価器を通じてフィードバック信号を提供する外部コンテキスト
• オプティマイザ (P): エージェントシステムを洗練させる役割を担うメカニズムで、その探索空間 (S) と最適化アルゴリズム (H) によって定義される

• Single Agentの最適化、MultiAgentの最適化、ドメイン最適化の3つがある

• 例えばSingleAgentの最適化は以下の4つの分野に分類される

• LLM動作最適化
• トレーニングベースの手法 (例：STaR（Self-Taught Reasoner））のような教師ありファインチューニング技術や、自己報酬メカニズムなどの強化学習アプローチ
• 推論ベースの手法(例：Baldur）推論ステップを検証するための検証モジュールを使用するフィードバックベースの手法や、複数の推論パスを探索するTree-of-Thoughtsのような検索ベースのアプローチ

• プロンプト最適化
• 編集ベースの手法（例：GRIPS、TEMPERA）：既存のプロンプトを反復的に洗練する
• 生成アプローチ（例：OPRO、PromptAgent）：全く新しいプロンプトを作成する
• テキスト勾配ベースの手法（例：TextGrad）：テキストに勾配のような最適化を適用する
• 進化的手法（例：EvoPrompt、Promptbreeder）：生物学的着想を得たアルゴリズムを使用する

• メモリ最適
• MemoChatやReflexionのような技術を用いた短期記憶最適化で、最近の対話を管理する
• A-MEMやGraphReaderのような検索拡張生成（RAG）アプローチを含む長期記憶システムで、永続的な知識を保存する

• ツール最適化
• モデルをツール使用のためにファインチューニングする学習ベースの方法（例：ToolLLM、ReTool）
• 実行時にツール選択と使用を最適化する推論時戦略（例：EASYTOOL）
• エージェントが自律的に新しいツールを開発できるようにするツール作成アプローチ（例：CREATOR、CRAFT）

• 課題
• Endure - 安全適応に関する課題
• task metricsが優先され安全性が軽視されている
• Excel - 性能保持に関する課題
• ドメイン特化タスクにおいて良質なラベルがない
• マルチエージェント化すると性能と速度のトレードオフが発生
• 同じ最適化手法が違うモデルでも有効とは限らない
• Evolve - 自律最適化に関する課題
• マルチモーダルはまだ難しい
• ツールセットが固定化されてることによる限界

• 将来の方向性
• MOP(Model Offline Pretraining) → MOA (Model Online Adaptation) → MAO (Multi-Agent Orchestration) → MASE (Multi-Agent Self Evolving)と進化していく

• その他
• EvoAgentXといったフレームワークも登場していて気になる
• https://github.com/EvoAgentX/EvoAgentX
• Agent as a Judgeという技術が最近注目
• 既存のLLM as a Judgeが最終結果でしか評価できなかったところを中間生成物も含めて評価できる枠組み

• Gemma3 270Mがリリース

• instruction-followingに強み

• ollamaで使える（ファインチューニングなし）
• 回答はとても速い
• サイズは小さいが、他言語が混ざらないのはすごい
参考: gpt-oss:20b（三目並べ）

• LLMのAPI活用における課題
• コスト面、速度面、安全面

• 解決策としてのオープンウェイトモデルの自社活用
• すべてのタスクを一度に移行するのは現実的ではない場合もある

• 完全な自社運用モデル移行が困難な場合でも、クローズドモデル(API)とオープンウェイトモデルを効果的に組み合わせることで、コスト削減とセキュリティ向上を実現
1. Pipeline（パイプライン）
• 処理を複数のステップに分解し、自社運用モデルで前処理や定型作業を実行後、その結果をAPIに渡して後続の処理を実行
• CoGenesis(Zhang et al., 2024)では、端末上のSLMが個人のコンテキストを読み取って整形し、クラウド上のLLMがタスクを実行
2. Routing（ルーティング）
• 入力内容の複雑度や機密性に応じて、自社運用モデルとAPIを動的に使い分けます。簡単なタスクは自社運用モデルで素早く回答し、難しいタスクはAPIを通じて実施
• CITER(Zheng et al., 2025)では、定型的な部分や平易な部分はSLMが生成し、重要度が高く正確さが必要な部分はLLMが担当
• このルーティングは強化学習で最適化

3. Auxiliary（補助／強化）

• APIをメインとしつつ、自社運用モデルが前処理や情報抽出で支援します。例えば自社運用モデルが社内文書から関連情報を検索・構造化し、その結果をコンテキストとしてクローズドモデルに提供

• Collab-RAG(Xu et al., 2025)では、SLMが複雑な質問を複数のサブクエリに分解することで検索精度を向上させ、LLMが最終的な回答を作成



4. Knowledge Distillation（知識蒸留）
• クローズドモデルの出力を教師データとして、自社運用モデルを改善
• 全体の出力のN(0 < N < 100)%をAPIで処理し、データを収集することで自社運用モデルを継続的に訓練

• Co-Planning
• 計画フェーズで、AIが出してきた計画を直接編集可能 ← [pon]良い！！！
• 曖昧な計画の修正
• ユーザーの知識を統合できる

• Co-Tasking
• エージェントに割り込む
• 進行中のアクションを一時停止
• 問題が発生している場合はガイダンスを提供
• エージェントが支援を求める
• システムは障害に遭遇すると説明や支援を求める。
• 最終検証
• 完了した作業を確認し、完了と判断する前にフォローアップの質問。

• リアルタイム制御ツール
• ライブプレビュー
• ウェブブラウザでエージェントのアニメーションインタラクションをリアルタイムで視聴
• 折りたたみ可能なインターフェース
• 計画ステップを展開して詳細なアクションを表示
• シームレスなハンドオフ
• 一時停止、リダイレクト、または手動制御を即座に実行
• 直接ブラウザアクセス
• 必要に応じて埋め込みブラウザにジャンプします
 
• → 複数のエージェント間のインタラクションを効率的に管理できるため、個々のエージェントのパフォーマンスが人間のレベルを下回った場合でも、価値を引き出すことができる。

• Memory
• ユーザーの介入を含むすべての履歴を処理し、再利用可能なプランを作成
1. 直接再実行
: 保存したプランを見つけて「プランを実行」をクリックします
2. スマート提案
: システムが新しいタスクに関連する計画を提案します
3. 手動添付
: 「プランを添付」を使用して特定のプランを添付します
4. 自動検索
: Vectorデータベースクエリにより、関連するプランが自動的に検索されます。

• セキュリティ
• 有害な行為からユーザーを保護する 2 段階のセキュリティ システムを示しています。
1. アクション分類 ← [pon]どうやって作る？
: 事前定義されたリスク レベル (常に安全、危険の可能性あり、決して安全ではない)
2. LLM セキュリティジャッジ
: 曖昧なアクションのカスタム評価
3. 人間による承認
: リスクのある操作に対して明確な「はい/いいえ」プロンプトを表示

Abstract

• TURA（Tool-Augmented Unified Retrieval Agent） は、従来のRAGシステムの静的情報検索の限界を克服し、リアルタイムなAPI呼び出しや動的データベースアクセスを可能にする3段階のAI検索フレームワークを提案

• 3つのコアモジュール（意図理解に基づく検索、DAGベースのタスク計画、軽量化されたエージェント実行器）により、複雑な多段階クエリを並列処理し、低レイテンシーを実現

• Baiduの本格的な商用環境で数千万ユーザーに展開され、従来のRAGベースラインと比較して回答精度87.5%（vs 65.3%）、信頼性96.2%（vs 72.4%）という大幅な性能向上を実証

1. Introduction（序論）

• 従来の検索エンジンは静的な「10個の青いリンク」パラダイムに限定され、リアルタイムデータや動的情報にアクセスできない

• LLMによるRAGシステムも同様に静的なWebページからの情報検索に制限され、航空券予約やリアルタイム在庫確認などの動的クエリに対応不可

• TURAは静的RAGと動的情報源の間のギャップを埋めるAgentic architectureとして提案

• 2025年5月から数千万ユーザーに展開され、従来のRAGでは対応困難だった動的・トランザクショナルクエリに対して正確なリアルタイム回答を提供

2. Related Work（関連研究）

• RAGシステムは「検索してから生成」のパラダイムで発展してきたが、事前定義されたワークフローに依存し柔軟性に欠ける

• ツール拡張エージェント（Tool Augmented Agent）はReActフレームワークに基づき計画・行動・反省の3段階プロセスで外部リソースにアクセス

• 既存システムは静的ワークフロー、異種ツールの意味的統合の困難、RAGとツール使用の非効率な協調という課題を抱えるが、TURAは動的な検索決定、ツール選択、応答生成を統合した統一アーキテクチャでこれらの問題に対処

3. Problem Definition（問題定義）

• ユーザーの自然言語クエリqと多様なMCPサーバー集合M={M1, M2, ..., MN}が与えられる

• 回答品質Q(A)を最大化しつつ、レイテンシー制約L(π) ≤ τmaxを満たす最適実行戦略π*を見つける制約付き最適化問題として定式化

4. Method（手法）

• 意図理解に基づくMCPサーバー検索：LLMによるMulti-intentクエリ分解、サーバーレベルの意味インデックス拡張、密ベクトル検索によりRelevancyの高いMCPツールを効率的に特定

• DAGベースタスクプランナー：サブタスク間のデータ依存関係を有向非環グラフ(DAG)でモデル化し、独立タスクの並列実行により最適化されたレイテンシーを実現

• 蒸留エージェント実行器：Deepseek-V3を教師モデルとしてQwen3シリーズをStudent modelに蒸留、「思考ありで訓練、思考なしで推論」パラダイムで高品質な判断を低コストで実現
• 思考ありで訓練、思考なしで推論

5. Experiments（実験）

• MCP-Bench：Baiduの匿名化された本番ログから構築した包括的ベンチマークで自然なクエリ分布を捕捉

• エンドツーエンド評価：TURAは回答精度87.5% vs RAGベースライン65.3%、信頼性96.2% vs 72.4%という大幅な性能向上を達成

• オンラインA/Bテスト：セッション成功率を8.9%向上させ、総問題数を16.7%削減（66→55）し、全カテゴリで一貫した改善を実証

• アブレーション研究：クエリ分解とインデックス拡張が不可欠、DAGプランナーが44.2%のレイテンシー削減、蒸留により教師モデルを上回る性能（88.3% vs 82.4%）を66%低レイテンシーで実現

所感

• Towards AI Search ParadigmもBaiduの論文で、動的にTool Searchするのは同じスタンス（方法は異なる）。検索で多様な情報を収集する必要性を考えると、各情報源に対するMCPが増えて、情報源MCPの検索、選択が課題になってくる。