IBMニュースレター
The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
最初のLLM（OpenAI の GPT-1 や GPT-2 モデルなど）は答えを直接提供するものでした。その後、2022年に初めて到来した思考連鎖モデルの波によって、外部化された推論の要素が追加されました。モデルは応答に到達するときに本質的に「声に出して考える」ようになり、精度と説明可能性が向上しました。
その次の世代では、この推論にツール呼び出し機能を追加した拡張言語モデル（「ALMシステム」）とAIエージェントが登場しました。ReActなどの初期のフレームワークでは、思考、行動、観察のパターンが採用されており、システムは再び考察する前に生成したものを観察します。一般的には効果的ですが、ReActのようなフレームワークでは、後続の各ツール呼び出しにそれ以前のすべての会話履歴を含める必要があるため、各ステップごとにコストが累積し、大量のトークン消費が必要になる場合があります。
ReWOOは、推論を外部観測から分離させ、思考、行動、観察のパターンから脱却し、選択的にツールを呼び出したり、情報を取得したりする前に、モデルが内部で推論の一連を計画できるようにします。この分離により、不必要なやり取りが減り、モデルはタスク全体を通じて計画を維持できるようになります。
ReWOOは、複雑なタスクを分割して克服する3つの異なるモジュールを採用しています。最初にPlannerモジュールが、ユーザーのプロンプトに基づいてモデルがどのように動作するかという青写真を作成します。次にWorkerモジュールが計画を実行し、外部ツールを呼び出します（ReActのように、コストのかかるLLM API呼び出しを繰り返し実行することはありません）。最後に、Solverモジュールが計画と証拠を取得し、最終的な応答を合成します。
アプローチの違いは小さいように思えるかもしれませんが、成果は劇的です。ReWOOは、いくつかのベンチマークに対してReActと同等の（またはわずかに上回る） パフォーマンスを発揮し、しかも使用トークンは 80% 程度少なくなっています。(トークンはAIモデルの意味の単位です。トークンの数が増えるほど、運用コストは高くなります。)例えばHotpotQAデータセット（AIシステムを評価するために使用される質問セット）の場合、ReWOO は 2,000トークンを使用して42.4%の精度を達成し、ReActは10,000トークンを使用して40.8%の精度を達成します。
重要なのは、トークン効率のこの最適化により、推論モデルが大規模かつ経済的に実行可能になることです。
これら2つの一般的な生成 AIフレームワークの違いを説明するために、特定のユースケースを検討してみましょう。明日、ニューヨークからシカゴまでのフライトに搭乗し、その日のうちにミルウォーキーまで移動するという旅行に向けて、荷造りのサポートを求めているユーザーのクエリに、ReActとReWOOのシステムがそれぞれどのように応答するかを考えます。
ReActシステムでは、最終的な答えを出す前に、問題を思考、行動、観測サイクルの3つのシーケンスに分解します。最初のサイクルでは、「ニューヨークの明日の天気を確認する必要がある」と考察し、検索拡張生成（RAG） を使用してその天気を検索し（行動）、最終的に成果を観測します。この成果は、シカゴの気象に対する思考、行動、観測の3ステップのサイクルをもう一度繰り返すためのインプットとして機能します。3回めとしてミルウォーキーの天気にも同じ処理を繰り返します。最後にその結果を照合してアウトプットを返します（たとえば、「それぞれの場所で寒くなるので、重ね着できるものを入れてください」）。
対照的に、ReWOO方式のシステムでは、すべての計画を事前に行うことで効率を高めます。まず、「明日のニューヨークの天気、明日のシカゴの天気、その翌日のミルワウキーの天気を取得する必要がある」という計画を立てます。次に、このステップでコストのかかる「思考」を行わずに、気象APIを1つのタイトなシーケンスで（または並行して）呼び出します。最後に、解決、証拠の照合、最終的な回答をアウトプットします。
ReWOOには、トークンの効率性に加えて、ツール障害に対する堅牢性という追加の利点もあります。たとえばReActでは、ツールに障害が発生すると、システムが無限ループに陥ってしまう可能性があります（たとえば、LLMがシカゴの天気について壊れたデータベースに繰り返しクエリする、など）。
ReWOOはもっと機敏です。ツールが特定の証拠を返せなかった場合でも、最初の包括的な計画は引き続き有効です。つまり、Workerモジュールは処理を進めることができ、Solverモジュールは少なくとも部分的な回答を提供できます。この天気の例であれば、シカゴの天気に関するデータベースにクエリする無限または過剰なループに囚われることなく、Solverモジュールは少なくともニューヨークとミルウォーキーの気象情報をユーザーに知らせる回答を返します（必要な情報を読み込むことができたとすれば）。最終的にこの情報は、ユーザーの旅行計画のニーズには十分に役立つでしょう。
ReWOOにはたしかにメリットがありますが、普遍的に優れたフレームワークというわけではありません。特定の種類の仕事に秀でているのです。特に、必要な証拠の種類と量が一般的で予測可能である場合に適しています。しかし、予測可能性が低く、構造化されておらず、創造性、探求、または即興を必要とする問題の場合は、ReWOOでは不十分です。ReWOOは未知の要素が既知である場合には優れていますが、完全に未知の場合はうまく動作しません。
例えば、ReWOOはPythonコードのデバッグには最適ではありません。つまり、修正プログラムごとに新しいエラーや手掛かりを生成する可能性があり、最善の計画がすぐに消えてしまう可能性がある、探索的で反復的なプロセスだからです。ReActのような適応性の高いフレームワークは、抽象化においてのトークン効率は低くなりますが、最終的にはこのような問題により適しているといえます。
ほとんどのAIシステムやフレームワークと同様、ReWOOワークフローの実装にはさまざまなアプローチを利用できます。このフレームワークの「公式」実装は、研究者Binfeng Xu（とその同僚ら、2023年[1]）が最初に記述したもので、Github から入手できます。LangGraph （モジュールを「ノード」と呼ぶ）や関連するLangChainなどの生成AIフレームワークも人気があります。また、 IBM のGraniteを使用すると、 ReWOO スタイルのマルチステップ推論手法も利用できます。
どのLLM環境でも、ツールインプットの前に一連の質問に答えるための段階的な計画の作成を指示する、十分に練られたプロンプトを使えば、ReWOOを概念レベルで試すことができます。
例えば、ReWOOについて最初に解説した論文にはプロンプトの例が記載されています。その中の一つの書き出しは次の通りです。「これに続くタスクでは、問題を段階的に解決できる計画を立てます。各計画について、証拠を取得するために使用される外部ツールとツール・インプットを指定してください。」ただし、この研究の著者らは、「ReWOOは一般的なパラダイムであり、プロンプトは必ずしも固定されているわけではありません。読者とユーザーが自分のニーズに合わせてプロンプトを調整することを奨励します」と追記しています。 1
生成AIを使用してワークフローとプロセスを自動化する強力なAIアシスタントとエージェントを構築、デプロイ、管理しましょう。
信頼できるAIソリューションでビジネスの未来を構築します。
IBMコンサルティングAIサービスは、企業がAIをトランスフォーメーションに活用する方法を再考するのに役立ちます。
脚注
1. "ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models," Binfeng Xu, Zhiyuan Peng, Bowen Lei, Subhabrata Mukherjee, Yuchen Liu, Dongkuan Xu. Arxiv.org、2024年5月23日。