• ICML 2025 Workshop on Multi-Agent Systems

• レポジトリ：https://github.com/chengqiArchy/MermaidFlow

• 従来のワークフロー生成は、Planが脆弱なために実行不可能なワークフローを作りがち。

• Mermaidでグラフを表現することで静的解析、可視化、コード生成までを一貫して行えるようにした。

• 最適化として進化的プログラミングを採用した。

• 既存研究
• AFlow、MaAS、MetaGPTなどのシステムは通常、ワークフローをPythonスクリプトやJSONツリーを使用して表現
• 計画の決定が実装の詳細と密結合している
• 問題
• 実行時のみのエラーしか検知できず、失敗が高コスト
• 小さな変更でもワークフロー全体を無効にしてしまい、再検証コストがでかい
• 解釈可能性が低い。構造が暗黙的で、人間にも機械にも読み解きにくい。
• 再利用性が限られる
• GPTSwarmのインタラクショングラフやMetaGPTのSOPスタイルのテンプレート
• 静的解析がしにくい、形式の自由度が高い
• DebFlowやEvoFlowのような進化的アプローチ
• 制約が弱く計算リソースが無駄になる

• 手法



• 宣言的グラフ
• まず何をしたいか (ノードの役割や入出力、エッジ)を明示し、実装と切り離す
• これにより、構造と意味が人間にも機械にも明快に見え、静的検証が可能になる。これが共通インターフェースになる。
• ノードは をもち、 は入出力の型変換、 はPromptや分析方針など、コード生成時に必要な情報が入る。エッジにはラベルをつけて、情報の種類や流れを明示しつつ、ノードの を使って型整合を取る。
• ノードに型をもたせているので、 と で機械的にPromptと入出力フォーマットを一意に定めることで、Mermaid → Pythonへの変換が規則的で安定する。
• ノードの編集はMermaidの静的な制約の中での局所的な編集に閉じることができる。
• 静的検証とカスタムチェック Mermaidの文法レベルの検証に加え、ワークフロー特有のルール（PROBLEMとRETURNの存在、全ノードが入力から出力までつながっているか、Ensembleノードには複数入力があるか、など）を独自のチェッカーで確認。
(Appendix ) Node タイプ
1. - 特殊な推論戦略に使用され、定義された役割を通じて特定のタスクを実行する。 例：K["Custom<br/>(role: validate_1)"]
2. - ワークフローのエントリーノードと終了ノードであり、問題の入力点と出力点の両方を含む。 例：PROBLEM([Problem])
3. - コード生成と計算を実行するノードであり、特に数学的な問題に適している。 例：P["Programmer<br/>(analysis: ’Calculate step by step’)"] 数学の問題のみがこのノードタイプを使用する。
4. - 複数のソリューションを1つの結果に結合するノードであり、適切に機能するには複数の入力を必要とする。 例：ENSEMBLE["ScEnsemble<br/>"]
5. - ソリューションをValidationするためのノードであり、コードが定義済みのテストケースに合格するかどうかを確認するために使用。 例：T["Test<br/>" コードの問題のみがこのノードタイプを使用する。
6. - 問題の説明に基づいてコードを生成するために特別に設計されたノード。 例：CODE_GEN["CustomCodeGenerate<br/>(instruction: xxx)"] コードの問題のみがこのノードタイプを使用する。
• 進化的プログラミング
• 以下の操作を行う
1. Node置換
2. Node追加
3. Edgeの再配線
4. Node削除
5. サブグラフの変異
6. 交叉
• 二つの親グラフが共有するインターフェース節点(型・インターフェース整合が保たれる点) を境にサブグラフを入れ替え。
(Appendix) Validation
• ハードチェック：MermaidCLIによる構文コンパイル
• ソフトチェック：Mermaidコードから正規表現などでコンポーネント情報を引っ張ってきてチェック
• 以下のValidationを実装
1. W1 - 必須のPROBLEMおよびRETURNインターフェースノードの存在を確認
2. W2 - 各ノードがPROBLEMからRETURNへのパスを持つワークフロー内で適切に接続されていることを確認
3. W3 - PROBLEMおよびRETURNノードがインターフェース型として正しく分類されていることを検証
4. W4 - すべてのノードが構成に従って有効な型を持っていることを確認
5. W5 - ScEnsembleOpノードが少なくとも2つの入力接続を持つことを確認
• 各世代の探索で、履歴バッファに「過去の有効ワークフローとスコア」蓄積。スコアを元に親を二つサンプリングしてから、LLM-as-a-Judgeで「タスク適合性・構造品質・一貫性」などを評価し、最有望の子だけを選んで本評価に回す。
• (ponさんのblogで言うところのVerifier的な)
• LayerX エンジニアブログRepeated Samplingを使ったLLM推論時スケーリングで麻雀点数計算問題生成タスクを解くぞ！ - LayerX エンジニアブログ
• 全体のサイクル
• 初期化: 既知の良質なMermaidワークフローを用意し、履歴バッファに格納。
• 親選択: 履歴バッファからスコアと多様性を考慮して親を二つ選ぶ。
• 生成: N個の候補グラフをLLMで生成。
• 静的検証: ハード＋ソフトチェックで不適合を排除。
• 予備評価: LLM-as-a-Judgeで有望度をスコアリングし、トップの子を選抜。
• 実行評価: 選抜子をコード生成して実行し、解答精度やpass@1等のメトリクスでスコア化。
• 更新: 子とスコアを履歴バッファに追加し、次ラウンドへ。 このループで、壊れにくく、かつ改善が積み上がる探索が実現します。

• 結果
• MATHとCode系のベンチマークでSoTAより全体的に改善



• AFlowより効率も良い

• LLM Evaluation Framework

• LLM as a Judge の実装が豊富で、自前で実装するときの参考によさそう
• GitHubdeepeval/deepeval/metrics at main · confident-ai/deepeval

• e.g. conversation_completeness ‣
1. extract_user_intentions
会話からユーザーの「意図（目的）」を抽出し、JSONで返す。
2. generate_verdicts
その意図が会話の中で満たされたかを判断し、 の形で返す。
3. generate_reason
全体の「完成度スコア（0〜1）」に対して、なぜその点数なのかを簡潔に説明する理由文をJSONで返す。

• Reasoningタスクに有効なべき分布によるサンプリング

• ベースモデルの尤度に従ってトークンサブシーケンスを反復的にリサンプリングするMCMCを提案。これにより、べき分布の近似サンプリングができる。

提案手法：べき分布からのMCMCサンプリング

アルゴリズム

ブロックごとに処理する＋MCMCステップが確定したらそのブロックを確定させて、次のブロックにすすむ（10行目の処理っぽい）

結果

Shift Parallelism

• 従来の並列化アプローチ（例：TP(Tensor Parallelism)、DP(Data Parallelism)）が特定の指標（低レイテンシまたは高スループット）のために静的に最適化されていた

• これはKVキャッシュのメモリレイアウトがTPとSP間で違うため、データ変換/転送コストが高くなるため

• Shift Parallelismは動的に以下の2つのモードを切り替えることで、これらすべての指標を単一のデプロイメントで達成します
• Tensor Parallelism (TP)：小規模なバッチ向けで、TPOT(Time Per Output Token)を最大化します
• Sequence Parallelism (SP) ：大規模なバッチ向けで、TTFT(Time To First Token)を最小化し、ほぼ最適なスループットを実現します。
• つまりSPはDPをTPとKVキャッシュメモリレイアウトが不変になるように設計されたもの

• これらをバッチサイズによって切り替える！

• ‣
• 評価スクリプト

• データセット：　soya.infini-cloud.net
• 入手するためには登録が必要。

• 早稲田大学、CyberAgent、AI Shiftの論文

• 感想
• 動画と旅行と地理情報という自分の興味ど真ん中なテーマ
• Appendixが豊富で面白い

1. はじめに (Introduction)

• 背景と課題:
• 近年のMLLMは動画理解において顕著な進歩
• 既存のベンチマークは主に屋内シーンや短時間の屋外活動に焦点を当てており、複数都市にまたがる数日間の旅行のようなマクロなスケールのシナリオが未検討

• VIR-Benchの提案: このギャップを埋めるため、旅行Vlog動画から旅程を再構築するタスクを設計。再構築された旅程は「訪問順序グラフ（Visiting Order Graph）」として表現され、場所（ノード）と、それらの地理的包含関係および時間的遷移関係（エッジ）から成る

• 主な発見: 最先端のプロプライエタリ（クローズド）モデルであっても、特にPOI（地点）の特定や遷移関係の予測において苦戦しており、長時間の空間的・時間的スケールを扱う難しさが浮き彫りに

• 応用: 本ベンチマークの知見を活用した旅行計画エージェントのプロトタイプを開発し、実際のアプリケーションにおける有効性を検証

2. 関連研究 (Related Work)

2.1 動画ベンチマーク (Video Benchmarks)

2.2 旅程抽出 (Itinerary Extraction)

2.3 旅程生成 (Itinerary Generation)

3. データセット構築 (Dataset Construction)

3.1 訪問順序グラフ (Visiting Order Graph)

• ノード（場所）:
• Root: グラフの開始ノード
• Prefecture（都道府県）: 最上位の行政区画（例：東京、大阪）
• City（市区町村）: 都道府県内の自治体（例：千代田区、名古屋市）
• POI（Point of Interest）: 具体的な施設名（例：東京駅、MIRAI TOWER、特定のレストラン）

• エッジ（関係性）:
• Inclusion（包含）: 地理的な包含関係（大きいエリアから小さいエリアへ。例：愛知 → 名古屋市 → 名古屋駅）
• Transition（遷移）: 同一階層レベルの異なる場所間の時間的な移動（例：東京 → 愛知、名古屋駅 → MIRAI TOWER）

3.2 データアノテーション (Data Annotation)

4. 実験 (Experiments)

4.1 タスク定義 (Task Definition)

• ノード予測: 動画から訪問したすべての場所（都道府県、市区町村、POI）をリストアップする、GeoGuessrのようなタスク

• エッジ予測: 動画と訪問場所の正解リストが与えられた状態で、場所間の包含関係（地理的知識）と遷移関係（時間的理解）を予測

4.2 ベンチマークモデル (Benchmark Models)

4.3 評価指標 (Evaluation Metrics)

4.4 主な結果 (Main Results)

• 全体性能: プロプライエタリモデルがオープンモデルを一貫して上回りました 。Gemini-1.5 Proが最も高性能だが、それでも都市/POIノード予測や遷移エッジ予測のF1スコアは約60にとどまる

• 遷移エッジ予測の困難さ: 最も難しいタスクであり、多くのモデルがF1スコア1桁台。失敗原因として、タスクの誤解釈や、階層レベルの制約（例：異なる都市のPOI間を直接遷移させてしまう）を無視する傾向が見られる

• 思考モデルの効果: o1-miniやGemini-1.5 Proのように、推論（Thinking）時間を設けることで、特にエッジ予測の性能が大幅に向上

4.5 アブレーション研究 (Ablation Study)

• フレーム数: 入力フレーム数を増やす（例：64から128以上）と、特に時間的推論が必要なタスクで性能が向上

• 音声: Gemini-1.5 Flashで音声入力を除外すると、遷移エッジ予測の性能が約50%低下し、時間的理解における音声の重要性が確認

5. 旅行計画エージェント (Travel-planning Agent)

5.1 タスク定義 (Task Definition)

5.2 エージェントシステムの実装 (Implementation of the Agent System)

5.3 実験設定 (Experimental Setup)

5.4 結果と考察 (Results and Discussion)

• P+Vの優位性: 「POIリスト＋動画」の設定が最も魅力的な計画を生成。動画は現地の雰囲気や具体的な活動といった豊かな文脈を提供し、計画の魅力を高める

• 動画のみの不安定さ: 「動画のみ」の設定では、最初のPOI特定に失敗すると、動画内容と「完全に無関係」な計画が生成される割合が最も高い（31%） 。

• POI選択戦略: エージェントは、動画内での滞在時間が長く、Googleマップでの評価が高いPOIを優先的に計画に組み込む傾向

この論文 is ?

• 現実の環境でAIエージェントを訓練するのは、お金も時間もかかり、しかも不安定。

• DreamGymは「現実で試す前に、学びに必要な経験だけをうまく作って与える」仕組み。

背景と課題

• 実環境は遅いし壊れやすい。長い操作やサーバ管理が必要。

• 与えられる課題が少なく単調で、すぐにパターン学習になってしまう。

• 成功・失敗の判定（報酬）が間違っていたり遅かったりする。

DreamGymのコア発想

• 現実そっくりを再現しない。代わりに「テキストで表した簡潔な世界」で、次に何が起きるかと成否をAIが筋道立てて作る。

• 過去の似た体験も参照して、作る内容の「現実味」を保つ。

• ちょうど良い難しさの課題を自動で増やしていく。

3つのコンポーネント

• 経験モデル: 今の状態と行動から「次に起きること」と「評価」を説明付きで作る。

• リプレイ（思い出帳）: 本物の少量データ＋過去の合成データを貯めて、参照して間違いを減らす。

• 課題ジェネレーター: 今の実力でギリ解ける課題を自動で作り続ける。

実験結果

• WebのようにRLが難しい環境でも、成功率が大きく上がった（+30%超）。

• 本物の環境で8万回試すのと同じレベルに、合成だけで到達。

• 現実に移す時は、必要な実データが10分の1で、性能は+40%。

なぜ効くのか

• 余計な見た目情報を捨て、学習に必要な筋だけを濃く与えるから。

• 「なぜそうなるか」を説明しながら作るので、ブレにくい学習信号になる。

• 常に中くらいの難しさを出し続けるので、成長が止まらない。

アブレーションと分析

• リプレイなし→現実味が下がり、間違いが増える。

• 説明なし→内容が浅くなり、評価の間違いが増える。

• 課題生成なし→すぐ頭打ちになる。

まとめ

• 問題は「どれだけ試すか」ではなく「どんな経験を与えるか」。

• 正しい経験を合成できれば、現実に出る前に強いエージェントを作れる。

• NeurIPS 2025 ワークショップに採択された研究

• Walmart の研究

対象問題

1. 大量のアイテムペアに対して単一のLLMを単純に適用するのは難しい

2. モデルファミリー、サイズ、設定によって判定がどのように変化するかについてほとんど知られていない

研究の貢献

1. ScalingEvalの提案

2. 人間のアノテーションなしの評価

キモは？

• パターンチェック
• 「この2つの商品は補完関係にあるか?」を判定
• 例: スマホ + スマホケース → ✓補完関係

• 問題点チェック
• ダメな理由を特定
• 例: 「サイズが合わない」「全く無関係」など

• レポート作成
• 良い組み合わせと悪い組み合わせをまとめる

• 36個のAIがそれぞれ独立に評価

• 各商品ペアについて投票

• 過半数の意見を「正解」とする

• 意見が割れた場合 → 「却下」を優先(保守的判断)

有効性の検証方法

1. 大規模ベンチマーク: 36種類のLLM(GPT、Gemini、Claude、Llamaを含む)を複数の製品カテゴリーにわたって体系的に比較

2. カテゴリー別分析: 構造化されたドメイン(電子機器、スポーツ)では一致しやすい。ライフスタイルカテゴリー(衣類、食品)では不一致しやすい傾向