Orchestration
[Paper Note] Sakana Fugu Technical Report, Yujin Tang+, arXiv'26, 2026.06
Paper/Blog Link My Issue
#Multi #NLP #LanguageModel #AIAgents #reading #Initial Impression Notes #Author Thread-Post Issue Date: 2026-06-27 GPT Summary- LLMの特化を統合するために、オーケストレーター型モデルSakana Fuguを開発。Fuguはユーザーのクエリを理解し、動的にエージェントフレームワークを設計。これにより、様々な難解なタスクで最先端の性能を達成。日常利用と高難度応答のバランスを取るFuguと、回答品質を優先するFugu-Ultraを公開。トレーニング方法には大規模ファインチューニングや強化学習を含む。研究がマルチエージェントシステムの発展に寄与することを目指す。 Comment
元ポスト:
基盤となる技術:
- [Paper Note] TRINITY: An Evolved LLM Coordinator, Jinglue Xu+, ICLR'26, 2025.12
- [Paper Note] Transformer-Squared: Self-adaptive LLMs, Qi Sun+, ICLR'25, 2025.01
- [Paper Note] Learning to Orchestrate Agents in Natural Language with the Conductor, Stefan Nielsen+, ICLR'26, 2025.12
[Paper Note] Transformer-Squared: Self-adaptive LLMs, Qi Sun+, ICLR'25, 2025.01
と [Paper Note] TRINITY: An Evolved LLM Coordinator, Jinglue Xu+, ICLR'26, 2025.12
によってFuguが学習され、さらに [Paper Note] Learning to Orchestrate Agents in Natural Language with the Conductor, Stefan Nielsen+, ICLR'26, 2025.12
によってFugu Ultraが学習される、という構図に見える。
これはただの感想だが
- nature inspiredなAIを実現するというビジョンのもと
- 世界にインパクトを与えられるようなプロダクトを設計し
- プロダクトから逆算して技術的に必要な課題を列挙し、
- 個々の課題についてトップカンファレンスに通すレベルの水準まで、ストーリーと研究を追求した上で実際にカンファレンスに通し
- 最終的にそれらをつなぐことによってプロダクトを構成する
という、プロダクトと研究が一体となる戦略をとっているように感じた。
プロダクトと研究が分離していると、まずプロダクトがあって、そのプロダクトを運用している中で課題が見つかり、それを解決するための仕事をしていたらそこから研究にできそうな芽が出てきて、出てきた芽をうまく切り出して結果的に研究として出版される、という流れになる気がするのだが、これとは根本的に戦略が異なるように感じる。
[Paper Note] Recursive Agent Optimization, Apurva Gandhi+, arXiv'26, 2026.05
Paper/Blog Link My Issue
#NLP #LanguageModel #ReinforcementLearning #AIAgents #Test-Time Scaling #PostTraining #read-later #Selected Papers/Blogs #One-Line Notes #RecursiveModels #Initial Impression Notes #Delegation #Author Thread-Post Issue Date: 2026-05-10 GPT Summary- 再帰エージェント最適化（RAO）を導入し、エージェントが自身のインスタンスを生成してサブタスクを委任できる強化学習アプローチを提案。推論時のスケーリングアルゴリズムを実装し、長い文脈への拡張と難しい問題への一般化を可能にする。この訓練により、効率が向上し、タスクのスケールや一般化能力が高まり、実時間の短縮が実現される。 Comment
元ポスト:
著者ポスト:
pj page: https://apga.github.io/RAO/
再帰的にAI Agentがサブタスクを委任する子エージェント（子エージェントは自身のコピー）を作成できるようにし、子エージェントがサブタスクを実施した際のRewardや子エージェントのタスクの成功率などの情報に基づいて親エージェントの報酬が決まるような報酬設計にする。再帰が深くなるにつれ、サブタスクは簡単になっていくため、エージェントは自然に学習するためのカリキュラムを構築していると捉えることができる。これにより、エージェントがタスクをサブタスクに分解し再帰的にinferenceをするような挙動をend-to-endで学習する。再帰の木構造の深さは、場合によっては特定の部分木が非常に深いものとなってしまうケースもあるため、深さの情報に基づいて重みづけを調整する。
という感じだろうか。
サブタスクを委任するポリシーが自分のコピーで、これにより自分自身を分解されたサブタスク上から得られる報酬と、適切な委任による報酬によって訓練することになるといううまい報酬設計がミソな気がする。
著者ポスト2:
[Paper Note] MAS-Orchestra: Understanding and Improving Multi-Agent Reasoning Through Holistic Orchestration and Controlled Benchmarks, Zixuan Ke+, ICML'26, 2026.01
Paper/Blog Link My Issue
#Multi #NLP #Dataset #LanguageModel #AIAgents #Evaluation #ICML #read-later #Selected Papers/Blogs #Initial Impression Notes #Author Thread-Post Issue Date: 2026-05-09 GPT Summary- MASのオーケストレーションを強化学習形式で定式化するMASOrchestraを提案。これにより、エージェントの複雑性を管理し、システム全体のグローバルな推論を促進。タスクを5軸で分析するMASBENCHを導入し、利得がタスクや能力に依存することを示す。公開ベンチマークで一貫した改善を達成し、10倍以上の効率を実現。MASOrchestraとMASBENCHはマルチエージェント知性の向上を目指す。 Comment
元ポスト:
SASと比べてMASにすることでどれだけ利点があるかをモデルが理解せずにfoldingしてるよね、というのは重要な指摘に感じる。
[Paper Note] Learning to Orchestrate Agents in Natural Language with the Conductor, Stefan Nielsen+, ICLR'26, 2025.12
Paper/Blog Link My Issue
#NLP #LanguageModel #ReinforcementLearning #AIAgents #ICLR #Test-Time Scaling #read-later #Author Thread-Post Issue Date: 2026-04-26 GPT Summary- Conductorモデルを導入し、LLM間の協調戦略を自動発見。通信トポロジを設計し、個々のLLMの能力を最大化する指示を生成。7BパラメータのConductorは、単一ワーカーを超える性能向上を実現し、難解なベンチマークで最先端結果を達成。ランダム化されたエージェント訓練により、任意のエージェント集合に適応し、新たな再帰的トポロジを形成してオンラインでの性能向上を図る。この研究は、強力な協調戦略がRLを通じて自然に現れることを示す初期の実証である。 Comment
openreview: https://openreview.net/forum?id=U23A2BUKYt
公式ポスト:
[Paper Note] TRINITY: An Evolved LLM Coordinator, Jinglue Xu+, ICLR'26, 2025.12
Paper/Blog Link My Issue
#NLP #LanguageModel #AIAgents #ICLR #reading #KeyPoint Notes #EvolutionaryAlgorithm #Author Thread-Post Issue Date: 2026-04-26 GPT Summary- Trinityは、LLMs間の協調を調整する軽量なコーディネーターを用いて、基盤モデルの統合に伴う制約を解決する。約6億パラメータのコンパクトな言語モデルと約1万パラメータの軽量ヘッドから成り、適応的な委任を実現。複数ターンにわたるクエリに対して、コーディネーターは各LLMに役割を割り当て、スキルを効果的にオフロードする。実験の結果、Trinityはコード作成や数学、推論、領域知識タスクで優れた性能を示し、標準ベンチマークで最先端の成果を達成。コーディネーターの隠れ状態表現が文脈化を提供し、進化戦略の適用が有利であることが確認された。 Comment
openreview: https://openreview.net/forum?id=5HaRjXai12
軽量なcoordinator + 非常に軽量なheadを用いてターンごとに適切なモデルとロールを選択する。coordinatorは全てのターンの会話に対応するcontextualな表現を最後から2番目のトークンに対応するhidden state[^1]から取得し、
- LLM poolの中からどのLLMを用いて応答を生成するか
- 事前定義されたロール（Thinker, Worker, Verifier）のうちどれを選択するか
を決定する。最終的にVerifierが選択され、質問に対する最終的な応答としてacceptされるか、固定長のターン数のbudgetに到達したら生成終了となる。
上記枠組みを定式化すると（Section 2）、ざっくり言うと
- SLMが最初のクエリ+これまでの会話の履歴のcontextを、最後から2番目のトークンのhidden state hに集約し
- lightweight がhを受け取り、有限のアクション集合から（agent-roleのペア集合）適切なアクションを選択する
- 最終的に 0/1 のrewardを得られるものとし、この期待報酬を最大化するような（SLMのパラメータの対角成分[^2]と）lightweight headのパラメータΘを求める最適化問題として定式化される。
- ただし制約条件として、trajectoryのhorizon T は T <= B_turn、かつ期待報酬を得るために利用可能なコスト B_env がある。
となる。
（この辺は少し自信がないが）本研究のタスク設定は以下の特徴を持つ：
- 1ステップの評価が複数のLLM呼び出しを含むため非常に高コストであり、かつ評価に利用可能なコスト（B_env）の制約も厳しく
- lightweight headの次元数は10kであり、予算に強い制約がある中で学習するには次元数が多く
- かつlightweight headのパラメータはblock-epsilon-separabilityという性質を持つらしく
- 個々のlogitに寄与するブロックが独立していて、かつ独立したブロックの対角成分によって出力が決定される
- また、ブロック間は弱い相互作用をしている、という状態のようである
- 最終的に得られる報酬は2値のsparseな報酬でノイジー
パラメータΘを学習する上で、REINFORCEのようなパラメータごとの勾配を求める手法は、個々のパラメータが最終的な報酬に与える影響が小さく、かつ報酬がsparseでノイジーであるため効果的に学習ができないことから（時間をかければ学習できるのかもしれないが、B_envの制約がきつくて無理）、パラメータの対角成分を扱う手法であるseparable CMA-ESと呼ばれる進化的アルゴリズムによって学習するとのことである。
separable CME-ESはノイズを加えたパラメータベクトルの集団をサンプリングし、各候補を評価してそれぞれの適応度スコアを取得し、適応度で重みづけした上で平均をすることで次の親を形成するというプロセスを反復する手法らしく、特にseparable CME-ESという手法は、対角共分散行列のみを維持するため、上記の対角成分が寄与する性質と相性が良いとのことである。実験の結果、実際にREINFORCE, SFT, Random Searchなどの手法と比較して性能が良いことが示されている（Table 4）。
SLMのパラメータの対角成分は Singular Value Finetuning
- [Paper Note] Transformer-Squared: Self-adaptive LLMs, Qi Sun+, ICLR'25, 2025.01
によって効率的に学習される。この結果、学習をするパラメータ数は20k程度で済み、パラメータ効率が非常に良いとのことである。
[^1]: 最後から2番目のトークンは `` や `
[^2]: Section 2にはおそらく定式化のシンプルさを優先して最適化の対象はlightweight headのパラメータΘのみで定式化がされており、Section 3やFigure 2において、SLMのパラメータの対角成分も学習する旨が記載されている
[Paper Note] AgentConductor: Topology Evolution for Multi-Agent Competition-Level Code Generation, Siyu Wang+, arXiv'26, 2026.02
Paper/Blog Link My Issue
#NLP #AIAgents Issue Date: 2026-02-23 GPT Summary- LLM駆動のマルチエージェントシステムを用いて、コード生成タスクのための動的なトポロジーを実現。AgentConductorは、エージェントの役割と難易度に応じて最適な通信グラフを生成し、冗長性を減少。実験結果では、競技レベルのデータセットで最先端の精度を達成し、従来の方法を大幅に上回る成果を示した。 Comment
元ポスト:
[Paper Note] AOrchestra: Automating Sub-Agent Creation for Agentic Orchestration, Jianhao Ruan+, arXiv'26, 2026.02
Paper/Blog Link My Issue
#NLP #LanguageModel #AIAgents #read-later #Selected Papers/Blogs #KeyPoint Notes #LongHorizon #Adaptive #BudgetAllocation Issue Date: 2026-02-11 GPT Summary- 任意のエージェントを命令・コンテキスト・ツール・モデルのタプルとしてモデル化し、タスクの自動化を促進する統一されたフレームワークを提案。AOrchestraでは中央オーケストレーターがタプルを具体化し、専門的な実行者を生成。この設計により、エンジニアリング作業を削減しつつ、エージェントの多様性と性能を最適化。実験では、AOrchestraが競合モデルに対して16.28%の相対改善を達成。 Comment
元ポスト:
サブエージェントを生成するオーケストレータを学習し、動的に直面するタスクに適応したサブエージェント（適切なコンテキスト, 指示, ツール, モデル）[^1]を持つエージェントを構築し、実行を委譲することで、固定されたハーネスに依存せず、人間がエンジニアリングするコストも削減しながら、性能が向上する、という話に見える。
ベンチマークの性能向上が非常に大きく、効果的な手法であることが伺える。
[^1]: このようなサブエージェントのAbstractionを定義したのも貢献だと考えられる。
具体的な手法としては下記で、(a)オーケストレータエージェントがユーザからタスクを受け取り、サブタスクを解くためにサブエージェントを構築し委譲する。その後結果を受けとり状態を更新し、さらにサブエージェントを構築しタスクを委譲する、といった操作を繰り返す。(b)サブエージェントは(M, T, I, C)によって抽象化され、それぞれモデル、ツール、指示、コンテキストである。図中の(c)では自己教師あり学習が利用される旨が記述されているが、本文中ではSFTを使うと記述されているためここは齟齬があるように感じる（タイポも含まれている）。オーケストレーションのポイントは、タスクのオーケストレーションと、モデルのルーティングの二つの要素に分けられる。前者をSFTで学習し、後者はInstructionをiterativeに改善するプロセスで最適化する。
具体的には、オーケストレーションという特化したタスクを学習させるため、今回はexpertによる正解となる(T, I, C)を模倣できるように、SFTで学習する（GRPOのような手法でも学習できることについても言及されている点には注意）。
また、後者のモデルルーティングの最適化については、さまざまなモデルに対してInstructionを与え、得られたtrajectoryに対して性能とコストを計算し、これらを考慮してInstructionを更新することを繰り返すAutomatic Prompt Optimizationを採用している。これにより、コストと性能のパレート最適な構成を見つける。
Auto-Routing Models, dari.dev, 2026.07
Paper/Blog Link My Issue
#Article #EfficiencyImprovement #NLP #LanguageModel #Blog #SmallModel #Selected Papers/Blogs #Initial Impression Notes Issue Date: 2026-07-25 Comment
元ポスト:
HF: https://huggingface.co/dari-ai/router-slm
Sakana FuguのようなLLMプールの中からターン単位で適切なLLMを選択するオーケストレータ（ルータ）で、QwenのLoRA Weightとして学習された重みが公開されているようである。
関連:
- [Paper Note] TRINITY: An Evolved LLM Coordinator, Jinglue Xu+, ICLR'26, 2025.12
- Sakana Fugu: A Multi-Agent Orchestration System as a Foundation Model, sakana.ai, 2026.04
- Sakana Fugu: One Model to Command Them All, SakanaAI, 2026.06
- [Paper Note] Sakana Fugu Technical Report, Yujin Tang+, arXiv'26, 2026.06
Sakana Fugu: One Model to Command Them All, SakanaAI, 2026.06
Paper/Blog Link My Issue
#Article #NLP #LanguageModel #AIAgents #Blog #Test-Time Scaling #Initial Impression Notes #Reading Reflections Issue Date: 2026-06-23 Comment
元ポスト:
所見:
Opus 4.8, Gemini 3.1 Pro, GPT 5.5（他にもありそう）のオーケストレータ
beta:
- Sakana Fugu: A Multi-Agent Orchestration System as a Foundation Model, sakana.ai, 2026.04
テクニカルレポート:
- [Paper Note] Sakana Fugu Technical Report, Yujin Tang+, arXiv'26, 2026.06
v1.1になり、新たに公開されたフロンティアモデルをルーティングに加えることで性能向上:
基本的に新たなモデルが公開されたらルーティングを更新すればFuguの性能も向上していくので、性能面でFrontier Modelに遅れをとる可能性は小さいと思われる。一方で、Fugu内部で商用APIを叩いた場合そのコストは他社のマークアップが上乗せされたものになると思うので、利用コストをどの程度抑えられるかがポイントになるだろうか。ただ、ターン単位で利用されるモデルが変更されるので、たとえばFable5を最も重要なプランニングで利用し、その後のフェーズではより安価なモデルを使う、といった柔軟なモデルの組み換えが可能なので、そこの最適化がされればタスクを完遂する際に特定の1モデルを利用するよりも結果的に安い可能性は高い。
Sakana Fugu: A Multi-Agent Orchestration System as a Foundation Model, sakana.ai, 2026.04
Paper/Blog Link My Issue
#Article #Multi #NLP #LanguageModel #AIAgents #Proprietary #Initial Impression Notes Issue Date: 2026-04-26 Comment
元ポスト:
複数のフロンティアモデルを（おそらく個々のモデルのタスクごとの強みに合わせて）動的にオーケストレーションすることで高い性能を達成する
テクニカルレポート:
- [Paper Note] Sakana Fugu Technical Report, Yujin Tang+, arXiv'26, 2026.06