Agent新型网络搜索降低检索税

Andrej Karpathy 曾说过，LLM 有点像一个患有顺行性遗忘症的同事。这种症状表现为：你保留着旧的记忆，但无法形成新的记忆。

LLM 在两个方面受制于这种状况。它不会在跨对话中记住你，也从未学习过训练结束后发生的任何事情。

记忆功能的存在是为了弥补第一个缺口。本文探讨的是第二个缺口，因为 AI Agent 大多被用来处理当前的事务。

市场在变化，人员在变动，价格在更新，新闻在爆发。网络搜索是模型看到这一切的方式，而这个方式的效果最终决定了整个 Agent 有多有用。

于是你给 Agent 装上一个搜索工具，以为它现在能读取网页了。然后你检查最初的几次追踪，结果令人失望。

你为搜索支付的大部分 Token 都浪费在了 Agent 需要翻找的原始页面文本上，只有很少一部分用在了回答你的问题上。

原因在于搜索调用实际返回的内容。典型的搜索 API 返回的是链接和三十个词的摘要片段，仅此而已。

所以 Agent 并不是在读取网页，而是在阅读目录。获取实际页面成了它的工作，这意味着在真正的工作开始之前，它需要拉取 HTML、剥离标记、挖掘可用文本。

在单个查询上你几乎注意不到这种开销。但在需要多次搜索的任务中，比如一项研究任务或一个简报流水线，你每一次都为此支付代价。

问题不在于 Agent 搜索得不好，而在于每次搜索调用返回的是内容的指针而非内容本身，而 Agent 每次调用都要花钱来填补这个差距。

我们通过三种检索设置运行了同一个问题，并统计了 Token 数。最昂贵的设置成本大约是最便宜检索选项的 4 倍。

本文会详细分析这些数字，并展示当 Agent 是读者时，搜索响应应该是什么样的。本文还涵盖了一类只有完整文档才能回答的问题。

我们先来看看成本究竟来自哪里。

每个循环迭代都要支付检索税

这种重复的获取和清洗工作有个名称。称之为检索税，即 Agent 在推理你的问题之前，为准备内容而消耗的 Token。

只需要一个循环的 Agent 就能感受到它的存在。一个研究 Agent 搜索、阅读返回的内容、决定下一步查找什么、然后再次搜索，每一次循环都在上一次的基础上支付检索税。

以下是单个问题的成本。我们特地选了“Y2K 是什么？”这个问题，因为模型从训练中已经知道了答案。

我们通过三种方式回答它：直接从记忆里、通过网络搜索循环、通过一个 owned index（一种提前爬取并清洗页面并存储自己处理过的网络副本的搜索服务），并统计每次的计费 Token 总数。

选择一个模型已知的问题是为了保持实验的干净。三次运行中的思考成本是相同的，任何超出它的 Token 都完全来自于检索。

从记忆中回答，整个过程大约用了 600 个 Token。这是基线，即零检索下的回答成本。

owned index 是一种已经爬取并清洗了页面的搜索服务，一次调用就能返回完整文档。使用它大约花了 6900 个 Token。

单次网络搜索跳转的成本大约是 3750 个 Token。但摘要片段往往太简短，无法回答，所以 Agent 会重新获取并精化，三次跳转后成本攀升到大约 28700 个 Token，是 owned index 的 4 倍多。

循环与索引之间的差距就是检索税的直观体现。每一次跳转都会对整个不断增长的上下文窗口重新计费，所以到第三次循环时，Agent 大部分成本都花在了携带它已经读过的页面上。

owned index 完全跳过了这些。当查询到达时，完整文档已经在那里了。

实现这一切的关键在于搜索调用本身的返回结果，所以我们接下来看看这一点。

好的检索返回文档，而不是方向

解决方案不在于更聪明的 Agent 或更好的提示词，而在于搜索调用返回的内容。

SERP（搜索 API 返回的简单结果列表）给你的是 URL，然后让 Agent 自己去读网页。

一个以爬取优先的工具通过返回原始 HTML 或 Markdown 更进一步，但 Agent 在使用前仍然需要清洗它。

owned index 在查询到达之前就完成了所有这些工作，所以返回的内容已经可读。

以下是三者对同一个查找操作的对比。我们将搜索 Christoph Molnar，他是《可解释机器学习》一书的作者。

SERP

## 查询
results = search("Christoph Molnar interpretable ML")

## 响应
[
  {"title": "Interpretable Machine Learning", "url": "christophmolnar.com/books/...", "snippet": "一份让黑盒模型可解释的指南..."},
  {"title": "Christoph Molnar - Google Scholar", "url": "scholar.google.com/...", "snippet": "被引次数：12,847..."},
  # 另外5个来自不同域的结果
]

Agent 得到了一串标签页，而不是一个答案。

神经搜索

## 查询
results = neural_search("Christoph Molnar", type="person")

## 响应
[
  {"highlight": "Christoph Molnar 是一位统计学家和机器学习可解释性研究员..."},
  {"highlight": "《可解释机器学习》的作者，这是一本拥有超过40万读者的开放获取书籍..."},
  # 一段关于另一位研究人员的无关段落
]

它找到了正确的人，但只是高亮片段。要获取完整记录仍然需要另一次调用。

Owned index

## 查询
result = client.search("Christoph Molnar", scope="people")

## 响应
{
  "name": "Christoph Molnar",
  "roles": [
    {"title": "研究科学家", "org": "Mindful Modeler", "start": "2021"},
    {"title": "作者", "work": "Interpretable Machine Learning", "editions": 3}
  ],
  "education": [{"degree": "统计学博士", "institution": "慕尼黑大学"}],
  "websites": ["christophmolnar.com", "github.com/christophM"],
  "languages": ["德语", "英语"]
}

一次调用返回完整记录，Agent 直接进入推理。

Seltz 正是为此构建的一个网络索引。它提前爬取网络，将每个页面处理成结构化文档，并通过一次 API 调用返回已处理好的内容。

它带有三个范围，每个范围根据你的 Agent 需要返回不同类型的已完成文档。

people 范围返回完整的结构化档案，包含每个职位及其日期、教育背景、网站以及该人曾工作过的组织。

news 范围返回完整的文章文本，并带有日期窗口，因此你可以只拉取特定时间段内发布的内容。

wiki 范围返回干净的 Wikipedia 文档，有助于在深入之前围绕公司、行业或主题构建上下文。

在基于 people 范围进行构建之前，有一个注意事项值得了解。它在总监和区域领导层这个层级效果最好。

对于最资深的高管，从开放网络搜索开始，然后使用 Seltz 来丰富他们之下的所有人。

有些答案只存在于跨记录之中

完整文档解锁了超越减少检索税之外的某些能力。

有些问题并不存在于任何单个搜索结果中。答案只有在跨多条记录阅读并找到它们交叉点时才存在。

无论是 SERP 还是神经搜索工具都无法在第一次调用时做到这一点。它们没有持有每条记录的足够信息来合并它们，因此这项工作又落回了 Agent 身上。

考虑一个 GTM 团队实际会运行的问题。你希望获得所有在过去一个季度招聘了数据或 AI 领导岗位人员的潜在目标客户。

回答这个问题需要两样东西：完整的职位履历，以找到谁在何时开始了一份新工作；以及近期的新闻，以确认时间并揭示触发事件。

你可以查询 people 范围来找到谁最近转到了相关岗位，然后交叉引用 news 范围来查找触发事件。

最终输出的是一个按热度排序的客户名单，并附带足够的上下文，以便为每个客户撰写一条相关的初始接触文案。

这个答案在网络上任何地方都不存在为一个页面。它只在你合并记录时才存在，而合并只有在你有完整记录时才可能。

串联发现与深度，每次迭代都会更便宜

Seltz 并不能取代开放网络搜索。它是针对特定类别问题的正确工具。

开放网络搜索擅长发现。比如查找当前谁担任某个职位，确认上周发布的内容，阅读今早上线的页面。

一旦你知道了你要找什么，Seltz 就能在一次跳转中返回完整记录，而不是一个标题和一个链接。

许多流水线对每个查询都使用同一个搜索工具，无论问题需要什么。发现查询和深度查找查询使用相同的调用，循环在两者上都支付检索税。

相反，将两者串联起来，每次循环迭代就能根据其实际目标获得正确的检索形态。

这就是本文的核心论点。Agent 循环的成本更多是由每次搜索调用返回的内容决定的，而不是模型本身。返回已完成的文档正是你停止为同一套页面反复付费的方式。

• 原文链接： x.com/akshay_pachaar/sta...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～