We are thrilled to announce that NVIDIA NeMo Retriever team has developed a new agentic retrieval pipeline that has officially secured the #1 spot on the ViDoRe v3 pipeline leaderboard. In addition, this exact same pipeline architecture achieved the #2 spot on the highly demanding, reasoning-intensive BRIGHT leaderboard.

In the rapidly evolving landscape of AI retrieval, many solutions are highly specialized, engineered to perform exceptionally well on specific, narrow tasks. However, real-world enterprise applications rarely have the luxury of perfectly curated, single-domain data. They require systems that can seamlessly adapt to a wide variety of challenges—from parsing complex visual layouts to executing deep logical reasoning.

That is why we prioritized generalizability in our design. Rather than relying on dataset-specific heuristics, we built an agentic pipeline that dynamically adapts its search and reasoning strategy to the data at hand. This allows us to deliver state-of-the-art performance across vastly different benchmarks without requiring any underlying architectural changes.

Here is a look at how we built it.

動機: なぜセマンティック類似性だけでは足りないのか

長年、セマンティック類似性に基づく高密度検索は情報を見つける標準でした。しかし、検索の適用範囲が広がるにつれ、関連する文書を見つけるにはセマンティック類似性だけでは足りません。複雑な文書検索には推論スキル、現実世界のシステムの理解、反復的な探索が必要です。

根本的なギャップがあります。LLMは思考と推論には長けていますが、同時に何百万もの文書を一度に処理することはできません。逆に、リトリーバは何百万もの文書を容易にふるいにかけることができますが、推論能力は限られています。エージェント型検索は、LLMとリトリーバの間に能動的で反復的なループを作ることでこのギャップを埋めます。

仕組み: エージェント型ループ

エージェント型検索パイプラインの概要

私たちのエージェント型検索パイプラインはReACTアーキテクチャに依存しています。1回限りのクエリではなく、エージェントは反復的に検索・評価・アプローチを洗練させます。

エージェントは、think のような組み込みツールを使用してアプローチを計画し、final_results を用いて特定のクエリに必要な正確な文書を出力します。さらに、コーパスを探索するための retrieve (query, top_k) ツールも併用します。このループを通じて、成功する検索パターンが自然に現れることを観察しました:

• より良いクエリの生成: エージェントは新たに発見された情報に基づいて検索クエリを動的に調整します。
• 継続的な言い換え: 有用な情報が見つかるまで、クエリを絶えず言い換え続けます。
• 複雑さの分解: 複雑で多部構成のクエリを、明確な目的を持つ複数の単純なクエリへと分解します。

最終的に反復的な発見を統合するため、エージェントは final_results ツールを呼び出して、与えられたクエリへの関連度が最も高い文書を出力します。安全策として、たとえばエージェントが最大ステップ数に達した場合や文脈長の制限に達した場合には、パイプラインは Reciprocal Rank Fusion (RRF) にフォールバックします。RRF はエージェントの軌跡全体の全取得試行における順位に基づいて文書をスコア付けします。

速度とスケールのためのエンジニアリング

エージェント主導のワークフローは、悪名高く遅くリソースを大量に消費します。リーダーボード規模の評価にこのパイプラインを実現可能にするために、LLMエージェントとリトリーバーの通信方法を見直す必要がありました。

初期には、リトリーバーは Model Context Protocol (MCP) サーバーを介してエージェントに公開されました。MCP は外部ツールへのアクセスをLLMに提供するために設計されているため、自然な選択です。しかし実際には、このアーキテクチャは実験速度に追加の税を課しました。各実行には別の MCP サーバーを立ち上げ、適切なデータセットコーパスをGPUメモリにロードし、クライアントとサーバーのライフサイクルを調整する必要がありました。これらの各ステップは、静かな設定ミスや高負荷時のサーバーフリーズの機会となりました。ネットワークの往復通信は取得呼び出しごとに遅延を追加し、2プロセス構成の全体的な認知的負荷は、他のチームがパイプラインを採用して反復するのを著しく難しくしました。

これを解決するために、MCPサーバーを排除し、プロセス内にあるスレッドセーフなシングルトンリトリーバを採用しました。シングルトンはモデルとコーパスの埋め込みを一度だけロードし、すべてのアクセスを再入可能ロックで保護し、同じ retrieve() インターフェースを任意の数の同時エージェントタスクに対して公開します。これにより、複数のスレッドからGPUに居住するリトリーバに安全に共有アクセスできるという MCP サーバの主要な利点を、ネットワークのシリアライズオーバーヘッドを発生させることなく、別サーバープロセスを必要とせずに実現します。この単一のアーキテクチャの変更により、展開エラーのクラス全体を排除し、GPUの利用率と実験スループットの両方が劇的に向上しました。

ベンチマーク間の一般化と専門化

現代の検索評価における共通の観察として、特定のタイプのタスクに高度に最適化された解決策は、まったく異なるドメインに適用すると性能ギャップを経験することがよくあります。

私たちは推論負荷の高い BRIGHT リーダーボードで #2 を、NDCG@10 が 50.90 で獲得しました。そのリーダーボードの #1 ソリューションである INF-X-Retriever は、印象的な 63.40 を達成します。しかし、ドメインを跨いだ適応性を検証するため、INF-X パイプラインを、私たちのエージェント系パイプラインで使用しているのと同じ nemotron-colembed-vl-8b-v2 埋め込みモデルと組み合わせて ViDoRe v3 に対してベンチマークしました。ViDoRe v3 は視覚的に豊かで多様な企業文書に焦点を当てたデータセットです。この別のタスクでは、NDCG@10 は 62.31 に落ち、dense retrieval のスコア 64.36 より低くなりました。言い換えれば、INF-Query-Aligner は ViDoRe v3 における dense retrieval ベースラインを改善していません。

対照的に、同じエージェント系パイプライン（Opus 4.5 と nemotron-colembed-vl-8b-v2 の組み合わせ）は、ViDoRe v3 でスコア 69.22 で首位を獲得しました。

これは私たちのアプローチの核心的な強みを示しています：汎用性。データセット固有のヒューリスティクスやクエリ書換え/整列器に依存するのではなく、エージェント系ループは、複数のステップの論理推論が必要か、複雑な視覚レイアウトの解析が必要かに関係なく、対象のデータセットに対して自然に戦略を適応します。

アブレーション研究：オープン対クローズドモデル

ViDoRe v3

BRIGHT

We conducted extensive ablations to understand the tradeoff between frontier closed models and open-weights alternatives:

• Model Choice: On ViDoRe v3, swapping Opus 4.5 for the open gpt-oss-120b resulted in a small accuracy drop (69.22 to 66.38 NDCG@10) and makes much fewer retrieval calls. On BRIGHT, the gap was wider, indicating that deeper reasoning tasks still benefit heavily from frontier models like Opus 4.5.
• Embeddings: Pairing the agent with specialized embeddings (nemotron-colembed-vl-8b-v2 for ViDoRe and llama-embed-nemotron-reasoning-3b for BRIGHT) yielded the best results, proving that a strong baseline retriever provides a higher ceiling for the agent to reach.
• It's also interesting to note that the agent can close the gap between stronger and weaker embedding models. For example, on ViDoRe, the gap between the stronger nemotron-colembed-vl-8b-v2 and the weaker llama-nemotron-embed-vl-1b-v2 is about 8.5 in dense retrieval, but when coupled with gpt-oss-120b agent, the gap shrinks to about 4. Similarly, llama-embed-nemotron-reasoning-3b is about 19 points better than llama-nemotron-embed-vl-1b-v2 on BRIGHT, but the lead shrinks to about 7.5 when coupled with gpt-oss-120b agent.

自律のコストと今後の展望

無料のものはありません。エージェント型検索は、標準の密集検索よりも高価で遅いです。ViDoRe v3 の結果を見てみると、エージェントは1クエリあたり平均136秒を要し、1クエリあたりおおよそ760kの入力トークンと6.3kの出力トークンを消費します。 （注: 連続待機遅延は、1つの A100 GPU で、同時に Claude API 呼び出しを1件のみ行った場合の真の検索時間を反映するために測定されています。）

ただし、エージェント型検索は高リスク・高複雑なクエリに対して極めて実用的なアプローチだと信じています。今後の第一の取り組みはコスト削減に焦点を当てています。これらのエージェント的推論パターンを、より小型で専門的なオープンウェイトのエージェントへ蒸留する方法を積極的に研究しています。think と retrieve のループをネイティブに統括するよう小型モデルをファインチューニングすることで、遅延とコストのごく一部で Opus レベルの精度を実現することを目指します。

Build Your Own Agentic Pipeline

独自のエージェント型パイプラインを構築する。私たちのリーダーボード上位の実行では、Claude Opus や gpt-oss のような組み合わせと、私たちの研究用埋め込みモデルを併用しましたが、このアーキテクチャの真の強さはモジュール性にあります。生産準備が整ったデプロイメントでは、選択したエージェントを私たちの堅牢な商用埋め込みモデル llama-nemotron-embed-vl-1b-v2 と組み合わせて使うことを強くお勧めします。これらのモデルを探索し、ツールを活用し、独自で高い汎用性を持つリトリーバルワークフローを構築し始めるには、今すぐ NeMo Retriever ライブラリ をご覧ください。