これは何の論文か
Argus の出発点は、深掘り調査エージェントの並列化がすぐ重複にぶつかることにある。単一 ReAct 実行は一つの探索経路しか見られない。だから複数の実行を並列に走らせるが、答えに必要な証拠は補完的なピースでできているため、同じような証拠ばかり集まると伸びが止まる。
この論文は、深掘り調査を『たくさん答えさせて後で選ぶ』問題ではなく、『足りない証拠片を見つけて埋める』問題として捉え直す。Searcherは Web検索やページ訪問を行う標準的な ReAct エージェントのままにし、Navigator がそのトレースを証拠と主張に分解して共有グラフへ載せる。
証拠グラフには、証拠ノード、主張ノード、支持または矛盾のエッジがある。Navigator はグラフ全体を見て、未検証の主張、矛盾した主張、まだ扱われていない部分質問を検出し、それぞれに狙いを絞ったクエリを作って Searcherに追加探索を依頼する。
最終回答を作る段階では、Navigator は生の記録全部を読み直さない。完成した証拠グラフだけを読み、各主張がどの証拠ノードと出典URLに支えられているかを辿れる形で答える。この構造が、文脈爆発を抑えつつ並列探索を伸ばす鍵になっている。
実験では、35B-A3B MoE 基盤で、単一 Searcher に比べて平均 +5.5 ポイント、8 並列 Searcherで +12.7 ポイント改善した。64 Searchers では BrowseComp 86.2% に到達し、25.6M トークンの Searcher 出力を 21.5K トークンのグラフビューに圧縮している。
Argusは、深掘り調査エージェントのテスト時スケーリングを、実行軌跡選択ではなく証拠組み立てとして設計する論文である。
従来の並列検索は、複数のエージェントが独立に探索し、最後に多数決、最良候補選択、LLMによる集約でまとめる。だが、複雑な調査では、同じ証拠を複数回拾うより、未確認の論点を埋める方が重要になる。
Argusは、Searcherと Navigator を分ける。Searcher は一つのクエリに対して ReAct 実行を行い、Navigator はそれらのトレースを共有証拠グラフへ変換し、足りない証拠を取りに行く。
何が問題だったのか
深掘り調査では、検索結果をたくさん集めるほど全体像が見えにくくなる。複数の Searcher が別々に証拠を取ってきても、どの主張を支えているのか、どこが矛盾しているのか、まだ何が未検証なのかが整理されなければ、最終回答はただの長い要約になる。
特に問題なのは、中間状態が検索ログの束として残ることだ。ログは情報量が多いが、次に何を調べるべきかを決める作業状態としては扱いにくい。並列化すると Searcher の出力は増える一方で、統合役の文脈はすぐ圧迫される。
Argus が扱う問題は、調査を「検索してまとめる」ではなく、証拠、主張、矛盾、不足を外部化しながら組み立てる必要がある、という点である。
既存の deep research 系手法では、複数の検索結果を最後にまとめる設計になりやすい。しかしそれだけでは、途中で見つかった証拠、矛盾、未検証の主張を次の検索へ戻しにくい。
Argus は、調査の中間状態を証拠グラフとして外部化する。Searcher が証拠を集め、Navigator がグラフを更新し、不足や矛盾を次の探索へ戻すことで、検索と検証を同じループに入れる。
提案手法の中身
Searcher は状態を持たないエージェントで、SEARCH、VISIT、ANSWER の行動を使い、思考、行動、観測からなる ReAct 実行軌跡を返す。Searcher 同士は通信せず、証拠グラフも見ない。
Navigator は証拠ノード、主張ノード、支持/矛盾エッジからなる有向非巡回グラフを維持する。各証拠ノードは出典URLに紐づき、主張ノードは証拠または別の主張から支持・矛盾される。
Navigator は返ってきたトレースを読み、証拠と主張をグラフに追加する。さらに各主張を支持あり、矛盾あり、未検証として判定する。この判定は固定ルールではなく、Navigator の方策が出典の多様性や矛盾を見て行う。
未検証の主張には独立した裏取り、矛盾した主張には権威ある解決、まだ触れていない質問部分には直接探索のクエリを生成する。これらを batch として Searcher に投げる。
構築が終わると、Navigator はループ中の作業文脈を捨て、元の質問と完成したグラフだけで最終回答を合成する。これにより、回答の各主張は出典URLへ戻れる。
どうやって確かめたのか
評価は、並列探索を増やした時に、単なる回答集約ではなく証拠グラフの更新が効いているかを見る構成になっている。複雑な情報探索ベンチマークを使い、単独探索と並列探索の両方を確認する。
比較対象は、生の Searcher、証拠グラフを使う Argus-Solo、複数 Searcher を走らせる Argus-Parallel、グラフ表現を削った構成、別の Searcher 基盤に差し替えた構成である。
測る指標は、最終回答の正解率、Searcher 数を増やした時の伸び、証拠グラフの有無による差、集めた証拠をどれだけ短い表現に圧縮できるかである。
結果はどうだったのか
8つの複雑な情報探索ベンチマークで評価され、Argus-Parallelは BrowseComp-ZH、GAIA、Seal-0、xbench-DeepSearch-2510、FrontierScience Olympiad の5つで最先端を達成した。
Argus-Soloは生の Searcher より平均 +5.5 ポイント改善し、Argus-Parallelは 8 並列 Searcher で平均 +12.7 ポイント改善した。これは単純な並列サンプル平均ではなく、Navigatorの組み合わせ的な検証が効いていることを示す。
BrowseComp では、Searcher の累積トークンを増やすと正解率が 55.0% から 86.2% まで伸びた。一方で Navigator が読むグラフビューは最大 21.5K トークンに抑えられた。
グラフ表現のアブレーションでは、テキストのみより素のグラフが +2.7 ポイント、さらに支持/矛盾ラベルと検証状態を持つ完全なDAGが +2.5 ポイント改善した。
別の Searcher 基盤に差し替えても Navigator の効果は残り、DeepSeekや Seed-2.0-Proを Searcher にした場合でも Argus-Parallel が最も高い BrowseComp 正解率を示した。
限界・注意点
- Argusは重い深掘り用調査解答役であり、低コスト・低遅延のアシスタントではない。64 Searchers では1問あたり Searcher トークンが 25.6M に達する。
- Searcher が見つけられない情報、paywall の背後にある情報、Web に存在しない情報には届かない。Argus は証拠を組み立てる仕組みであり、Searcher の再現率上限を消すものではない。
- 出典追跡は監査可能性を高めるが、誤情報、著作権、エージェント型検索一般のリスクは残る。
- 比較には公式報告値や再現実験の混在があるため、完全に同一条件の横比較として読むには注意がいる。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、検索は「関連しそうな情報を取る」だけでは足りない。調査中に、どの証拠がどの主張を支え、どこが矛盾し、何が未検証なのかを作業状態として持つ必要がある。
Argus 的に見るなら、調査ログは最後に要約するものではなく、証拠グラフへ更新して次の探索を決める材料になる。論文読み、技術調査、比較記事の準備では、未確認の穴を明示して次の検索へ戻す設計が効く。
Q&A
Argus は普通の並列検索と何が違う？
普通の並列検索は、複数の最終回答や記録を後から集約する。Argus は途中で証拠グラフを作り、足りない証拠や矛盾を見つけて、次の探索をそこへ向ける。中心は回答集約ではなく証拠組み立て。
Searcherと Navigator の役割は？
Searcher は一つのクエリを受けて ReAct 形式で検索・訪問・回答を行う。Navigator は複数 Searcher のトレースを証拠グラフへ変換し、未検証や矛盾を見つけて追加探索を指示し、最後にグラフから回答を作る。
なぜ文脈が小さくなる？
Navigator がすべての生記録を読むのではなく、証拠グラフという圧縮表現を読むから。論文では 25.6M トークンの Searcher 出力を 21.5K トークンのグラフビューに圧縮している。
Navigator はどう学習する？
教師ありファインチューニングでグラフ構築と統合の形式を初期化し、その後 GRPO で訓練する。報酬には、検証後のグラフでの回答が検証前のグラフよりどれだけ良くなったかを入れている。
実務でそのまま使える？
そのまま使うには重い。ただし、論文調査、記事作成、勉強会準備を『証拠グラフの未充足部分を埋める作業』として設計する考え方はすぐ使える。
一番見るべき結果は？
BrowseComp 86.2% も目立つが、より重要なのはグラフアブレーション。テキストのみよりグラフ、グラフより支持/矛盾ラベルと検証状態つき完全なDAG が効いている点。
弱点は？
高コストで低遅延用途には向かない。Searcher が見つけられない情報には届かない。出典追跡は助けになるが、誤情報や著作権などエージェント型検索一般のリスクは残る。
一言でいうと？
深掘り調査は、たくさん答えを出して選ぶより、足りない証拠を見つけて埋める方が伸びる、という論文。
関連する記事
コーパスを直接歩く検索エージェント
Argus が複数 Searcher の証拠を組み立てる話だとすると、こちらは検索対象のコーパスそのものをどう歩くかに焦点があります。探索の入口と、探索結果を証拠として統合する出口を分けて読めます。
grepだけで十分なのか
検索器の性能だけでなく、検索結果を保持し、読み直し、次の行動に渡すハーネス側の設計が重要になります。Argus の証拠グラフは、そのハーネスを深掘り調査向けに拡張した例として読めます。
エージェント型検索は引用だけでは評価しきれない
Argus は最終回答の出典だけでなく、途中でどの主張が支持され、どこが未検証だったかを扱います。行動ログや探索経路をどう読むかという観点では、エージェントの振る舞い解釈の記事と接続します。