今週のTOPIC

[paper]LoongFlow: Directed Evolutionary Search via a Cognitive Plan-Execute-Summarize Paradigm

Baidu による、新しい進化型エージェント LoongFlow の提案。AlphaEvolve の進化版。進化的アルゴリズムを活用して、与えられた問題を解くアルゴリズムを改善していく。

進化的アルゴリズムに最近のAIエージェントの知見を組み合わせていったという印象を持ちました。

AlphaEvolveってそんな探索効率悪いんだ。

PESパラダイムのほうはいわゆるエージェントのReflection的な話か。ハイブリッド進化メモリも、その名の通りメモリ管理の話。多様性の部分はマルチエージェントの話。

Summary を構造化して残し、次世代以降で活用しやすいように。

マルチエージェントだなと思った。基本的に独立して動くサブエージェント群をうまいこと組み合わせることでより良い多様なアウトプットを目指す。

 

[blog] Understanding Manifold Constrained Hyper Connections

DeepSeek-AIがクリスマス🎄 に出したmHC (Manifold-Constrained Hyper-Connection) の解説記事。ざっくり理解ではResNetの進化版と捉えて良さそう。

 

 

ResNet

ResNetでは、恒等写像を横からくっつける。これによって、深いネットワークの学習安定化につなげている。

ただし、DeepSeekの27Bパラメータとかになってくると、接続パターンが多様化して対応できなくなっていた。

Hyper Connections (HC)

ByteDanceが発表した接続方法（論文）。トポロジカルな複雑性を高めるアーキテクチャ。

3つのマッピング機構を使って、線形に次元数を調整している。

（重み）行列に制約がないので、信号の増幅や減衰を引き起こし、大規模な学習で不安定になる可能性がある。

Manifold-Constrained HC (mHC)

二重確率行列のバーコフ多面体 (Birkoff polytope of doubly stochastic matrices)を使ってHCの安定化を図っている。ざっくりいうと行列の行と列の合計が1になるように制約している。

二重確率行列

• 非負性: 行列内のすべての要素が 0 以上である

• 行の和が1: どの行（横一列）の要素を足しても合計が 1 になる。

• 列の和が1: どの列（縦一列）の要素を足しても合計が 1 になる。

二重確率行列の利点として以下のことがあるらしい。

• 信号の安定化（Norm Preservation）二重確率行列のスペクトルノルム（最大特異値）は 1 以下になります。これにより、信号が層を通過する際に過度に増幅（爆発）したり減衰（消失）したりするのを防ぎ、学習を安定させます 。

• 層を重ねても性質が保たれる（Compositional Closure）「二重確率行列同士の積もまた二重確率行列になる」という数学的な性質があります。これにより、深い層まで重ねていっても信号の総量や性質が保存され、安定した情報の伝播が可能になります 。

• 凸結合としての解釈幾何学的には、入力特徴量の「凸結合（Convex Combination）」として機能します。つまり、情報を混ぜ合わせる（Mixする）役割を果たしますが、信号の総エネルギー量は変えないため、恒等写像（Identity Mapping）に近い安定性を保つことができます 。

 

これによって、複数レイヤに渡って恒等写像の特性が復元されて、信号の消失や爆発を防ぎながら拡張残差ストリームのパフォーマンス上の利点を維持できる。

 

HCのフォワードパスはこのようになっているが

レイヤを重ねるとこのようになって、 が発散してしまう（第一項）。この を二重確率行列 (doubly stochastic matrix) というらしい。

mHCでは、 に次の制約を加えて発散を防ぐ。Sinkhornアルゴリズムを使って、列と行を繰り返し正規化することで二重確率行列にしているらしい。

 

ひとことまとめ

HCと同じ構成だが、Res Mapping行列 に制約を加えることで信号の発散を防いでいる。

 

結果

mHCは安定的に学習できている。勾配も跳ねてない。

性能も良い

---

[paper] How to Auto-optimize Prompts for Domain Tasks? Adaptive Prompting and Reasoning through Evolutionary Domain Knowledge Adaptation

目的と課題

理想的には、適切に構築されたセマンティック因果グラフ（SCG: Semantic Causal Graph）と効果的なシステムプロンプトは、LLMの推論プロセスと予測性能を大幅に向上させる。しかし、現実には以下の2つの問題により性能が変動する可能性がある。

• SCGが不完全または不正確である

• システムプロンプトがLLMを効果的にガイドできない

EGO-Promptは、これらの課題に対処するため、テキスト勾配手法をSCGおよびプロンプトの最適化に応用する。

 

Iterative Optimization

テキスト勾配を利用して、システムプロンプト、SCG 、および因果システムプロンプトを更新する。SCGの修正は、以下の3つの操作に限定される。

• 候補ノードセットからのノードとその因果記述・リンクの追加

• ノードとその関連記述の削除

• 不正確または不必要な既存記述の編集

これらの仕組みにより、EGO-Promptは人間の専門家が作成した不完全な初期SCGとプロンプトを、グラウンドトゥルースデータからのテキスト勾配に基づいて自動的に洗練し、LLMのドメイン固有タスクにおける推論精度と解釈性を向上させている。

 

[pon]node数 edge数が10程度の小さなグラフ(実験より)を想定してるし、groundtruth必要だったりとちょっと使いにくさはある

---

[report]Uni-Parser Technical Report

概要

科学文献や特許などのPDFドキュメントを、構造化データへ変換するために設計された解析エンジン。 VLM（視覚言語モデル）によるEnd-to-End解析ではなく、特化型モデルを組み合わせたパイプライン方式を採用。

さらに、それを支える非同期マイクロサービスアーキテクチャにより、単一ページの処理速度だけでなく、システム全体のスループット（単位時間あたりの処理枚数）を最大化し、20ページ/秒という性能を実現している。

背景と課題

科学文献や特許には、テキスト以外に「数式」「化学構造式」「表」「グラフ」が混在しており、既存手法には以下の課題が存在した。

• VLMベースの手法: 汎用性は高いが、計算効率が低くコストが高い。また、非テキスト領域（化学式等）で幻覚を起こすリスクがある。

• 従来のパイプライン手法: 直列処理のため遅延が発生しやすく、レイアウト解析のミスが文脈分断を招いていた。

技術的アプローチ：速度と精度の両立

Uni-Parserは、「賢いモデル」と「待たせないシステム」を融合させた設計となっている。

1. システムインフラ（速度の源泉）

単一ページのレイテンシ短縮以上に、「待ち時間の隠蔽（Latency Masking）」によるスループット向上に主眼が置かれている。

• 非同期マイクロサービス: レイアウト解析モデルが完了したバッチから即座にタスクキューへ投入される。後続の各エキスパート（OCR、化学式認識など）は、前のページの全処理完了を待たずに並列に稼働する。

• パイプライン並列化 (Pipeline Parallelism): CPU（前処理・後処理・データ転送）とGPU（推論）の処理を時間的にオーバーラップさせ、GPUのアイドル時間（Bubble time）を極小化している。

• 動的負荷分散: ドキュメントの内容（化学式が多い等）に応じて、各マイクロサービスのインスタンス割り当てを動的に調整し、ボトルネックを解消する。

2. アルゴリズムとモデル（精度の源泉）

• グループベースのレイアウト検出:
• 物体検出モデル（DETRベース）を使用。「図とキャプション」などを意味的なペアとして認識し、文脈の維持を実現する。
• 学習には50万ページ規模の独自データセット（人間によるアノテーション含む）を使用。

• 情報の統合と順序復元:
• 非同期でバラバラに処理された結果は、保持されたページ情報・座標情報・グループ情報をキーとして再統合（Gathering）される。
• ページをまたぐ段落や表についても、言語的な連続性やレイアウトの手がかりを用いてマージ処理を行い、正しい文書構造を復元する。

• 特化型エキスパートモデル:
• 既存モデルをそのまま使うのではなく、科学・特許ドメインの実データを用いた大規模なファインチューニングを行っている。
• 化学構造: MolParser 1.5。1000万枚の実データ学習を追加し、キラル/マーカッシュ構造に対応。
• 図表・キャプション: Qwen-2.5-VL-3B をベースに、数十万〜数百万件の科学図版データセットでファインチューニング（SciParser等）。
• 表構造: SLANet をベースに、化学式や数式を含む複雑な表データセットで再学習。
• その他: 数式（PP-Formulaベース）、テキスト（PP-OCRv5ベース）もそれぞれチューニング済み。

評価結果

パフォーマンス

• スループット: 8 x NVIDIA RTX 4090D GPU環境において、最大 20ページ/秒 の処理速度を報告。

• 大規模処理: 240 GPU（NVIDIA L40）クラスタ構成において、1600万件以上のドキュメントを6日未満で処理した実績がある。

化学構造認識精度

論文内のベンチマーク（Uni-Parser Benchmark）において、既存ツールと比較して高い精度を示している。

Model	All	Chiral (キラル)	Markush (省略記法)
MolParser 1.5 (Uni-Parser)	0.886	0.809	0.805
MolParser 1.0	0.800	0.676	0.664
MolScribe	0.417	0.274	0.168

考察と展望

• データ抽出への応用:
• 化学構造や反応式を高精度に構造化データとして抽出できる点は、大規模な化学・生物医学データベースの構築（AI4Science）や、RAGにおける検索精度の向上に寄与すると期待される。

• ツールキットの公開:
• としての公開が計画されている。

Adaptation of Agentic AI

About

AI Agentとツールをタスク・環境最適化する手法を4パターンに分けて整理したサーベイ論文。

 

最適化対象と手法で4パターンに分けている

 

パターン

A1：Tool Execution Result as Signal

• ツール実行結果を教師信号としてエージェントを最適化する

• SFT→近年ではRLVRを軸に、PPO/GRPOでツール操作精度をあげる方向が人気に
• RLVR：自動計算可能な報酬をもとにRLする手法

A2：Agent Output as Signal

• Tool利用有無を問わず、最終的な出力を教師信号としてエージェントを最適化する

• ショートカット学習や評価ハックに脆い

T1：Agent-Agnostic Tool Adaptation

• LLMは固定し、Toolを最適化する

• RetriverやReranker, Plannerなどの出力結果を評価し、精度改善を行う

T2：Agent-Supervised Tool Adaptation

• LLMは固定するがLLMの出力評価をもとにツールを最適化する

• LLMが使いやすいように、どのようにツールを最適化させられるか？というAとは逆のアプローチ

• 専門特化した小型Subagentをトレーニングする方向へシフトできる
• この論文の推しポイントはここ
• 強いClosedなモデルのツールとして小型LLMをタスク特化させてトレーニングする方がA2と比べて学習コストも格段に小さく済むよね
• タスク特化のLLMをスキルや知識のモジュールとして分離し、個別に学習できるようになり、柔軟性が上がる

Memo

• LLMのRLについては商用LLMのリリースノート中心に頻繁にみかけるので理解をふかめたく読んだ

• モデルによってツールの使い分けが上手い/下手のようなモデル特性の差はA1/A2の差分から生まれていそうと考えた

• 各所で述べられている「大型モノリシックvs小型専門家モジュールアーキテクチャ」構図を、エージェント適応とツール適応という学習手法の設計空間観点から評価していて学びになる

• 学習手法が公開されているモデルを手法ごとに整理してくれているのも深掘りに向いている（知らないモデルばかり）

• チューニング手法や応用例をガッと学べて良いサマリーだった
• 理解に役立ったもの
• kuto-sanのブログ
強化学習はLLMの新しい能力を『発見』しているのか？
2025年、LLM研究において強化学習(Reinforcement Learning, RL)の役割が大きくなってきています。中でも話題となったのが、2025年1月に発表されたDeepSeek-R1です。
https://zenn.dev/kuto5046/articles/41c8a08421e3a1
• TRPO/PPO/GRPO
LLMのための強化学習手法 2025 -PPO・DPO・GRPO・DAPO一気に理解する-｜olachinkei
AI Solution EngineerをやっているKeisuke Kamata (X: olachinkei) です。LLMのための強化学習手法を一気に理解する記事を書きました！構成を書きながら「万里の長城よりなげーよ」と思ったのですが、一気に理解するのも悪くないと考え、詰め込みました。お好きなペースで読んでください。 なぜ今、LLMの強化学習なのか LLMの学習プロセスは、事前学習と事後学習の2段階に分かれます。事前学習で言語能力の土台を作り、事後学習でユーザーにとって有用な振る舞いを身につける。2022年のChatGPT以降、この事後学習において強化学習（RL）が重要な役割を
https://note.com/olachin/n/n9706c13c8678
 

メインTOPIC

Recursive Language Models

概要

先行研究

長文脈処理における課題

既存の長文脈管理手法

1. アーキテクチャの変更と再訓練: より長いコンテキストを扱えるようにモデル自体を変更する方法

2. LM周辺のスキャフォールド構築: LMの周囲にコンテキストを暗黙的に処理する仕組みを構築する方法（RLMはこちら）

• コンテキスト圧縮・要約: コンテキストが閾値を超えたら繰り返し要約する手法（Baleen、OpenHands Context Condensation、ReSum等）。プロンプトの多くの部分への密なアクセスを必要とするタスクには十分な表現力がない。

• 明示的メモリ階層: MemWalker、MemGPT、mem0、gMemoryなどのように、ツリー構造やメモリ階層を構築する手法

• タスク分解とサブLM呼び出し: ViperGPT、THREAD、DisCIPL、ReDel、Context Folding、AgentFoldなどの手法。タスクの再帰的分解に焦点を当てているが、基本LMのコンテキストウィンドウを超える入力を処理できない。

主要な貢献

1. Recursive Language Models (RLM) の提案

1. プロンプト が与えられると、RLMはRead-Eval-Print Loop (REPL)プログラミング環境を初期化し、 を変数の値として設定

2. LMに環境の一般的な情報（例：文字列の長さ）を提供し、を覗き込んで分解するコードを書くことを許可

3. 実行による副作用を反復的に観察可能

4. 重要: RLMは、LMが生成するコード内で、プログラム的にサブタスクを構築し、自身を再帰的に呼び出すことを推奨

実装: rlm/core/rlm.py のRLMクラスが上記のメカニズムを実装。completion()メソッドが反復ループを制御し、_completion_turn()で各ステップのLM呼び出し→コード抽出→REPL実行を処理。

2. 推論時スケーリングによるコンテキスト拡張

3. タスク非依存の汎用手法

実験結果

評価タスク

• 概要: 大量の無関係なテキストから特定のフレーズや数値を見つけるタスク

• 複雑性: 入力サイズに関わらず一定の処理コスト（定数オーダー）

• タスク数: 50タスク

• 評価指標: Accuracy (正しいフレーズを見つけられたタスクの割合)

• 概要: DeepResearchのための多段階質問応答ベンチマーク。複数の文書にわたる推論が必要

• 複雑性: 複数の文書から情報を組み合わせる必要があり、S-NIAHより複雑

• データ: 10万文書のオフラインコーパスから1000文書を提供

• タスク数: 150タスク（ランダムサンプリング）

• 評価指標: Accuracy

• 概要: 入力のチャンクを意味的に検査・変換し、集約して最終回答を形成する長時間推論ベンチマーク

• 複雑性: データセットのほぼすべてのエントリを使用する必要があり、入力長に対して線形にスケール。(該当するエントリを全て抜き出せ、のようなタスク)

• タスク数: 50タスク（質問の意味ラベル付きデータセット）

• 評価指標: 数値回答は 、その他は完全一致

• 概要: OOLONGのtrec_coarse splitを手動で修正し、チャンクのペアを集約する必要がある20の新しいクエリを追加

• 複雑性: データセットのエントリのほぼすべてのペアを使用する必要があり、入力長に対して二次にスケール。(該当するペアを全て抜き出せ、のようなタスク)

• 評価指標: F1スコア

• 概要: コードリポジトリ理解のための多肢選択タスク

• 複雑性: コードベース内の固定数のファイルにわたる推論が必要

• 評価指標: 正解率

評価手法とベースライン

• GPT-5 with medium reasoning（商用最先端モデル）

• Qwen3-Coder-480B-A35B（オープン最先端モデル）

1. Base Model: LMを直接使用

2. RLM with REPL: Python REPL環境にコンテキストを文字列としてロード。サブLMへのクエリが可能
• GPT-5実験では、再帰呼び出しにGPT-5-miniを使用、ルートLMにGPT-5を使用

3. RLM with REPL, no sub-calls: サブLM呼び出しなしのアブレーション版

4. Summary agent: コンテキストが閾値を超えると要約を繰り返すエージェント
• GPT-5では、コスト削減のため圧縮にGPT-5-nanoを使用

5. CodeAct (+ BM25): ReActループ内でコードを実行できるエージェント。BrowseComp+ではBM25レトリーバーを装備

主要な実験結果

主要な観察結果

• すべてのタスクで、RLMはフロンティアLMの実効的コンテキストウィンドウをはるかに超える入力タスクで強力な性能を実証

• 基本モデルや一般的な長文脈手法を最大2倍の性能で上回りながら、同等またはより安価な平均トークンコストを維持

• BrowseComp-Plus (1K)の例:
• GPT-5-miniが6-11M入力トークンを取り込むコストは$1.50-$2.75
• RLM(GPT-5)の平均コストは**$0.99で、要約およびレトリーバルベースラインを29%以上上回る

• OOLONG:
• RLM(GPT-5)は基本モデルを28.4%上回る
• RLM(Qwen3-Coder)は基本モデルを33.3%上回る

• OOLONG-Pairs:
• GPT-5とQwen3-Coderの基本モデルは両方ともF1スコア<0.1%とほとんど進展なし
• RLM(GPT-5): 58.00%のF1スコア
• RLM(Qwen3-Coder): 23.11%のF1スコア
• 極めて情報密度の高いタスクを処理するRLMの創発的能力を強調

• サブ呼び出し機能なしでも、RLMのアブレーションはモデルのコンテキスト制限を超えてスケール可能

• CodeQAとBrowseComp+（Qwen3-Coder）では、アブレーション版がRLMを17.9%と3%上回る

• すべての情報密度の高いタスクで、RLMはサブ呼び出しなしのアブレーション版を10%-59%上回る

• GPT-5の性能は、より複雑なタスクで著しく速く劣化

• RLM性能も劣化するが、はるかに遅い速度で劣化

• コンテキスト長が を超えると、RLMは一貫してGPT-5を上回る

• RLMコストはタスクの複雑性に比例してスケールするが、GPT-5と同じオーダーのコスト内に留まる

• GPT-5の場合、中央値のRLM実行は中央値の基本モデル実行より安価

• しかし、多くの外れ値RLM実行は基本モデルクエリよりも著しく高価

• 要約ベースライン（全入力コンテキストを取り込む）と比較して、RLMはすべてのタスクで強力な性能を維持しながら最大3倍安価

• BrowseComp-Plusでは、RLM(GPT-5)がほぼすべてのタスクを解決する一方、RLM(Qwen3-Coder)は半分しか解決できない

• RLMシステムプロンプトは各モデルですべての実験で固定され、特定のベンチマークに調整されていない

• GPT-5とQwen3-Coderの唯一の違いは、Qwen3-Coderに対してサブ呼び出しの使いすぎを警告する追加の行のみ

RLM軌跡における創発パターン

パターン1: モデルの事前知識に基づくコード実行による入力情報のフィルタリング

• コンテキストをルートLMに数行印刷してプローブ

• その観察に基づいてフィルタリング

• サブLMを使用して検証を実行することで、暗黙的にcontext rotを回避

• コード実行のみを使用してプログラム的に回答の正しさを検証

コード実装の詳細

主要な機能

1. 変数: クエリに関する極めて重要な情報を含む変数
• 以下のようにしてまずcontextを読み込むコードを実行して、変数に格納

2. 関数: REPL環境内でLLMをクエリする関数（約500K文字を扱える）

3. 文: REPLコードの出力を表示し、推論を継続する能力

実装: rlm/environments/local_repl.py でとが実装。ソケット通信経由でのLMHandlerにリクエストを送信し、サブLM呼び出しを実現。

1. : 回答を直接提供

2. : REPL環境で作成した変数を最終出力として返す

状態管理

• Local実行は辞書に格納

• Docker環境は.ファイルに格納
• (知らなかったけど、pklの上位互換で関数なども保存できる形式らしい)

Qwen3-Coder版との違い

サマリーエージェントベースライン

1. コンテキストが満杯になるまで反復的に入力を与える

2. 満杯になった時点で、すべての関連情報を要約するようクエリ

3. 要約後、継続

4. 単一ステップでモデルのコンテキストウィンドウより大きいコンテキストが与えられた場合、このコンテキストをチャンク化し、これらのチャンクに対して要約プロセスを実行

CodeActベースライン

関連研究との比較

長文脈LMシステム

RLMの独自性

1. シンボリック操作: プロンプトを外部環境に配置することで、任意の長さの文字列をシンボリック的に操作可能

2. 実行フィードバック: 永続的なREPL環境からの実行フィードバックを通じて再帰を反復的に改善

3. 情報損失なし: 要約のような非可逆的圧縮を行わず、必要に応じてコンテキストのすべての部分にアクセス可能

制限事項と今後の課題

1. 最適な実装メカニズムの探索不足

• 非同期サブ呼び出し: ランタイムと推論コストを大幅に削減できる可能性

• サンドボックス化されたREPL: セキュリティとパフォーマンスの向上

実装: 公式実装では複数の実行環境をサポート（rlm/environments/）:

• : ホストプロセスで直接実行（Python 使用）

• : Docker隔離環境

• : Modalクラウドサンドボックス

バッチ処理による並列サブLM呼び出しもで実装済み。

2. 再帰の深さの制限

実装: RLMクラスのmax_depthパラメータで制御。深度上限に達すると通常のLM呼び出しにフォールバック。

3. 既存のフロンティアモデルのみでの評価

実装: 公式実装では多様なバックエンドをサポート（rlm/clients/）: OpenAI, Anthropic, OpenRouter, Portkey, LiteLLM, ローカルモデル（vLLM経由）

4. 小規模入力でのわずかな性能低下

5. 高い分散とランタイムコスト

• 中央値は基本モデルより安価

• しかし外れ値は著しく高価

• 現在の実装ではすべてのLM呼び出しがブロッキング/シーケンシャル

実装: max_iterationsパラメータ（デフォルト30）で反復上限を制御。rlm/logger/で実行時間とトークン使用量を記録し、コスト分析が可能。

結論

主要な成果

1. 劇的なスケーラビリティ: モデルのコンテキストウィンドウの100倍を超える入力を処理可能

2. タスク非依存: 単一の固定プロンプトで多様なタスクに対応

3. コスト効率: 同等またはより低いコストで大幅な性能向上

4. 推論時のみ: 訓練やアーキテクチャ変更が不要

実装の核心

• Python REPL環境に変数としてコンテキストをオフロード

• LMがコードと再帰的LM呼び出しでコンテキストを推論可能

• 純粋にトークン空間ではなく、プログラム的な操作を可能に

今後の展望

• RLMとして推論するようにモデルを明示的に訓練する今後の研究

• これにより、次世代の言語モデルシステムのための別のスケール軸が生まれる可能性

Appendix

タスク複雑性とスケーリングパターンの新しい視点

論文は、長文脈処理を考える上で重要な視点を提供。

仮説: LMの実効的コンテキストウィンドウは、タスクと独立して理解できない

これは、従来の「モデルXのコンテキストウィンドウはYトークン」という単純な理解を超える。

タスクの複雑性の分類:

• 定数オーダー (S-NIAH): 入力サイズに関わらず一定の処理

• 線形オーダー (OOLONG): 入力のほぼすべてのエントリを処理

• 二次オーダー (OOLONG-Pairs): 入力のほぼすべてのペアを処理

この分類により、タスクの本質的な難しさを定量化でき、どの手法が適切かを判断可能。

コスト分析の詳細

 

論文は、平均コストだけでなく、四分位点やコスト分布も詳細に報告：

• 25パーセンタイル、50パーセンタイル（中央値）、75パーセンタイル、95パーセンタイル

• これにより、外れ値の影響を理解可能

GPT-5の場合、RLMの中央値コストは基本モデルより安価だが、95パーセンタイルでは著しく高くなる。一部のタスクで非常に長い軌跡が生成されることを示す。

実用的な示唆

1. いつRLMを使うべきか:
• 入力がモデルのコンテキストウィンドウを超える場合
• 情報密度が高いタスク（プロンプトの多くの部分への密なアクセスが必要）
• 複雑な推論が必要なタスク

2. いつ基本LMで十分か:
• 入力が短く、モデルのコンテキストウィンドウに収まる場合
• シンプルなタスク（例：S-NIAHのような定数オーダーの複雑性）

3. コスト管理:
• 中央値コストは基本モデルと同等またはより低い
• しかし、一部のクエリで高コストの外れ値が発生する可能性
• 非同期実装により、ランタイムとコストをさらに削減できる可能性

まとめ