今天是2024年11月07日，星期四，北京，天气晴，今天立冬，冬天悄然来临。
本文继续看RAG，围绕4个问题，对应对应到建库、召回以及生成等阶段，都是trick，分别是关于RAG中的分块策略对比回顾、大模型生成策略，在大模型中增加输出多样性、RAG的chunk表示：HTML比纯文本更适合用于RAG系统中建模检索到的知识、GraphRAG微软版本更新0.4.0，引入DRIFT推理。
仔细读，会有收获，供大家一起参考。
一、RAG中的分块策略对比回顾
关于分块策略，我们已经在之前的工作中说过多次，可以再来回顾下，
《Is Semantic Chunking Worth the Computational Cost?》( https://arxiv.org/pdf/2410.13070)，提到三种方式
固定大小分块器（Fixed-size Chunker）：这是基线分块器，它根据预定义或用户指定的每个分块的句子数量将文档顺序分割成固定大小的分块；
基于断点的语义分块器（Breakpoint-based Semantic Chunker）：这种分块器通过检测连续句子之间的语义距离阈值来分割文本，以保持连贯性；
基于聚类的语义分块器（Clustering-based Semantic Chunker）：这种分块器利用聚类算法按语义分组句子，捕捉全局关系，并允许非连续文本分组。
至于具体效果，可以看看评估指标：
二、大模型生成策略，在大模型中增加输出多样性
关于多样性，我们一般都会调整topk, topp, temperature等系数，最近的工作《Growing a Tail: Increasing Output Diversity in Large Language Models》(https://arxiv.org/pdf/2411.02989)，为了提高模型的输出多样性，尝试了三种方法：
1）通过温度采样增加生成的随机性，温度从0.3提高到1；
2）引导模型从多个角度来看待问题，例如，在原始提示“你能列出三部好的电视剧吗？”增加提示“从多种角度回答”这几个词，变为：“从多种角度回答：你能列出三部好的电视剧吗？”；(“answer from diverse perspectives”, before the original prompt in one treatment (e.g., “Answer from diverse perspectives: Can you list three good television series?”)，及promotD-ante，也可以后置，变为“你能列出三部好的电视剧吗？从多种角度回答”，即promotD-post；
3）将多个模型的输出进行聚合，例如，将不同的模型在不同生成条件下的输出进行合并。
看看效果，只要使用熵来判定，在信息论中，熵（entropy）是用来衡量不确定性的一个概念。熵通常用来量化多样性，熵越高，表示回应的多样性越大。
“AVE”线指定了在每个处理方式下每组模型生成的回应的平均熵。“AGG”线指定了在每种处理方式下每组模型聚合生成的回应的熵。颜色是以渐变方式设置的，因此更鲜艳的颜色反映了更高的熵。
三、RAG的chunk表示：HTML比纯文本更适合用于RAG系统中建模检索到的知识
要注意，传RAG系统通常使用网页作为外部知识的来源，并通过Web搜索引擎检索结果，然后下载HTML源文件，并从HTML源文件中提取纯文本供LLMs使用。然而，这种方法在转换过程中会丢失HTML中的结构和语义信息，但是，这是我们所说的AI搜索的场景，不是普通场景，用户先输入一个query，然后召回出来网页，一开始很乱，需要将网页做个清洗再返回，这个就是精华了。
《HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems》(https://arxiv.org/pdf/2411.02959)，这个工作使用HTML而不是纯文本作为RAG系统中检索知识的格式，理由是，HTML在模拟外部文档的知识方面优于纯文本，而且大多数LLMs都具备理解HTML的能力。这个工作的核心，就是说了下怎么洗html文档，即we design HTML cleaning and HTML pruning to shorten HTML while retaining key information
HTML本身就是个domtree，是一棵树，里面构成了一些层级关系和结构化信息，尤其是表格，其富含结构信息，但是markdown也同样可以做（因此，现在很多RAG系统都在卷pdf2markdown这些功能）。
但是，使用HTML也带来了新的挑战，因为HTML包含了标签、JavaScript和CSS规范等额外内容，这些会给RAG系统带来额外的输入标记和噪声。
所以，应该怎么办，那就是做清洗，所以提出了HTML清洗、压缩和剪枝策略，以缩短HTML内容，同时尽量减少信息损失，所以设计了一个基于规则的HTML清洗模块，去除CSS样式、注释和JavaScript等内容，并合并多层单嵌套标签以减少冗余结构。
例如，去除CSS样式、JavaScript和注释。这些内容虽然对HTML结构的理解有一定帮助，但对于生成高质量的答案并不必要；清除冗长的HTML标签属性：合并多个层次的单一嵌套标签，例如将<div><div><p>some text</p></div></div>简化为<p>some text</p>，并移除空标签如<p></p>。
处理完之后，需要接入到RAG，因此需要建立索引，怎么建，构建块树(Block Tree)，将所有检索到的HTML文档连接在一起，并使用Beautiful Soup解析成一个单一的DOM树。为了简化处理，采用一种可调节粒度的块树构建方法，将DOM树合并成层次化的块，块的粒度可以通过调整最大单词数来控制。
流程如下：
然后是检索阶段，味了保留HTML文档的结构信息并降低上下文压力。
给定用户查询，需要找到对应的上下文，但考虑到上下文过长，所以进行剪枝，包括两个部分，一个是基于文本嵌入的块剪枝，使用现有的嵌入模型对块树进行初步剪枝，删除与用户查询相似度较低的块。这一步骤虽然简单有效，但受限于嵌入模型的上下文窗口和细粒度块的处理能力。
另一个是生成式细粒度块剪枝，采用生成式模型，根据每个块的路径（即HTML标签序列）计算其得分，并使用贪婪算法进行剪枝，生成式模型的长上下文窗口使其能够覆盖整个块树，而不仅限于逐个建模块。
具体的块得分计算逻辑如下：
这个步骤采用生成模型的prompt如下：
实验的效果还不错：
不过，需要注意的是，HtmlRAG方法仅仅适用于需要从网页和结构化文档中提取知识的场景。目前很多文档可能不是以HTML格式存储的，如果真的要做，那需要通过适当的转换工具将这些文档转换为HTML格式，才能利用HtmlRAG方法的优势，例如，LaTeX文档通过LaTeXML工具转换为HTMLWord文档可以通过Microsoft Word或其他办公软件转换为HTML。这个处理速度也并不快。
四、GraphRAG微软版本更新0.4.0，引入DRIFT推理
先回顾下GraphRAG微软的实现过程，两个场景。
全局搜索（Global search）处理跨越整个数据集的查询。这种场景综合了来自不同底层来源的信息，以回答需要对整个语料库有广泛理解的查询。例如，在一个关于科技公司研究努力的的数据集中，一个全局查询可能是：“过去五年中，在多个组织中出现了哪些AI研究趋势？”虽然连接分散信息很有效，但全局搜索可能是资源密集型的。
局部搜索（Local search）针对目标查询进行了优化，从与用户输入紧密匹配的文件的一个小子集中提取信息。当答案位于少数文本单元中时，这种模式效果最好。例如，一个查询询问：“微软的Cosmos DB团队在10月4日发布的新功能和集成有哪些？”
最近，GraphRAG微软版本更新0.4.0，引入DRIFT推理（https://github.com/microsoft/graphrag/releases/tag/v0.4.0，https://github.com/KylinMountain/graphrag-server，http://uncharted.software/，https://github.com/microsoft/graphrag），回顾下，GraphRAG有两个主要组成部分，一个是索引引擎，一个是查询引擎，索引引擎将文档分解成更小的块，将它们转换成包含实体和关系的知识图谱。然后它在图中识别社区，并生成摘要，或称为“社区报告”以代表全局数据结构。
其中的重点模块是graph reasoning query module(https://www.microsoft.com/en-us/research/blog/introducing-drift-search-combining-global-and-local-search-methods-to-improve-quality-and-efficiency)，其核心叫做：DRIFT Search: A step-by-step process，一步步来，可以自行体会下。
一个完整的DRIFT搜索层次结构如上，三个阶段。
A (Primer)：当用户提交查询时，将其与最相关的K个社区报告进行比较。这会产生一个初始答案以及几个后续问题，这些问题作为全局搜索的轻量级版本。为此，使用假设文档嵌入（HyDE）扩展查询，以增加敏感性（召回率），嵌入查询，与所有社区报告对照查询，选择顶部K个，然后使用这些顶部K个尝试回答查询。
B (Follow-Up)：使用局部搜索来精炼查询，产生额外的中间答案和后续问题，增强特定性，这里默认迭代两次。
C (Output Hierarchy)：最终输出是一个按相关性排名的问题和答案的层次结构，使结果具有适应性和全面性。
总的来说，DRIFT推理，这个是在检索阶段做的一个优化，但效率可能会降低，因为额引入了迭代搜索，但看其效果还不错：
总结
本文主要讲了4个问题，分别是关于RAG中的分块策略对比回顾、大模型生成策略，在大模型中增加输出多样性、RAG的chunk表示：HTML比纯文本更适合用于RAG系统中建模检索到的知识、GraphRAG微软版本更新0.4.0，引入DRIFT推理，都是围绕RAG来做的，可以对应到建库、召回以及生成等阶段，都是trick。
当然，trick固然很多，但我们需要找到对应合适的场景来应用它们，各位可以多思考。
参考文献
1、https://arxiv.org/pdf/2410.13070
2、https://arxiv.org/pdf/2411.02989
3、https://arxiv.org/pdf/2411.02959
关于我们
老刘，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。
对大模型&知识图谱&RAG&文档理解感兴趣，并对每日早报、老刘说NLP历史线上分享、心得交流等感兴趣的，欢迎加入社区，社区持续纳新。
加入会员方式：关注公众号，在后台菜单栏中点击会员社区->会员入群加入
