浏览器与语言模型看同一URL却看到完全不同内容

300KB-800KB HTML 让 RAG 直接使用原始标记变得不可行

浏览器打开一个新闻或文档页面，看到的是完整的渲染界面：顶部导航、侧边栏推荐、广告横幅、cookie 同意弹窗、各种脚本和交互组件，最后才是用户真正想读的正文。而语言模型只能接收我们喂给它的文本表示，两者对同一 URL 的理解存在本质差异。

一篇典型文章页面的原始 HTML 体积通常在 300KB 到 800KB 之间。其中绝大部分是与核心内容无关的标记语言。导航栏、页脚、广告位、追踪脚本、样式表、内联 JavaScript 以及各种隐藏的 div 层叠在一起，把真正有价值的文章文本深深埋在里面。如果直接把这样的 HTML 塞进 RAG 管道，检索结果会充斥大量噪声，嵌入向量质量下降，最终导致生成答案时出现幻觉或遗漏关键事实。

这个痛点在实际工程中非常突出。RAG 系统依赖高质量的 chunk，而原始网页标记里 70% 以上的内容都是冗余。开发者如果不做提取，直接把整个 HTML 切块，不仅 token 消耗暴增，检索相关性也会大幅降低。尤其是当管道需要处理大量外部链接时，噪声累积效应会让整个系统变得不可用。

中文互联网上的情况更复杂。很多网站采用服务端渲染加客户端动态加载的混合模式，重要段落可能要等 JavaScript 执行后才出现。单纯抓取静态 HTML 经常拿不到完整正文，这进一步放大了提取的难度。浏览器能正常显示的内容，语言模型却只能看到一堆未执行的脚本和占位符。

因此，网页内容提取不再是可有可无的预处理步骤，而是决定 RAG 管道上限的核心环节。没有干净的输入，后续的检索和生成都会被拖累。

Perceive 先渲染页面再用模型提取干净正文

Perceive 的核心思路是让工具模拟真实浏览器行为，先完整渲染页面，再交给语言模型做针对性提取。

具体流程是：使用无头浏览器加载目标 URL，等待页面稳定后捕获完整的 DOM 和渲染结果，然后把必要部分（主要是可见文本和结构）喂给专门微调过的模型。模型的任务不是总结，而是严格按照指令把正文、标题、作者、发布时间等结构化信息抽取出来，同时过滤掉导航、广告、评论区等无关内容。

这种“渲染+模型提取”的路径避开了传统规则提取器的维护难题。网站前端经常改版，XPath 或 CSS 选择器很容易失效，而模型能理解上下文，即使布局变化也能较好地识别什么是正文。

整个过程强调“给模型看的不是原始 HTML，而是经过渲染且被裁剪后的表示”。这样语言模型看到的就和人类读者接近得多，减少了因标记噪声导致的误判。Perceive 的构建过程表明，这种方法在新闻类和文档类站点上都能取得较高准确率。

对开发者来说，这套方案把原本分散在不同工具里的步骤统一起来：浏览器负责真实呈现，模型负责语义理解，避免了单纯正则或 BeautifulSoup 容易漏掉动态内容的短板。

中文网站动态加载与编码问题需要额外处理层

中文互联网的内容站点普遍采用 Ajax 动态加载、正向防爬、GBK 与 UTF-8 混用等做法，给提取工具带来独特挑战。

很多新闻门户和博客平台的正文是在页面加载后通过 JavaScript 从接口拉取的。如果只抓取初始 HTML，往往只能拿到骨架和少量静态文本。Perceive 的做法是必须等待页面网络请求完成、主要元素渲染出来后再进行提取，这需要合理的等待策略和资源加载监控。

编码问题同样常见。部分老旧站点仍使用 GB2312 或混合编码，标题和正文可能出现乱码，直接影响后续分词和嵌入。提取流程里需要增加编码探测和转码模块，确保模型拿到的是正确可读的中文文本。

此外，中文页面里的广告和推荐内容经常与正文混杂在同一 div 内，特征不明显。模型需要针对中文排版习惯进行额外提示，例如重视段落长度、忽略包含“相关阅读”“热门推荐”的区块等。

这些额外处理层让提取工具的复杂度上升，但对中文 RAG 应用必不可少。没有针对性的适配，直接套用英文优化过的工具，在中文站点上的召回率会明显下降。

提取策略必须在准确率、延迟和成本间反复权衡

构建 Perceive 的过程中，团队反复测试了多种方案，最终发现没有一种方法能在所有维度都占优。

纯规则提取速度最快、成本最低，但准确率在复杂布局站点上容易崩盘。纯大模型直接吃完整 HTML 的方式准确率高，却带来极高的 token 消耗和延迟。Perceive 选择的渲染后模型提取路线，是在三者之间取得平衡的结果：渲染带来一定延迟，模型调用产生一定成本，但准确率显著高于规则方法。

不同场景的权衡标准也不一样。对实时性要求高的产品，可能需要牺牲部分准确率换取更低的延迟；对知识库构建这类离线任务，则可以接受更高成本以换取更干净的文本。团队的经验是，必须把提取效果量化成可测量的指标，例如正文完整度、噪声比例、结构化字段准确率，然后根据具体业务目标设定阈值。

中文场景下，模型提示词的优化也直接影响成本。精心设计的 few-shot 示例能让小模型完成任务，避免每次都调用最贵的大模型。

这些权衡没有标准答案，只能根据自己的 RAG 管道规模、预算和对幻觉的容忍度来决定。目前 Perceive 仍在持续迭代，说明这个领域仍有很多工程空间。

干净内容输入直接降低 RAG 幻觉并提升召回

当 RAG 管道拿到的是去噪后的干净正文时，检索阶段的向量匹配质量会明显提高。无关的导航文本和广告不再占用 embedding 空间，核心内容 chunk 的语义边界变得清晰，召回率随之上升。

生成阶段的幻觉现象也显著减少。因为上下文里不再充斥大量矛盾或无关信息，模型更容易聚焦在正确的事实上。实际测试显示，使用提取后的干净文本后，答案中虚构内容的比例有明显下降。

对中文开发者而言，这一点尤其重要。中文语料的分词特性使得噪声对 embedding 模型的影响比英文更大。一旦输入干净，中文 RAG 系统的整体表现会提升一个台阶，无论是企业内部知识库还是公开信息问答产品，都能得到更可靠的结果。

干净输入还降低了 token 用量。去掉 70% 以上的冗余标记后，单次检索的上下文长度大幅缩短，整体成本随之下降。这在处理大规模网页数据时，累积效应非常可观。

自建类似工具时优先渲染后结构化再精炼

如果要自己搭建类似 Perceive 的网页提取工具，推荐的顺序是：先用无头浏览器完整渲染页面，得到稳定 DOM；然后用较小的模型或规则做初步结构化，提取标题、正文候选区、元数据；最后用更强的模型对候选内容做二次精炼，去除残余噪声并输出标准化格式。

这个“渲染→结构化→精炼”的流水线能兼顾效率和准确率。渲染步骤不可省略，否则动态内容会大量缺失。结构化步骤尽量用轻量方法完成，把重活留给最后的精炼模型，避免不必要的算力浪费。

目前仍未完全解决的权衡点包括：如何在移动端适配的页面中准确识别正文，如何处理无限滚动加载的内容，以及如何在隐私合规前提下抓取受保护站点。这些问题需要持续投入工程资源。

对中文团队来说，还需要额外投入精力构建中文特有的提示词模板和评估数据集。只有把提取工具的输出质量稳定在较高水平，RAG 管道才能真正发挥价值。

整个提取环节看似是基础设施，却直接决定了最终产品的智能程度。干净的内容输入，是高质量 RAG 应用的前提。

参考来源