架构并评估 AI 优先的搜索 API

构建可扩展且具备 AI 前瞻性的搜索 API，在信息检索、AI 与系统设计这些交叉领域中带来了独特的研究挑战。与操作限定数据的传统服务不同，搜索 API 必须持续索引数以十亿计的文档，理解跨语言和领域的查询意图，并在几毫秒内呈现相关结果。在 AI 代理的世界中，搜索 API 还必须仔细梳理提供给开发者模型的上下文，以确保这些模型发挥最佳性能并纳入最准确的信息。有效的上下文工程不仅要求 API 能够捕获文档级别的相关性，还要求将文档的各个部分和片段视为独立的一等单位。

在本文中，我们将介绍 Perplexity 搜索 API 的设计与评估。首先，我们探讨支撑我们每日处理 2 亿次查询的生产级搜索基础设施背后的架构和关键技术决策。我们的架构结合了混合检索机制、多阶段排序流水线、分布式索引以及通过自我优化内容理解模块进行的动态解析。

随后，我们将描述通过全新开源的评估框架对搜索 API 性能进行实证评估的方法。通过与现有商业 API 的全面基准测试对比，我们展示了在质量和延迟方面的领先性能。Perplexity 搜索 API 从即日起面向全球开发者开放。

[在 GitHub 上找到 search_evals]

构建针对 AI 模型优化的搜索系统

自创立以来，我们深知强大的搜索功能对于实现我们要发布的定义类别 AI 产品至关重要。起初，我们希望这些功能已以公开形式存在。我们测试了 2022 年底可用的搜索 API 产品组合，而 Perplexity 答案引擎的最初版本实际上整合了其中一些产品。具体来说，我们会分析用户查询，制定并向这些 API 发送请求，然后收集结果作为我们下游生成流水线的上下文。

然而，随着用户涌向 Perplexity，我们很快意识到这些 API 无法随着我们的增长而扩展。我们遇到的价格极其昂贵，其中一家领先的 API 提供商收费为每千次查询 200 美元。更致命的是，这些传统 API 根本不是为前沿 AI 系统引入的新检索范式而设计的。

放大

首先，这些传统 API 的请求和响应格式是为人类作为搜索结果唯一消费者的世界而设计的。因此，这些 API 优先考虑文档级结果，排除了子文档单元所揭示的更细粒度的信息。AI 模型的成功取决于所提供上下文的质量和紧凑性，我们亲眼目睹了过宽的检索如何导致 AI 模型偏离轨道，无论检索到的文档整体看起来多么相关。我们试图将精度强加于不精确结果的尝试收效甚微。

我们还观察到传统 API 要么太陈旧，要么太慢。独立开发的搜索 API 依赖于不完整且更新频率过低的索引。基于抓取的 API（如针对 Google 搜索的各种非官方 SERP API）受益于更全面的索引，但由于查询第三方搜索引擎固有的低效性，导致延迟高得无法接受。高延迟使得这些 API 不适合面向用户的应用程序，而陈旧性则使结果集对于任何希望准确且可信的 AI 系统而言都无法使用。

最后，我们观察到 AI 生态系统在词法搜索和语义搜索之间发生了分叉，出现了过度优化其中一种模式而非另一种的系统。我们看到了向量数据库的兴起，但它们甚至无法充分支持简单的布尔过滤器。传统的搜索后端表现稍好一些，但对 AI 解锁的语义排序和检索机会的支持也很原始。

当我们意识到要使 Perplexity 变得更好需要构建我们自己专用的搜索基础设施时，我们将我们的观察结果归纳为三个关键标准：

完整性、时效性和速度：搜索索引必须全面、不断更新，并为实时延迟进行工程化设计。

细粒度内容理解：AI 模型的脆性和有限的上下文窗口要求以尽可能精细的级别呈现和排序搜索结果。

混合检索和排序：检索和排序流水线必须结合词法和语义信号，使结果对 AI 有用。

放大

爬取和索引基础设施

以 Perplexity 的规模进行运营需要能够全面映射网络并响应其持续演变的基础设施。我们的搜索索引跟踪超过 2000 亿个唯一 URL，并具备跟踪数千亿个以上 URL 的容量。

确保我们的索引覆盖足够全面的互联网范围，并且每个文档反映最新状态是一项艰巨的任务。完整性与时效性之间存在内在张力：对于固定的索引预算，现有页面的刷新操作必须与新未访问页面的索引操作竞争。我们通过结合扩展（通过增加索引预算来放宽优化约束）和 ML 驱动的优先级排序（确保每次索引操作对整体索引的价值最大化）来平衡这种张力。

我们构建了一个 exabyte 规模的索引和爬取装置，可在大小和查询量上进行水平扩展。Perplexity 的爬虫和索引集群总共包含数万个 CPU 和数百 TB 的 RAM，并具有进一步扩展的巨大空间。我们将这种计算基础设施与冷热存储的平衡相结合。我们使用学习模型和调整后的启发式算法来确定哪些文档应保持热态，优先考虑来自权威域的文档、涉及未充分覆盖主题的文档，以及其他具有丰富索引潜力的类别。

这种基础设施使 Perplexity 能够每秒处理数万次索引操作。但即使有如此慷慨的预算，互联网的规模也过于庞大，无法频繁且重复地索引每一个 URL。这就是 ML 的用武之地。我们训练一个 ML 模型来预测给定的候选 URL 是否需要被索引。训练目标旨在确保我们将索引决策校准为特定 URL 的重要性和可能的更新频率。我们还依靠 ML 来告知我们确切的索引操作调度时间。对于具有常规发布和刷新节奏的站点，这允许我们将操作推迟到它们可能最有用的时间点。通过不断优化这些 ML 模型，我们能够维护一个在完整性和时效性上均符合标准的索引。

尽管我们的爬取基础设施易于水平扩展，但我们意识到网站运营商面临不同的技术限制。我们注意保持对任何给定域的请求速率处于可预测且可管理的水平。我们的搜索爬虫 PerplexityBot 遵守robots.txt文件中明确规定的限制，或者在没有域指定限制的情况下，遵守关于请求速率的行业标准规范。当检测到站点不可用时，我们也会调整爬取行为。我们的分布式系统旨在强制执行这些限制，即使在数万个并发操作中也是如此。

互联网规模下的自我优化内容理解

即使拥有地球上最大、最新的搜索索引之一，每次查询的结果质量也取决于我们的系统对每个文档内容的理解。在这里，我们面临一个根本性的挑战：网络是一个杂乱的地方。没有任何一套固定的解析规则能够处理整个互联网上发现的无限多样的布局、结构和样式。

我们通过开发一个内容理解模块解决了这一挑战，该模块使用动态规则集解析网站并提取语义上有意义的内容。列表或表格形式中结构化数据密集的网站可能受益于更形式化的解析和提取规则，而主要以自由格式用户生成内容为特征的另一个网站可能需要更宽松的规则集。由于网络在短时间内大部分是静态的，我们发现给定规则的寿命相对较长。但随着站点随时间演变，以及我们了解更多关于提取信息的最佳方法，我们的规则集也需要持续维护。

为了促进这种动态适应，我们自然转向 AI。在 Perplexity 的规模下，我们在每小时为数百万用户查询提供服务的过程中，观察到了互联网极其丰富的横截面。这构成了迭代自我优化循环的基础。我们观察我们查询全集中当前规则集的解析行为和提取输出。然后，我们使用前沿大语言模型（LLM）评估两个主要维度的性能：

完整性：我们的索引应接收尽可能多具有语义意义的内容，同时避免虚假提取无信息或无意义的材料。

质量：我们的索引依赖于实质和形式上均高质量的内容。信息应以保留原始内容结构和布局的方式进行捕获。

请注意，完整性和质量呈现出另一种内在张力：手动优化质量是可能的，但由此产生的解析规则可能无法捕获关键内容。同样，我们可以编写对原始内容进行最小过滤的宽容规则，这可能会提高完整性但以质量为代价。这就是为什么我们转向 AI 驱动的自我优化，以一种能够以领域自适应方式同时优化两者的方式演进我们的规则集。

具体来说，在每次 LLM 驱动的解析性能评估之后，我们的系统会制定一套提议的规则集变更，以解决最重大的错误类别。这些规则集经过进一步验证，之后我们将新版本部署到索引器。鉴于解析和提取逻辑的改进只能使未来的索引操作受益，我们对 ML 优化重索引的投资尤为重要：使用此逻辑的最新版本持续刷新高流量文档，确保了紧密的自我优化循环。

这些规则不仅对于基准解析性能很重要，而且对于子文档单元的分割也很重要。当涉及到前沿 LLM 时，每个上下文 token 都很珍贵。大量现有工作已经记录了 LLM 性能如何随上下文大小的增加以及无关信息对上下文的污染而下降。拥有结构良好、全面的解析使我们能够将文档分解为独立的片段，每个片段都可以在查询时单独检索和排序。

检索和排序流水线

现代搜索需要在紧迫的延迟预算下确保完整性和相关性。Perplexity 的检索和排序流水线通过多阶段架构实现这一点，该架构通过一系列日益复杂的模块逐步优化结果。我们通过在最大程度上水平扩展任何潜在的瓶颈来解决潜在问题。

流水线从索引检索开始。我们不强制在词法检索和语义检索之间做出选择。相反，我们通过两种模式查询搜索索引，并将结果合并为混合候选集。在这个阶段，优先考虑的是全面性而非精确性——流水线的后续阶段将优化精确性。

流水线继续进行预过滤阶段，在此阶段我们应用基本启发式算法和初步过滤器，从候选集中删除显然无响应或陈旧的内容。

然后，我们采用多个逐步先进的排序阶段。早期阶段依赖于针对速度优化的词法和基于嵌入的评分器。随着候选集逐渐被剔除，我们然后使用更强大的交叉编码器重排序模型来执行结果集的最终雕琢。多亏了我们在推理性能方面的众多投资，我们能够在保持总体排序延迟较低的同时，利用最先进的模型架构进行这些后期阶段。

在整个流水线中，我们在文档和子文档级别检索并评分结果。如上所述，AI 需要仔细的上下文工程。我们的流水线旨在向模型呈现尽可能原子化的单元，以便下游消费者可以在不从源文档的其他地方引入无关上下文的情况下整合这些精确单元。

确保此流水线每个阶段的高质量，只有通过与 Perplexity 产品组合的协同设计才有可能实现。排序堆栈的每一个细节都旨在利用我们每天每小时处理的数百万个用户请求所产生的丰富信号。这些信号中的绝大多数是自动化的，每个生成的 Perplexity 答案都为实时代理工作流中使用的搜索质量提供了一个经验数据点。我们将 AI 驱动的评估与实时人工反馈相结合，以丰富我们嵌入和排序模型的训练数据，这远超任何手动构建的数据集所能提供的。

搜索与产品之间的这种协同效应是 Perplexity 所独有的。传统的搜索引擎仅限于蓝链遥测提供的粗略信号。较新的搜索产品尝试实现其中一些 AI 前瞻性概念，但它们缺乏能够验证搜索质量并提供快速改进循环所需信号丰富性的现实世界环境。我们很幸运拥有缺失的要素：一个由前沿 LLM 提供支持，并由全球数百万好奇用户持续实战测试的实时搜索质量验证平台。

确立质量与性能的新前沿

在构建Perplexity 搜索 API和SDK以使全球开发者能够使用我们的搜索基础设施后，我们希望了解各种商业 API 产品在现实世界的 AI 用例中表现如何。评估 AI 模型本身已成为常事，但我们需要对这种模式进行调整：评估由 AI 模型调用时搜索 API 的质量。

我们首先着眼于开源生态系统以了解现有技术。我们发现了严谨评估的许多关键要素，但没有一个将这些要素集成到即插即用基准测试解决方案中的框架。因此，我们着手开发一个评估框架，不仅供 Perplexity 使用，也供任何寻求基准测试搜索 API 的研究人员或开发者使用。

使用此评估框架，我们对 Perplexity 搜索 API 与其他产品进行了严格的基准测试。优化搜索性能很复杂，在质量和速度之间存在许多细微的权衡。对于开发者而言，一个好消息是，我们发现 Perplexity 搜索 API 在质量和延迟方面均设定了新的最先进标准。开发者不再需要在构建闪电般快速的应用程序和确保高质量结果之间做出选择：使用 Perplexity，他们两者兼得。

放大

为代理搜索工作流设计可靠的评估

我们首先定义了评估框架的三项指导原则：

复杂性范围：评估框架应衡量在简单和复杂的代理 AI 用例中的性能。

中立性：评估框架应在平等的基础上评估所有 API。

简洁性：尽管某些用例可能很复杂，但框架本身应尽可能简单，以便其他人可以理解、重现结果，并以最小的冗余扩展框架。

我们的轻量级评估框架 search_evals 通过简单的模块化设计实现了这些目标。我们开发了两个 AI 代理工具，以捕获经典的单次搜索用例和高级代理工作流（以消费者市场上广泛使用的各种“深度研究”产品为例）。这两个工具都以一种直观的方式实现，几乎没有留下隐藏优势的空间。

为了推动我们的评估，我们采用了四个基准：用于单步搜索的 SimpleQA 和 FRAMES，以及用于深度研究的 BrowseComp 和 HLE。总的来说，这些基准测试为知识代理提供了广受认可的衡量标准。遵循既定惯例，我们使用原始工作中使用的相同提示分类器方法对所有基准进行评分。精确的基准测试实现（包括评分逻辑）可以在我们的 GitHub 仓库中查看。

我们在设计框架时考虑了可重现性和可扩展性。任务级分数和底层代理输出都与每次运行一起存储。额外的工具、基准测试和搜索 API 产品可以轻松集成。研究人员和开发者可以阅读我们的 GitHub 文档，了解有关扩展框架以满足您精确需求的更多信息。

评估结果

有了这个评估框架，我们着手评估我们的搜索 API 与其他 API 产品相比的表现。在所有测试的基准测试中，Perplexity 都是市场上最快、质量最高的 API。

放大

我们发现我们在上述索引、检索和排序效率方面的投资获得了丰厚的回报。Perplexity 的中位延迟为 358ms，比第二快的提供商领先 150ms 以上。95 百分位延迟舒适地保持在 800ms 以下。随着当今前沿模型漫长的 TTFT（首次 token 时间）指标，每一毫秒在创造令人愉悦的用户体验方面都很重要。过去两年我们一直在为自己的用户优化延迟，我们很高兴这些同样的投资现在也将使开发者社区受益。

搜索 API 延迟

（请求从 AWS us-east-1 发起）

针对来自 AWS us-east-1 的请求的 Search API 延迟百分位数。

* 许多搜索 API 供应商使用 SERP 抓取作为其结果的基础。为了捕获此类方法的性能，我们使用 Tavily 提供的具有代表性的 Google 基于 SERP 的 API。

这种速度优势并不以牺牲质量为代价。Perplexity 搜索 API 在单步搜索和深度研究设置中均产生了最先进的性能。在每个测试的基准测试中，Perplexity 在提供可驱动不同复杂性 AI 工作流的高质量结果方面均处于领先地位。Perplexity 与最佳替代方案之间的差距在 SimpleQA 和 HLE 上尤为明显，这表明这些结果在整个任务复杂性范围内都是稳健的。

放大

与延迟一样，我们在搜索质量方面的领导地位源于我们在构建令人愉悦、高流量 AI 产品方面的领导地位。我们数百万用户使用 Perplexity 来满足他们对任何可想象主题的好奇心，由此产生的质量和相关性信号使我们的搜索模型能够随着时间的推移而不断改进。

搜索 API 质量基准

Search API 在 SimpleQA、FRAMES、BrowseComp 和 HLE 上的质量得分。

AI 原生搜索引擎仍处于早期阶段，衡量的艺术和科学无疑将不断演变。我们诚邀社区贡献力量，通过开发严谨且创造性的方法来评估 AI 代理时代的搜索引擎。

AI 下一章的基石

代理系统和智能助手的未来将取决于进入世界集体知识的丰富程序化接口的可用性。当今的传统搜索引擎使用量已达到每天约 10¹⁰ 次查询的饱和点，这一数字可能已经达到顶峰。下一代搜索和检索系统将服务于多出几个数量级的请求，因为一个不断增长的 AI 代理世界依赖它们获取准确的实时信息。

我们迄今为止的努力使我们成为可通过 API 访问的最快、性能最高的搜索引擎。但我们需要更雄心勃勃的创新来推动 AI 的下一个篇章。面对日益增长的需求，我们如何有效地扩展这些系统？鉴于上下文工程和后期训练的新颖方法，这些搜索系统如何优化？我们又该如何在全面性、时效性和延迟之间不断存在的张力中导航？这些都是悬而未决的问题，Perplexity 凭借我们的产品足迹、规模和技术人才的结合，处于应对这些问题的独特地位。

引用

@online{perplexity2025ArchitectingAndEvaluatingAnAiFirstSearchApi,
  author = {{Perplexity} and Aleksandr Bogutskii and Aleksandr Nikolenko and Aleksei Bykov and Alexander Pecheny and Alexandr Yarats and Arsenii Shevchenko and Denis Bykov and Dmitry Pervukhin and Ismail Gadzhiev and James Liounis and Kevin Hu and Kirill Priemko and Maksim Gaiduk and Maksim Morozov and Marko Kevac and Michael Liang and Mikhail Galanin and Nandor Licker and Nataliya Pevgova and Nikita Kireev and Nikolai Tretiak and Paul Schofield and Saif Ali Raja and Saleh Alghusson and Sebastian Sepulveda and Sergei Miller and Svyatoslav Feldsherov and Vitalii Polshkov and Vladimir Zaytsev and Denis Yarats},
  title = {{Architecting and evaluating an AI-first Search API}},
  date = {2025-09-25},
  url = {https://www.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}