AI智能体的AI搜索:Grounded Search vs 传统RAG — 哪个真正有效?

你的AI智能体推理能力一流,但一问到竞争对手当前定价就露馅。本文解析为什么RAG不是答案,以及Grounded Search如何改变智能体工作流。

by AnyCap

你可能经历过这样的时刻:你的编码智能体刚刚完成了一次优雅的重构,生成了一张完美的架构图,然后你问它"我们最大的竞争对手现在定价多少?"——它要么编造一个答案,要么告诉你它的训练数据截止于半年前。

这不是模型的问题。Claude、GPT、Gemini——它们在推理方面都极其出色,但谁也无法独自看到实时网络。于是开发者们被迫拼凑Google API密钥、向量数据库和大模型调用,试图构建一个本应一条命令就能完成的功能。

这个问题有个名字:搜索鸿沟——AI智能体基础设施中最大的缺口。而解决方案不是堆更多的RAG管线,而是一种完全不同的方法。


RAG是为内部文档而生的,不是为互联网而生的

当你的数据存放在向量数据库中、每季度才更新一次时,检索增强生成(RAG)工作得非常好。员工手册、产品规格、历史数据。建索引、查询、搞定。

问题始于你需要的信息不在你的索引中。

竞争对手推出了新的定价层级。某项法规发生了变化。你依赖的某个库出现了一个严重Bug,整个Hacker News都在讨论。你的RAG管线对此一无所知。它不可能知道——它只能看到你上次重建索引时喂给它的内容。

我见过团队试图通过加快索引重建频率来解决这个问题。然后尝试混合搜索。然后为内部和外部数据构建独立的管线。每增加一层,系统变得更强大——也更脆弱。每个新数据源都是一次新的集成,每次集成都可能在凌晨两点出故障。

真正的问题不是RAG不好,而是RAG的设计初衷是回答"关于X,我们的政策是怎么说的"——而不是"此时此刻世界上正在发生什么"。


Grounded Search在你提问的那一刻从网络中检索实时信息。不是从索引中,也不是从快照中,而是从当前公开可用的任何信息中,并且每一个主张都附带来源URL。

这更像是你自己做研究的方式:搜索、浏览几个来源、综合得出答案,并注明每条信息的出处。区别在于,你的智能体在几秒内而不是几分钟内完成这一切。

用一个简单的对比来具体说明:

维度 传统RAG Grounded Search
数据来源 你自己索引的文档 此时此刻的实时网络
知识范围 你索引过的任何内容 所有公开可访问的信息
过时时间 源数据变化的那一刻 不会过时——每次查询都重新获取
部署成本 索引管线、向量数据库、文档切分 一条CLI命令

对于私有数据——客户记录、内部财务数据、任何不应该接触公共互联网的内容——RAG依然胜出。大多数团队最终采用的实际架构是:内部知识用RAG,外部上下文用Grounded Search。智能体根据被问到的内容进行选择。


智能体实际上如何使用它

CLI被刻意设计得简单,因为智能体不会导入库——它们运行命令。

anycap search "Acme Corp enterprise pricing Q2 2026" \
  --citations \
  --output acme-pricing.json

智能体得到一个带引用的结构化答案。它可以将答案传递给用户,输入到工作流的下一步,或保存起来供后续使用。无需折腾API密钥,无需封装Python SDK。它就是智能体像调用 lsgit diff 一样可以调用的工具。

使这强大的不是搜索本身,而是搜索成为智能体可以串联使用的众多工具之一。搜索竞争对手定价。深度研究市场格局。生成对比可视化。将所有内容整合成一份报告。发布它。

一个CLI。一次认证。智能体在不同功能之间切换,无需为每一步写定制集成代码。

我见过这种模式在竞争监控方面特别有效。智能体每周检查竞争对手定价,与上周对比,标记变化,并在Slack中推送摘要。一个cron任务,零中间件。


选择搜索工具时真正重要的东西

暂时忘掉功能对比矩阵。以下是我在评估Grounded Search工具时实际会测试的:

引用是否正确? 测试20个你知道正确答案的查询。对于每一个,点击引用并验证它们是否真正支持工具所声称的内容。一个用错误引用返回"正确"答案的工具,比一个承认自己不知道的工具更危险。我曾经因为一个搜索工具引用了实际说法相反的来源,而浪费了半天时间追逐一个"事实"。

实际速度有多快? 不是营销宣传的延迟,而是50个智能体同时请求时的P99延迟。一个每个搜索步骤都要等8秒的智能体管线会让所有参与者崩溃。

边缘情况处理得如何? 问一些冷门的东西、最近发生的事情、不同来源有分歧的问题。好工具会呈现出冲突,而不是将分歧平均化成一堆废话。

是CLI还是SDK? 这比听起来更重要。智能体不会写 from x import y,它们调用命令。一个藏在Python库后面的工具,在你手动写封装之前,你的智能体根本无法使用。


为什么这比听起来更关键

搜索鸿沟不是一个小麻烦。它是阻碍智能体处理真正研究工作流的最大单一因素。一个能推理但不能搜索的智能体,就像一个Stack Overflow被屏蔽的开发者——有能力,但被切断了与真正需要的信息的联系。

解决方案并不复杂。只是大多数团队不会首先想到它,因为RAG很熟悉,而搜索鸿沟只有在你的智能体向信任它的人自信地传达错误信息时才会变得显而易见。

如果你的智能体正在撞这堵墙——处理内部数据时表现出色,但一旦需要外部信息就崩溃——那可能不是模型的问题,也可能不是提示词的问题,而是搜索架构本身为不同的问题而构建的。


延伸阅读: