网页不会整页进入 AI 上下文：Perplexity 如何筛选关键、无关与重复片段

一个网页被搜索系统召回，不代表整页内容都会进入答案模型。

2026 年 3 月，Perplexity 公布 Search API 的新一轮抽取与评测改进：系统会针对“查询—文档”组合标记文本 span，区分必须保留的 vital 证据、应该排除的多类 irrelevant 内容，以及 duplicate 重复信息。两个月后，Perplexity 又披露了已经部署到其应用与 API Platform 的 query-aware context compression 模型，进一步解释这些标签如何变成线上 snippet [1][2]。

这次更新揭开的不是“AI 怎样给整页打分”，而是一个更细的中间层：候选网页已经找到之后，哪些局部证据值得占用有限的模型上下文。

---

先给结论

Perplexity 公开的流程可以压缩成一句话：

系统先召回候选文档，再结合当前 query 判断哪些原文片段应该保留，过滤无关、广告、元数据、界面导航和重复内容，最后把更小、更聚焦的 snippet 送给答案模型。

这与传统 chunking 不是一回事：

• Chunking 解决文档预先怎样分段、索引和召回。
• Query-aware extraction/compression 解决面对这一个问题时，已召回内容中的哪些局部证据值得留下。
• Answer generation 再用留下的证据组织答案和引用。

有五个边界必须先说清楚：

1. Perplexity 没有把 Span-Level Extraction 作为独立产品名。 官方使用的是 span-level labeling、snippet extraction 和 query-aware context compression 等表述。
2. 网页可能先被完整抓取和解析，但不会必然完整进入答案模型。 本文讨论的是下游 context，不是说搜索系统从未处理整页。
3. 标签相对于 query，而不是网页的永久质量分。 同一句话面对不同问题，可能从 off-topic 变成 vital。
4. 公开指标来自 Perplexity 自测。 它们能说明其系统设计与内部结果，不能直接外推到 Google、ChatGPT、Claude 或所有 Perplexity 请求。
5. 这不等于企业应该把网页切成大量短碎片。 Google 甚至明确表示，没有为了生成式搜索把内容切成小块的要求 [9]。

真正值得企业关注的不是固定段落长度，而是：当系统只留下与一个具体问题最相关的少量原文时，你的结论、条件和证据能否一起存活。

---

Perplexity 这次到底改了什么

Perplexity Search API 返回的每条结果包含标题、URL、snippet、发布日期和更新时间等字段。这里的 snippet 不是装饰性摘要，而是下游模型或代理真正会消费的上下文材料 [4]。

2025 年公布的 Search API 架构已经说明，Perplexity 会同时在文档级与子文档级检索和评分，并把文档中的 section 与 span 当作一等单位。原因很直接：整篇文档主题相关，不代表其中每一段都能帮助回答当前问题；过宽的上下文反而可能干扰模型 [3]。

2026 年 3 月的更新向前推进了两步：

• 建立 span-labeling pipeline，精确评估 snippet 里该包含和该排除的内容；
• 改进页面解析，使表格、嵌套列表和此前规则难以稳定处理的动态渲染内容更容易进入结构化抽取流程 [1]。

5 月的后续技术稿则公开了线上压缩模型。它接受 query 与候选结果，选择应该保留的原文 span，删除其余内容；最终输出不重新撰写摘要，而是尽量保留来源原文，方便核验和引用对齐 [2]。

一条更准确的处理链

这里的 span 可以理解为文档中可定位的一段连续文本，但不能简单等同于一个段落、一个 DOM 节点或固定 token chunk。Perplexity 公开的训练流程以 span 产生监督，线上输出则会把预测按句子聚合，再结合阈值和 token budget 裁剪 [2]。

---

六类内容：哪些留下，哪些被删

3 月的技术稿只概括为 vital、多个 irrelevant 类别、duplicate 与其他类别。5 月的后续评估把 snippet token 具体分成六类 [1][2]：

最关键的词是当前 query。

例如一页软件产品文档同时包含离线模式、价格、数据驻留和售后支持。面对“该产品能否在弱网环境离线工作”，离线功能与适用平台可能是 vital，价格和服务时区则是 off-topic。换成“在德国部署的总成本是多少”，价格、席位假设和税费条件可能变成 vital，离线功能反而退出核心上下文。

因此，这套系统不是给网页画一张永不变化的“好段落清单”。它是在每个 query 下重新决定什么是信号，什么是噪声。

---

Span 标签如何变成线上 snippet

Perplexity 公布的训练与服务流程可以分为四步。

第一步：先理解 query 的可能意图

监督管线使用 LLM judge 读取用户 query，并先列出可能意图。这样做是为了避免只靠词面重合标记证据：一个片段没有复述查询原词，也可能准确满足隐含条件。

第二步：从候选页面复制并分类 span

Judge 随后读取候选页面的链接、标题、摘要和上下文，返回从原文逐字复制的 span，并为每个 span 标注类别。Perplexity 表示，直接字符串匹配找回了 98% 的 judge span，再加入简单正则匹配后达到 100%。这里的数字描述其标签对齐管线，不是线上答案准确率 [2]。

第三步：把多类标签转换为 keep/drop 监督

Perplexity 用这套流程标注了 75 万组 query-document pairs，再把 span 转成 token 级保留/删除监督，训练一个压缩头。类别帮助研究人员检查标签，但线上模型的核心决策仍是哪些 token 值得保留。

第四步：线上按句聚合并受预算约束

模型让 query 与候选上下文双向交互，对整个上下文并行预测。服务时，snippet engine 把预测聚合到句子级，应用阈值，再按照请求的 token budget 裁剪。

这也解释了为什么 Perplexity 选择抽取式压缩，而不是让模型为每一页生成新摘要：保留原文更容易维持来源措辞、核对事实和绑定引用；生成式摘要可能引入来源中没有的表述，同时增加时延和成本 [2]。

相关研究也把 context pruning 建模为序列标注问题，在生成前动态删除无关上下文，以减少长上下文成本和噪声传播 [8]。Perplexity 的实现属于这一技术方向在生产搜索系统中的具体落地。

---

为什么更小的 snippet 反而可能更准确

直觉上，给答案模型更多原文似乎更安全。但长上下文并不等于模型能稳定使用每一段。

“Lost in the Middle”研究显示，当相关信息位于很长上下文的中部时，模型表现可能明显下降；模型通常更容易利用开头或结尾的信息 [7]。Perplexity 将无关上下文带来的问题概括为三类：准确性下降、时延增加和 token 成本上升 [2]。

它公布的内部结果包括：

• 生产模型由 28 层 teacher 蒸馏为 17 层 student，官方报告线上 p99 低于 20 ms；相较 teacher，推理时延下降 35%–40%，总体 GPU 计算下降 40%–45%，内部压缩质量没有下降。
• 在 BrowseComp 的多步搜索评测中，开启压缩后，query 级 token 使用量减少 10%–70%，准确率提高 4–4.81 个百分点。
• 在 SimpleQA 单步问答中，medium 配置平均每个文档约 200 tokens，官方报告达到 95% 准确率；其样本文档平均长度超过 10,000 tokens。
• 在 1,000 条混合领域验证查询的 token 分类中，压缩后 vital 内容占比平均提高 63%，irrelevant 内容下降 29%；UI/navigation、metadata 和 ads 分别下降 58%、46% 和 43% [2]。

这些都是Perplexity 自己的模型、流量、基准与统计口径下的结果。它们不能证明“所有 AI 引擎都应该删掉相同比例”，也不能推出“页面缩短 70% 就会更容易被引用”。

系统优化的是送给模型的 snippet，不是要求网站把原始内容删短。

---

Dynamic Benchmark 在测什么

3 月更新的另一部分是把 SEAL 纳入 search_evals。这与 span 标签评估解决的是不同问题。

SealQA 专门测试：当网页搜索结果存在冲突、噪声、过时或无帮助信息时，搜索增强模型能否找到当下正确答案。Seal-0 聚焦基础模型几乎无法答对的问题，Seal-Hard 扩展难度，LongSeal 则加入长上下文和多文档干扰 [6]。

Perplexity 在 2026 年 2 月 24 日的公开仓库快照中，用单步搜索代理和 SimpleQA grader 跑了 254 条 SEAL-Hard 任务，并保存不同搜索 API 与模型组合的结果。这是端到端答案正确率，不是 span precision、recall 或 F1 [5]。

三层评测不能混用

Perplexity 3 月稿称，在使用 Claude Sonnet 4.5 对 2 月 22 日版 SEAL 运行评测时，其分数上升，而其他被测供应商在 SEAL-Hard 上下降 [1]。这仍是厂商在自己框架中的比较，不应被改写成独立行业排名。

Dynamic benchmark 的真正价值，是迫使搜索系统面对答案会变、旧页面仍存在、多个来源互相冲突的现实。对 GEO 来说，新鲜度不再只是页面上的日期字段，而是当前值能否从历史噪声中被准确抽出来。

---

用一个产品页面看懂六类标签

假设用户问：

FieldPro 在印度尼西亚没有网络时，技术人员还能完成工单吗？

候选产品页包含以下内容：

真正危险的不是页面长，而是关键结论与限制条件被分开。

如果“支持离线工单”在产品介绍开头，而“仅限 2026.4 以上版本、附件需联网同步”藏在很远的脚注里，压缩器可能只保留第一句，生成一个过度宽泛的答案。好的内容工程不是机械缩短，而是让结论、适用对象、版本、例外和来源彼此靠近。

同样，面对“FieldPro 的 AI 排班有什么功能”，刚才的 off-topic 段落会变成 vital。标签随着问题改变，这正是 query-aware 的含义。

---

企业应该怎么调整内容

1. 把结论与限制条件写在同一证据单元里

一个可核验事实至少应尽量带上：主语、动作或数值、单位、适用范围、时间或版本、必要例外。不要让营销标题负责结论、脚注才负责真实边界。

2. 降低正文周围的模板噪声

导航、重复 CTA、活动横幅、相关推荐和自动插入模块会增加解析负担。它们未必导致降权，但可能占用抽取和上下文预算。至少要让主内容在 HTML 与视觉层级中清楚可辨。

3. 让表格与列表保留完整语义

Perplexity 特别提到对表格和嵌套列表的解析改进 [1]。表头、单位、行列关系和条件不能只靠颜色或位置表达；否则某个单元格被抽出来时，数值可能失去含义。

4. 减少没有新增信息的重复表述

同一主张在 Hero、功能区、FAQ 和页尾反复出现，不会自动增加四次证据。更有价值的是让不同区块分别补充定义、限制、数据、方法与来源。

这里的 duplicate 指上下文中的信息冗余，不等于应该因为这篇文章去大规模删除 canonical 页面或改写 SEO 架构。

5. 给时效性事实一个明确的当前版本

价格、库存、功能状态、法规和兼容性最容易与历史页面冲突。保留更新时间、版本号、适用地区和变更记录，并确保旧说明被明确标记或重定向。

6. 做一次“六色标注”人工审计

选一个高价值问题，把相关页面打印或复制出来，分别标记 Vital、Off-topic、Ads、Metadata、UI/navigation 和 Duplicate。然后只读取 Vital 片段，检查：

• 能否独立回答问题？
• 主语、单位和时间是否完整？
• 限制条件有没有一起留下？
• 每项关键结论能否回到原始来源？
• 删除其余内容后，是否出现误导？

这不是复刻 Perplexity 内部模型，而是一种基于公开机制的内容 QA 方法。

---

Innflows 在这里解决什么

企业无法从 Perplexity 前端或 Search API 报表直接看到某个页面被标成了哪些 span，也不能读取其他平台未公开的内部上下文。

Innflows 更适合处理结果层的问题：围绕一组稳定的业务问题，持续记录不同 AI 平台是否提及品牌、引用了哪些 URL、答案采用了哪些关键事实，以及内容更新前后这些结果怎样变化。

结合本文方法，可以建立一张“问题—关键证据—承载页面—引用结果”矩阵：

1. 用业务问题确定每个页面必须保住的 vital facts；
2. 审计结论、条件、日期和来源是否在同一证据单元；
3. 发布更新后，用跨平台重复测试观察引用 URL 与答案事实是否变化；
4. 把长期缺失或经常被竞品占据的证据主题列入下一轮内容计划。

边界同样明确：外部监测看得到最终答案与引用，看不到平台内部的 token 标签，不能证明某次引用变化由某一个 span 编辑直接造成，也不能保证下一次回答继续引用同一页面。

---

六个最常见的误读

1. Perplexity 给每个网页永久贴上 Vital 或 Irrelevant 标签

不是。模型同时读取 query 与候选上下文；标签随问题变化。

2. Duplicate 就是 SEO 重复内容

不是。这里主要指当前 snippet/context 中已经出现的信息再次重复，不能直接等同于重复 URL、canonical 或站内内容治理规则。

3. Snippet 越短越好

不是。压缩存在 precision-recall 取舍。删得过多会丢失必要条件，Perplexity 也通过阈值与 token budget 调节保留量 [2]。

4. 既然系统会抽取，网页结构就不重要了

相反，解析必须先正确识别正文、表格、列表与布局，后续 span 选择才有可靠输入。抽取模型不能恢复抓取阶段从未获得的事实。

5. SEAL 分数证明 span 标签准确

不能。SEAL 测端到端答案正确率，span 标签质量和 snippet 组成是另外两层评测。

6. 这套数字适用于所有生成式搜索引擎

不能。公开数字来自 Perplexity 的系统和内部/公开基准。其他引擎可能使用不同解析器、检索器、压缩方法和上下文预算。

---

常见问题

Span-level extraction 与 chunking 有什么区别？

Chunking 通常发生在预处理、索引或初步检索阶段，先把文档分成可管理单元。Span-level extraction 则在 query 已知、候选内容已召回之后，进一步判断哪些局部原文对当前问题有用。两者可以同时存在。

Span 是一句话、一个段落还是一个 DOM 节点？

公开资料没有给出一个永远固定的网页 span 单位。训练监督来自可定位的原文 span，随后转为 token 级 keep/drop；线上服务再按句子聚合并受 token budget 约束 [2]。

网站所有者能看到自己的 Vital span 吗？

目前没有公开的站长报表提供这项能力。Search API 返回结果 snippet，但不展示每个 token 的内部类别或选择分数 [4]。

企业应该把段落控制在多少字？

没有一个由这项研究推出的固定字数。Perplexity 优化的是 query-dependent snippet；Google 也明确表示，不要求为了 AI 把内容拆成细小块，也没有理想页面长度 [9]。

表格和列表会不会被 AI 忽略？

不能一概而论。Perplexity 表示其解析系统已经扩大对表格与嵌套列表的处理范围，但具体页面仍取决于抓取、HTML 结构和解析结果。表头、单位和条件应使用可读文本明确表达。

优化证据单元能保证被引用吗？

不能。它只改善内容在抽取阶段被准确理解和保留的可能性。网页还要经过抓取、索引、检索、重排、来源选择和答案生成等环节。

---

核心结论

Perplexity 这轮技术更新把 AI 搜索的中间层讲得更清楚：搜索系统不只是找到一篇相关网页，还要在每次 query 下决定，网页里的哪些原文值得进入答案模型。

这套机制带来四个关键认识：

• Vital、Off-topic、Ads、Metadata、UI/navigation 和 Duplicate 是相对当前问题的上下文角色，不是网页永久评分。
• 抽取式压缩保留来源原文，比为每页生成摘要更容易维持引用可追溯性。
• 更小的 snippet 可以降低噪声、时延和成本，但过度压缩也可能丢失必要条件。
• Span 评测、snippet token 构成和 SEAL 端到端答案准确率是三层不同证据，不能混成一个指标。

对企业来说，最可执行的动作不是把所有文章重新切成固定长度，而是确保每项关键结论都与它的主语、范围、时间、限制和来源紧密相连。

AI 最终引用的不是“整页写得不错”这件事，而是它在当前问题下能够保留下来的那组证据。

---

参考来源

[1] - Search API: Better Extraction, Dynamic Benchmarks — Perplexity，2026 年 3 月 11 日

[2] - Query-Aware Context Compression for Better Snippets — Perplexity Research，2026 年 5 月 14 日

[3] - Architecting and Evaluating an AI-First Search API — Perplexity Research，2025 年 9 月 25 日

[4] - Search the Web: Search API Reference — Perplexity

[5] - search_evals Repository Snapshot — Perplexity，提交于 2026 年 2 月 24 日

[6] - SealQA: Raising the Bar for Reasoning in Search-Augmented Language Models — arXiv:2506.01062

[7] - Lost in the Middle: How Language Models Use Long Contexts — TACL / arXiv:2307.03172

[8] - Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation — ICLR 2025 / arXiv:2501.16214

[9] - Google's Guide to Optimizing for Generative AI Features on Google Search — 更新于 2026 年 7 月 10 日