中国科学院（CAS）によるこの研究は、「ディープサーチエージェント」が抱える二つの決定的な技術的な課題を解決しました。一つは、問題自体の難易度が不十分なため、モデルが真剣に考える必要がないこと。もう一つは、ツールの長大な出力によってコンテキストがすぐに溢れてしまい、プロセスが途中で打ち切られてしまうことです。研究者はこの課題に正面から取り組み、データとシステムの両面から学習および推論プロセスを同時に再構築し、複雑な推論が実用的かつ実行可能になるようにしました。
ここには明確なエンジニアリング上のトレードオフが見られます。「高品質で検証可能、かつクロスソースの」問題を訓練の燃料とし、「初期のツール出力」を永続的な負荷ではなく、必要な時に取り出せるキャッシュとして扱い、このコンテキスト状態の一貫性を訓練と推論を通して維持することです。結果として、エージェントは十数ラウンドで終了を余儀なくされることなく、標準の32kコンテキスト内で最大100回近くのツールインタラクションを着実に処理し、その過程での推論チェーンを完全に保持できるようになりました。最終的に、中規模な32Bのオープンソースモデルでも、「複数サイトの調査、証拠、推論が必要な」タスクに対して、安定的に、説明可能で、費用対効果の高い方法で作業できるようになります。これは、多くの企業が「AIリサーチアシスタントまたはアナリスト」を実際に運用可能で再利用できるものにするための鍵です。
問題の根本はどこにあるのか
あなたもこの落とし穴に陥ったかもしれません。訓練データが「浅すぎる」ため、現実の研究的な振る舞いを学習できないのです。現在一般的に使用されているオープンソースのマルチホップQAデータは、ウィキペディア的な傾向があり、モデルが記憶や単一ページ検索で「偶然正解」してしまうことがあります。しかし、本番環境で複数サイト、複数タイムラインにまたがり、検証が必要なタスクに直面すると、「対応できなくなる」のです。もう一つの問題は、コンテキストの爆発です。長時間のプロセスが維持できず、32kコンテキストでは有効なインタラクションが通常10〜15ラウンドしか持ちません。ツールが返すウェブページの断片は、アシスタントの応答の通常5〜10倍の長さであり、この急成長する部分が常にスペースを食い潰します。多くのシステムは要約モデルを使ってツールの出力を圧縮しますが、これでは情報粒度が失われ、システムの結合度が複雑になり、さらに重要なことに、エンドツーエンドの検証可能な強化学習に組み込むのが難しくなるため、訓練時の最適戦略と本番運用時の挙動に乖離が生じてしまいます。
コアアイデア 1：逆方向構築による複雑な問題データ
この目標は、複数のウェブページ、複数のステップの推論が必要であり、かつ答えがウェブ上の証拠によって検証可能な問題を作成することです。これにより、訓練時にモデルは「検証—バックトラック—サブゴールの分解—クロスドキュメントの統合」といった専門家的な戦略を習得することを余儀なくされます。研究者はこれを「逆方向構築」（reverse construction）のタスク生成法と呼んでいます。
具体的な3つのステップ
ステップ 1：「エンティティ」をアンカーとし、まず実際のウェブ証拠を収集する（情報が十分かつ補完的であること）
まずウィキペディアから人名をスクリーニングしますが、「露出度が適度な」人物のみを選びます。あまりにマイナーだと参照資料が不足し、有名すぎるとモデルが記憶から直接思い出してしまうため、訓練効果が得られません。研究者は、過去6ヶ月間のページ閲覧数が特定の範囲内にあることを「適度」の定量的な基準として示しています。その後、各エンティティについて2種類の検索を行います。一つは人名を直接検索して伝記情報を取得すること、もう一つはニュース検索で最近の動向を取得することであり、通常数十個の候補ウェブページが得られます。
収集したウェブページに三重のフィルタリングを適用します。1. エンティティ対応性：ウィキペディアと照合し、「同名異人」の混同を排除します。2. 情報の補完性：新規かつ独立した情報を提供するページのみを残し、重複した記述を削除します。3. サイトの信頼性：信頼できない情報源を排除し、信頼できるサイトのみを保持します。これにより、後で問題を作成する際、情報が「複数ページに分散」「相互補完的」かつ「信頼できる」ことが保証されます。
ステップ 2：マルチソースの証拠に基づいて「出題」し、意図的に難易度を上げる（マルチソースを強制、ウィキペディアを禁止、「二次的な曖昧化」を適用）
ウィキペディアのページ自体を証拠として使用することを禁止し、モデルが単一の構造化された情報源から答えを掘り出すのを防ぎます。
各問題が少なくとも四つの異なる情報源を統合することを明確に要求し、単一ページ検索ではなく「クロスドキュメント推論」を強制します。
既に生成された問題に「二次的な曖昧化」を適用します：「具体的な指示」を「より一般化された記述」に置き換えます（例：「7月2日生まれ」を「21世紀初頭生まれ」といった一般化された記述に変更）。ただし、答えの一意性は保証します。これにより、モデルは検索時にすぐに答えを見つけることができず、「一般化された記述」と複数のページの詳細情報を段階的に対応させることで、一意の答えを特定しなければなりません。このステップは、「情報マッチング」を「推論による復元」に変換します。
ステップ 3：二重フィルタリング – 「簡単な問題」は全て除外し、「品質問題」を厳密に除去する
難易度フィルタリング：簡単すぎる問題を排除するために、二つの自動化された「プローブ」を使用します。1. 直接検索エンジンでエンティティや答えがワンステップで検索できるかを確認します。2. ゼロショットLLMが直接推測できるかを確認します。どちらか一方でも容易に成功する場合、それは我々が求める「多段階、マルチソース必須」の問題ではないため、全て除外します。
品質フィルタリング：検証可能性を損なう問題を全て削除します。これには、1. 表現が曖昧で、誤解を招きやすいもの。2. 答え自体が曖昧または一意でないもの。3. 答えが与えられた参照ドキュメントから論理的に導出できないもの（証拠チェーンが不十分）。フィルタリング後に残ったQ&Aペアだけが、「難しくかつ検証可能」な高品質の訓練サンプルとなります。
なぜこの方法が有効なのか？ それは、現実の長距離検索タスクに正面から対応しているからです。情報が分散し、S/N比が不揃いであり、クロス参照とバックトラック確認が必須となります。既存の多くのマルチホップデータセットは構造化されたウィキペディア情報に依存しており、「浅い検索＋モデルの記憶」で解決しやすいため、「検証、バックトラック、計画」といった真の「専門家的な認知行動」を誘発できません。
コアアイデア 2：動的スライディングウィンドウ
なぜ新しい戦略が必要なのか？研究者はまず実証分析を行いました。一般的な32kコンテキストでは、ほとんどのモデルは約10〜15ラウンドでコンテキストを使い果たします。その理由は、ツールから返されるウェブコンテンツが、アシスタントの応答の通常5〜10倍の長さであるため、雪だるま式に蓄積し、対話空間を急速に圧迫するからです。しかし、これらの「非常に長いツール出力」は、「直後のステップの決定」にのみ強く影響し、十数ラウンド後の決定には影響が弱いことがわかっています。したがって、全ての履歴ツール出力を保持することは、コンテキストの浪費であり、非効率です。
この観察に基づき、研究者は「スライディングウィンドウ」コンテキスト管理を提案しました。
マルチラウントラジェクトリを $\tau$ = {ユーザー質問 $q$、アシスタント $a1$、ツール $t1$、アシスタント $a2$、ツール $t2$ …} とします。
ウィンドウサイズ W とスライドステップサイズ S を設定します。累積されたツール応答の数が W に達すると、それより古いツール応答は一括でプレースホルダープロンプト（例：「以前のツール出力は省略されました。必要に応じてツールを再実行してください」）に置き換えられ、最新の W 個のツール出力のオリジナルテキストのみが保持されます。同時に、アシスタント自身の推論内容は全て完全に保持され、切り詰められません。これにより、「推論の脈絡」を失うことなく、「過去の長いウェブページ」をコンテキストから解放します。
訓練と推論の一貫性（訓練時における実施方法）
推論時のみスライディングウィンドウを適用するだけでは不十分です。モデルが「完全な履歴」で訓練されているにもかかわらず、「スライディングウィンドウコンテキスト」内での推論を強いられると、分布の不一致が発生し、不安定になります。このため、研究者は各トラジェクトリを、推論中のスライディングウィンドウのリズムに合わせて複数の訓練シーケンスに分割し、訓練期間中にモデルが「一部の古いウェブページがプレースホルダーに置き換えられた」コンテキスト状態に慣れるようにしました。
あるトラジェクトリに T 回のツール呼び出しがある場合、 $1 + \lfloor (T - W) / S \rfloor$ 個の訓練シーケンスが生成されます。最初のシーケンスには、初期の完全なコンテキストが含まれます。続くシーケンスでは、スライディング境界に従って古いツール呼び出しがプレースホルダーに置き換えられ、ウィンドウ内のツールのオリジナルテキストのみが保持されます。これにより、推論プロセスにおける実際の可視コンテキストを再現します。
「同じアシスタントの出力を繰り返し最適化する」ことによる衝突を避けるため、各シーケンスにマスキングを適用し、各アシスタントの応答が一度だけ訓練されることを保証します。論文にはマスキングの式（以下に図示）が示されており、これは $k$ 番目のシーケンスでは「新しく生成された部分」のアシスタントテキストのみがバックプロパゲーションに参加し、以前に出現したアシスタントテキストは「読み取り専用コンテキスト」として扱われることを意味します。
アシスタントの応答 $a_i$ の位置でのみ損失（Loss）が計算されます。これにより、「推論期間中のスライディングウィンドウの可視性」が訓練期間に一対一で再現されます。
結果と利点（なぜこの方法が「古いウェブページを要約する」よりも有利なのか）
外部の要約を一切行わないため、モデルは必要に応じて「ツールを再実行」することで元のウェブページの内容を取得でき、情報損失がありません。
メカニズム自体は、追加の要約モデルの複雑さや計算コストを増やさず、エンドツーエンドの強化学習への組み込みも容易です（要約コンポーネントはしばしば「訓練の盲点」となります）。
同じ、あるいはより小さなコンテキスト予算で、スライディングウィンドウ法は有効なインタラクションラウンド数をより高く押し上げることができます。論文では、32k コンテキストで約 100 ラウンドの安定したインタラクションを達成し、「管理なし」や「要約圧縮」よりも多ベンチマークで優れた性能を示しています。表と図が示すように、32k/64k/128kの3つの制限下で、スライディングウィンドウソリューションは32kで約 33.3%に達しますが、他の2つの戦略はより大きなコンテキストでようやくこのレベルに近づきます。
訓練フロー：コールドスタートから検証可能な強化学習へ
コールドスタート段階では、教師ありファインチューニング（Supervised Fine‑tuning, SFT）を採用し、「ツールを使う、段階的に考える」という基本スキルを確立させます。研究者は、より高性能なモデルを使用し、実際のウェブ環境で行動トラジェクトリを生成しました。生成時には、コンテキストの長さによってトラジェクトリが途切れるのを防ぐために、同様に動的スライディングウィンドウを使用しました。最終回答が間違っているか、長さが過度なトラジェクトリはフィルタリングされ、残りの高品質な例は「マルチシーケンス構築」を経て、モデルが動的コンテキストに適応するように訓練されます。強化学習段階では、グループ相対ポリシー最適化（Group Relative Policy Optimization, GRPO）を使用してポリシー改善を行います。同じ問題に対して複数の完全なトラジェクトリが生成され、最終的な回答が正しいかどうかに基づいて検証可能な二値の報酬が与えられます。その後、グループ内で標準化されてアドバンテージが得られ、このトラジェクトリレベルのアドバンテージが対応する全ての訓練シーケンスに伝えられます。これにより、トラジェクトリレベルのフィードバックがシーケンスレベルのパラメータ更新に安定的に使用されます。
具体的なエンジニアリングの詳細も明確に説明されています。ベースモデルはQwen3‑32Bで、思考モードを有効化しています。SFTでは約3000の高品質トラジェクトリを使用し、バッチサイズ256、学習率 $1 \times 10^{-5}$。RLでは約4000の問題を使用し、バッチサイズ32、学習率 $2 \times 10^{-6}$。各問題に対して8つのロールアウトを生成し、最大トラジェクトリ長は4万トークン、単一問題のラウンド上限は60です。ツールウィンドウサイズは5、スライドステップは3に設定されており、訓練の実装はVERLフレームワークに基づいています。評価時には、BrowseComp、BrowseComp‑zh、XBench‑DeepSearch、およびGAIA全体で、温度0.6、top‑p 0.9、最大100ラウンドのインタラクションを統一して使用し、同様にウィンドウ5とスライド3のコンテキスト管理を使用します。最終的な回答の正確性は、構造化されたプロンプトを持つレビューアモデルによって判断されます。
ツールスイートとインタラクションの詳細：3つのツールで十分
多くの人がウェブコンテンツを圧縮するために要約モデルを追加することを最初に考えますが、研究者は「何を読み、どう読み、どのページで止めるか」に焦点を当てました。彼らが保持したのは、軽量で高レバレッジな3つのツールだけです。検索サービスを使用してタイトル、リンク、要約を取得すること。取得サービスを使用してウェブページをページごとにスクロール可能なMarkdownテキストに変換すること。そして、ページ内検索を使用して長いドキュメント内のキーワードとその周辺のコンテキストを特定することです。これにより、モデルは人間のように、まず概要を確認してから深読みするかどうかを決定でき、一度に数千字を押し込まれて受動的に消化するのではなく、ページごとのコンテンツを早送り、一時停止、終了することができます。外部要約を行わないため、情報の詳細が事前に切り詰められることはなく、エンドツーエンドの訓練において「実際のテキストが見えない」という最適化の断絶も発生しません。
実践演習：実際の問題がどのように解決されるか
研究者は付録でケーススタディのトラジェクトリを提供しています。この問題は、雑多な手がかりの中から唯一の歴史的な場所を特定することを要求します。条件には、国の首都に位置するかどうか、川に面しているか、着工年と完成年の範囲、壁の厚さの数値範囲、特定の期間の竜巻と地震による被害を経験したかどうか、1980年から1990年の間に政府に買収されたかどうか、および買収当時の大統領の誕生年が含まれます。このような問題は、エージェントに複数のウェブページにまたがって繰り返し検証し、必要に応じて振り返って再調査することを強制します。ツールの連携については、まず検索サービスを使用して候補を絞り込み、次に取得サービスを使用して重要なページをページごとに詳細に読み込み、さらにページ内検索を通じてキーワード周辺の段落に迅速にジャンプします。同時に、スライディングウィンドウは古い長いツール出力を継続的に除去し、思考プロセスを完全に保存します。最終的に特定された答えはダッカの Ahsan Manzilであり、プロセス全体が「マルチソースからの事実のつなぎ合わせと相互検証」という定石を非常に安定して実行しており、内部記憶にも、一律の要約にも依存していません。
まず検索を使用して条件に関連する候補建物を特定し、首都にあるか、川に隣接しているかの2つの情報を記録して、明らかに一致しない対象を迅速に除外します。
最も有望な候補に対して取得サービスを使用してページごとに読み進め、着工年と完成年が指定された閉区間に収まっているかを重点的に確認し、同時に壁の構造や厚さなどの技術的な詳細がページに記載されているかにも注意を払います。
ページ内検索を利用して「tornado」「earthquake」などのキーワードを特定し、1880年から1890年の竜巻被害記録、および1890年から1900年の地震被害記録がそれぞれ存在するかを項目ごとに確認し、日付が厳密に範囲内にあるかを比較します。
同じエンティティの異なる情報源間で「政府による買収」の年を比較し続け、その年に対応する国の大統領が誰であったか、そしてその大統領の誕生年が1920年から1935年の閉区間内にあるかを相互検証し、制約チェーンを閉じます。
百科事典の要約には一般的ではない「壁の厚さ」のような詳細については、より専門的な情報源または地域的な情報源に切り替えて補足検索を行い、数値を既存の条件と照合し、全ての条件が孤立してではなく同時に満たされていることを確認します。
検証プロセス全体を通じてスライディングウィンドウを維持し、初期の長いツール出力をプレースホルダープロンプトに置き換えさせます。情報が不確かな場合は、再度ツールを呼び出して原文を取得し直すことで、追跡可能性を失うことなく、コンテキストが過去の断片に引きずり込まれるのを防ぎます。
実験結果と再現性の設定
道筋が整備された後、数値的なパフォーマンスが全てを物語ります。
研究者は、4つの「ディープウェブ調査型」ベンチマークでモデルをテストしました。
| データセット | 概要 |
|---|---|
| BrowseComp-en | 複数のウェブページを検索し、推論する必要がある複雑な英語のウェブQAタスク。 |
| BrowseComp-zh | 中国語版。上記のタスクタイプと同様。 |
| XBench-DeepSearch | 多段階の対話型推論に焦点を当てた、クロスリンガルの「ディープサーチ」評価セット。 |
| GAIA | DARPA GAIAプログラムによって提供される、複雑なウェブ上の事実確認タスク。 |
これらのベンチマークは全て、実際のウェブツールを必要とするタスクです。つまり、問題の答えはモデルの記憶から直接引き出すことはできず、ウェブを検索、統合、検証する必要があります。
DeepMiner‑32BはBrowseComp‑enで33.5の正解率を示し、これまでのオープンソースエージェントの範囲から大幅に向上しました。また、BrowseComp‑zh、XBench‑DeepSearch、およびGAIAでも同様の改善が見られます。さらに参考になるのは、SFT版のパフォーマンスであり、これは多くのベンチマークで多数のオープンソースエージェントを既に上回っています。この結果は、DeepMinerがオープンソースのエコシステム内で「商用レベルに近い」ディープウェブ推論効果を達成したことを意味します。これは、「高難易度で検証可能なデータ」自体が利益をもたらし、それが検証可能な強化学習と動的コンテキストの連携によってさらに強化されることを示唆しています。評価は、温度0.6およびtop‑p 0.9のデコード設定、最大100ラウンドのインタラクション上限、およびウィンドウ5とスライド3のコンテキスト管理を統一して使用し、構造化されたレビューアプロンプトを使用して判定プロセスを追跡可能にしています。これらの詳細は、ローカルでの再現性に非常に重要です。
スライディングウィンドウメカニズムの効果検証
このセクションでは、3つのコンテキスト管理戦略の違いを個別に測定しました：
| 管理戦略 | 特徴 | 32kコンテキストでのパフォーマンス |
|---|---|---|
| 管理なし | 全てのウェブコンテンツを保持 | 約 22%。コンテキスト上限に達する前に、最大で 15〜20 ラウンドしか実行できない |
| 古いウェブページを要約 | 外部要約モデルを使用して履歴ページを圧縮 | 約 27%。30〜40 ラウンド実行可能だが、詳細が失われる |
| スライディングウィンドウ（研究者による方法） | 古いウェブページのオリジナルテキストのみ削除、アシスタントの推論テキストは保持 | 33.3%。100 ラウンド近くまで安定して実行可能 |
さらに、64kと128kのコンテキスト長での比較：
管理なしの戦略は、ウェブページが長くノイズが多いため、パフォーマンスの伸びが非常に遅い。
要約戦略はわずかに向上するが、依然としてスライディングウィンドウに及ばない。
スライディングウィンドウ戦略は、32kの時点で128kの要約戦略のパフォーマンスを達成している。
結論：スライディングウィンドウ管理は、コンテキストを節約するだけでなく、推論の安定性も維持します。同等のコンテキスト容量で、モデルにほぼ4〜6倍のラウンド数で推論させることができます。
研究者は実験図で、異なるコンテキスト長における3つの戦略の曲線を示しています。スライディングウィンドウの曲線はほぼ32kで頂点に達しており、他の方法は128kになってようやくそれに近づいています。
この研究の意義は何か？
「ディープサーチ」の二つの主要な問題点を同時に解決：「逆方向構築＋マルチソース合成＋曖昧化＋厳格なフィルタリング」を用いて訓練タスクを「難しく、かつ本物」にする一方、「スライディングウィンドウ」をメカニズムとして使用し、マルチラウント推論の「持続可能な長さ」を延長しました。これにより、追加の要約モデルに頼らず、詳細を失わず、システム複雑性を増すことなく、訓練と推論の同分布を実現しました。
データ効率と能力転移：SFTのみのバージョンであっても、HotpotQAのような従来のマルチホップデータで訓練されたモデルを大幅に上回っており、構築されたデータが「ウェブ深掘り調査」の実際のニーズにより適合していることを示しています。さらにRLを重ねることで、能力は継続的に向上します。
エンジニアリングの実現可能性：一般的な32kコンテキスト内でインタラクションラウンド数を約100にまで押し上げられる能力は、実際のシステムにとって極めて重要です。なぜなら、単にコンテキストを拡大する（128k以上など）ことには高いコストが伴うからです。
潜在的な限界と注意点
データと倫理：訓練データは公開ウェブページに由来しますが、個人的な情報が含まれる可能性があります。研究者は、公開サイトのみを使用し、不適切なサイトやソーシャルメディアをフィルタリングし、公開前に匿名化を行い、悪用のリスクを減らすために重みへのアクセス審査を設定することを約束しています。
評価判定のLLM依存：主観的な評価には強力なモデルが裁判官として用いられますが、これは一般的な手法であるものの、結果が「レビューアのプロンプトとモデルバージョン」の影響をある程度受けることを意味します。研究者は再現性を高めるために、付録でレビューアのテンプレートを提供しています。
ディープサーチエージェントに関する関連研究として、このサーベイも参照できます：
ファーウェイとオックスフォードが共同で万字のレポートを公開、OpenAIとGoogleが密かに開発を進める「DRエージェント」の秘密を解明
結びに
結局のところ、このアプローチは「問題が本物で難しいこと」「コンテキストが制御可能で一貫していること」「フィードバックが検証可能で安定していること」の三点を統合した結果、マルチラウント検索エージェントが浅い試みから持続的な深掘りへと進化しました。私はこれを、エンジニアリング視点の整理された考え方として捉えたいです。まず推論チェーンの連続性を守り、次に最も大きなコンテキストコストを必要に応じて移動させ、最後に訓練と推論が同じ「世界の状態」を共有するようにするのです。あなたがウェブ検索、インテリジェント分析、または企業知識QAを実用的な製品にしようとしているなら、これらの改善点は既存のシステムに徐々に移行することが可能であり、一からやり直す必要はありません。「どれだけ長く考えられるか」と「正しく考えられるか」という二つの古い問題を同時に安定させることができます。