Perplexity 架构解析：如何实现有依据的 LLM 输出#

Perplexity 是“答案引擎”（answer engine）这个产品形态里最有代表性的产品之一。它不像传统搜索引擎那样只返回一组蓝色链接，而是先检索网页和其他来源，再用大语言模型综合信息，最后给出带引用的自然语言回答。

这篇文章不试图断言 Perplexity 内部每个模块的私有实现细节。更稳妥的方式是：以 Perplexity 为代表，拆解一个现代生成式搜索 / 答案引擎大概率需要的通用架构。

也就是说，我们讨论的是一种工程模式：如何让 LLM 的回答尽量有来源、可追溯、可验证，而不是只依赖模型参数里的记忆。

Perplexity 是什么#

Perplexity 可以理解为“搜索 + 阅读 + 总结 + 引用”的组合产品。

用户输入一个自然语言问题后，系统会：

1. 理解问题。
2. 搜索或检索相关资料。
3. 读取和筛选来源。
4. 用 LLM 综合答案。
5. 在回答中插入引用。
6. 支持继续追问。

它的核心价值不只是“回答得像聊天机器人”，而是：

• 实时性：能利用当前网页和最新信息。
• 可验证性：回答旁边有来源链接。
• 综合能力：把多个来源合成一个结构化答案。
• 对话式检索：用户可以自然追问，而不是重新组织关键词。

从产品定位上看，Perplexity 更像“研究助手”或“答案引擎”，而不是单纯的聊天机器人。

从搜索引擎到答案引擎#

传统搜索引擎的流程大致是：

query → retrieve → rank → show links

用户还要自己打开网页、判断可信度、阅读、对比、总结。

答案引擎的流程则更接近：

query → search/retrieve → read/rerank → synthesize → cite → answer

多出来的关键步骤是：

• 阅读来源内容。
• 选择能支持答案的片段。
• 将多个来源合成一段回答。
• 把具体陈述和来源建立引用关系。

这也是 Perplexity、Google AI Overviews、Bing/Copilot、You.com、Brave Answer with AI 等产品与传统搜索结果页的核心差异。

一个现代答案引擎的整体架构#

一个典型的生成式搜索系统可以拆成这些层：

用户问题
  ↓
Query Understanding / Intent Routing
  ↓
Search & Retrieval
  ↓
Content Fetching / Extraction
  ↓
Ranking / Reranking / Deduplication
  ↓
Context Construction
  ↓
Grounded Generation
  ↓
Citation Alignment / Verification
  ↓
Answer UI / Follow-up Loop

每一层都会影响最终答案质量。

如果检索错了，LLM 再强也只能基于错误材料回答。如果引用对不准，答案看起来有来源，但实际上不可验证。如果上下文过长又没有重排序，模型可能只利用靠前内容，忽略真正关键的信息。

1. 查询理解与意图路由#

用户的问题不一定等于最好的搜索查询。

例如：

• “这家公司最近怎么了？”需要先识别“这家公司”是谁。
• “Claude Code 和 Cursor 哪个适合团队？”需要拆成多维比较。
• “今天英伟达为什么涨？”需要实时行情、新闻和市场解释。
• “RAG 是什么？”可能不需要最新网页，只需要稳定解释和权威资料。

所以第一层通常会做：

• 查询改写。
• 子问题拆分。
• 实体识别。
• 时间意图识别。
• 语言和地区判断。
• 来源类型选择。

一个简化的意图路由可能是：

def route_query(query: str) -> SearchPlan:
    if has_recent_time_signal(query):
        return SearchPlan(mode="fresh_web", recency="high")

    if asks_for_comparison(query):
        return SearchPlan(mode="multi_query", strategy="compare")

    if asks_for_academic_evidence(query):
        return SearchPlan(mode="academic", domains=["papers", "scholar"])

    return SearchPlan(mode="web", recency="normal")

真实系统通常不会只靠规则，而是规则、轻量分类模型、LLM planner、搜索日志和用户画像共同决定。

2. 搜索与检索#

答案引擎里的检索通常不是单一路径，而是混合系统。

可能包括：

• Web search。
• News search。
• Academic search。
• Finance search。
• 站内索引。
• 用户上传文档。
• 企业知识库。
• 向量检索。
• BM25 / 关键词检索。
• Knowledge graph 或结构化数据库。

Perplexity 公开 API 文档里也能看到类似分层：它提供 Search API、Sonar API、Agent API、Embeddings API 等能力。Search API 用于获取原始、排序后的网页搜索结果；Embeddings API 可用于语义搜索和 RAG；Agent API 则强调模型、实时 web search、工具配置和推理控制的统一接口。

工程上，常见策略是 hybrid retrieval：

BM25 / lexical search
  +
Dense embedding search
  +
Domain / recency / authority filters
  +
Reranker

原因很简单：

• BM25 擅长精确词、专有名词、代码、型号、股票代码。
• Dense retrieval 擅长语义相似、同义表达、自然语言问题。
• Freshness filter 对新闻、股价、政策、产品更新很关键。
• Authority filter 对医疗、法律、技术文档、金融解释很关键。

没有一种检索方式能单独解决所有问题。

3. 内容抓取与抽取#

搜索结果只是 URL 和摘要，不等于可用于生成的高质量上下文。

系统通常还需要：

• 打开网页。
• 提取正文。
• 去掉导航、广告、推荐内容。
• 处理 paywall、robots、反爬和版权边界。
• 识别发布时间、作者、来源域名。
• 抽取关键段落。
• 对长文分块。

这一层非常重要，因为 LLM 最后看到的不是“整个互联网”，而是被系统抽取出来的若干段文本。

抽取质量差时，常见问题包括：

• 引用了网页侧边栏，而不是正文。
• 把旧文章当成新消息。
• 把评论区观点当成事实。
• 把转载站当成原始来源。
• 多个网站转载同一篇通稿，造成虚假的多源一致。

所以一个成熟答案引擎需要 source normalization 和 deduplication。

4. 排序、重排序与去重#

搜索引擎返回的 top results 不一定就是最适合回答的 evidence。

答案引擎通常还要做二次排序：

def build_evidence_set(query, documents):
    candidates = extract_chunks(documents)
    candidates = remove_duplicates(candidates)
    candidates = rerank_by_relevance(query, candidates)
    candidates = boost_authoritative_sources(candidates)
    candidates = boost_fresh_sources_if_needed(query, candidates)
    return candidates[:k]

重排序考虑的因素可能包括：

• 与问题的语义相关性。
• 来源权威性。
• 发布时间。
• 是否是一手来源。
• 是否有清晰作者和上下文。
• 内容是否完整。
• 与其他来源是否互相印证。
• 是否存在明显 SEO 垃圾或内容农场特征。

这里还有一个容易忽略的问题：引用位置偏差。

如果模型上下文里第一个来源写得比较完整，它可能更容易被引用；如果关键来源放得太后，模型可能忽略。新的 GEO / answer engine citation 研究也在关注“什么内容更容易被答案引擎引用”。

5. Context Construction：把资料变成模型能用的上下文#

拿到来源片段后，还要把它们组织成 prompt。

一个简单格式可能是：

You must answer using only the sources below.
Cite sources using [1], [2], ...

[1] Title: ...
URL: ...
Date: ...
Excerpt: ...

[2] Title: ...
URL: ...
Date: ...
Excerpt: ...

Question: ...

但真实系统会更复杂：

• 给每个来源分配 source id。
• 保留 URL、标题、发布日期、作者、domain。
• 控制每个来源的 token budget。
• 把互相矛盾的来源放在一起。
• 对多跳问题保留中间推理证据。
• 对实时问题保留数据时间戳。
• 对技术问题优先官方文档和原始 issue / PR。

上下文构造的目标不是“塞越多越好”，而是让模型更容易把答案中的每个关键陈述绑定到具体 evidence。

6. Grounded Generation：带证据生成#

生成阶段的核心约束是：不要只凭模型记忆回答，而要基于检索到的来源回答。

一个简化 prompt 可能是：

Answer the user's question using the provided sources.
Every factual claim should be supported by citations.
If the sources disagree, explain the disagreement.
If the sources are insufficient, say what is missing.
Do not cite a source unless it supports the sentence.

这类 prompt 能减少幻觉，但不能完全消除幻觉。

原因是：

• 模型可能误读来源。
• 模型可能把来源 A 的事实归到来源 B。
• 模型可能生成来源中没有的推断。
• 模型可能引用一个相关但不支持该句的链接。
• 检索结果本身可能错误或过时。

所以“带引用”不等于“必然正确”。它只是让错误更容易被发现。

7. Citation Alignment：引用不只是贴链接#

答案引擎最难的部分之一是 citation alignment：一句话到底由哪个来源支持？

糟糕的引用系统只是把用过的网页列在答案末尾。看起来有来源，但用户很难知道每个具体陈述来自哪里。

更好的系统应该做到：

• 句子级或段落级引用。
• 引用的来源真正支持该陈述。
• 多来源综合时给出多个引用。
• 对冲突来源明确说明分歧。
• 对推论和事实分开表达。
• 对时效性信息标注日期。

学术研究已经指出，生成式搜索引擎的引用精度和引用召回并不天然可靠。早期针对 Bing Chat、NeevaAI、Perplexity、YouChat 的评估发现，这类系统虽然流畅，但经常有 unsupported statements 和 inaccurate citations。

因此，真正严肃的答案引擎不能只做“生成时要求模型加 [1][2]”，还应该有生成后验证。

8. 生成后验证与答案修正#

一个更强的系统会在答案生成后做检查：

draft answer
  ↓
claim extraction
  ↓
claim-source matching
  ↓
unsupported claim detection
  ↓
rewrite / remove / add citation
  ↓
final answer

可能的技术路线包括：

• 用另一个 LLM 做 citation verifier。
• 用 NLI / entailment 模型判断来源是否支持陈述。
• 把每句话反查 evidence。
• 对无来源陈述要求重写。
• 对高风险领域提高引用门槛。

这一步会增加延迟和成本，但能显著提升可信度。

Perplexity 的产品演进：不只是 RAG#

早期讨论 Perplexity 时，很容易把它简单理解为“RAG + 搜索”。但到现在，这个产品已经不只是一个搜索框。

围绕答案引擎，Perplexity 已经扩展出：

• 面向开发者的 Sonar / Search / Agent / Embeddings API。
• Pro Search / Deep Research 类型的多步研究体验。
• Comet 这类 AI 浏览器和网页代理入口。
• 面向企业、媒体、开发者工作流的集成。
• MCP、SDK、LangChain、Vercel AI SDK、Claude Code、Cursor 等生态连接。

这说明答案引擎的竞争点正在从“能不能搜索并总结”扩展到：

• 能不能做多步研究。
• 能不能调用工具。
• 能不能进入浏览器和工作流。
• 能不能提供可信引用。
• 能不能处理版权、爬虫、内容合作和发布方关系。

法律与内容生态风险#

答案引擎还有一个非技术但非常关键的问题：来源内容从哪里来，是否被允许使用，如何给发布方带来价值。

Perplexity 近年同时面临两种相反方向的压力：

• 一方面，一些媒体与 Perplexity 达成合作，希望通过答案引擎获得引用、流量或授权收益。
• 另一方面，也有多家媒体和内容机构起诉或指控 AI 答案引擎未经授权抓取、复用、摘要或分发内容。

这说明“有引用”并不自动解决版权和生态问题。引用能帮助用户核查，也能给来源曝光，但它不等于内容授权，也不等于发布方一定获得合理回报。

未来答案引擎能否长期成立，不仅取决于 RAG 架构，还取决于内容授权、爬虫规范、robots 尊重、发布方分成、版权边界和用户信任。

开源替代方案与自建路线#

如果想自己搭一个“类似 Perplexity 的答案引擎”，可以分成两类路线。

路线一：直接使用现成开源产品#

比较常见的方向包括：

• Perplexica：开源 Perplexity-like 搜索问答项目，通常结合 SearXNG、多模型后端和引用生成。
• RAGFlow：更偏企业文档 RAG，强调文档解析、知识库、引用和 UI。
• AnythingLLM / Dify / Flowise / Langflow：更偏低代码或应用编排，可接搜索工具和 RAG pipeline。

这类方案的优点是上手快，有 UI，适合做 demo 或内部知识库。

缺点是：

• 网页搜索质量通常不如商业搜索基础设施。
• 引用对齐和事实验证能力有限。
• 抓取、解析、反爬、版权和来源质量都要自己处理。
• 一旦进入生产，就会遇到权限、审计、缓存、成本、延迟问题。

路线二：自己搭 pipeline#

一个自建版答案引擎的最小架构可以是：

Search API / crawler
  → content extractor
  → chunker
  → embedding + BM25 hybrid index
  → reranker
  → context builder
  → LLM generator
  → citation verifier
  → UI

MVP 阶段可以简化为：

1. 用搜索 API 拿结果。
2. 抓取前几个 URL 的正文。
3. 用 reranker 选片段。
4. 把片段编号塞进 prompt。
5. 要求模型按编号引用。
6. 对输出做基本引用检查。

但如果目标是生产级，就要继续补：

• 缓存和去重。
• 失败重试。
• 来源白名单 / 黑名单。
• 内容时间戳。
• 版权和 robots 策略。
• 引用精度评估。
• 生成后事实检查。
• 用户反馈闭环。
• 成本和延迟监控。

一个简化实现示意#

下面是一个非常简化的伪代码，只展示数据流：

def answer(query: str):
    plan = plan_query(query)

    search_results = search_web(
        query=plan.search_query,
        recency=plan.recency,
        domains=plan.domains,
    )

    pages = fetch_and_extract(search_results[:10])
    chunks = chunk_pages(pages)
    ranked_chunks = rerank(query, chunks)
    evidence = dedupe(ranked_chunks)[:8]

    draft = generate_answer(
        query=query,
        evidence=evidence,
        instructions="Cite every factual claim using source ids.",
    )

    checked = verify_citations(draft, evidence)
    final = rewrite_unsupported_claims(checked)

    return final

这段代码看起来简单，但每个函数背后都可以展开成一个系统。

真正决定效果的往往不是“用了哪个 LLM”，而是：

• 检索能不能找到正确来源。
• 抽取能不能拿到正文。
• 重排序能不能保留关键片段。
• prompt 能不能约束模型。
• verifier 能不能发现不支持的陈述。
• UI 能不能让用户快速核查来源。

评估指标#

答案引擎不能只看“回答是否流畅”。更重要的是：

其中 citation precision 和 citation recall 尤其关键。一个答案看起来有很多引用，但如果引用不支持具体句子，就只是“引用装饰”。

局限性#

即使用了 RAG 和引用，答案引擎仍然会有局限：

• 搜索结果可能被 SEO 垃圾污染。
• 权威来源可能被 paywall、robots 或反爬挡住。
• 新事件早期信息混乱，来源互相矛盾。
• LLM 可能错误综合多个来源。
• 引用可能对不上具体陈述。
• 版权和内容授权问题仍然存在。
• 用户可能因为“看起来有引用”而过度信任答案。

所以，答案引擎最适合做研究入口和信息综合，而不是替代所有专业判断。

小结#

Perplexity 的重要性不在于它发明了 RAG，也不在于它单独拥有某种神秘检索技术。

它真正代表的是一种新产品范式：把搜索、阅读、总结和引用压缩成一个对话式答案界面。

从架构上看，一个高质量答案引擎至少需要：

1. 查询理解和意图路由。
2. 混合搜索与检索。
3. 正文抓取和内容抽取。
4. 重排序、去重和来源质量判断。
5. 面向引用的上下文构造。
6. Grounded generation。
7. Citation alignment。
8. 生成后验证和修正。
9. 面向用户信任的 UI。
10. 对版权、爬虫和内容生态的治理。

RAG 只是起点。真正困难的是让每一句回答都尽量有证据、有边界、可核查，并在速度、成本、版权和用户体验之间取得平衡。

参考资料#

• Perplexity API Documentation
• Perplexity API Documentation Index
• Evaluating Verifiability in Generative Search Engines
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Dense Passage Retrieval for Open-Domain Question Answering
• AI Answer Engine Citation Behavior: An Empirical Analysis of the GEO16 Framework
• What Gets Cited: Competitive GEO in AI Answer Engines