核心内容摘要
内容访问工具：信息获取技术的原理与应用解析
在AI大模型爆发的当下检索增强生成RAG早已不是什么新鲜概念。
无论是智能客服自动解答用户疑问还是学术研究者快速梳理文献要点亦或是企业搭建内部知识库助手RAG技术都在背后发挥着关键作用。
我们常说RAG的核心是“检索生成”大家也都在拼命卷检索模型的召回率想让模型更快更准地找到相关信息同时也在优化生成模型的流畅度和准确性力求输出的内容既专业又易懂。
但很多人都忽略了一个藏在流程最前端的关键环节那就是文档分块。
可能有人觉得分块不就是把长文档切成一小块一小块吗这有什么技术含量。
但实际落地过RAG项目的人都知道分块环节直接决定了后续检索和生成的效果上限。
就像我们做饭食材处理得好不好直接影响最终的菜品口感。
如果食材切得大小不一要么煮不熟要么煮烂同理文档分块如果做得不好后续再强的检索模型和生成模型也很难输出令人满意的结果。
今天我们就来深度聊聊分块这个“隐藏王者”重点解析一款融合了Small2big思想和语义分块的创新方案——LGMGCLogits-Guided Multi-Granular Chunker看看它是如何解决传统分块的痛点让分块从“机械切割”升级为“智能拆分”的。
在聊LGMGC之前我们先静下心来想想为什么分块值得我们花这么多心思去研究。
毕竟在RAG的整个流程里分块似乎是最“不起眼”的一步但恰恰是这一步埋下了很多隐患。
我们都清楚RAG的基本流程分块→检索→生成。
先把动辄几万字甚至几十万字的长文档切割成一个个大小合适的块然后当用户提出问题时检索模块从这些块里找出和问题最相关的部分最后把这些相关块作为上下文喂给大模型让模型基于这些信息生成答案。
这个流程看似简单但分块环节的一点点偏差都会在后续环节被无限放大。
传统分块方法最大的问题就是粒度不合理。
要么是切得太碎把完整的语义单元拆得支离破碎。
比如一句话“人工智能技术的快速发展给医疗行业带来了革命性的变化”如果被硬生生拆成“人工智能技术的快速发展”和“给医疗行业带来了革命性的变化”那么检索时模型单独看到其中任何一部分都很难理解完整的语义更别说精准匹配用户的问题了。
这种情况在处理叙事类文本或者学术论文时尤为明显一段文字里的逻辑连贯性被破坏后后续的检索和生成都会变成“无的放矢”。
要么就是切得太大一个块里包含了大量无关信息。
比如把一整篇学术论文的一个章节直接当成一个块里面可能包含了研究背景、实验方法、实验结果、结论等多个部分。
当用户只想了解其中的实验结果时检索模型不得不从这个庞大的块里“大海捞针”不仅检索效率低还很容易把无关的信息也带进来导致大模型生成的答案冗余、不准确。
这种情况在企业知识库场景中很常见很多企业的文档都是长篇大论的规章制度或项目报告粗放式的分块会让RAG系统的实用价值大打折扣。
除了粒度问题现有分块方法还面临着“效果”和“成本”的两难抉择。
早期的递归分块是最粗放的方式完全不考虑语义只按照固定的字符长度或单词数量来切割文档。
这种方法的优点是简单、高效、成本低但缺点也很明显就是语义连贯性极差很容易出现我们上面说的“切得太碎”或“切得太大”的问题完全无法满足高精度RAG场景的需求。
后来出现了语义分块方法比如基于句子嵌入距离的分块通过计算句子之间的语义相似度来判断哪里是合适的分割点。
这种方法比递归分块要智能得多能够在一定程度上保证语义的完整性但也存在明显的短板。
比如在寻找最优分割点时往往需要进行大量的计算和迭代而且对于不同类型的文本适配性也参差不齐有时候还是会出现语义边界判断不准的情况。
再到后来有人提出用大模型直接进行分块通过给大模型喂入提示词让大模型自主判断文档的语义边界然后输出合适的块。
这种方法的效果确实好几乎能完美保证语义的完整性分块质量远超传统方法。
但问题也随之而来这种方式需要反复调用大模型的API每调用一次都要花费一定的费用对于需要处理大量文档的企业来说长期下来成本非常高昂。
而且反复调用API还会导致处理速度变慢同时企业的核心文档数据需要传给第三方API还存在数据安全泄露的风险这也是很多企业在落地时非常顾虑的一点。
所以说一个好的分块方法必须要做到“语义完整粒度灵活”。
既要保证每个块都是一个完整的语义单元不被随意拆分又要能够根据不同用户的问题需求提供不同大小的块用于检索和生成。
检索时需要更精细的小块这样才能精准定位到答案所在的位置生成时则需要更完整的大块这样才能为模型提供充足的上下文信息让生成的答案更连贯、更全面。
而LGMGC的核心目标就是解决这个“语义完整”和“粒度灵活”的矛盾用一种简单、高效、低成本的方式实现分块效果的升级。
那么LGMGC到底是如何实现“智能分块”的呢其实它的核心思路非常清晰简单来说就是“先合后分”先通过语义分块得到“语义完整的父块”再把父块拆成“多粒度的子块”通过这两个步骤的结合既保证了语义的连贯性又兼顾了检索的灵活性。
整个框架主要包含两个关键模块这两个模块相互配合形成了112的效果。
第一个模块是Logits-Guided Chunker核心作用是利用小模型的语义理解能力切出语义完整的父块。
这里可能有人会问Logits是什么其实不用把它想得太复杂简单来说Logits就是大模型在预测下一个token字符或单词时输出的概率信息。
比如模型在处理一句话的末尾时会预测下一个token是句子结束标记[EOS]的概率这个概率越高就说明模型认为这句话已经说完了语义是完整的。
LGMGC正是利用了模型的这一特性来精准判断文档的语义边界。
具体来说这个模块的操作流程分为三步。
第一步先对原始文档进行初步处理用递归分块的方式把文档切成固定大小比如θ个单词的初始块。
这一步的目的是为了避免一开始就处理过长的文本提高后续处理的效率相当于先给文档做一个“粗加工”。
第二步给每个初始块添加一个简单的提示词比如“请基于前面的句子继续写作”然后把这个带有提示词的初始块输入到预训练的小模型中让模型进行一次前向传播计算出每个句子末尾出现[EOS]标记的概率p[EOS]。
这里的关键是“只做一次前向传播”不需要让模型输出完整的分块结果只需要获取它的Logits信息就行这样就大大降低了计算成本和时间成本。
第三步从计算出的p[EOS]中选择概率最高的位置作为分割点分割点前面的文本就是一个“父块”这个父块保证了语义的完整性。
然后把分割点后面剩下的内容和下一个初始块拼接在一起重复上面的步骤直到整个文档都被处理完得到一系列语义完整的父块。
这个模块的优势非常突出。
首先它的语义边界判断非常精准因为它是基于模型对文本的理解来判断的而不是像传统方法那样基于固定长度或简单的语义相似度。
其次它的成本非常低只需要调用一次小模型的前向传播不需要反复调用API而且小模型本身的部署成本也很低支持本地部署完美解决了大模型分块成本高、数据安全风险大的问题。
最后它的处理速度很快一次前向传播就能完成一个初始块的处理效率远超需要反复迭代的语义分块方法。
第二个模块是Multi-Granular Chunker核心作用是借鉴Small2big的思想把父块拆成多粒度的子块适配不同的查询需求。
Small2big是近年来在RAG领域非常流行的一种思路核心逻辑就是“检索用小块生成用大块”。
检索时小块的精度更高能够精准定位到和问题最相关的信息生成时大块的上下文更完整能够让模型更好地理解信息之间的逻辑关系生成更连贯、更全面的答案。
LGMGC的这个模块就是把这个思路落到了实处。
这个模块的操作非常直观主要分为两步。
第一步对第一步得到的父块进行递归拆分。
假设父块的大小是θ个单词那么就把它拆成θ/
θ/4大小的子块以此类推而且在拆分的过程中会严格保证句子不被拆分确保每个子块的语义也是完整的。
比如父块的大小是400个单词那么拆分后就会得到200个单词、100个单词大小的子块这些子块都是从父块中拆分出来的语义上既独立又连贯。
第二步在推理阶段父块的相似度得分由它所有子块包括父块本身的最高得分决定。
比如一个父块拆分成了200个单词和100个单词两个级别的子块那么在检索时会分别计算这个父块以及它的所有子块和用户问题的相似度然后取其中的最高得分作为这个父块的最终得分。
最后根据得分高低选择前k个父块传给大模型生成答案。
这种多粒度的设计让LGMGC能够完美适配RAG的“检索生成”全流程。
在检索阶段通过小块的高精度匹配快速找到和问题最相关的信息在生成阶段通过父块的完整上下文为模型提供充足的信息支撑让生成的答案既精准又连贯。
而且这种设计还能提高RAG系统的鲁棒性不管用户的问题是宽泛的还是具体的都能找到合适的块来匹配避免了单一粒度分块在面对不同类型问题时的局限性。
把这两个模块结合起来就是LGMGC的整体流程。
先通过Logits-Guided Chunker对文档进行“精加工”生成一系列语义完整的父块再通过Multi-Granular Chunker对父块进行“细拆分”生成不同粒度的子块最后在推理阶段结合子块的高精度检索和父块的完整上下文生成实现RAG效果的最大化。
这种“先合后分”的思路既解决了传统分块语义不连贯的问题又解决了单一粒度适配性差的问题堪称分块环节的“最优解”之一。
当然任何技术方案的好坏都需要通过实验来验证。
LGMGC的论文中用了两个主流数据集、多种基线方法做了对比实验结果非常有说服力。
我们不妨结合实验结果看看LGMGC到底有多“能打”。
首先来看实验的基础设置。
论文选择了两个具有代表性的数据集分别用于测试检索性能和问答性能。
其中检索性能测试用的是GutenQA数据集这个数据集被称为“大海捞针”型数据集每个问题的答案只存在于
句话中非常考验分块的精准性只要分块稍微有一点偏差就很难检索到正确的答案。
问答性能测试用的是LongBench的3个单文档数据集分别是NarrativeQA、MultifieldQA、QasperQA这三个数据集涵盖了叙事文本、多领域文本、学术论文等多种常见场景都是实际应用中经常遇到的抽取式问答场景测试结果的实用性很强。
评估指标方面检索性能主要用了DCGk和Recallk两个指标。
DCGk衡量的是检索结果的相关性和排名得分越高说明检索出来的结果不仅相关而且排名越靠前Recallk衡量的是检索系统能不能找到相关的证据得分越高说明漏检的概率越低。
问答性能主要用了F1分数这个指标衡量的是预测答案和真实答案的匹配度得分越高说明生成的答案越准确。
基线方法方面论文选择了目前主流的几种分块方法包括递归分块、语义分块、段落级分块、LumberChunker现有大模型分块方法的代表同时还加入了LGMGC的两个子模块LG Chunker、MG Chunker进行消融实验以此来验证两个模块的有效性。
关键参数方面所有方法都测试了
200、
500个单词三种常见的块大小保证了实验的公平性。
而且LGMGC用的是8位量化的Llama
b模型这种模型属于轻量化模型部署成本很低非常适合企业实际落地使用。
从实验结果来看LGMGC的表现可以说是“全面碾压”基线方法不管是检索性能还是问答性能都处于领先水平。
我们先看检索性能的测试结果也就是GutenQA数据集上的表现。
首先LG Chunker单模块的表现就非常亮眼。
不管块大小是
300还是500个单词LG Chunker的DCGk和Recallk分数都远超递归分块、语义分块和段落级分块这三种传统方法。
这说明用Logits信息来判断语义边界的思路是完全可行的而且效果非常好比传统的分块方法更能精准地找到语义完整的块。
然后我们把LG Chunker和LumberChunker做对比。
LumberChunker是现有大模型分块方法的代表效果已经非常出色。
从实验结果来看LumberChunker在部分指标上略高于LG Chunker但两者的差距非常小。
而LG Chunker的优势在于成本和部署难度LumberChunker需要反复调用大模型API成本高、速度慢还存在数据安全风险而LG Chunker只需要一次前向传播成本低、速度快还支持本地部署对于企业来说实用性要高得多。
再看MG Chunker单模块的表现多粒度分块的优势非常明显。
MG Chunker的得分比传统分块方法高很多这说明多粒度的设计确实能够提高检索的灵活性和精准性让检索系统能够更好地适配不同的问题需求。
最后是LGMGC融合后的表现它在所有指标上都拿到了最好的成绩实现了“登顶”。
而且更重要的是LGMGC的标准差最小这说明不管块大小怎么变化它的性能都非常稳定不需要用户花大量的时间去调优超参数。
这一点对于实际落地来说非常重要很多传统分块方法对块大小非常敏感块大小稍微调整一下性能就会出现很大的波动用户需要反复测试才能找到合适的块大小而LGMGC则完美解决了这个问题。
除了检索性能问答性能的测试结果更能体现LGMGC的实际价值。
LongBench数据集的测试结果进一步证明了LGMGC的优势主要体现在两个方面。
第一用RAG流程比直接喂整个文档效果好得多。
把文档分块后进行检索再生成比直接把整个文档截断后喂给大模型的F1分数高很多这也从侧面印证了分块环节的重要性好的分块能够为后续的生成环节提供高质量的“素材”让模型更容易找到准确的答案。
第二LGMGC在全场景下都表现最优。
不管是用BGE-Large还是E5-Large作为检索器不管是用Llama
b还是Llama
b作为生成器LGMGC的F1分数都是最高的。
这说明LGMGC的分块效果具有很强的通用性不管搭配哪种检索器和生成器都能发挥出很好的效果不会因为依赖特定的模型而限制其应用场景。
结合实验结果和个人在RAG落地过程中的实际体验我认为LGMGC的
核心价值在于它抓住了RAG分块的核心矛盾并用简单高效的方式解决了它。
它的优势可以
总结为四个方面每一个方面都切中了实际落地中的痛点。
第一个优势是语义连贯性强。
通过Logits信息判断语义边界能够精准识别文档中的完整语义单元避免了传统分块方法把句子拆碎的问题。
在实际应用中这一点非常重要比如处理学术论文时LGMGC能够精准地把一个实验方法、一个实验结果拆分成独立的父块检索时能够快速定位到相关的内容生成的答案也更准确、更连贯。
第二个优势是粒度适配性好。
多粒度子块的设计让LGMGC能够完美适配RAG的“检索生成”全流程检索时用小块保证精度生成时用大块保证上下文完整。
在实际落地中用户的问题需求是多样化的有的用户需要精准的答案有的用户需要全面的解释LGMGC能够根据不同的需求自动匹配合适的块粒度提高了RAG系统的用户体验。
第三个优势是部署成本低。
LGMGC采用的是轻量化的小模型支持本地部署不需要反复调用大模型API既降低了成本又保证了数据安全。
对于中小企业来说这一点尤为重要很多中小企业因为成本和数据安全的顾虑不敢轻易尝试RAG技术而LGMGC的出现为它们提供了一个低成本、高安全的分块解决方案让RAG技术的落地门槛大大降低。
第四个优势是性能稳定。
LGMGC对块大小不敏感不管块大小是
300还是500个单词性能都非常稳定不需要用户花大量的时间去调优超参数。
在实际落地中这能够大大提高项目的推进效率减少不必要的测试和调试工作让技术人员能够把更多的精力放在检索和生成模块的优化上。
正是因为这些优势LGMGC的适用场景非常广泛。
不管是处理叙事类文本比如小说、故事、新闻报道还是处理学术类文本比如论文、研究报告亦或是处理企业类文本比如规章制度、项目文档、客服话术只要是需要抽取式问答的RAG场景LGMGC都能派上用场。
比如在智能客服场景中LGMGC能够把客服话术文档拆分成语义完整的块当用户提出问题时快速检索到相关的话术生成准确的回复在学术研究场景中LGMGC能够把大量的文献拆分成不同粒度的块研究者可以快速定位到相关的研究方法、实验结果提高文献阅读和研究的效率在企业知识库场景中LGMGC能够把企业的规章制度、项目文档拆分成易于检索的块员工可以快速找到自己需要的信息提高工作效率。
当然我们也要客观地看待LGMGC的不足不能把它神化。
从个人的实际实践来看如果单纯追求极致的分块效果LumberChunker这类纯大模型驱动的语义分块方法效果会略胜一筹。
因为这类方法是让大模型直接理解整个文档的语义然后进行分块能够处理一些更复杂的语义场景比如多段落之间的逻辑关联、跨句子的语义衔接等。
但随之而来的是更高的API调用成本、更长的处理耗时以及数据安全方面的风险。
所以在实际落地时我们需要根据自己的需求做取舍如果追求极致效果并且不介意成本和数据安全风险那么可以选择纯大模型分块方法如果追求“效果成本安全”的平衡那么LGMGC无疑是更好的选择。
除了LGMGC本身还有一个值得我们关注的问题那就是分块效果的自动评估。
目前行业内还缺乏统一的分块效果评估标准很多时候我们都是通过下游的检索性能和问答性能来间接评估分块效果比如看DCGk、Recallk、F1分数等指标的变化。
但这种间接评估的方式很难精准地定位分块环节的问题比如到底是语义边界判断不准还是粒度设计不合理导致了下游性能的下降。
而且不同的数据集、不同的应用场景对分块效果的要求也不同很难用一套统一的指标来衡量所有场景下的分块效果。
结合互联网领域的相关研究和实践目前有一些初步的分块效果评估思路。
比如从语义完整性、粒度合理性、检索适配性三个维度来构建评估体系。
语义完整性可以通过计算块内句子的语义相似度、判断块是否包含完整的语义单元来评估粒度合理性可以通过分析块的大小分布、判断块是否存在过大或过小的情况来评估检索适配性可以通过分析块与查询的匹配度、判断块是否能够支撑精准检索来评估。
当然这些思路还处于初步阶段还需要进一步的研究和实践来完善。
后续我也会专门整理相关的研究和实践经验给大家系统介绍如何科学衡量分块质量感兴趣的朋友可以持续关注。
回到RAG技术本身分块作为整个流程的“第一步”其重要性不言而喻。
随着RAG技术的不断发展越来越多的人开始关注分块环节各种创新的分块方法也不断涌现LGMGC只是其中的一个优秀代表。
但无论分块方法如何创新其核心目标始终不变那就是实现“语义完整粒度灵活”为后续的检索和生成环节提供高质量的支撑。
在实际落地RAG项目时我们不能盲目追求新技术、新方法而是要结合自己的实际需求选择最适合的分块方案。
对于大多数企业和开发者来说LGMGC无疑是一个非常值得尝试的选择它不仅效果出色而且成本低、易部署、稳定性强能够快速落地并产生价值。
当然我们也可以在LGMGC的基础上结合自己的应用场景进行优化和改进比如根据文本类型调整块大小、优化提示词提高语义边界判断的精准性等让分块效果更贴合自己的实际需求。
最后我想说的是RAG技术的发展从来不是单一环节的优化而是整个流程的协同升级。
分块、检索、生成这三个环节相互影响、相互制约只有每个环节都做到极致才能实现RAG效果的最大化。
而分块作为整个流程的基础其重要性不容忽视。
希望今天的分享能够让大家对分块环节有更深入的理解也希望LGMGC这种优秀的分块方法能够帮助更多的人解决实际落地中的问题推动RAG技术在更多场景的普及和应用。
未来随着大模型技术的不断进步相信会有更多更优秀的分块方法出现让RAG技术的效果更上一层楼为我们的工作和生活带来更多的便利。