服务端渲染的AI搜索:Perplexity为什么快,以及你抄不了的部分

📅 2026/4/26 ✍️ 小文 📖 约 1 分钟

AI搜索产品的体验差距,70%在检索工程而非模型。本文拆解Perplexity类产品的延迟构成、检索架构与成本结构,讲清楚自建AI搜索要跨过的三道坎。

用过 AI 搜索的人都有同一个感受:Perplexity 类产品”答得顺”,自建的就是”答得慢、答得虚”。

差距不在模型。2026 年,几乎所有能用的模型都能”根据资料回答”。真正的分野在检索层和工程层。

一、延迟到底花在哪

一次 AI 搜索请求,时间大致分布:

环节占比关键点
查询理解与改写5%拆成子查询,决定检索方向
检索 + 抓取45%–60%真正的瓶颈
重排(rerank)10%–15%决定前 5 条是否靠谱
生成20%–30%已被推理加速压下来

绝大多数自建方案把精力花在”换个更快的模型”,而真正的瓶颈在抓取。

能做快的几件事:

  • 预抓取:热门查询的页面提前抓、提前切块、提前建索引
  • 并行检索:多引擎、多子查询同时发,谁先回用谁
  • 流式生成:不必等全部检索完再开始回答,先答已知部分

一个没做预抓取的系统,首次响应 4–6 秒;做了之后能压到 1.5 秒以内。用户感知的差距就是”能用”和”不想用”。

二、检索质量的三个真实难题

难题一:查询改写做不好,后面全废

用户问”今年最值得买的入门电吉他推荐”,直接拿这句去检索,命中的全是广告。

好的改写会拆成:入门电吉他 推荐 2026、入门电吉他 价格区间、Squier vs Yamaha 入门,再分别检索、合并。

改写本身也是一次模型调用,所以这里存在精度与延迟的取舍。实践中最有效的办法是用小模型做改写,并且限制输出为 2–4 个子查询。

难题二:来源质量决定答案天花板

同样的模型,喂进广告站和喂进专业评测,答案质量是两个物种。

需要一套来源打分机制:域名权重、内容长度、发布时间、是否有明确作者、是否被其他可信源引用。最低成本的做法是维护一个白名单 + 黑名单,覆盖 80% 的常见情况。

难题三:引用必须真的对得上

大模型最常见的”幻觉引用”是:答案对了,但引用的是第 3 段,而第 3 段其实没说过这句话。

解法是把引用生成做成约束式:先切块并给每块编号,要求模型在生成每个句子时标注 [1][2],最后做后处理校验,把没有对应来源的句子标黄或删除。

三、成本为什么降不下来

一次 AI 搜索的成本构成里,抓取和解析的费用常常超过模型调用。

Web 内容解析是脏活:正文提取、去广告、处理 PDF、处理动态渲染页面。页面越复杂,成本越高。这也是为什么很多”AI 搜索”只敢给用户 3–5 条结果——不是因为不需要更多,是算不过来。

可行的优化方向:

  • 分级抓取:先用轻量 HTTP 抓,失败才上无头浏览器
  • 缓存共享:同一 URL 在一定时间内只抓一次,跨用户复用
  • 结果摘要缓存:热门问题的答案缓存 10–30 分钟

四、自建 vs 用现成

适合自建

  • 垂直领域(法律、医疗、金融研报),通用搜索覆盖不到
  • 需要接入内部知识库和权限体系
  • 有明确的内容源,不需要全互联网抓取

不适合自建

  • 想做”下一个 Perplexity”。这个赛道的壁垒是抓取规模和索引基础设施,不是模型
  • 用户量小、预算有限的场景,直接接 API 更划算

写在最后

AI 搜索的竞争,本质上是信息获取效率的竞争。模型是公开的,抓取管道、缓存策略、来源评级这些”脏活”才是护城河。

如果你正在做这块,先别急着换模型。打开 trace,看看你的请求在”检索+抓取”上花了多少毫秒——优化空间大概率在那里。

📤 分享到