ReWOO論文を読む

1. ReWOOとは何か

ReWOO（Reasoning Without Observation Order）は、2023年に提案された 言語モデルの推論と外部情報参照（Observation）を分離する新しいフレームワーク です（Xu et al., 2023）。

従来の代表的アプローチである ReAct では、モデルが「Reasoning（思考）」と「Acting（外部ツール実行）」を交互に繰り返すため、各ステップで外部APIや検索を呼び出す必要がありました。これによりタスク解決の柔軟性は高い一方、

  • APIコール数が多くなる（高コスト・低効率）
  • 観測（Observation）が逐次的に入るため推論が不安定になる
    といった課題がありました。

ReWOOは、この問題を解決するために 「推論と観測をデカップル（分離）」 する仕組みを導入しました。

  • Stage 1: 推論（Reasoning）
    モデルはまず、タスクを解決するために必要なサブクエリをすべて列挙し、計画を立てます。ここでは外部観測は行いません。
  • Stage 2: 観測（Observation Retrieval）
    Stage 1で生成されたサブクエリに基づき、外部環境から情報を並列的に取得します。
  • Stage 3: 統合（Synthesis）
    取得した情報をまとめ、最終回答を構成します。

論文ではこの設計を 「Plan → Retrieve → Synthesize」 と整理しており、逐次観測を繰り返すReActに比べて効率性と安定性が大幅に向上すると報告されています。

実験では、

  • HotpotQA（マルチホップ質問応答）
  • FEVER（事実検証）
  • 2WikiMultihopQA
    といったベンチマークで、ReActより少ないAPIコールで同等かそれ以上の性能を達成しました。特にマルチホップ推論では ReActの50〜70%のAPIコール数 で同等の精度を達成しました。

2. ReWOOの基本アイデア

ReWOOの核心は、推論（Reasoning）と観測（Observation）を分離し、三段階の処理フローに再構成することです。これにより、従来のReActに見られる「逐次的に観測を行う非効率性」を解消します。

2.1 Plan（推論段階）

まずモデルは 外部情報に触れずに、与えられたタスクを解くために必要なサブクエリやサブタスクを 一括生成 します。

例（HotpotQAの質問）：「Q: 〇〇の出身地を答えよ」 → Plan段階で「1) 〇〇の人物情報を調べる」「2) 出身地を調べる」という2つのサブクエリを列挙。

論文では、この段階を「sketch generation」とも呼び、思考を外部環境から切り離して明示化することがポイントです。

2.2 Retrieve（観測段階）

Planで生成されたサブクエリをもとに、外部ツールやAPIをまとめて呼び出し、並列的に情報を取得します。

ReActのように「1ステップ推論 → 1回検索」ではなく、まとめて検索できるため効率が良い。

論文の実験では、この設計により APIコール数を半分以下に削減（ReAct比）できたと報告されています。

2.3 Synthesize（統合段階）

Retrieveで得られた情報をすべて統合し、最終回答を構築します

モデルは観測結果を参照しながら、Planで立てたスケッチを埋めるように推論を進めます

この構造により、逐次的に観測へ依存するReActよりも 安定した推論 が可能になります

2.4 ReActとの違い

ReAct：ReasoningとObservationを交互に実行（逐次的）。柔軟だが非効率で不安定

ReWOO：Reasoning（Plan）を先にまとめて行い、その後でObservationを並列的に取得 → 最後に統合

結果、ReWOOは 効率性（少ないAPIコール） と 安定性（推論の一貫性） を両立します。

3. アルゴリズムの流れ

ReWOOの処理は、Plan → Retrieve → Synthesize の三段階で進みます。
論文では、このフレームワークを HotpotQA や FEVER などのマルチホップ質問応答タスクに適用し、ReActよりも少ないAPIコールで同等以上の精度を実現しました（p.6–7）。

以下に、HotpotQAを題材とした具体的な流れを示します。

ステップ1：Plan（サブクエリ生成）

  • 入力: 「『Gravity’s Rainbow』を書いた作家の国籍は？」
  • モデルはまず、外部検索を行わずに必要なサブクエリを生成する
    1. 「Gravity’s Rainbow の作者を特定する」
    2. 「その作者の国籍を調べる」
  • この段階は純粋に推論だけで行われ、Observationは伴わない

ステップ2：Retrieve（外部観測）

  • Planで得られたサブクエリを外部ツールに投げ、情報を並列的に取得する
    • クエリ1 → 「Gravity’s Rainbow の作者は Thomas Pynchon」
    • クエリ2 → 「Thomas Pynchon の国籍はアメリカ」
  • ReActのように逐次呼び出すのではなく、まとめて観測を実行できるのが特徴

ステップ3：Synthesize（統合）

  • モデルは観測結果を取り込み、最終回答を構築する
  • 出力: 「『Gravity’s Rainbow』の作者 Thomas Pynchon はアメリカ国籍である」

実験結果

  • HotpotQA：ReActと同等の正答率を維持しつつ、APIコール数は 約50%削減
  • FEVER：観測数削減により効率性が向上しつつ、幻覚の発生率が低下
  • 2WikiMultihopQA：複数サブクエリを並列処理するReWOOが有効に機能

4. LangGraphでの実装例

coming soon…

5. 利点と課題

5.1 利点

  1. 効率性の向上
    • ReActでは「推論 → 観測 → 推論 → 観測…」を逐次繰り返すため、外部APIの呼び出し回数が多くなる
    • ReWOOは「Plan → Retrieve → Synthesize」によって観測をまとめて実行できるため、APIコール数を大幅に削減できる
    • 実験（HotpotQA, FEVER）では、ReAct比で約50%のAPIコール削減を達成
  2. 安定した推論
    • 観測を逐次挟まないため、モデルが部分的な観測に引きずられるリスクが減る
    • Plan段階で推論の全体構造を固めるので、一貫性のある答えを導きやすい
  3. 並列処理の活用
    • 複数のサブクエリを同時に投げられるため、外部検索・API呼び出しを効率化できる
    • 実際に 2WikiMultihopQA のようなマルチホップタスクで有効性が確認されている
  4. 幻覚の抑制
    • 観測情報を一括で取得 → 推論に組み込むため、根拠のない回答を生成する頻度が低下
    • FEVER（事実検証）では、ReActよりも幻覚率が低いと報告

5.2 課題

  1. 初期プランニングの品質依存
    • Plan段階で十分なサブクエリを立てられなければ、Retrieveで必要情報を取り逃す可能性がある
    • 論文でも「Planの質が低いと、全体性能が下がる」点が指摘されている
  2. 柔軟性の欠如
    • ReActのように「観測結果を見て即座に計画を修正する」ことは難しい
    • 想定外の観測結果に遭遇した場合の適応力は、逐次型のReActに劣る
  3. 長期タスクへの適用性
    • 非常に多段階の推論では、Planで膨大なサブクエリを生成する必要があり、コンテキスト長や効率の面で制約が出る
    • 論文でも「long-horizon reasoning」は今後の課題として言及
  4. 実装上の制約
    • 並列でObservationを取得できる環境（APIやデータベース）が必要
    • 社内システムへの適用では、既存のAPI設計が並列呼び出しに対応していないと効果を十分に得られない

まとめ

ReWOOは、ReActの逐次観測に伴う非効率さを克服し、効率性・安定性・幻覚抑制に強みを持つ手法です。
一方で、Plan段階の品質依存・柔軟性不足・長期タスク対応が課題であり、論文でも「今後の研究テーマ」とされています。

コメント

タイトルとURLをコピーしました