計画実行インテリジェンスは、これまでの設計よりも高速で、コスト効率が高く、タスク実行のパフォーマンスが高いソリューションを提供します。この記事では、LangGraphで3つの計画インテリジェンスを構築する方法を説明します。
私たちはLangGraphプラットフォームに3つの「計画・実行」モード知能を導入しました。これらの知能は、従来のReason and Act (ReAct)モードの知能に比べ、いくつかの改良が加えられています。
⏰ 第一に、これらの知能は、各アクションを完了した後に再び大規模知能の関与を要求する必要がないため、複数ステップのタスク処理をより迅速に実行できる。各サブタスクは、大規模言語モデル（LLM）を追加で呼び出したり、軽量LLMサポートを呼び出したりすることなく完了できる。
第二に、ReActインテリジェンスに比べてコストを効果的に削減できる。サブタスクにLLM呼び出しが必要な場合、通常、より小さく、ドメインに特化したモデルが使用されます。大きなモデルは、（再）計画ステップを実行し、最終的な応答を生成する必要がある場合にのみ呼び出されます。
🏆 最後に、タスク全体を完了するのに必要なプロセスをステップバイステッ プで明確に「考える」ようプランナーに求めることで、これらの知 識はタスク完了率と質の面でより良い結果を出すことができる。詳細な推論ステップを開発することは、成果を向上させる有効なキューイング技法である。問題を細分化することも、より集中的で効率的なタスク遂行につながる。
背景
この1年で、言語モデルに基づくインテリジェント・エージェントとステートマシンが、柔軟で効率的なAI製品を開発するための有望な設計パラダイムとして台頭してきた。
エージェントの核となるのは、一般的な問題解決ツールとしての言語モデルであり、質問に答えたりタスクを実行したりするために外部のリソースに接続する。
通常、言語モデルに基づく知的エージェントは、次のような主要なステップを踏む：
1.アクションの提案：言語モデルは、ユーザーに直接応答するか、機能に伝達されるテキストを生成する。
2.アクションの実行：コードが他のソフトウェアを呼び出して、例えばデータベースへの問い合わせやAPIの呼び出しなどの操作を実行する。
3.オブザーブ Observe：別の関数を呼び出すか、ユーザーに応答することによって、ツールの呼び出しからのフィードバックに反応する。
リ・アクト 知的エージェントはその好例で、思考、行動、観察の反復サイクルを用いて言語モデルを導く：
考える：現在の試合のスコアを調べるためにSearch()を呼び出そう。
アクション：Search("現在のXマッチのスコアは？")
観察：現在のスコアは24-21
...(N回繰り返す）
これは典型的なReActスタイルのインテリジェント・エージェントの軌跡である。
このアプローチは、次のようなものである。思考の連鎖プロンプトを表示することで、各ステップで1つのアクションしか決定しないようにする。これは単純作業には効果的だが、大きな欠点もある：
1.各ツールの呼び出しには、言語モデルの呼び出しが必要です。
2.言語モデルは一度に1つのサブ問題を計画する。これは、タスク全体について「推論」することを余儀なくされないため、最適でない処理軌道を導く可能性がある。
この2つの欠点を克服する効果的な方法は、明示的な計画ステップを含めることです。以下はLangGraphで実装した2つの例です。
計画・実行システム
プログラム実施機関
この単純な構造は、Wangらの論文[ ]に基づいている。計画と解決のヒントによって提案され、中島洋平の[ ]を参考にしている。BabyAGI]プロジェクトは、典型的なプランニングエージェントアーキテクチャとなった。これには2つの主要な基本コンポーネントが含まれている：
1.プランナー（A） プランナー)は、言語モデル(LLM)に複雑なタスクのマルチステッププランを生成するよう指示する役割を担っている。
2.複数のアクチュエータ遺言執行者(s))は、ユーザーのクエリ要求とプランのステップを処理し、そのタスクを実行する1つ以上のツールを呼び出すことができる。
タスクの実行が完了すると、エージェントは新しい計画プロンプトで再び呼び出され、その時点で、単に終了するための応答を提供するか、必要に応じて（元の計画がそのゴールに到達しなかった場合）さらなる計画を生成するかを決定する。
このエージェント設計により、ツールを起動するたびに大規模な計画言語モデルに依存する必要がなくなる。しかし、変数への代入操作をサポートせず、ツールを連続的に起動する必要があるため、タスクごとに個別の言語モデルが必要となる。
独立した観察を超えた推論
で [リウーXuらは、各タスクが大規模言語モデル（Large Language Model: LLM）に依存しなければならないという従来の方法を逆転させ、後続タスクが前のタスクの結果に依存できるようにした新しいエージェントモデルを考案した。このモデルは、出力計画に変数代入の機能を組み込むことによって実装される。下図はこのエージェントモデルの設計を示している。
ReWOOエージェントモデル
プランナは、"E# "行と交互に "plan"（推論）を含む計画のリストを生成する責任を持ちます。例えば、"What are the quarterback statistics for this year's Super Bowl contenders? "という問い合わせに対して、プランナは以下のプランを生成するかもしれません：
プラン：今年のスーパーボウル出場チームを知りたい
E1: [スーパーボウルを狙うのは誰か]を探す
プラン：全チームのクォーターバックを知りたい
E2：LLM【1stチームQB #E1
プラン：全チームのクォーターバックを知りたい
E3：LLM【2ndチームQB #E1
プラン：最初のクォーターバックのスタッツを調べる必要がある。
E4：[#E2のクォーターバックのスタッツ]を検索する
プラン：2人目のクォーターバックのスタッツを調べる必要がある。
E5: [#E3のクォーターバックのスタッツ]を検索する
プランナー(プランナー) `#E2`のような構文を使って、どのように以前の出力を参照できるのか。つまり、毎回スケジュールを組み直すことなく、一連のタスクを実行することが可能です。
「労働者たちワーカー) "ノードは各タスクを繰り返し実行し、その出力をあらかじめ決められた変数に代入する。そして、後続のタスク呼び出しが実行されると、これらの変数は対応する結果で置き換えられる。
最終的には、「リゾルバー(ソルバー)「すべての出力を統合して、最終的な答えを導き出す。
このエージェント設計思想は、各タスクが必要な文脈情報（すなわち、その入力と変数値）のみを含むため、単純な計画-実行モデルよりも効率的である。
しかし、この設計は依然として逐次的なタスク実行に基づいているため、全体的な実行時間が長くなる可能性がある。
LLMCompiler
LLMCompilerエージェント
LLMCompiler の組み合わせだ。チーム・キム]は、以前に説明したReWOOエージェントによる計画実行よりもタスク実行効率を向上させ、OpenAI並列ツール呼び出しよりもさらに高速になるように設計されたエージェントアーキテクチャを開発した。
LLMCompilerは以下の主要部分から構成されている：
1. プランナータスクの有向非循環グラフ（DAG）を生成する。各タスクには、ツール、パラメータ、依存関係のリストが含まれる。
2. タスクフェッチユニット（TFU） タスクのスケジューリングと実行を担当する。タスクのストリームを受け入れ、それらの依存関係が満たされたときにスケジューリングすることができる。多くのツールはサーチエンジンやLLMを追加で呼び出す必要があるため、この並列実行によって速度を大幅に向上させることができる（論文によれば最大3.6倍）。
3. コネクター（ジョイナー）この部分は、タスクの実行結果を含むタスク実行の全履歴に基づいて、動的にタスクを再計画または終了することができる。これはLLMセッションにおいて、最終結果を直接提示するか、作業を継続するためにプランナーに進捗を返すかを決定するステップです。
実装を加速させるこのアーキテクチャの重要なポイントは、次のとおりだ：
- プランナーの出力はストリーミングタスクのパラメータとその依存関係を即座に出力することができる。
- タスク獲得ユニット ストリームで送られてくるタスクを受け取り、すべての依存関係が満たされたときにスケジューリングを開始する。
- タスクのパラメータはバリアントすなわち、有向無サイクルグラフの前のタスクの出力である。例えば、このモデルは次のように表すことができる。
search("${1}")タスク1によって生成された検索コンテンツをクエリする。このアプローチにより、エージェントはOpenAIの通常の並列ツール呼び出しよりも効率的に作業することができます。
タスクを有向無サイクルグラフに整理することで、ツールを呼び出す際の貴重な時間を節約するだけでなく、より良いユーザーエクスペリエンスを提供する。
概要
これら3つのプロキシ・アーキテクチャは、Plan-Doデザイン・パターンのプロトタイプであり、LLM駆動の「プランナ」とツール実行ランタイムを分離しています。アプリケーションでツールやAPIを複数回呼び出す必要がある場合、これらのアプローチにより、最終結果を得るまでの時間を短縮し、上位レベルのLLMの呼び出し回数を減らすことでコストを削減することができます。
