NVIDIA NeMo Retriever 登顶 ViDoRe 榜单

深度Hugging Face2026年3月13日5 分钟阅读
NVIDIA NeMo Retriever 登顶 ViDoRe 榜单
NVIDIA NeMo Retriever 团队开发的智能体检索(Agentic Retrieval)流水线在 ViDoRe v3 榜单排名第一,并在推理密集的 BRIGHT 榜单位列第二。其核心优势在于通用性,能动态适应不同数据集的检索策略。

NVIDIA NeMo Retriever 团队开发了一套新的智能体检索(Agentic Retrieval)流水线,目前在 ViDoRe v3 流水线 榜单上排名第一。同时,这套相同的流水线架构在要求极高的推理密集型 BRIGHT 榜单上也拿到了第二名。

AI 检索领域发展迅速,很多方案都是高度专业化的,只在特定狭窄任务上表现优异。但现实中的企业应用很少能拥有完美整理的单领域数据。它们需要的系统必须能无缝适应各种挑战——从解析复杂的视觉布局到执行深度逻辑推理。

因此,我们在设计中优先考虑了通用性。我们没有依赖数据集特定的启发式方法,而是构建了一个智能体流水线,它能动态调整搜索和推理策略来适应手头的数据。这使得我们无需更改底层架构,就能在截然不同的基准测试中实现最先进的性能。

动机:为什么语义相似度不够

多年来,基于语义相似度的密集检索一直是查找信息的标准方法。然而,随着检索应用范围的扩大,寻找相关文档已经超出了单纯的语义相似度。复杂的文档搜索需要推理能力、对现实世界系统的理解以及迭代探索。

这里存在一个根本性的差距:大语言模型擅长思考和推理,但无法一次性处理数百万份文档。相反,检索器可以轻松筛选数百万份文档,但推理能力有限。智能体检索通过在大语言模型和检索器之间创建一个主动的、迭代的循环来弥合这一差距。

工作原理:智能体循环

智能体检索流水线概览

智能体检索流水线概览

我们的智能体检索流水线基于 ReACT 架构。智能体不是执行一次性的查询,而是迭代地搜索、评估和改进其方法。

智能体利用内置工具,如 think 来规划方法,final_results 来输出给定查询所需的确切文档,以及 retrieve (query, top_k) 工具来探索语料库。通过这个循环,我们观察到成功的搜索模式自然出现:

  • 生成更好的查询: 智能体根据新发现的信息动态调整其搜索查询。
  • 持续重述: 它会不断重述查询,直到找到有用信息。
  • 分解复杂性: 它将复杂的多部分查询分解为多个目标明确的更简单查询。

最后,为了综合迭代发现的结果,智能体调用 final_results 工具输出最相关的文档,并按它们与给定查询的相关性进行排序。作为安全网——例如,当智能体达到最大步数或上下文长度限制时——流水线会回退到 Reciprocal Rank Fusion (RRF),该算法根据文档在智能体轨迹中所有检索尝试中的排名进行评分。

为速度和规模而优化

智能体工作流以速度慢和资源消耗大而闻名。为了让这个流水线能够在榜单规模上进行评估,我们必须重新思考大语言模型智能体和检索器之间的通信方式。

最初,检索器是通过一个 Model Context Protocol (MCP) 服务器暴露给智能体的——这是一个自然的选择,因为 MCP 的设计初衷正是为了让大语言模型能够访问外部工具。但在实践中,这种架构给实验速度带来了复合成本。每次运行都需要启动一个单独的 MCP 服务器,将正确的数据集语料库加载到 GPU 内存中,并协调客户端和服务器的生命周期。这些步骤中的每一步都可能导致静默配置错误,或者在大量请求下服务器冻结。网络往返给每次检索调用增加了延迟,而管理双进程设置的整体认知负担使得其他团队更难采用和迭代该流水线。

为了解决这个问题,我们用了一个进程内的线程安全单例检索器取代了 MCP 服务器。这个单例会加载模型和语料库向量嵌入(Embedding)一次,用可重入锁保护所有访问,并向任意多个并发智能体任务暴露相同的 retrieve() 接口——实现了 MCP 服务器的关键优势(从多个线程安全、共享地访问驻留在 GPU 上的检索器),而没有产生网络序列化开销或需要单独的服务器进程。这一架构变更消除了整个类别的部署错误,并显著提高了 GPU 利用率和实验吞吐量。

跨基准测试的通用性与专业性

现代检索评估中的一个常见现象是,针对某一特定类型任务高度优化的解决方案,在应用于完全不同的领域时,往往会出现性能差距。

流水线ViDoRe v3
NeMo 智能体检索 (Opus 4.5 + nemotron-colembed-vl-8b-v2)69.22 (#1)
密集检索 (nemotron-colembed-vl-8b-v2)64.36
INF-X-Retriever (INF-Query-Aligner + nemotron-colembed-vl-8b-v2)62.31
INF-X-Retriever51.01
流水线BRIGHT
INF-X-Retriever63.40 (#1)
NeMo 智能体检索 (Opus 4.5 + nemotron-reasoning-3b)50.90 (#2)

我们在推理密集的 BRIGHT 榜单上以 NDCG@10 50.90 的成绩排名第二。该榜单的第一名解决方案 INF-X-Retriever 取得了令人印象深刻的 63.40。然而,为了测试跨领域适应性,我们在 ViDoRe v3 上对 INF-X 流水线(搭配与我们智能体流水线相同的 nemotron-colembed-vl-8b-v2 向量嵌入模型)进行了基准测试,这是一个专注于视觉丰富且多样化的企业文档的数据集。在这个不同的任务上,其性能为 NDCG@10 62.31,低于密集检索的分数 64.36。换句话说,INF-Query-Aligner 在 ViDoRe v3 上并没有超越密集检索的基线。

相比之下,我们相同的智能体流水线(将 Opus 4.5 与 nemotron-colembed-vl-8b-v2 配对)在 ViDoRe v3 上以 69.22 的分数获得了第一名。

这凸显了我们方法的一个核心优势:通用性。我们的智能体循环没有依赖数据集特定的启发式方法或查询重写器/对齐器,而是自然地调整其策略以适应手头的数据集,无论它需要多步逻辑推理还是解析复杂的视觉布局。

消融研究:开源与闭源模型

ViDoRe v3

智能体向量嵌入模型NDCG @10平均秒/查询总输入 token (M)总输出 token (M)平均检索调用次数
Opus 4.5nemotron-colembed-vl-8b-v269.22136.31837159.2
gpt-oss-120bnemotron-colembed-vl-8b-v266.3878.61860132.4
gpt-oss-120bllama-nemotron-embed-vl-1b-v262.4278.11459132.5
-nemotron-colembed-vl-8b-v264.360.67---
-llama-nemotron-embed-vl-1b-v255.830.02---

BRIGHT

智能体向量嵌入模型NDCG @10平均秒/查询总输入 token (M)总输出 token (M)平均检索调用次数
Opus 4.5llama-embed-nemotron-reasoning-3b50.79148.212511111.8
gpt-oss-120bllama-embed-nemotron-reasoning-3b41.2792.81546114.5
gpt-oss-120bllama-nemotron-embed-vl-1b-v233.85139.11516126.6
-llama-embed-nemotron-reasoning-3b38.280.11---
-llama-nemotron-embed-vl-1b-v219.560.08---

我们进行了广泛的消融研究,以理解前沿闭源模型和开源替代方案之间的权衡:

  • 模型选择: 在 ViDoRe v3 上,将 Opus 4.5 替换为开源的 gpt-oss-120b 导致准确率小幅下降(NDCG@10 从 69.22 降至 66.38),并且检索调用次数少得多。在 BRIGHT 上,差距更大,表明深度推理任务仍然极大地受益于像 Opus 4.5 这样的前沿模型。
  • 向量嵌入: 将智能体与专门的向量嵌入配对(ViDoRe 用 nemotron-colembed-vl-8b-v2,BRIGHT 用 llama-embed-nemotron-reasoning-3b)产生了最佳结果,证明一个强大的基线检索器为智能体提供了更高的性能上限。
  • 有趣的是,智能体可以缩小强向量嵌入模型和弱向量嵌入模型之间的差距。例如,在 ViDoRe 上,更强的 nemotron-colembed-vl-8b-v2 和更弱的 llama-nemotron-embed-vl-1b-v2 在密集检索中的差距约为 8.5 分,但当与 gpt-oss-120b 智能体配对时,差距缩小到约 4 分。同样,在 BRIGHT 上,llama-embed-nemotron-reasoning-3bllama-nemotron-embed-vl-1b-v2 好约 19 分,但当与 gpt-oss-120b 智能体配对时,领先优势缩小到约 7.5 分。

自主性的代价与未来方向

天下没有免费的午餐。智能体检索比标准密集检索更昂贵、更慢。看看我们的 ViDoRe v3 结果,智能体平均每个查询耗时 136 秒,每个查询大约消耗 76 万输入 token 和 6300 输出 token。(注:顺序延迟是在单个 A100 GPU 上测量的,且只进行单个并发的 Claude API 调用——即不同时搜索多个查询——以反映真实用例中的实际搜索时间)。

然而,我们相信智能体检索对于高风险、复杂的查询是一种高度可行的方法。我们接下来的工作重点是降低成本:我们正在积极研究如何将这些智能体推理模式蒸馏到更小、更专业的开源智能体中。通过微调更小的模型来原生编排 thinkretrieve 循环,我们的目标是以极低的延迟和成本实现 Opus 级别的准确率。

构建你自己的智能体流水线

虽然我们登顶榜单的运行探索了像 Claude Opus 和 gpt-oss 与我们研究向量嵌入模型的组合,但这种架构的真正优势在于其模块化。对于生产就绪的部署,我们强烈建议你尝试将你选择的智能体与我们稳健的商业向量嵌入模型 llama-nemotron-embed-vl-1b-v2 配对。要探索这些模型、深入了解工具并开始构建你自己高度通用的检索工作流,请访问 NeMo Retriever 库

觉得有用?分享给更多人

获取每周 AI 工具精选

工具推荐、实战教程和生态洞察,每周更新。

相关文章

Simon Willison 正在重构 LLM Python 库的抽象层,以支持服务器端工具执行等新功能。他利用 Claude Code 分析了四大 LLM 提供商的客户端库,生成了用于测试的 curl 命令和 JSON 输出。这些调研材料已开源,旨在帮助设计更通用的 API 抽象。

深度Simon Willison·4月5日·1 分钟

智能体技能——包含程序性知识和可执行资源的结构化包,供智能体在推理时动态加载——已成为增强 LLM 智能体的可靠机制。然而,推理时技能增强存在根本性限制:检索噪声引入无关指导,注入的技能内容带来大量 token 开销,而模型从未真正习得它所遵循的知识。我们提出一个问题:技能是否可以被内化到模型参数中,使其在无需任何运行时技能检索的情况下实现零样本自主行为?我们提出 Skill0,一个专为技能内化设计的上下文强化学习框架。Skill0 引入了一种训练时课程,从提供完整技能上下文开始,逐步撤除。技能按类别离线分组,并与交互历史一起渲染为紧凑的视觉上下文,教授模型工具调用和多轮任务完成。动态课程机制…

深度·4月5日·17 分钟

评论