こんにちは。Algomatic LLM STUDIO 機械学習エンジニアの宮脇です（@catshun_）。

本記事では LLM を用いたエージェントシステムの基盤となる「計画実行機能」について、ユーザ要求を構成的に分解して立案されたタスク系列（＝計画）を並列実行する LLM Compiler (Kim+'23) について紹介します。

Kim+’23 - An LLM Compiler for Parallel Function Calling arxiv.org

また LLM Compiler を LangGraph で実装した例の解説を以下に記載していますので同時に参照ください。

tech.algomatic.jp

おことわり

本記事では解説のため論文中の事例を翻訳等によって改変したり、論文内の記述を省いている場合があります。詳細については必ず論文を参照してください。
本記事は LLM 等の背景知識を持つ方向けの記事になります。
記事の誤り等がありましたらご指摘いただけますと幸いです。

1. 本研究の概要

複雑なユーザ要求に対して、構成性を仮定してタスク系列として計画的に推論を実行する際、複数のタスクを並列実行可能に編成する LLM Compiler を提案する。HotpotQA において、逐次的なタスク実行を伴う ReAct に対して LLMCompiler は 1.8 倍の高速な推論実行を達成した。

図1. HotpotQA の質問における ReAct と LLMCompiler の比較。 ReAct は各タスクを逐次的に処理する一方で、LLMCompiler は並列実行可能な処理を特定することで高速化を図る。具体的には以下を行う: (1) Planner がクエリから相互依存性を持つ複数タスクに分解し (2) Executor が依存関係を考慮しながら複数タスクを並列処理する (3) 最後にツールの実行結果を統合して最終的な応答を生成する。

2. 先行研究と比べてどこがすごい？

ReAct (Yao+'23) との比較

ReAct のようなタスク実行と思考のフェーズを繰り返す推論手法 (interleaved 型推論) は以下のような欠点が存在する。

Repetitive Function Calls: LLM の推論能力が不十分である場合や中間タスクの実行結果の連結に不備である場合に、関数の重複呼び出しや無限ループが発生する。

図A.4. HotpotQA における ReAct, LLMCompiler の呼び出し回数と正解率の関係。ReAct において 4 回以上の関数呼び出しが発生する場合に正解率低下を伴うことから、発散的動作が発生していることが分かる。
Premature Early Stopping: 目的に対してボトムアップに推論を行うことから中間推論過程が複雑になることで早期停止や不完全な情報に基づく意思決定が発生する。

図A.2. Movie Recommendation における ReAct, LLMCompiler の関数呼び出し回数と正解率の関係。ReAct の早期停止が正解率低下に影響していることが分かる。

図A.1. Movie Recommendation における ReAct, ReAct+, LLMCompiler の関数呼び出し回数の比較。LLMCompiler が 8 回の関数呼び出しを行うが、ReAct では 85% の例で早期停止する。これは精度にも影響しており、それぞれ 68.60, 72.47, 77.13 の正解率となっている。

LLM Compiler は、ユーザ要求を構成的に分解する推論手法 (decomposed-first 型推論) を採用することで、トップダウンに立案された推論計画に基づいて中間推論過程が形成されるため上記のようなエラーが緩和される。またタスク実行後に思考フェーズを含まないため、ReAct に比べて中間推論過程が複雑になりにくい。

ReWOO (Xu+'23) との比較

ReWOO は decomposed-first な計画立案を伴う推論手法であるが、立案されたタスク系列は上から逐次的に実行される。一方で LLM Compiler は 並列実行可能なタスク集合を LLM が決定する ことでより高速な実行が可能となる。

Skelton-of-Thought (Ning+'24) との比較

Skelton-of-Thought (SoT) は、骨子生成 (Skelton stage) と肉付け (Point-expanding stage) の 2 段階による言語生成手法で、生成された複数の骨子点に対して肉付けを並列に行うことで生成速度を向上させる。しかし SoT ではスケルトンタスク間に依存性がないことを前提としている。LLM Compiler は、SoT で対象としない相互依存性を持つ一連のタスクを Planner がプレースホルダ変数を用いて表現することでこの問題に対処する。

**Ning+'24, ICLR - Skelton-of-Thought**. Skelton-of-Thought では入力タスクに対して (1) 骨子の生成 (2) 肉付けの 2 段階で文章を生成することで肉付け処理を並列実行するアプローチ。一部のタスクで高速化可能であるが、依存関係を考慮しないため LLM Compiler に対して実行可能なタスク要求が限定される。

3. 技術や手法のキモはどこ？

アーキテクチャ

LLM Compiler は LLM Planner, Task Fetching Unit, Executor の 3 つのモジュールによって、複雑なユーザ要求を構成的かつ効率的にタスク系列に分解し並列関数呼び出しを可能にする。

LLM Planner

LLM の優れた構成性や推論能力を活用して、ユーザのクエリ要求から、実行すべきタスク系列をその依存関係とともに生成する。具体的には、ユーザからのクエリ、ツール定義書、文脈内計画例題を入力として受け取り、タスク系列を出力する。

**A.6-7**. Game of 24 タスクにおける Planner のプロンプトに含まれる例題と制約事項の記述。

Task Fetching Unit

Planner が立案したタスク系列おいて並列処理を含む実行準備が完了次第、Executor にタスクの実行要求を送信する。単純な fetch, queue のメカニズムで実装される。依存関係を持つタスクの出力結果はプレースホルダ型変数 $k, $k+1, .. を設定し、先行する依存タスク $k が終了次第、プレースホルダ変数$k にタスクの実行結果が格納される。

Executor

Task Fetching Unit から受理したタスクは全て独立に実行可能であると仮定されるため、受理したタスクを非同期に実行する。Executor では特定のタスクごとに事前に指定されたツールを呼び出すことが可能である。

4. どうやって有効だと検証した？

評価方法

GPT-{3,4} と LLaMA-2 を使用して、中間推論の実行タイプ別に以下の評価セットを用いて正解率、レイテンシ、トークン消費コストで評価。

図3.異なる関数呼び出しパターンとその依存グラフ。HotpotQA, Movie Recommendation は (a) のパターンを示し ParallelQA は (b,c) のパターンを示す。

HotpotQA (Yang+'18): マルチホップ推論の評価セットで本研究では検証セットを使用。図3.(a) のような 2 つのエンティティを比較する質問 1500 件で評価。
Movie Recommendation (Srivastava+'23): 4 つの選択肢から別の 4 つの映画集合と類似する映画を特定する問題。500 件の評価セットで評価。図3.(a) のような推論パスで 8 並列の検索が必要。

Movie Recommendation の質問と解答の例。
ParallelQA: 異なるエンティティの事実詳細に関する 113 件の数学的質問の評価セット。IfQA (Yu+'23) を踏襲して著者らが構築。図3. (b,c) のような推論パスの構築が必要。

e.g. If Texas and Florida were to merge and become one state, as well as California and Michigan, what would be the largest population density among these 2 new states?
Game of 24 (Yao+'23): 4 つの数と基本的な算術演算を用いて 24 を生成するタスク。例えば {2,4,4,7} が入力された場合 4 × (7 − 4) × 2 = 24 という計算過程を導く。100 件の異なる問題で評価。中間試行結果に基づく計画の再編成 が必要。
WebShop (Yao+'23): 商品購入指示が与えられ、ウェブショップ環境からアイテムを検索して購入アイテムを決定するタスク。500 件の指示で評価。LLM Compiler は ① 10 個のアイテムのリストを出力する検索機能 ② 見つかった各アイテムのリンクをクリックし、オプション、価格、属性、および利用可能な機能に関する情報を取得するエクスプローラ機能をツールとして採用。最後に収集された情報に基づいて入力指示に最も一致するアイテムを決定する。本記事では解説の対象外とする。

先行研究との比較

-- LLM Compiler は並列可能なパターンを特定することができるか？

タスク系列は互いに独立しており並列実行可能である HotpotQA, Movie Recommendation を用いて LLM Compiler が並列可能なパターンを特定することができるかを検証した。 ReAct の設定と同様にウィキペディア検索ツールを採用した（Lookup Tool はタスク解決に不要であるため採用しない）。

**表1-2**. HotpotQA, Movie Recommendation における LLMCompiler と既存手法との正解率、レイテンシ、コスト比較。ReAct† は無限ループや早期停止を抑制するためにアドホックなプロンプトを組み込んだものを示す。コストは各ベンチマークに使用された GPT の価格表に基づいて計算される。GPT モデルは

上の表 1-2 から、LLM Compiler は ReAct† に比べて同等またそれ以上の正解率を保持しつつ高速化を実現した。並列実行に加えてトークン効率の良さが高速化の要因であることが分かる（並列実行のみの影響は不明）。 ReAct が OpenAI Parallel Function Calling や LLM Compiler と比較して正解率が低いのは、前述した図 A.1,2 から早期停止が原因の一つであると考えられる。

-- LLM Compiler は複雑な推論計画でも同様に高性能な推論が可能か？

複雑なタスク依存関係を含むシナリオで LLM Compiler の計画能力を体系的に評価するため、図3 (b,c) のような推論パスの構築が必要となる ParallelQA を構築して評価を行った。ツールは ① 検索ツール ② 数学的問題を解く LLM エージェント（入力クエリを解釈し、適切な数式で numexpr 関数を呼び出す）を採用した。

**表1-2**. Parallel QA における LLMCompiler と既存手法との正解率、レイテンシ、コスト比較。コストは各ベンチマークに使用された GPT の価格表に基づいて計算される。

上の表 1-2 から、LLMCompiler が ReAct に対して同程度の正解率を示しつつ 2.15~2.27 倍の高速化を実現した。特に LLaMA-2 では LLMCompiler が +8.55% の正解率向上を示している。

Appendix.2 のエラー分析では、Parallel QA 113 件のうち 3 件のみが計画誤りであることが示されたが、これは複雑な問題を複数のタスクの依存関係に分解する LLMCompiler の有効性が強調された。

また LLM Compiler が ReAct, OpenAI Parallel Function に対して 大幅なコスト削減 を実現した。これは LLMCompiler が LLM の呼び出し頻度を減らしていることに起因している。例えば図 3.c において、OpenAI Parallel Function では、①検索タスク ②計算タスク ③最後の計算タスクの 3 回 LLM 呼び出し が必要であるが、LLM Compiler は計画に基づく推論実行により 1 回の LLM 呼び出し でこれを実現する。

-- LLM Compiler は中間的な観察によって動的な再計画が求められる場合でも推論実行が可能か？

Executor からの中間実行結果を LLM Planner に送り、LLM Planner が関連する依存関係を持つ新しいタスク系列を再生成することで LLM Compiler における再計画機能を実装し、Game of 24 で評価した。ここで使用するツールは Tree-of-Thoughts ら適応された ① thought proposer ② state evaluator ③ state evaluator の評価に基づいて thought proposer から上位 k 個の候補を選択する top k select の 3 つを用いる。これらのツールがすべて実行された後、どの提案も 24 とならない場合に再計画を実施する。

表1. Game of 24 における LLMCompiler と既存手法との正解率、レイテンシ比較。

上の表 1 から Tree-of-Thought と比較して、LLM Compiler は正解率をわずかに改善しつつ、×2.01~2.89 倍の実行速度を達成した。

ストリーム実行による更なる高速化

Planner によるタスク系列の生成をストリーム実行にすることで、各タスクの依存関係がすべて解決されるとすぐに Executor が処理できるようになり、更なる高速化が期待できる。

**表A.1.**. Planner でのストリーミングの有無による応答速度の比較。

表 A.1 ではストリーミングを使用することで、特に複雑な推論パスが要求される ParallelQA において ×1.30 倍の高速化が実現可能であることを示した。HotpotQA, Movie Recommendations においては Planner から生成されたタスク系列に依存関係がほとんど存在しないために高速化の向上幅がわずかであると考えられる。

5. 議論はある？

知見

Task Fetching Unit の並列実行・ストリーミングは実応用においても重要な手法。
ReAct に対して正解率だけでなく、実行速度・コストの面で効果的な性能を示している点が良い。

議論・改善の余地

高速化の要因がトークン効率と並列実行による 2 つであり、並列化のみによる高速化の影響が分からないため、ReWOO や対照実験による比較があっても良い。
もう少し抽象化されたシナリオでのユーザ要求（e.g. 昨年度の売り上げと売り上げに寄与した項目についてレポートして）における議論があっても良い。例えば、必要とされるツール数が膨大となる場合の推論への影響、ユーザ要求が曖昧である場合の推論の影響など。
計画および自己改善については様々な手法が提案されているので、実応用上でどれを採用するかについては悩ましいところ。