Perplexity · 研究报告
←
Research assessment

Perplexity：检索编排与引用溯源解析

Perplexity 没有公开生产搜索引擎的内部源码或完整服务拓扑。下面只描述官方产品与 API 明确暴露的边界。

文档类型 研究报告 分析日期 2026-08-27

返回主报告
分析对象：Perplexity Search、Pro Search、Search API、Agent API、Sonar API 与引用交互
证据基线：Perplexity 官网、帮助中心和开发者文档，读取日期 2026-08-24
专题结论：建议把 Perplexity 的检索/生成分层、模式化预算和渐进反馈作为重点设计参照；可将 Search API 作为可替换适配器 PoC，但不把外部 URL 引用直接当成当前产品的审计证据。

1. 公开可确认的检索能力边界

Perplexity 没有公开生产搜索引擎的内部源码或完整服务拓扑。下面只描述官方产品与 API 明确暴露的边界。

公开能力面 官方可确认行为 对产品架构的含义
Standard / Pro Search Pro Search 会多次搜索，覆盖网页、学术、论坛、视频和文件等来源模式，再生成组织化答案并允许多轮追问 “搜索”在交互上已是检索、阅读、综合的复合任务，而非十条蓝色链接
Search API Search API 返回实时、排序、结构化的原始结果；官方明确建议需要生成式答案和引用时使用 Agent API 检索基础设施和答案生成器是两个可替换层
Agent API Web Search 工具 由模型按提示判断何时调用；复杂问题可多轮调用并改写查询 编排控制权在模型/预设与工具契约之间，不只在用户 prompt
Sonar API Sonar 响应 返回生成内容、citations、search_results、图片与相关问题 答案、引用 URL 和检索结果元数据分开传输
Deep Research Research mode 迭代搜索、读取、推理和写报告；具体模型由系统自动组合 深度研究是一个自动路由的长任务，不允许用户逐模型控制

Search API 的控制面

Search API 文档 暴露的主要控制包括：

  • 单次请求可传最多五个相关查询，每个查询独立处理；
  • max_results 为 1–20，默认 10；
  • country 做地域定向；
  • 域名或 URL 路径 allowlist/denylist；
  • 语言过滤、发布时间/最后更新时间/相对时效过滤；
  • search_context_size 控制每个结果抽取内容的预算，分 low、medium、high；
  • 返回 title、URL、snippet、date、last_updated 等结构化字段。

这套接口最大的价值是：让来源策略成为参数，而不是藏在 prompt 里。 官方 Sonar Prompt Guide 也明确说明系统提示词不会改变搜索步骤，过滤条件应通过参数传递；并建议在检索结果不足时允许模型明确回答“没有找到”，不要用预训练知识补空缺。

2. 检索编排的合理抽象

以下流程是根据官方功能组合出的产品架构推断，不是 Perplexity 对内部实现的披露。

抽象示例（公开行为的编排模型，并非竞品源码）

sequenceDiagram
    participant U as 用户
    participant O as 模式/编排层
    participant S as Search API/网页搜索
    participant F as 页面读取/文件
    participant C as 代码与计算
    participant A as 答案与引用生成

    U->>O: 问题、模式、来源范围、文件
    O->>O: 判断是否澄清 / 拆解子问题
    par 多角度检索
        O->>S: 查询 A + 过滤器 + 预算
        O->>S: 查询 B + 过滤器 + 预算
    end
    S-->>O: 排序结果、snippet、日期、URL
    O->>F: 读取高价值页面/上传文档
    opt 需要数据处理
        O->>C: 计算、表格或代码分析
        C-->>O: 结果
    end
    O->>O: 证据充分性判断与下一轮查询
    O->>A: 结论、引用映射与格式要求
    A-->>U: 可追问答案或报告

值得参照的编排设计

  1. 问题复杂度路由：快速答案、Pro Search、Deep Research 的区别主要体现在时间、检索次数、推理预算和产物，不要求用户理解 Agent 拓扑。
  2. 多查询并行与迭代搜索并存：已知的不同角度并行；新发现触发的查询串行迭代。两者都需要显式预算。
  3. 搜索结果与完整页面读取分工：先用结构化结果和 snippet 缩小范围，再读取关键页面，控制成本。
  4. 来源策略参数化：域名、路径、日期、语言、地区和内容预算应进入运行配置，保证任务可复现。
  5. 空结果诚实：对专业研究尤其重要。没有证据时应停止并暴露缺口，而不是让生成模型补全。

公开材料未证明的部分

  • 查询计划是否作为稳定对象保存；
  • 每一步的选源原因、淘汰原因和重排分数是否能导出；
  • 网页正文是否快照化、是否有内容哈希；
  • 搜索索引刷新频率和删除策略；
  • 多来源冲突是否以结构化对象保存；
  • 相同输入、相同时间和相同模式能否重放出同一证据集。

因此不能从“会迭代搜索”推导出“具备可审计研究运行时”。

3. Perplexity 的引用数据模型

三套公开引用接口

接口 引用表示 能确认什么 不能确认什么
Sonar API 顶层 citations: string[] 与 search_results[] 答案使用了哪些 URL，以及检索结果的标题、时间、snippet URL 与具体 claim 的全部映射、原文版本和页面内精确位置
Agent API annotations[] 含 start_index、end_index、title、URL 答案文本某一区间关联哪个网页 URL 外部页面中的页码/段落、抓取快照、内容哈希
Agent API 流式模式 正文 [N] 映射到多批 search_results 的全局 ID 多步研究的引用编号如何稳定解析 引用内容是否真正蕴含结论、来源是否可信

Agent API 参考 给出了答案区间与 URL 注解；流式引用指南 强调 Deep Research 会返回多批检索结果，客户端必须累计全部批次，否则后续编号会无法解析。这个细节说明引用是运行级 ID 空间，不只是最终答案末尾的一组链接。

UI 层来源标签

Source Labels 为部分域名显示 Government、Academic 或 Trusted。官方同时明确：

  • 评分对象是整个网站，不是单篇页面；
  • 标签不代表 Perplexity 认可内容观点；
  • 没标签不代表来源低质；
  • 标签不能替代用户阅读原始来源；
  • 合作、支付等商业关系不影响标签。

因此标签可作为 SourceRecord.authority_class 的一个输入，但不能直接赋值给 ClaimEvidence.reliability。专业产品还需评估作者、发布日期、证据类型、原始/二手来源、利益冲突和结论与引文的蕴含关系。

4. 对当前产品的证据模型建议

最小对象与字段

对象 最小字段 解决的问题
ResearchRun run_id、mode、brief、开始/结束时间、预算、状态、模型/工具版本 一次研究可复盘、可计费、可比较
QueryStep query、父步骤、过滤器、原因、开始/结束、结果数、退出原因 为什么搜、搜了什么、为何停止
SourceRecord canonical_url、publisher、author、类型、authority、license、entitlement 统一来源身份与访问权
SourceVersion fetched_at、published_at、last_updated、content_hash、snapshot_ref、valid_time 外部内容变化后仍能复核当时证据
EvidenceSpan source_version_id、page/section/char range、原文、提取方式 从 URL 级引用升级到原文片段定位
Claim claim_text、claim_type、confidence、status、valid_time、recorded_time 把报告中的结论变成一等对象
ClaimEvidence claim_id、span_id、relation、strength、verifier_status 区分支持、反驳、背景和未经核验

relation 至少应支持 supports、contradicts、qualifies、background；claim_type 至少区分事实、推断、建议和未验证。

引用生成链路

抽象示例（当前产品建议证据关系，并非竞品源码）

网页/文档 → 规范化来源 → 固定版本 → 原文片段
                                  ↓
                           支持/反驳关系
                                  ↓
                    Claim → 报告 → 决策 → 情景模拟

报告渲染时再把 ClaimEvidence 转成角标。这样 Markdown、DOCX、PPT、网页、API 都只是同一证据账本的不同视图。

5. 推荐的检索编排 PoC

PoC 范围

  • 选 30–50 个真实研究问题，覆盖事实查找、跨来源比较、时间敏感信息、负面证据和多来源冲突。
  • 为每题预先标注“必须找到的权威来源”“可接受替代来源”“常见误导来源”和“正确回答允许为空”的条件。
  • Perplexity Search API 只作为 OpenWebSearchAdapter，与另一检索供应商和自建搜索做同题对比。
  • 生成层统一使用当前产品自己的 EvidenceSpan 与 ClaimEvidence，不直接把供应商返回的引用数组作为最终证据。

验收指标

指标 建议定义
必找来源召回率 黄金来源中被检索到的比例
引用蕴含准确率 随机抽取 claim，原文片段确实支持该 claim 的比例
引用完整率 可核验事实 claim 中有有效 EvidenceSpan 的比例
来源权威分布 一手官方、专业二手、普通媒体、社区/聚合站占比
时间正确率 发布日期、最后更新时间和事件发生时间是否被正确区分
冲突暴露率 黄金任务中预设冲突是否被明确呈现
空结果诚实率 证据不足时没有用模型记忆补答的比例
单题成本/时延 搜索、页面读取、模型与验证的分项成本和 P50/P95

6. 可借鉴与不可照搬

建议直接参照

  • Search API 与答案 API 分层；
  • 过滤器参数化而不是 prompt 化；
  • 快速/标准/深度三档研究预算；
  • 多查询并行、迭代读取、代码工具的统一编排；
  • 运行中持续流式返回来源与发现；
  • 引用与检索结果使用稳定运行级 ID 映射；
  • 明确允许“未找到”与“近似结果不匹配”。

需要调整后参照

  • 来源标签：从域名级扩展到页面、作者和 claim 级；
  • 会话记忆：升级为可查询的研究对象和版本，不只依赖对话上下文；
  • Related Questions：由通用追问升级为“未证实假设、冲突点、下一步证据缺口”；
  • 引用 URL：升级为 SourceVersion 与 EvidenceSpan。

不建议照搬

  • 把搜索次数或来源数量当质量指标；
  • 只保存最终答案和 URL；
  • 用单一供应商的排序结果作为事实真相；
  • 在结构化输出中要求模型自行生成 URL；Perplexity 官方也建议从 API 返回的 citations/search_results 读取真实链接；
  • 把域名标签当成单篇文章或单项事实的准确性背书。

7. 明确结论

维度 结论 理由 前提与限制
引入 建议局部 PoC Search API 的多查询、过滤和内容抽取适合作为开放网页适配器；Agent API 可用于对照体验 必须包在供应商无关接口后；自行快照、抽取、验证和保存运行账本；先通过黄金集
参照 建议重点参照 检索/生成分层、模式预算、渐进反馈和空结果策略具有通用价值 不能从产品文案推断内部实现；不可把引用 URL 等同审计 Provenance

8. 官方证据索引

返回主报告