网站建设费用选择网络专业中国站长之家

网站建设费用选择网络专业,中国站长之家,做全球视频网站赚钱吗,企业信息发布系统各种关于RAG的解读文章中#xff0c;留言区一定会看到这样一个问题#xff0c;chunk大小到底怎么选#xff1f;为什么选XX尺寸chunk#xff1f;选小了#xff0c;细节足够丰富#xff0c;但上下文直接断裂#xff1b;选大了#xff0c;全局语义没问题#xff0c;可具体…各种关于RAG的解读文章中留言区一定会看到这样一个问题chunk大小到底怎么选为什么选XX尺寸chunk选小了细节足够丰富但上下文直接断裂选大了全局语义没问题可具体的关键事实又被忽略。近期被英伟达开出 20~30 亿美金收购意向的以色列 AI 公司 AI21 Labs发布了一篇关于 RAG 分块的重磅研究《Chunk size is query-dependent: a simple multi-scale approach to RAG retrieval》。在这篇文章中作者提出chunk大小从来没有通用最优解而是和查询强相关。文中作者还给出了一套多尺寸chunk方案无需重训模型就能让 RAG 检索性能提升 1%~37%部分数据集甚至能达到 20%~40% 的性能天花板。接下来我们就来拆解这份研究的核心内容看看多尺寸chunk方案到底怎么做。01不存在标准chunk大小准确率与提问强相关过去我们一般默认chunk的最优区间是500-800token因为它正好对应一段话的长度可以做到细节与语义的兼顾。这个结论没错但是问题是真的存在能适配所有查询的单一chunk大小吗答案是否定的。AI21 用多个数据集和不同chunk尺寸做了检索性能测试发现了一个规律即便是查询同一语料库不同提问对应的最优chunk大小也天差地别比如事实型查询用 100token 的小chunk才能精准命中有的理解型查询只有 500token 以上的大chunk才能匹配到关键上下文。比如沃尔沃做企业知识库理解型内容更多就用了大chunk但Open claw通用任务多就用了一刀切的500 token chunk。当然以上只是习惯性经验AI21还做了参照实验选了三个类型差异极大的数据集覆盖了不同的文本形式和查询类型保证实验结果的普适性QMSum会议转录文本文档平均 5000token信息分散在不同发言者和主题查询多是具体的讨论点NarrativeQA长篇故事和书籍章节查询需要理解不同粒度的关联情节考验上下文理解能力宋飞正传自定义数据集电视剧转录文本的趣味问答同时测试具体事实和全局上下文的检索能力。针对每个语料库他们分别对其按照 50、100、200、500、1000、2000token 进行切块并检索其top K。最终结果如下最优chunk大小会随查询的变化而变化。不存在占绝对优势的chunk大小适用于某一查询的chunk大小往往无法适配另一查询。最优性能相比任何固定尺寸chunk都有20%~30%的准确率优势部分数据集甚至超过40%。以上结论在不同的文本类型中均成立。也就是说放弃固定尺寸chunk为不同查询匹配最优chunk是提升 RAG 性能的关键方向。当然业内早就有研究者意识到了固定尺寸chunk的问题也提出过不少优化方案比如Anthropic 的上下文检索会给chunk补充文档级的上下文信息弥补小尺寸chunk的上下文缺失Jina AI 的Late Chunking则采用先embedding后chunk的方式为每个小chunk带上包含丰富上下文信息的向量表示序列RAPTOR 算法则在固定尺寸chunk的基础上构建分层摘要用摘要来串联零散的小chunk。但这些方法仍未脱离固定尺寸chunk大小的框架还增加了模型的复杂度有些方法甚至需要重新训练embedding模型或者需要LLM生成新的上下文可能引入噪声。相比之下AI21 的研究走了一条更简单的路不改变chunk的基础逻辑只是在数据处理阶段采用了多尺寸的chunk方式。02如何构建多尺寸chunk并对索引结果排序这套方案的核心思路很简单预处理时做多个尺寸的chunk并为其建索引推理时并行查询所有索引最后用倒数排名融合RRF 整合所有查询结果得到最终文档排名。这里有几个细节值得讨论一下。首先是为什么用 RRF 做排名聚合而不是直接对比相似度分数对比。因为不同chunk大小的相似度分数没有可比性。小chunk的embedding更聚焦相似度分数可能偏高大chunk的embedding更泛化分数可能偏低直接加总毫无意义。而 RRF 是一种模型无关的排名聚合方法它不看绝对的相似度分数只看chunk的排名位置排名越靠前投票权重越高还不用在不同索引间做分数校准简单又高效。它的得分计算公式也很直观文档的最终得分是所有尺寸下其chunk的排名权重之和排名越靠前权重越大。其中为chunk大小的集合如为chunk大小下文档被检索到的chunk集合为chunk在chunk大小为时对应索引中的排名排名越靠前投票权重越高。简单来说这个公式会更偏向于那些被多次检索到的文档要么在某个尺寸下多次上榜要么在多个尺寸下都能被找到。03结果测评为了验证这套方案的实际效果AI21 在多个基准数据集上做了测试选用了 intfloat-multilingual-e5-small、nomic-embed-text-v1 两款常用的开源embedding模型对比了固定尺寸chunk索引 和多尺寸索引 RRF的效果。最终结果显示在 MTEB 检索任务子集中8 种模型配置里有 7 种多尺寸方案都优于传统的固定chunk方案。虽然提升只有 1%~3%但在成熟的检索基准测试中SOTA 模型之间的差距往往也只有百分之零点几。而在 TRECCOVID 数据集上这套方案直接实现了36.7% 的效果提升这也说明查询类型越多样、文档结构越复杂的数据集从多尺寸chunk中获得的收益就越大。而在FinanceBench、NarrativeQA、QMSum和《宋飞正传》数据集上结果也呈现出一致的趋势多尺寸chunk方案的性能更优且无限接近SOTA结果。04延伸解读这套方案的核心价值不在于多复杂的模型设计而在于重新思考了文本表示和检索结果的聚合方式不用换模型、不用重训embedding、不用加规则仅通过多尺寸chunk和简单的排名聚合就能实现和更换嵌入模型相当的性能提升这对于广大做 RAG 工程落地的同学来说是极具参考价值的。当然AI21 的这套方案并非完美。它最大的局限在于引入多尺寸chunk需要embedding和存储的chunk数量会增加2~5倍对于一些成本敏感型场景并不适用。与此同时相比单一索引查询它的推理耗时会明显变长对低延迟要求的实时场景不友好。另外这套方案做的还是基于不同固定尺寸的硬切分依然会存在跨分块的语义割裂比如一个完整的段落被切到两个chunk里影响检索效果。目前行业的研究和实践主要朝着自适应、分层、查询感知几个方向发展这些方案也各有侧重适配不同的场景语义自适应chunk这是目前最主流的优化方向摒弃固定滑动窗口基于文本的语义边界做chunk比如按段落、句子、主题切分用 LLM 或embedding模型判断文本的语义连贯性避免硬切分带来的语义割裂。分层chunk检索在 RAPTOR 分层摘要的基础上升级将文本切分为细粒度块 粗粒度块粗粒度块包含细粒度块的主题摘要检索时先查粗粒度块快速定位文档范围再查细粒度块找精准信息平衡了上下文和细节还降低了多尺度索引的成本。基于查询判断的动态chunk结合 AI21 的多尺度思想在推理阶段先通过轻量分类器判断查询类型事实型 / 理解型 / 推理型再针对性地查询部分尺度的索引既保留了多尺度的匹配性又减少了无效的索引查询大幅降低检索延迟混合chunk策略将语义chunk和多尺寸chunk结合先做语义chunk保证文本的语义完整性再对每个语义块做小尺度的细切分兼顾语义完整和多尺度的查询匹配性解决了滑动窗口硬切分的语义割裂问题是目前工程落地的优选方案之一基于既定chunk方式的工程化优化在现有chunk基础上做工程层面的优化比如为chunk添加位置、主题、来源等元数据检索时结合元数据过滤无效chunk或者利用向量库的分区索引、混合索引功能优化多尺度索引的存储和检索效率降低成本。阅读推荐 拆解OpenClaw就是agent记忆的最佳范式其逻辑与RAG有何区别 自动驾驶百亿向量全球GPU龙头如何用Milvus加速模型训练 高效索引之HNSW_SQ如何同时兼顾RAG的速度、召回率与成本 Spark做ETL与Ray/Daft做特征工程的区别在哪里如何选型 都有混合检索与智能路由了谁还在给RAG赛博哭坟