Software 2.0

IndexLM：基于索引的网页提取

admin -

在多跳问答或智能体驱动的深度研究等场景中，系统通常需要一次性阅读数百个网页。

问题是什么？ 网页体积庞大。

这篇文章可能提供了一个有用的视角。

1、网页提取已成为新的瓶颈

HTML比你想象的更重。

根据HTTP Archive的数据（2025年8月），网页HTML的中位大小（包括CSS和JavaScript）约为870 KB，相当于约89万个字符或大约22.3万个token。这远远超过了大多数大语言模型能够处理的范围，即使是32K或128K的上下文窗口也是如此。

即使排除JS和CSS字节（约占大小的96%），剥离后的HTML仍然携带约9K个token，而这只是一个页面的数据。

现在想象一下尝试分析50到100个这样的页面。这不再仅仅是内存问题。它很快变成了上下文管理的噩梦。你最终会得到臃肿的输入和臭名昭著的*"迷失在中间"*问题，关键信息被淹没在噪音中。

2、现有解决方案不足

图1：基于索引的网页内容提取与先前工作的对比。分块和重排序RAG方法无法执行主要内容提取，而基于启发式规则的方法难以进行查询相关提取。相比之下，这种方法既有效又高效。来源。
  1. 生成式提取模型： 这些模型逐个token生成相关内容。虽然灵活，但扩展性不好——你想要的内容越多，速度就越慢。延迟随提取目标内容的长度增加而增加。
  2. 基于规则的启发式方法： 想想手工编写的脚本，它们剥离页眉、页脚、导航栏和广告。这些方法对于简单、结构良好的网站效果不错，但网页设计混乱且不一致。几乎不可能编写出能够跨整个网络泛化的规则。此外，它们对查询意图是盲目的。
  3. 分块和重排序（RAG）： 这种方法将内容分成块，然后使用BM25或嵌入相似度选择相关片段。但问题是：相似度并不总是等于相关性。而且它无法区分主要内容和侧边栏或广告。所以你经常最终提取到错误的内容。

3、我们真正需要什么？

为了让网页智能体和RAG管道在大规模上高效运行，提取需要进化。理想的解决方案应该：

  • 将提取速度与内容长度解耦： 长内容不应该意味着更慢的提取。
  • 支持主要内容和查询特定提取： 无论你是想要页面的核心内容还是仅与问题相关的部分。
  • 理解网页结构： 它应该能够区分导航、页脚和真实内容。
  • 为下游LLM或智能体提供简短、准确的输入： 上下文应该精确，不仅仅是更小，而是更好。

4、基于索引的网页内容提取

基于索引的网页内容提取重新思考了如何从网页中提取信息。不再是让模型生成大段文字，而是将任务重新定义为指向——即从索引块列表中选择跨度。模型的工作就是简单地输出一组索引范围，如[[2, 3], [5, 6]]，系统将这些映射回原始HTML。

图2：基于索引的网页内容提取的完整过程。来源。

这种方法将过程分为三个不同的阶段：

4.1 索引构建

第一步是清理HTML。这包括移除JavaScript和CSS（同时保留脚本中嵌入的文本内容）、注释和其他噪音。页面标题也被提取出来。

接下来，HTML通过DOM树的深度优先遍历解析为结构化块，主要在块级标签如<div>, <p>和 <h1>上进行分割。带有文本标题的图像可能形成自己的块，而内联格式标签如<b>, <i>和 <br>则保留在块内，而不是用作单独的分割边界。过长的块（超过预定义的最大长度）按句子或单词分割，并相应标记以便后续准确重建。

然后为每个内容块分配一个唯一的数字索引，格式如下：

[2]<h1>示例标题</h1>
[3]<p>该标题下的段落。</p>

4.2 索引预测

这个流水线的核心是IndexLM，这是一个模型家族，经过训练可以预测哪些块与给定查询相关。它有三种尺寸（0.6B、1.7B和4B参数），全部基于Qwen3系列。

模型接收四个输入：网页URL、页面标题、索引内容块列表和自然语言查询。

其输出是索引区间列表，如[[1, 2], [4, 4]]。如果没有找到相关内容，则返回NA。

处理长文档时，内容块根据L_max,doc限制进行分块，并对每个块进行预测。然后合并结果。

模型使用交叉熵损失进行训练。

训练数据来自两个来源：

  • 查询相关提取：从HotpotQA、Natural Questions和MultiHopRAG等数据集采样。对于每个查询，检索15个网页并使用DeepSeek V3.1标注相关块。
  • 主要内容提取：从Common Crawl前500域名采样页面，以及上述数据集的子集。使用DeepSeek V3.1标注（人工标注仅用于测试集）。

所有样本都进行去重，没有相关内容的实例被部分过滤。

示例提示结构：

图3：基于索引的网页内容提取的提示。来源。

4.3 后处理

一旦预测出相关索引范围，相应的内容块就被拼接在一起。系统重建DOM关系，如列表或表格结构，以在必要时恢复格式。

最后，内容被转换为Markdown，这既保持了结构的轻量级，又减少了下游语言模型使用的token数量。

以下是实际效果的示例：

图4：基于索引的网页内容提取示例。绿色背景文本表示查询相关内容，红色表示相反。原始内容将被映射到索引，最后，查询相关索引将被映射回原始文本块。来源。

5、评估

在五个QA数据集和两个答案模型上，IndexLM-4B（在Qwen3-4B下与IndexLM-1.7B并列）获得了最高的平均F1分数。Firecrawl Extract在多跳HotpotQA和MuSiQue数据集上实现了略高的F1，而IndexLM在TriviaQA、Natural Questions和MultiHopRAG上表现更好， 最终在总体上效果最好。

实验表明，这种方法比生成式模型在端到端延迟上快达10倍，并通过提供更干净的上下文有效提高了RAG QA准确性。此外，直接评估确认它在显著减少LLM token负载的同时保持高召回率。

由于空间限制，对于那些对完整评估感兴趣的人，请参考参考文献。

6、思考

这项工作的不同之处在于它从内容生成到索引选择的转变。通过将提取定义为结构化预测任务——本质上是指向网页的相关部分——它将复杂的生成问题简化为更轻量级的问题。在上下文空间仍然昂贵的时代，这种设计选择是一个非常实用的工程胜利。

但我有两个担忧：

  • 首先，该模型严重依赖上游LLM标注（人工数据仅用于评估）。这引发了关于它在长尾领域或与合成训练分布不同的反爬取页面上的表现如何的问题。
  • 其次，虽然它包含从JavaScript中提取文本的启发式方法，但流水线最终依赖于静态DOM结构。如果HTML严重损坏或需要完整的客户端渲染，与基于视觉或基于浏览器的方法相比，性能可能仍会下降。

从部署角度来看，价值在你处理大量网页、紧张的上下文预算和成本效益模型的组合中变得清晰——这种组合适用于当今大多数真实世界的系统。在这些设置中，基于索引的提取如IndexLM可以在QA质量和吞吐量方面提供显著提升，而无需更换主模型。

原文链接: IndexLM: Turning Web Extraction into an Indexing Game

汇智网翻译整理，转载请标明出处