HtmlRAG

news/2025/10/28 13:28:46/文章来源:https://www.cnblogs.com/alouette/p/19171555

HtmlRAG阅读笔记

HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems

把论文完整标题放在正文而不是标题能不能降低检索权重啊！

开始前的碎碎念

大概是我的个人风格吧，喜欢先记录一下自己的心情。久违地打开了这个“Blogs/论文”的文件夹，上一篇文章还是两年前的（我竟然已经荒废这个博客这么久吗），当时还是第一次参加组会的时候记录的。虽然过于稚嫩，但是现在我一定有进步了。

CNCC开会（公费旅游）期间和师姐的聊天和交流激励了我保持常态化的论文阅读，那么就先从师兄的文章开始读吧，当时出来的时候我就感兴趣，只是一直有别的事情排在它前面。和N老师的交流又让我下决心从现在开始阅读原文，不要翻译，毕竟在这里记录的每一篇都是值得精读的，精读就应该看英文原文。

发在这里是不想被人看见，好像博客园的内容被检索到的概率不大，我对论文绝对有很多判断不准确的地方，但是我不想在自己还没准备好的情况下受到公域的质疑，所以小红书或者知乎都是不可行的，谢谢你，博客园！

Abstract

RAG当中，网络常常是外部知识的来源，但是把结构化的HTML转化成plain text作为输入，会损失heading或者table之类的专属于HTML的结构信息。因此这篇工作用HTML而不是plain text作为检索到知识的格式。现在的LLM理解HTML的能力也有。不过使用HTML的挑战在于它含有额外的内容，比如tags，JavaScript，CSS等，带来了额外的输入token以及噪声。为了处理这个问题，提出HTML cleaning，compression，还有一个两阶段的基于block-tree的剪枝策略，缩短HTML且最小化信息损失。在6个QA数据集上测试了这种方法的优越性。

真的就和师姐形容的好工作的特点一样，motivation非常清晰，是一个重要的但是别人没有去做的点，平时多阅读的过程中也要这样多保持观察和思考。

Introduction

LLM的缺陷是遗忘长尾数据、提供过时知识、产生幻觉。因此RAG通过外部知识增强，减缓了LLM的幻觉。Perplexity和SearchGPT等RAG系统都用了Web search作为底层的检索系统。

传统的RAG pipeline都用plain text作为外部知识的格式，所以HTML文件都被转化成plain text，和用户的query进行拼接，然后塞进LLM。一些tag比如<code>和<a>都被抛弃了，但是这些tag很重要。所以本篇要探索的是一个很直觉性的问题：我们可以用HTML作为外部知识的格式吗？这样就可以尽可能保留信息了。

用HTML格式有几个好处，预训练时LLM就见过HTML了，所以拥有理解HTML的内在能力。最近开源闭源的LLM都开始支持更长的上下文窗口，所以输入更多HTML文档是可行的。而且Latex，PDF，Word格式的文档都可以以最小的损失转换到HTML，因此这一应用也是非常可泛化的。

但是处理HTML格式意味着更长的输入和更多噪声，90%以上的篇幅都是CSS，JS，注释和其他无意义token。上下文一般32K到128K，而一个HTML不经修剪放进去就占了80K，这些无意义token也会影响生成质量，所以需要HTML Cleaning模块来移除语义不相关的内容，同时调整HTML树结构而不影响语义信息，比如合并多个嵌套tags、移除空tags，最终把HTML缩小到原本篇幅的6%。

即便清洗过后也相对较长（每个超过4K），现有的RAG系统使用了不同种类的后处理refiner，提取相关的chunks或者关键句。不过这些refiner是基于plain text的，无法直接应用到HTML，因为不考虑结构而直接给HTML分chunk可能产生不合理的chunk。因此提出HTML Pruning模块，基于HTML树结构进行操作：

创建一个block tree，因为dom tree太细粒度了，把它分层变成粗粒度的blocks，粒度还可以调解。
基于text embedding修剪blocks，也就是计算各个block和query的embedding相似度，根据贪心策略来修剪低相似度的block。这一步对于细粒度的block不太好做，因为基于小block得到的embedding信息太模糊、不准确，所以这一步只能应用在粗粒度的block tree上。
生成式细粒度的block pruning，扩展上一步修建好的block tree的叶节点。因为生成模型有更大的上下文窗口，所以可以全局建模block tree，而非一次一个block。这个生成模型应该计算每个block的分数，即生成这个block对应序列的概率。序列就是从<html>开始往下一直到block所在的tags和内容。最终根据这个block score，使用类似的贪心策略得到最终的pruned HTML。

RAG

标准的pipeline就是rewriter，retriever，reranker，refiner，reader。检索过程方面有些创新，比如动态决定何时搜索，或者LLM计划搜索过程是线性还是树结构的，不过总之大部分检索结果都是用了plain text格式。

Post-Retrieval Process of RAG

比如chunking-based refiner，首先根据某些规则分chunk，然后用reranking model选择高相关度的top chunks；或者abstractive refiner，直接生成摘要（也就是告诉LLM帮你生成摘要），这个模型有人用现成的有人自己去微调。还有人用logits来判断文档中单词的重要性。不过这些都是基于plain text……（然后开始复读intro提到过的“我们新提出了xxx”）

Structured Data Understanding

前人证明了HTML等带结构的文档含有更多信息，并且设计了任务去理解结构化数据。本文不仅限于理解某一类数据格式，而是推荐在RAG里面用更丰富的数据格式，是第一个提出在input中用HTML格式的。

Methodology

感觉intro已经看明白了，这里就只用补一点细节！

目标是找到压缩HTML的最佳方式，使得生成的answer质量最高。

Cleaning移除CSS，JS和注释，以及很长的tag attributes。原始的HTML结构总是包含冗余，所以进行合并和清理空tag：<div><div><p>content</p></div></div>变成<p>content</p>，移除类似<p></p>的。

block tree的粒度由每个block中的maxwords控制，从dom tree开始，把碎片化的child nodes合并到parent里面作为一个block，且这一过程可以递归进行。原本的叶节点如果无法被合并，就也被视为block。

htmlrag_fig2

Block-Tree-Based HTML Pruning

第二步生成式修剪是把之前保留下来block里面进一步区分哪些留哪些舍弃。embedding based那一步受限于上下文窗口，embedding模型没有全局的把握，也没办法进行细粒度的修剪，因为内容太短了模型还没学到语义信息。

灵感来自CFIC（同为本组工作）和生成式检索，它们用chunk序列生成概率来当作这个chunk的分数，本文提出用tags序列来identify一个block。这个序列从root tag开始一直到block tag，把它称为block path。生成模型根据这个path来计算分数，是通过token logits得到的。

htmlrag_fig3

如果分支只有一个，概率一定是1，跳过，无需推理（虚线框）；否则会分配概率，加和为1，在block里面把token级别的概率相乘计算block的概率（实线框）。

到这里我还是没搞懂这个计算logit概率是在哪一步进行的

后来懂了，就是生成模型生成token tree之后根据logit进行softmax归一化得到的概率，token概率的对数和得到block的分数

给生成模型的prompt：

给出HTML内容和question

你的任务是识别HTML文档中和question最相关的text piece，可以是对fact的直接改写，也可以是能够推理得到fact的一个证据。这个text piece的总长度应该在20-300词之间。你应该给出到达这个text piece的path，（这里举了个例子）

Training a Path-aware Generative Model

用了轻量化的长上下文模型，但是不微调用不了，因为没遇到过这种path generation任务。

少样本SFT，在开源QA数据集采样，对每个query用Bing检索几个HTML文档，然后清理、embedding-based剪枝。可以得到2K-32K长短不等的HTML文档。之后建block tree，计算block里面的内容和gold answer之间的em值，舍弃那些没有一个block可以完全匹配到glod answer的样本。

Efficient Tree-Based Inference with Dynamic Skipping

推理过程中，生成模型应该计算block的分数，每个block都有一个block path，经过tokenize得到N个token。给定模型input和已经生成的\(n-1\)个tokens，生成模型计算第\(n\)个token的logit，即给定input和\(n-1\)个tokens生成第\(n\)个token的条件概率。

本文提出了一个高效的基于树的推理，给定一个tokenizer，这个token tree和block tree有一对一的对应关系。token tree得到block tree的方式就是根据path的前缀，一致则可以合并到同一个block。最终，这个tokenized block path的第\(i\)个token会出现在token tree的第\(i\)层。

建设完token tree之后就可以计算每个token的概率了：

root node总是<因此概率为1
没有兄弟姐妹的子节点概率为1
其余节点的概率由生成模型的生成概率得到，也就是把logits做softmax，使得每个节点的所有子节点概率加和为1

前两种情况无需生成模型推理，说明很多token可以被跳过，所以推理的计算开销就减少了。此外，token logit的计算顺序也是计算开销的重要部分。本文采用了DFS遍历token tree并且计算logits，这样被按序列计算的tokens就能共享最长的前缀序列。这一策略最大地重用了前缀序列的KV cache。

算法细节在附录F，上面这段话我确实还没有非常理解，之后要仔细看看附录！

最终，把生成概率从token tree转回block tree，以计算block的分数。为了避免精度上溢（不过原文是overflow，但是概率乘起来应该是特别小的一个数，可能应该是下溢），block score采用token概率的对数和的形式。得到score之后重用贪心策略去对block tree进一步剪枝。

这儿有一个问题：按照这个描述，最后一步细粒度剪枝最后也是归到block层面之后再去剪的，但是图片的描述是一个block里面可以保留一些sub block、丢弃另一些sub block。

一个可能的回答是，把token tree转回block tree这一步其实不是还原之前的粗block，而是转为更细的block？等看完算法细节再确认。

Experiments

在六个QA数据集做实验：ASQA，HotpotQA，NQ，Trivia-QA，MuSiQue，ELI5。检索器用的Bing API，US-EN范围。对于单个短答案的用EM，对于多个短答案的用EM和Hit@1，对于长答案的用ROUGE-L和BLEU。

Baseline选了三个chunking-based refiner，在LangChain里面遵守同一个chunking规则，还选了三个rerank模型（BM25，BGE，E5-Mistral）以及两个抽象refiner（LongLLMLingua，JinaAI Reader）。

选了Llama不同大小的两个模型，都是4K上下文窗口，block tree选用的粒度是256词（在embedding模型剪枝之前），细化的block tree是128词（在生成模型剪枝之前）。

这里回答了上一个问题，我的推测是正确的。

选择BGE-Large-EN作为embedding模型，Phi-3.5-Mini-Instruct 3B作为生成模型的基座。训练集包含2635条自动构建的样本，长度从2K到32K都有。

Experimental Results

对于chunking-based refiner，使用LangChain的chunking规则，根据它的tag heading来。虽然它考虑了一些HTML结构，但是没有像本文方法一样有效使用结构信息。而且把最终的输出转化为plain text仍然导致丢失结构信息。在使用的三个reranker中，稀疏检索的BM25不如另外两个密集检索的，encoder-based的BGE超过了decoder-based的E5-Mistral，甚至后者的参数量更大。

在抽象refiner中，LongLLMLingua没有针对HTML文档优化过，所以表现较差，Jina的可以生成精细化的markdown。然而长输入输出的情况下，token-by-token的decoding对于端到端的生成模型很有挑战，而且开销也很高。

Further Analysis

消融实验做了HTML Cleaning的效果，减去Cleaning仍然大多数超过了plain text和markdown。还做了block tree、prune-embed、prune-gen的消融，证明了缺了哪个都不好使。以及block粒度的影响，生成模型比embedding模型更适应细粒度，验证了两阶段剪枝的合理性。