65毫秒，AI搜索的分水岭

65毫秒。Perplexity把自家检索引擎的p99延迟从800ms砍到65ms，手段很硬核——用Rust把当年fork来的开源检索引擎整个重写，取名Photon。这个新引擎已经接管全部生产流量，还顺手在Perplexity Search API里开了个Fast Search模式，单次调用延迟160ms。

🚀 从fork到自研：为什么要重写

Perplexity的检索层并非从零自建。早期为了快速验证产品，他们fork了一个为传统网页搜索设计的开源检索引擎，在此之上魔改。这条路在前期能跑通，但随着规模增长，原引擎的设计边界逐渐暴露，重写的动机主要有三个：

• 架构耦合不足：传统搜索引擎为“人翻十页蓝链”的场景设计，检索（retrieval）和排序（ranking）通常是两个独立服务，中间隔着网络调用和数据序列化。而AI搜索需要把检索结果直接交给大模型消费，检索层必须与排序、生成环节深度协同——服务拆分带来的每一次跨网络跳转，都是纯开销。
• 长尾延迟失控：旧引擎的p99延迟高达800ms。在AI搜索链路里，这只是“第一公里”，后面还要叠加模型推理时间。对话式产品对长尾极其敏感，最慢的那批请求直接决定用户体感。
• 为旧场景做的取舍不再适用：通用引擎的索引结构、打分逻辑和扩展点，都是围绕网页搜索优化的，通用能力在AI-native场景里反而成了包袱。

到2025年9月，Perplexity正式发布Photon，全量接管生产流量，并在Perplexity Search API中同步上线Fast Search模式。

🔧 架构设计：两个杠杆

杠杆一：Rust。 检索和排序是典型的高并发热路径服务，任何运行时的不确定性（最典型的就是GC停顿）都会在长尾上现形。p99衡量的是最慢的那1%请求，800ms的p99意味着每100次检索里就有几次拖过0.8秒。Rust没有GC停顿、零成本抽象、内存安全由编译期保证，把“语言层面的不确定性”从系统里移除了，这正是压长尾的关键。

杠杆二：检索与排序一体化。 Photon把原本拆开的检索和排序收进同一个引擎，消除了服务间的网络跳数和序列化开销。这是从架构层面挤出来的性能，不是调参调出来的。

另外，Photon是为AI搜索重新设计的数据通路：检索结果不需要为“渲染成搜索结果页”做工作，而是直接以适合大模型消费的形式输出——这也是Fast Search API能做薄的缘故。

📈 基准数据

p99压掉超过12倍，等于把第一公里的长尾几乎抹平。作为参照，市面上多数搜索API的单次调用延迟仍在数百毫秒量级，Fast Search的160ms是面向AI Agent场景专门优化的档位——Agent一次任务里可能发起几十次搜索调用（查航班、比价格、核对政策），每次调用省下的几百毫秒会累积成用户可感知的差距。

⚠️ 这不是对开源的否定

Photon是又一个“fork—魔改—重写”三部曲的完成时。但被替换掉的那个开源引擎，是Perplexity能走到今天的地基——开源把从0到1的成本打到接近于零，而它的设计边界决定了它很难为一个具体业务的极致需求继续服务。重写是自然结果，不是打脸。

小结：几点判断

以下更多是判断而非事实：

1. 自研检索层的门槛正在成为AI应用公司基础设施成熟度的分水岭。 重写的前提是瓶颈清晰可量化（这里是p99）、流量规模足够大、团队密度够高，三者凑齐前动手是过早优化。

2. 检索能力正在变成新的“云原语”。 就像对象存储和数据库，AI应用的标配底座里会有一个“搜索服务”。Perplexity的路径很典型：C端产品建口碑，API赚开发者的钱，而搜索原语的毫秒数就是定价权。

3. AI栈的中间件层正在被系统语言重写的一体化组件逐步吃掉。 下一步，这股深挖的风潮大概率会蔓延到记忆层和工具调用层——当模型能力趋同，竞争筹码会持续向下沉到基础设施。