13款搜索API实测：你忽略的隐藏成本可能比标价还高

搜索API的真实账单，远不止标价那么简单

在构建AI Agent或RAG（检索增强生成）系统时，开发者往往只关注搜索API标注的"每次请求价格"。然而，一位开发者的实测揭示了一个被普遍忽视的真相：搜索API的真正成本，一半藏在你看不到的地方。

RAG（Retrieval-Augmented Generation）是当前AI应用最主流的架构模式之一，其核心思想是让大模型在生成回答前先检索外部知识库，从而减少"幻觉"并提供有据可查的答案。所谓"幻觉"（hallucination），是指大模型在缺乏真实信息支撑时，凭借语言模式生成看似合理但实际错误的内容——这是纯粹依赖模型参数知识的根本缺陷，也是RAG架构被广泛采用的核心驱动力。在RAG架构中，大模型的计费以token为单位——token是文本被分割后的最小处理单元，英文中大约每个单词对应1-1.5个token，中文则每个汉字约1-2个token。值得注意的是，token化（tokenization）的具体实现因模型而异，OpenAI使用的BPE（Byte Pair Encoding）算法通过统计语料中的高频字节对来构建词表，这导致常见词汇被编码为单个token，而罕见词汇则被拆分为多个token。这意味着搜索返回内容中包含的专业术语、URL、代码片段等非常规文本，其token消耗可能远高于同等长度的普通文本——一个包含大量URL和技术参数的搜索结果，其实际token数量可能比同等字符数的普通段落高出30-50%。

以GPT-4o为例，输入token的价格为每百万token 2.5美元，输出token为10美元。这意味着，如果搜索API返回一个包含5000 token的冗长payload，仅"阅读"这段内容的成本就已经超过了很多搜索API本身的请求费用。而在实际Agent运行中，一个任务可能触发数十次搜索调用，token成本会以乘数效应快速放大。

这位开发者（同时也是SERPdive的构建者，该产品占据了本次测试13个配置中的3个）对13种定价配置进行了系统性基准测试。他的核心观点一针见血：每家搜索服务商都会公开一个价格——即每次请求的费用。但请求返回后，它会向你的Agent发送一段payload（返回内容），而你的大模型在"阅读"这段内容时，会再次向你计费。

"第二笔成本从来不会出现在定价页面上，而它通常才是更大的那一笔。"

为什么搜索API存在"第二笔成本"

理解这个问题的关键在于搜索API在AI链路中的工作方式。AI Agent是一种能够自主规划、调用工具并迭代执行任务的AI系统。与传统的单轮对话不同，Agent往往需要多次调用外部工具（如搜索引擎、数据库、代码执行器）来完成复杂任务。这种能力通常基于"工具调用"（function calling / tool use）机制实现——模型根据当前任务状态自主决定调用哪个工具、传入什么参数，并将工具返回的结果整合到后续推理中。主流的Agent框架如LangChain、LlamaIndex、AutoGPT等都将这种模式标准化了。

在这种多步骤架构中，每一次工具调用都会产生成本，而工具返回的结果又会被注入模型的上下文窗口（context window）进行处理。上下文窗口是大模型一次能"看到"的全部文本的容量上限，目前主流模型的上下文窗口从128K到200K token不等（Claude 3.5为200K，GPT-4o为128K，Gemini 1.5 Pro为200万token）。当搜索返回的内容占据了大量上下文空间时，不仅产生直接的token费用，还可能挤占了其他有用信息的空间——如系统提示、对话历史、其他工具的返回结果等——间接影响回答质量，甚至在极端情况下触发上下文溢出，迫使系统进行代价高昂的截断或摘要操作。

更值得关注的是Agent架构中工具调用的成本累积特性。在ReAct（Reasoning + Acting）等主流Agent范式中，模型每一步都需要"看到"之前所有步骤的完整历史——包括所有工具调用的参数和返回结果。这意味着第N次搜索调用的token成本不仅包括本次返回的payload，还包括前N-1次搜索结果在上下文中的重复计费。这种累积效应使得payload体积的影响呈二次方级别增长，而非线性增长。举例来说，如果一个Agent在完成任务过程中进行了5次搜索，每次返回3000 token，那么第5次搜索时模型需要处理的历史搜索内容就已达到12000 token（前4次的返回结果）——这还不包括模型自身的推理输出和系统提示。这就是为什么payload体积在Agent场景下的成本影响远大于简单的单次调用场景。

一次典型的Agent检索流程分为两步：

1. 搜索调用：Agent向搜索API发起请求，服务商按次收费；
2. 阅读理解：搜索返回的原始内容（网页摘要、正文片段等）被塞进大模型的上下文，模型需要消耗token来处理这些内容并生成答案。

问题就出在第二步。不同搜索服务商返回的payload体积差异巨大——有的精简克制，有的则塞满冗余文本。而这些内容全部要经过大模型的token计费。换句话说，一个标价便宜但返回内容臃肿的API，最终可能比标价贵但返回精炼的API花掉你更多钱。

Payload体积差异的技术根源

不同搜索API返回的payload体积之所以差异巨大，根源在于各服务商的数据处理策略不同。当前搜索API市场可大致分为三个代际：第一代是以SerpAPI、Bright Data、ScaleSerp为代表的传统SERP抓取服务，主要面向SEO监控和市场研究场景，它们的设计初衷是为数据采集和竞品分析服务，追求"完整性"而非"精炼度"；第二代是以Bing Web Search API、Google Custom Search为代表的官方搜索引擎API，它们提供结构化的搜索结果但通常不包含网页正文内容；第三代则是以Tavily、Exa、Perplexity API、SERPdive为代表的"AI-native"搜索API，它们从设计之初就考虑了作为LLM工具链组件的使用场景，在返回数据结构、信噪比、延迟特性上与前两代有本质差异。

一些服务商（如传统的SERP API）会返回原始网页的大量内容，包括HTML标签残留、侧边栏文本、广告文案、面包屑导航、页脚信息等"噪声"内容。而另一些服务商则会在服务端进行内容提取（content extraction）和去噪处理，只返回与查询高度相关的核心段落。内容提取技术包括基于DOM结构分析的正文识别（如Readability算法，最初由Mozilla为Firefox阅读模式开发，通过分析HTML元素的类名、标签类型和文本长度来判断哪些区域是正文）、基于文本密度的噪声过滤（通过计算HTML标签密度与文本密度的比值来区分正文与导航/广告区域——正文区域通常具有高文本密度和低标签密度的特征）、以及更先进的基于机器学习的相关性排序（利用BERT等语义模型判断段落与查询的语义相关度，只保留相关性评分超过阈值的段落）。这种差异可以是数量级的——同一个查询，一个API可能返回800 token的精炼内容，另一个则可能返回8000 token的未经处理的原始文本。

从信息论角度看，真正有用的信息密度（signal-to-noise ratio，信噪比）才是衡量搜索API质量的关键指标——高信噪比意味着每个token都携带了与查询相关的有效信息，而低信噪比则意味着大模型需要在大量噪声中"淘金"，既浪费算力也增加了误判风险。研究表明，当上下文中包含过多无关信息时，大模型的注意力机制会被分散，甚至出现"Lost in the Middle"现象——模型倾向于关注上下文开头和结尾的内容，而忽略中间部分的关键信息。这一现象由斯坦福大学的研究团队在2023年的论文中系统性地揭示，他们发现当相关信息被放置在长上下文的中间位置时，模型的检索准确率可下降超过20个百分点。这对搜索API的设计有直接启示：不仅要控制返回内容的总量，还要注意将最相关的信息放在返回结果的前部，以匹配大模型的注意力分布特性。

测试方法：把变量压到最小

为了让对比公平可信，这次基准测试的设计相当严谨：

• 统一问题集：对相同的100个问题进行测试；
• 单次搜索调用：每个问题只发起一次搜索；
• 同一个阅读模型：所有配置使用相同的answering model来处理返回内容；
• 原样传递：payload逐字传给阅读模型，仅去除各厂商自带的synthesis（合成/总结）功能；
• 真实token计费：token数量来自answering call的真实账单，而非估算；
• 统一定价口径：所有价格均采用list pay-as-you-go（按量付费的标价），包括作者自己的产品。

这种测试设计体现了"控制变量法"的核心思想——通过固定除被测变量之外的所有因素，确保最终差异只能归因于搜索API本身的特性。特别值得注意的是"原样传递"这一设计：在实际生产环境中，很多团队会在搜索结果送入模型之前进行二次加工（如截断、摘要、reranking），但这些操作会引入额外变量，使得我们无法准确衡量搜索API本身的"原始成本特性"。同样值得注意的是"单次搜索调用"这一约束——在真实Agent系统中，一个用户问题可能触发3-10次甚至更多的搜索调用（例如先搜索获取概览，再根据概览中的线索进行细化搜索），这意味着本次测试中呈现的成本差异在实际生产中会被进一步放大。

最终结果按"每千次查询的实际总成本"排序。这种方法论的价值在于，它把"搜索费用"和"阅读费用"合并计算，还原了开发者真正会收到的账单。

如何正确解读测试结果

作者特别提醒读者要"带着误差范围来看数据"，这体现了难得的严谨态度：

• 准确率列（correctness）：在n=100的样本量下，误差约为±10个百分点。这基于二项分布的置信区间计算。在统计学中，当衡量一个比例（如准确率）时，样本量n决定了估计的精度。二项分布描述的是"n次独立试验中成功k次"的概率分布，而准确率本质上就是这样一个比例估计。根据正态近似公式，标准误差SE = √(p(1-p)/n)，当p≈0.75、n=100时，SE≈0.043，在95%置信水平（即1.96倍标准误差）下，误差范围为±8.5个百分点，约等于作者所说的±10个百分点。这意味着如果两个API的准确率分别为78%和73%，我们无法断言谁真的更好——它们在统计上是不可区分的。要将误差压缩到±3个百分点以内，需要约1000个测试样本，但这会使测试成本增加10倍。排行榜顶部的几个配置在准确率上并没有被本次测试拉开差距。这也解释了为什么许多大规模的AI评测基准（如MMLU、HumanEval等）通常包含数千乃至上万个测试样本——只有足够大的样本量才能在模型间检测出有意义的性能差异。
• 成本列：作者明确表示这一列"不是噪声"（not noisy），即成本数据是稳定可信的。因为token计数和API计费是确定性的数值，不受采样波动影响——同一个API对同一个查询返回的payload大小基本恒定，不存在随机性。这种对不同指标可信度的区分，是高质量技术评测的标志。在机器学习评测领域，混淆"统计显著性"和"实际显著性"是一个常见错误，而这位作者清晰地区分了哪些数据可以直接比较、哪些需要保留判断。

这种区分非常重要：当准确率难分伯仲时，成本就成了决定性的选型指标。 换句话说，如果几个API在回答质量上打平手，那么谁的总成本更低，谁就是更理性的选择。

对开发者的实际启示

这次测试虽然带有作者自身产品的立场（利益披露明确，所有payload和日志都公开在仓库中供核验），但其揭示的方法论问题具有普遍价值。

评估搜索API要看"全链路成本"

传统的比价方式只看每次请求的单价，这在AI Agent场景下已经严重失真。真正应该衡量的是：从发起搜索到得出最终答案，整条链路花了多少钱。 一个返回内容臃肿的"便宜"API，可能通过撑爆你的模型token账单而变成"贵"的选择。这种"全链路成本"（Total Cost of Ownership，TCO）的思维方式在云计算领域早已被广泛接受——评估一个云服务时，不能只看虚拟机的单价，还要考虑数据传输费、存储费、运维人力等隐性成本。搜索API在AI Agent语境下的成本结构，本质上是同样的TCO问题。更具体地说，这种TCO分析还应包括延迟成本（payload越大，传输和处理时间越长，用户体验越差）、以及间接的工程维护成本（如果需要自建中间层来处理冗余返回内容，这本身就是持续的工程投入）。

payload体积是隐性成本杠杆

搜索返回内容的精炼程度，直接决定了下游模型的成本。这提示开发者在选型时应关注：

• 服务商是否提供内容裁剪、去重能力；
• 返回结果是否包含大量无关的HTML、导航文本等"噪声"；
• 是否可以在API层面控制返回内容的粒度和长度。

值得补充的是，即使选择了一个返回内容较冗余的API，开发者仍有中间层优化手段可用。例如：在搜索结果进入大模型之前，先经过一个轻量级的reranker模型（如Cohere Rerank、BGE-Reranker等）进行相关性排序和截断——reranker是一种交叉编码器（cross-encoder），它将查询和每个候选文档拼接后进行联合编码，输出一个相关性分数，相比双塔模型（bi-encoder）精度更高但速度较慢，通常用于对初步检索结果进行精排。或者使用正则表达式和DOM解析进行规则化去噪（如去除所有<nav>、<footer>、<aside>标签内的内容）；甚至用一个低成本的小模型（如GPT-4o-mini，其输入价格仅为GPT-4o的1/16）先做一轮摘要压缩，将5000 token的原始内容压缩到1000 token以内。

在大规模生产系统中，全链路成本优化已发展出一套更完整的方法论。除了上述手段外，还包括：语义缓存（semantic caching）——对语义相似的查询复用之前的搜索结果，避免重复API调用，实现方式通常是将查询向量化后在向量数据库中做近似最近邻检索，当相似度超过阈值时直接返回缓存结果；自适应检索策略（adaptive retrieval）——根据查询复杂度动态决定是否需要搜索、搜索几次、使用哪个API，例如对于简单的事实性问题可能一次搜索就够，而对于需要综合多个信源的分析性问题则需要多次定向搜索；以及分级模型策略（model routing）——简单查询用廉价模型处理，复杂查询才调用高端模型。这些优化组合使用时，通常能将总成本降低50-80%。但这些中间层操作本身也有成本和延迟，是否值得引入取决于具体的规模和场景——一般而言，当日均调用量超过数千次时，中间层优化的投入就能通过节省的token费用得到回报。

警惕厂商自带的synthesis功能

有意思的是，本次测试特意"去除了各厂商自带的synthesis功能"。Synthesis（合成/总结）功能是近年来搜索API领域的一个重要趋势。以Perplexity API、Exa、Tavily等新一代搜索服务为代表，它们不仅返回检索结果，还会用内置的大模型对结果进行总结和重组，直接给出一个"预消化"的答案。这种"搜索即答案"的模式深受Perplexity产品端成功的影响——Perplexity作为AI搜索引擎在消费端获得了巨大成功（截至2024年估值已超过90亿美元），其API产品自然也延续了这种范式。Tavily则从设计之初就明确面向AI Agent场景，将synthesis作为核心卖点，其文档中直接标榜"为AI Agent优化的搜索API"。Exa则走了另一条路，它使用基于嵌入向量的语义搜索替代传统的关键词匹配，声称能更准确地理解自然语言查询的意图。

这看似方便，但引入了多层问题：首先是额外的成本不透明——synthesis的模型调用费用通常被打包在请求价格中，开发者无法单独核算，也无法知道厂商用的是什么模型、多大规模、是否经过蒸馏优化；其次是可控性降低——你无法选择synthesis使用的模型、prompt策略或截断逻辑，这意味着你的系统行为部分取决于第三方的内部实现，而这个实现随时可能变更且无法提前通知；最后是调试困难——当最终答案出错时，你很难判断是检索环节还是synthesis环节的问题，这种"黑箱叠加黑箱"的架构会让问题排查变成噩梦。在软件工程中，这被称为"可观测性"（observability）问题——一个系统的可观测性取决于你能否通过外部输出推断内部状态，而synthesis功能的引入直接降低了整个链路的可观测性。现代可观测性工程强调三大支柱：日志（logs）、指标（metrics）和链路追踪（traces），而当关键处理步骤被封装在第三方黑箱中时，这三大支柱都无法完整建立。

对于追求成本透明和链路可控的团队，直接拿原始检索结果、用自己的模型统一处理，反而更容易算清账，也更容易定位和修复问题。这种"解耦"的架构哲学——将检索、处理、生成三个环节明确分离——虽然初期搭建成本略高，但在长期维护、成本优化和质量迭代方面具有显著优势。这也与微服务架构中"单一职责原则"（Single Responsibility Principle）的精神一脉相承：每个组件只做一件事，做好一件事，组件间通过明确定义的接口通信。

结语：把不透明变透明

这次基准测试最大的价值，或许不在于某个API排到了第几名，而在于它把"搜索API的第二笔成本"这个长期被行业刻意或无意忽视的问题摆上了台面。作者公开全部payload和日志的做法，也为这类评测树立了可复现、可核验的标准。在AI工具生态快速膨胀的今天，这种"可复现性"（reproducibility）尤为珍贵——太多的AI评测要么样本量不足、要么测试条件不透明、要么无法独立验证，导致开发者在选型时只能依赖营销材料和口碑，而非硬数据。这种困境在学术界被称为"复现危机"（replication crisis），而在工业界则表现为"benchmark gaming"——厂商通过选择性报告或针对特定评测集优化来美化产品表现。公开原始数据和完整方法论是对抗这种趋势的最有效手段。

对于正在构建Agent、RAG或任何检索驱动型AI应用的团队来说，下一次挑选搜索API时，不妨问自己一个问题：我看到的价格，是账单的全部吗？ 答案很可能是否定的。真正理性的做法，是像这次测试一样，跑一遍属于自己场景的全链路成本，用真实token账单说话。毕竟，在AI应用从原型走向规模化的过程中，成本控制往往是决定产品能否持续运营的关键——一个每次查询成本高出3倍的方案，在日均10万次调用的规模下，每月差额可能高达数万美元。而随着AI Agent应用逐渐从实验性项目走向生产级部署，这种成本意识将从"nice to have"变为"must have"——毕竟，没有哪个商业模式能在单位经济（unit economics）为负的情况下持续扩张。

完整测试数据与日志已开源：github.com/edendalexis/search-api-cost-benchmark