Perplexity Sonar 是 Perplexity 面向开发者推出的问答模型系列，官方描述说它把检索与生成封装成 API，可输出带引用的答案，适合接入需要实时信息的应用。它解决的是一个具体工程问题：当你的产品需要「回答当下的问题」时，怎么让答案有依据。
这篇文章按场景讲：先说清楚这类需求为什么难做，再说 Sonar 的能力对应哪一环，最后给出接入时的落地建议。
背景：应用为什么需要实时问答
大模型的训练数据有截止时间，截止之后发生的事情它不知道。对聊天场景，这通常可以接受；但对检索、客服、资讯、行业工具这类产品，时效性就是核心价值。
过去的做法有两种。一是自己搭检索系统，把网页抓下来、切块、建索引，再让模型基于检索结果作答。二是直接调模型，接受答案可能过期。前者工程量大，后者质量不可控。Sonar 这类产品的定位就落在两者之间。
卡点一：模型不知道当下发生了什么
第一个卡点纯粹是信息问题。用户问的是「最近的政策」「当前的版本」「今天的价格」，模型只能给出训练时见过的旧信息，而且往往不会主动说明自己不知道。
解决思路是让检索发生在生成之前：先去公开网络上找相关页面，再基于找到的内容组织答案。听起来简单，实际难点在检索质量——找错了页面，后面的生成再流畅也没用。
卡点二：没有出处的答案不敢用
第二个卡点是信任问题。在面向用户的产品里，一个没有来源的断言很难交代，尤其是涉及数据、政策、医疗等敏感领域。
带引用输出的价值就在这里：用户能自己点开看依据，产品方也能在出现争议时有据可查。需要注意的是，引用本身不等于正确，来源是否权威、引用与结论是否对应，仍然需要判断。
Sonar 的对应能力
按官方描述，Sonar 是「面向开发者推出的问答模型系列」，这意味着它的形态是接口而不是应用。它把检索与生成封装成 API，调用方不需要自己维护抓取和索引流程，这是它最实际的省事之处。
第二项能力是输出带引用的答案。对开发者来说，这等于把「可核验」做成了接口的一部分，前端可以直接把引用渲染出来。第三，官方描述点明它适合接入需要实时信息的应用，也就是把「时效性」当作产品卖点而非附加功能。官方描述没有给出调用量、延迟、覆盖范围等具体指标，这些属于选型时必须实测和向厂商确认的部分。
落地建议
第一，明确时效要求的颗粒度。是「今天发生的」还是「这个月内的」，直接决定检索策略和成本结构。
第二，为无结果设计兜底。检索不到内容时，产品应当明确告诉用户没查到，而不是让模型自由发挥。第三，把引用当作产品的一部分而不是装饰，前端给出可点击的来源，用户信任度会明显不同。
第四，保留人工复核环节。涉及合规、医疗、金融的产品，自动化输出应当有审核链路。第五，先用小流量验证效果再放大，实时问答的效果和查询类型高度相关，不同业务差别很大。
小结
- Perplexity Sonar 是 Perplexity 面向开发者推出的问答模型系列。
- 官方描述称它把检索与生成封装成 API，可输出带引用的答案。
- 它适合接入需要实时信息的应用，形态是接口而非成品应用。
- 大模型的知识有截止时间，实时性是这类接口要解决的核心问题。
- 引用便于核验但不等于结论正确，来源质量仍需判断。
- 落地时要明确时效颗粒度、设计无结果兜底、把引用做成可点击来源，并保留人工复核。
- 官方描述未给出延迟、调用量等指标，选型需实测确认。