
Cloudflare 推出面向 AI 智能体的 Web Search API 测试版
来源标题:Web search for agents is here: Why ranking still decides the answer
Cloudflare 在 AI Gateway 中开放 Web Search API 测试版,让智能体通过单一接口调用多家搜索服务,并附带来源链接、日志和访问控制。其出发点是没有搜索时智能体会编造网址或依赖过时训练数据。但报道指出,实时搜索只解决“找到”的问题,哪些页面和自有文档值得信任仍取决于排序。
以下正文由 AI 翻译自 The New Stack(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
AI agent 一直存在一个 URL 问题。当 agent 需要获取最新信息却没有搜索工具时,它往往会凭空编造一个它认为答案所在的网址。它可能会猜测类似 docs.example.com/v4.2/auth 这样的地址,尝试加载,却因为页面不存在而收到“页面未找到”的错误。然后它要么继续猜测,要么退回到训练数据中的过时信息。
“实时网页搜索为 AI agent 提供新鲜页面。但如何决定哪些页面比自有数据更可信,仍然是一个排序问题。”
基础设施提供商已经注意到了这一点。10 月,InfoQ 报道称 Cloudflare 在其 AI Gateway 中开放了 Web Search API 的 beta 版本。Agent 可以通过一个接口调用多家搜索提供商,并获得带有来源链接、日志记录和访问控制的实时结果。Cloudflare 的理由直截了当得令人耳目一新:没有搜索,agent 就会靠猜。
这是一个值得欢迎的变化,实时搜索很可能在一年内成为 agent 的默认工具,但它只解决了“找到”这一半问题。当新鲜页面摆在 agent 面前时,仍然需要有机制来决定这些页面中哪些、以及你自己的文档中哪些,才是 agent 真正应该依赖的。这个决策发生在你的检索层。
问题:两个证据池,一个上下文窗口
在企业内部工作的 agent 很少仅靠网页来回答。它还拥有让它对该公司有价值的数据:产品目录、文档、合同、支持历史、账户记录和权限。接入网页搜索后,任务的每一步都可以从两个截然不同的池中获取信息。
| 网页结果 | 内部数据 |
|---|---|
| 时效性 | 通常是几小时到几天前 |
| 质量 | 参差不齐:官方文档与论坛帖子并存 |
| 结构 | 大多是非结构化文本 |
| 权威性 | 需要从来源推断 |
| 访问控制 | 公开 |
Agent 必须协调这些信息,而且往往在一个任务中就要协调多次。它需要回答的问题,是搜索 API 从未被设计来处理的问题。当昨天的供应商变更日志与去年春天的内部知识库文章相互矛盾时,以哪个为准?这个结果适用于该客户的版本和地区吗?Agent 甚至被允许展示它吗?
这些都是排序和过滤决策。它们取决于你的数据和业务规则,因此你必须在两者都可得的地方做出这些决策。
为什么简单拼接结果在生产环境中会失效
最简单的集成方式是:跑一次网页搜索,跑一次内部搜索,把一个列表追加到另一个后面,让模型自己去理清。一开始可能效果不错,但一旦面对不断增长的数据和流量,它往往会以几种可预见的方式失效:
- 冲突无法解决。 模型看到两个自信的来源相互矛盾,却没有任何信号判断哪个更新或更权威,于是它要么选一个,要么把它们混合成一个与两者都不符的答案。
- 过时信息被隐藏。 一篇 3 个月前的知识库文章如果与用户的措辞几乎完全匹配,仅凭相似度就会胜过 4 天前的变更日志。embedding 中没有任何信息表明这篇文章已经过时。
- 权限应用得太晚。 如果访问规则在检索之后才运行,受限内容可能已经进入了 prompt。如果规则执行得粗糙,有用的结果会连同敏感内容一起被丢弃。
- 成本和延迟叠加。 人只跑一次搜索然后阅读结果。而 agent 在一个任务中,随着规划、检查和细化,可能触发十几次甚至更多的检索调用。每次调用都把每个候选结果发给模型,成本会迅速累积,而更多的上下文并不能可靠地带来更好的答案。
更大的上下文窗口解决不了这些问题。给模型更少、但选择更精准的证据,才能解决。
“更大的上下文窗口解决不了这些问题。给模型更少、但选择更精准的证据,才能解决。”
Clarm 是一家 Y Combinator 公司,为开源软件公司构建销售和支持 agent,它很早就遇到了这个问题。其创始人 Marcus Storm-Mollard 表示,团队意识到“搜索,而非生成,才是真正需要解决的问题”。生成答案是容易的部分。找到正确的信息来支撑答案才是困难的部分,这就是为什么 Clarm 通过单一查询运行文本搜索、向量相似度和结构化过滤,而不是把独立的存储拼接在一起。
当 agent 跨来源搜索时,发生了什么变化
当 agent 将实时网页结果与内部数据结合时,它们需要考虑到不同的检索方法、元数据、权限和排序信号。有四个设计考量尤为突出。
1. 在单一查询中跨方法检索
关键词匹配能捕捉精确的产品名称、错误代码和版本文本串,而这些恰恰是 embedding 出了名地不擅长的。向量搜索能捕捉改写和意图。结构化过滤则强制执行硬性约束,如客户、版本和授权。
在单一索引集合内,混合检索可以结合关键词匹配、向量相似度和结构化过滤。但这本身并不能将外部网页搜索 API 的结果与内部索引的结果融合在一起。双源集成需要单独的设计决策。
select * from evidence where
({targetHits: 200}nearestNeighbor(embedding, q) or userQuery())
and visibility contains "customer"
and product_version contains "4.2"
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。