Perplexity

Perplexity 是一家 AI 答案引擎公司，产品围绕搜索与准确性构建：处理大量信息，并简洁地汇总成直接答案。作为公司，它也是答案引擎优化（AEO）语境里最常被点名的答案引擎之一——内容方优化内容，就是为了被 Perplexity 这类产品在生成答案时引用。

编码能力 → 搜索质量：一条直接反馈链

Perplexity 联合创始人兼首席战略官 Johnny Ho 在 OpenAI 案例研究中给出了一个不太直观但很关键的观察：每当模型写代码的能力变强，Perplexity 的搜索引擎就会变好。原因是其搜索流水线本身就是模型写的程序——模型越会写代码，就越能写出更好的程序去检索网页和公司内部信息、并把结果汇总得更简洁。“搜索公司"与"编码模型"在这条链路上直接耦合：模型能力的提升不是先落到聊天体验，而是先落到检索与汇总流水线的质量上。

把信息能力落到真实系统

Ho 认为，比信息处理更难的题是把信息侧的收益应用到真实系统上，而 GPT-6 Astra 让这一步变容易了。按案例研究的说法，Perplexity 现在：

• 让模型起草沟通文稿（draft communications）；
• 让模型修改真实软件系统（edit real-world systems）；
• 让模型监控生产系统（monitor production software）；
• 并且以明显低于以往模型代际的频率人工检查（check in much less frequently）。

Ho 的原话：“We’re actually able to trust it with full end-to-end systems and check in on it much less frequently than previous generations of models."——信任的单位从"单次任务"升级成了"端到端系统”，人的介入频率成了衡量模型代际差距的实际指标（对照 Human-Agent Teams 中"检查频率与授权范围"的讨论）。

模型当测试替身：一个可复用的工程模式

案例研究中给了个具体可复制的用法：让模型给应用搭一个小测试程序，并由模型自己扮演被依赖的外部服务。手工测试时间有限时，Ho 让 Astra 围绕应用生成测试程序，模型产出的响应与现实服务的真实响应同构（例如某个 LLM API 或 connector 的返回），以此替身（test double）检查应用如何响应、把工作流从头到尾跑通——不必等真实外部服务。

值得注意的边界：这是一份 OpenAI 自己发布的厂商案例研究，全部论据来自一位高管的自述，全文没有任何数值（无百分比、无错误率、无时间节省），也未指明对照的"上一代模型"是哪一代；“检查频率降低"是定性描述而非测量。把 Perplexity 的经验当参考点时，应记得这是模型厂商挑选出来的正向故事。

相关词条

• GPT-6 Astra — 本案例中被端到端授权的模型
• Answer Engine Optimization（答案引擎优化） — Perplexity 所处的答案引用生态
• Human-Agent Teams — “减少检查频率"对应的人机协作组织问题