做RAG项目也有一阵子了我觉得文本分片Chunking是整个链路里最容易被低估、也最值得花时间琢磨的环节。不少朋友刚开始接触RAG时注意力全放在Embedding模型选型和向量库调参上结果检索效果不理想翻来覆去改的是prompt最后才发现问题往往出在“喂进去的文本是怎么切开的”这件事上。我甚至遇到过一种情况只在分片策略上做了调整没动任何模型和参数检索命中率就提升了近一倍。今天就把我对文本分片的理解从原理到实操一次讲透。这篇内容主要面向两类人一是准备搭建RAG应用、但还没想清楚文本该如何处理的开发者二是已经在跑RAG系统、检索质量却总差一口气的工程师。我会把分片的“为什么”和“怎么做”都讲清楚包括不同分片策略的原理和适用场景、块大小怎么定、工程落地时会踩哪些坑以及如何设计实验来衡量分片质量。无论你用的是长文本问答、知识库问答还是文档增强生成这篇都能给你一些可以直接照做的思路。1. 为什么分片策略比Embedding模型更难选1.1 先搞清楚一个核心逻辑分片决定了语义检索的基本单元很多人以为RAG检索是先有一个“用户问题”然后去文档库里找相似的段落最后拼给大模型生成答案。这个理解方向没错但忽略了一个关键细节你的向量库里存的不是“整篇文档”而是“切碎后的一个个文本块”。检索系统拿用户问题去匹配的也不是文档本身而是这些块。也就是说分片策略其实决定了系统“看世界”的基本单元。如果你的块切得太大、太粗一个块里塞进了好几个不相关的主题那么当你问其中一个小问题时这个块的向量表示会被其他无关内容的语义“稀释”。打个比方一个块讲了三件事Ask模型算出它的向量时会被三件事的平均语义带偏检索时自然找不到精确答案。反过来切得太细、太碎原本紧密关联的上下文被硬生生拆开模型在看单个块时就像只看到一句话的前半句缺乏足够语境自然也难给出好回答。所以分片本质上是在解决一个矛盾既要保证每个块内部尽量是一个完整、连贯的信息单元又要保证块与块之间的边界恰好落在语义的“天然断点”上。1.2 向量化的特性决定了“块内上下文”的重要性Embedding模型不是逐字逐句独立编码的。以主流Transformer结构为例一个Token在生成向量时会通过自注意力机制参考上下文窗口内其他Token的信息。这意味着一个块的长度、块内内容的连贯性会直接影响这个块最终被编码成什么样。更直白一点说向量化生成的Embedding是“站在块内所有文字的语境下去理解其中每一句话”的结果。同样的“苹果”两个字在一个说水果的段落里和在一个说手机品牌的段落里向量表达完全不一样。分片的目的就是让块内保持尽量单一的语境背景这样才能发挥Embedding模型的真正能力。还有一点容易被忽略Embedding模型通常有最大输入长度限制。超过这个长度的文本要么被截断要么被池化压缩语义信息都会打折。但我也不是建议大家为了“塞进去”就一直把块压小因为你问LLM的问题往往也需要上下文支撑块太小时上下文信息量不够。所以分片不是单纯的“字面切分”而是要替Embedding模型创造“刚好合适”的阅读单元。1.3 分片质量直接决定RAG系统的三项关键指标我们可以把分片质量与最终系统的三项具体表现对应起来看检索命中率如果答案分散在两个相邻块里检索过程可能只捞到其中一个块另一个相关块因为边界问题没被匹配上命中率直接下降。生成忠实度即便找到了相关块如果这个块本身信息残缺或包含过多噪音大模型在生成时就会“脑补”缺失内容出现幻觉或事实性错误。召回效率块越大、越碎向量库中的条数越多检索时的计算开销和延迟自然增加。一个合理的分片策略能让系统用更少的向量条数覆盖更多的有效语义。我记得有一次做知识库问答客户反馈说“问不到精确数字”。排查时发现文档里有一张表格被统一硬切成了若干固定长度块同一行数据被切到了两个块里检索时匹配到的是“标题栏前几列”数字信息丢了。后来把表格区域作为一个独立语义块处理问题立刻缓解。这就是分片质量对实际效果影响最直观的体现。2. 分片策略的核心框架语义边界、块大小与overlap的博弈2.1 语义边界什么样的地方适合作为切开点文本里天然存在一些“语义断点”找对这些断点分片就成功了一大半。常见的断点包括段落结束段落通常是作者表达一个完整意思的基本单元。章节标题前后新章节意味着话题切换非常适合切分。列表项之间每个列表项往往是一条独立信息。换行密集处很多时候连续的换行意味着内容的主题或语境发生了变化。不过要提醒一句很多PDF转出来的文本、扫描件识别出的内容段落并不是靠“空行”体现的往往是连续的一长串文字只有换行符而无空行。这种情况下对段落边界的判断就不能只依赖“空行”这一个信号而要靠标点符号、句子长度、主题连贯度等因素综合判断。2.2 块大小Chunk Size不是拍脑袋出来的块大小通常用“Token数”来标识因为向量模型和LLM都以Token为基本单位。我见过不少朋友直接用固定字符数比如“每500个字切一块”这其实是把“字”和“Token”混为一谈了。同样500个字英文可能对应600到700个Token中文可能是700到800个Token这直接影响了向量模型是否能完整编码。块大小没有一个万能值它取决于四个因素Embedding模型的输入上限比如某模型支持512或1024 Token块大小不能超过这个上限。内容本身的重复度与复杂度如果文档专业术语密集、逻辑环环相扣建议稍大一些如果是常见生活化内容稍小也能接受。下游生成模型的上下文窗口最终拼接给生成模型的内容越多越要考虑总成本块太大会导致一次请求的Token数量失控。检索测试的实际反馈这一点最重要。块大小应该由实验数据来定而不是拍脑袋。你先设一个初始值跑一批问题集看命中率和答案质量的变化。2.3 Overlap重叠的作用与代价重叠的意思是相邻两个块之间会保留一部分共用的文本。比如块1覆盖文本1到400块2覆盖文本351到750那351到400这一段就被两个块共同承保了。表面上看重叠浪费了一些存储空间但它能解决一个非常实际的问题避免一个完整的信息单元比如一句承上启下的关键句恰好落在块的边界上导致检索时它的后半段“跑”到上一个块里去了。重叠的另一个好处是即使查询点落在两个块的边界附近系统也能在至少一个块内看到完整的语境。缺点也很明显存储成本增加向量条数不变但每个块的Token量变大。检索时可能同时命中多个高度相似的块导致去重和排序变复杂。生成阶段如果多个块都包含同一段文本模型看到的上下文会有重复浪费Token。我的习惯是重叠部分一般控制在块大小的10%到20%之间。如果块大小是400 Token重叠可以设为40到80 Token再大往往收益降低。实际项目中可以调几次对比效果不要有洁癖。3. 六类常见分片策略的横向对比与选型思路3.1 固定长度分片最简单的方案也是最容易翻车的方案固定长度分片就是按固定Token数或字符数硬切完全不考虑文本结构。这种方案实现成本最低适合在快速原型阶段跑通流程时用。但如果文档结构复杂固定长度经常会把一句话、一个公式、一个表格拦腰砍断导致检索质量很不稳定。我做原型验证时用过这种方案结果发现只要切到代码片段、公式或中英文混合内容问题就特别多检索到的块经常是“半句话”。所以这个方案只适合当作基线不能当主力。3.2 递归字符分片目前最实用的通用方案递归字符分片是目前工程上最常用的通用方案。它的核心思想是按一组分隔符依次尝试切分如果当前切分结果仍然超过目标块大小就换用更小的分隔符继续切。比如一套典型的分隔符序列是“\n\n\n”、“\n\n”、“\n”、“。”、“\n”。意思是先按多个空行切大段落如果大段落还是太长再按单空行、按句子标点、按换行符逐级下探。这样做的好处是文本尽量保持自然段落结构每个块内部的语义完整性明显好于固定长度切分。这一策略几乎是目前做通用RAG的首选。选分隔符的顺序也有讲究通常把“段落级”的分隔符放在前面把“句子级”的分隔符放在后面这样切出来的块首先会尊重原文的结构层次。3.3 Sentence Level 分片适合需要精确引用的场景按句子切分的方案比固定长度聪明不少它能把每个句子作为独立单元特别适合法律条款、合同条款这类句子意思高度独立的文档。这类文档里一句话就是一个完整条款检索时只需要把相关条款捞出来即可过多上下文反而会干扰。不过纯按句子切分也有明显缺陷文档里很多信息是一几句话加几个解释句组合在一起的单独抽出一句可能丢失必要的限定条件。所以完整方案一般不是“只按句号切”而是按“句子聚类”或者“滑动窗口句组”来切比如一次取两到三个连续句子构成块必要时让相邻句组有重叠兼顾语义完整性和定位精度。3.4 语义分片Semantic Chunking算法更先进但要谨慎使用语义分片不依靠原文的显式结构而是先计算相邻句子或段落之间的语义距离再寻找“语义突变点”作为块的边界。实现上通常先把文本拆成句子列表用Embedding模型给每个句子编码然后计算相邻句子向量的余弦距离。距离比较大的地方意味着前后两句语义差异明显这就是可能的边界。这种方案的优点是块边界贴近“语义聚落”理论上效果最好。但实际工程中它有三个隐患语义距离阈值不好定不同的文档类型、不同领域阈值往往不一样。计算成本高需要额外调用Embedding模型处理每一个候选句子比递归字符分片贵。不可复现性有些实现依赖于局部距离的浮动稍微调整输入就可能改变边界。我的建议是如果文档内容高度结构化、且原始结构标记很清晰语义分片不如直接用结构分片如果文档是小说、混排内容这类无明显结构的文本语义分片可以考虑但也一定要先做成本测算。3.5 面向结构的感知分片充分利用文档自带的标记很多文档本身自带结构信息Markdown的标题层级、HTML的标签、LaTeX的章节命令、代码的缩进层级、PPT的页面边界等。面向结构的分片就是把这类标记当作天然切分点。以Markdown为例可以先按一级标题分再按二级标题分如此类推直到每个块的Token量控制在目标范围内。这种方案的核心优势是语义边界几乎不需要猜测标题本身就是作者给的“答案”检索时还能用标题作为块的上下文提示。具体实现时可以把标题信息存成块的元数据。比如一个块的正文来自某个二级标题下的段落我们就把“二级标题文本”和“一级标题文本”一起作为元数据存入向量库。检索时即便命中的块本身很短系统也可以带着标题节点去参与匹配这种“上下文提示”能明显改善检索效果。3.6 基于模型的语义拆分边际收益和成本问题还有一种思路是用短文本摘要模型或语言模型来判断文本边界甚至让模型输出理想的切分方案。效果确实不错但成本也最高因为需要对整篇文档的每个候选切分点都推理一次。除非你的场景特别依赖高质量检索、数据量又可控否则我不建议在通用场景里直接用模型分片。一块文档只有几十KB算下来拆分成本可能比后续检索成本还高性价比很低。下面把这六类策略放在一起直观对比分片策略切分依据优点缺点典型场景固定长度Token/字符数实现简单、速度快破坏语义、切割代码和表格易出错快速原型、基线对比递归字符多层分隔符通用性强、兼顾结构对无结构内容不敏感各类通用文本首选方案句子级句号/语气词检索精度高信息碎片化法律条款、FAQ语义分片相邻Embedding距离理论上最优成本高、阈值难调无明确结构的混合文本结构感知标题/标签/代码缩进语义边界准、可带元数据依赖文档结构完整Markdown、HTML、代码文档模型拆分LLM/摘要模型效果强成本高、延迟高小数据量精品知识库4. Chunk Size与Overlap的调优实验方法4.1 设计一套可控的对比实验分片调参最忌讳凭感觉。正确做法是先准备一个有标准答案的问题集然后在同一套向量库、同一个Embedding模型、同一个检索参数下只改变分片策略和块大小观察指标变化。问题集要贴近真实使用场景建议不少于50条。每道问题对应一个或多个期望命中的文档块这个“标准答案”可以用人工标注来建立。如果你没有人工标注预算至少也要记录“期望包含答案的文档片段”然后判断检索结果是否覆盖。用到的指标主要有三个命中率Hit Rate检索返回的前K个结果中有多少条命中了包含标准答案的块。这个指标最直观也最容易理解。MRRMean Reciprocal Rank考虑命中结果在排序中的位置。如果正确答案排第一记1分排第二记0.5分。它能衡量检索结果排序质量。** faithfulness忠实度/答案一致性**最终生成答案与标准答案的一致性此项由人工或模型打分用来兜底前两个指标无法体现的“内容可用性”。大致流程可以这样组织确定多个候选方案例如递归字符分片块大小取300/500/800 Token重叠取50/80/100 Token组成若干组。依次为每组方案构建向量库索引注意保持文档集、向量模型、检索的TopK完全一致。跑同一批问题分别记录上述三项指标。排序对比选综合表现最好的方案。4.2 一个可参考的Python验证代码思路下面是一段伪代码展示了如何快速测算“命中率”和“MRR”你可以按需改造成本地环境可跑的脚本import numpy as np # chunk_list: 每个分片文档入库时记录的唯一ID或文本 # expected_chunk_ids: 每个query期望命中的chunk ID列表 # retrieved_chunk_ids: 每个query实际检索返回的TopK chunk ID列表 def evaluate(retrieved: list[list[str]], expected: list[list[str]], k5): hit_count 0 mrr_sum 0.0 for ret_list, exp_list in zip(retrieved, expected): exp_set set(exp_list) # 只看前k个结果 ret_k ret_list[:k] hit_flag False for rank, cid in enumerate(ret_k, start1): if cid in exp_set: hit_flag True mrr_sum 1.0 / rank break if hit_flag: hit_count 1 n len(retrieved) hit_rate hit_count / n mrr mrr_sum / n return {hit_rate: hit_rate, mrr: mrr}注意这段代码里的retrieved要确保来源是同一个向量库在不同分片参数下的检索结果而不是不同库之间的混跑结果。4.3 常见实验结论和我的经验参考从我在多个文档集上的实验经验看有几个规律可以作为起点块大小在500到800 Token之间命中率普遍高于300以下的小块原因是块内信息量够用。块超过1000 Token后命中率往往下滑因为语义开始被杂质干扰向量表达不够聚焦。重叠设置对命中率的影响通常小于块大小但会影响排序质量MRR对重叠更敏感。如果你的文档本身就是问答对用句子级分片比用递归字符分片效果好很多。这些规律不是金科玉律但作为第一轮实验的候选参数非常好用。跑完第一轮后你再围绕表现最好的一组参数做细粒度调整比如从500 Token起步分别试450、500、550、600找到峰值的拐点。4.4 别只看检索指标务必看生成质量我提醒过很多同行Hit Rate上去不代表生成答案质量就同步上去。有个典型场景是块大小恰到好处检索命中的块标题、摘要都匹配但块里包含正确答案的句子太靠后实际生成模型读到时已经信息衰减导致回答不够准确。所以调参一定要“检索指标生成答案人工抽检”双轨并行。每次调完参数后固定抽10到20道测试题把检索到的块和生成答案打印出来人工看一遍。这个过程很花时间但非常值得。曾经有一位同事调整分片后看到Hit Rate提升了0.15但人工检查发现生成答案出现了更明显的重复引用现象差点上线后才发现我建议他一定要先跑人工抽检后来果然救了一版。5. 工程落地中容易踩的坑与我的应对思路5.1 元数据必须和分片绑定否则知识库就是“黑盒”分片之后每个块如果只保存“原文文本”和“向量”那么当生成模型引用某个块的信息时你甚至无法追溯它来自哪份文档、哪个章节。工程上一定要给每个块附带元数据常见的元数据包括文档ID和文件名章节标题路径如一级标题/二级标题块在原始文档中的起始位置和结束位置文档来源链接或页码这些元数据可以被检索系统用来构造更丰富的返回结果也可以在生成阶段做引用溯源。我习惯把“标题路径”作为向量检索的前缀拼入文本比如“税法总则 - 纳税人权利 - 第12条”这样即使块内只提到“该条”模型也能从上下文中理解确切指向。5.2 不同文档类型混用时不要强行统一分片参数一个常见错误是一个知识库里既包含合同条款、产品手册、技术支持FAQ还包含长篇文章笔记却用同一组分片参数跑全库。这会导致某些文档检索效果差得离谱。其实合理的做法是按文档类型设定不同分片策略和参数并在元数据里标注“分片策略类型”。检索时让向量库支持按元数据过滤再结合业务场景选择性地检索某一类文档。比如FAQ类内容直接用句子级分片产品手册用结构感知分片长篇文章笔记用递归字符分片效果会好很多。你可以先按文档类型分别做实验再决定是否统一参数。5.3 Overlap并不总是越多越好前面我给出了10%到20%的建议范围但这里要补充一个反例如果你的文档是层层递进的比如数学证明、教程代码重叠设多了检索到的多个块之间会频繁包含同一段解释文字导致生成模型在拼接时出现前后矛盾。因为模型看到两段话都在讲“上一步的结论”会误以为需要强调或者重复最终答案出现冗余信息。所以重叠多少既要看块大小也要看文档的叙事节奏。我在处理连续性很强的技术文档时会故意把重叠压得很低甚至设为零换取检索结果之间的“信息差”让每个块尽量呈现新材料。5.4 处理中英文混合内容时的Token换算问题中文和英文的单位Token差异极大。英文大约4个字符对应1个Token中文大约1个字对应0.6到1.5个Token具体取决于模型和分词方式。如果你按字符设置块大小很容易超出模型上限。我建议所有分片实现都用Token级参数并且在代码里接入模型自带的Token计数函数。另外混合内容最好单独处理。比如一篇介绍API的文档英文代码注释多中文说明多就不能用同一个字符数去切通常我会把代码块和文字段落分开分块后分别管理。5.5 查询端的分片策略也要同步思考很多人只关注“入库端”的分片却忘了检索时查询语句同样会被Embedding模型编码。如果查询很长很乱模型对查询的理解也会被噪音左右。目前的实践对查询端的处理相对成熟入库时怎么切查询时尽量保持相似的粒度和风格。比如入库时每个块是段落级的那么查询最好不要是超长的整篇文章否则检索效果会受影响。如果业务上确实有长查询需求可以尝试“查询重写”先用一个轻量模型把长查询压缩成关键词列表或数条短查询再用短查询分别去检索最后合并去重。这个方法在长段落匹配场景里很有效。5.6 边界情况的处理表格、公式、代码块这三个数据类型可以说是分片界的“老大难”。表格表格行之间通常有紧密的对应关系单独切几行会导致数据断裂。我的方法是把整个表格作为一个块过长的表格再按“行组”切并保留表头信息重写到每个行组块里。公式公式内部的语义不依赖上下文但公式说明文字依赖。建议把“公式块”和“说明文字块”分开存并在说明文字块的元数据里引用公式块ID。代码块不要按行数直接切代码否则一个函数容易断在中间。按照函数、类、导入区块等代码结构来切或至少按空行分效果远好于固定长度切分。如果代码很长可以保留“所在函数名/类名”作为元数据前缀。5.7 长期维护视角分片逻辑和版本管理知识库不是一次性建好的文档会更新分片逻辑也会调整。我踩过的坑是更新了一部分文档后新旧两种分片方案混在一个库里检索结果非常混乱。所以现在我的做法是每次调整分片逻辑都重建新版索引并且保留版本号。线上检索时可以灰度切流让一部分请求走新索引、一部分走旧索引收集真实用户反馈后再全面切换。伪代码上只需要在元数据里增加一个“分片版本号”字段检索时按该字段过滤就行。6. 最后再分享两个我在分片调优中学会的实操技巧第一个技巧不要忽视“标题 首句 尾句”的组合作用。很多情况下一个块即使内容丰富检索匹配时也只依赖其中一两句话的语义如果这一两句话被埋没在大量中间内容里命中率就会下降。你在做一个分片方案时可以试着在向量化之前给每个块创建一个“摘要前缀”把块的标题、关键要点压缩成一小段文本放到块的前面再一起向量化。这相当于给每个检索单元加了一个“快照索引”能显著降低信息被淹没的概率。第二个技巧先把“任务分解”这件事做好再用分片解决“检索单元”。RAG应用中能不能检索到正确答案通常不只看分片也看问题拆得好不好。我的做法是把用户问题拆成几个子问题每个子问题对应检索一类文档最后把结果合并。这样即使某些块检索不到位整体答案也不会断链。分片和查询设计是一对拍档单独调分片而不优化查询并不会让你达到最优效果。回头看我做过的几个RAG项目凡是提前在分片策略上花过心思的后来的调试成本都低很多。分片看起来是链路里最“笨”的一环却承载着整个系统的记忆精度。希望这次分享能让你在自己的项目里少走几步弯路。 
长河君 · 2026/10/19 7:39:37 · 阅读 1.2k RAG文本分片实战：从Chunking策略到调优方法全解析
做RAG项目也有一阵子了我觉得文本分片Chunking是整个链路里最容易被低估、也最值得花时间琢磨的环节。不少朋友刚开始接触RAG时注意力全放在Embedding模型选型和向量库调参上结果检索效果不理想翻来覆去改的是prompt最后才发现问题往往出在“喂进去的文本是怎么切开的”这件事上。我甚至遇到过一种情况只在分片策略上做了调整没动任何模型和参数检索命中率就提升了近一倍。今天就把我对文本分片的理解从原理到实操一次讲透。这篇内容主要面向两类人一是准备搭建RAG应用、但还没想清楚文本该如何处理的开发者二是已经在跑RAG系统、检索质量却总差一口气的工程师。我会把分片的“为什么”和“怎么做”都讲清楚包括不同分片策略的原理和适用场景、块大小怎么定、工程落地时会踩哪些坑以及如何设计实验来衡量分片质量。无论你用的是长文本问答、知识库问答还是文档增强生成这篇都能给你一些可以直接照做的思路。1. 为什么分片策略比Embedding模型更难选1.1 先搞清楚一个核心逻辑分片决定了语义检索的基本单元很多人以为RAG检索是先有一个“用户问题”然后去文档库里找相似的段落最后拼给大模型生成答案。这个理解方向没错但忽略了一个关键细节你的向量库里存的不是“整篇文档”而是“切碎后的一个个文本块”。检索系统拿用户问题去匹配的也不是文档本身而是这些块。也就是说分片策略其实决定了系统“看世界”的基本单元。如果你的块切得太大、太粗一个块里塞进了好几个不相关的主题那么当你问其中一个小问题时这个块的向量表示会被其他无关内容的语义“稀释”。打个比方一个块讲了三件事Ask模型算出它的向量时会被三件事的平均语义带偏检索时自然找不到精确答案。反过来切得太细、太碎原本紧密关联的上下文被硬生生拆开模型在看单个块时就像只看到一句话的前半句缺乏足够语境自然也难给出好回答。所以分片本质上是在解决一个矛盾既要保证每个块内部尽量是一个完整、连贯的信息单元又要保证块与块之间的边界恰好落在语义的“天然断点”上。1.2 向量化的特性决定了“块内上下文”的重要性Embedding模型不是逐字逐句独立编码的。以主流Transformer结构为例一个Token在生成向量时会通过自注意力机制参考上下文窗口内其他Token的信息。这意味着一个块的长度、块内内容的连贯性会直接影响这个块最终被编码成什么样。更直白一点说向量化生成的Embedding是“站在块内所有文字的语境下去理解其中每一句话”的结果。同样的“苹果”两个字在一个说水果的段落里和在一个说手机品牌的段落里向量表达完全不一样。分片的目的就是让块内保持尽量单一的语境背景这样才能发挥Embedding模型的真正能力。还有一点容易被忽略Embedding模型通常有最大输入长度限制。超过这个长度的文本要么被截断要么被池化压缩语义信息都会打折。但我也不是建议大家为了“塞进去”就一直把块压小因为你问LLM的问题往往也需要上下文支撑块太小时上下文信息量不够。所以分片不是单纯的“字面切分”而是要替Embedding模型创造“刚好合适”的阅读单元。1.3 分片质量直接决定RAG系统的三项关键指标我们可以把分片质量与最终系统的三项具体表现对应起来看检索命中率如果答案分散在两个相邻块里检索过程可能只捞到其中一个块另一个相关块因为边界问题没被匹配上命中率直接下降。生成忠实度即便找到了相关块如果这个块本身信息残缺或包含过多噪音大模型在生成时就会“脑补”缺失内容出现幻觉或事实性错误。召回效率块越大、越碎向量库中的条数越多检索时的计算开销和延迟自然增加。一个合理的分片策略能让系统用更少的向量条数覆盖更多的有效语义。我记得有一次做知识库问答客户反馈说“问不到精确数字”。排查时发现文档里有一张表格被统一硬切成了若干固定长度块同一行数据被切到了两个块里检索时匹配到的是“标题栏前几列”数字信息丢了。后来把表格区域作为一个独立语义块处理问题立刻缓解。这就是分片质量对实际效果影响最直观的体现。2. 分片策略的核心框架语义边界、块大小与overlap的博弈2.1 语义边界什么样的地方适合作为切开点文本里天然存在一些“语义断点”找对这些断点分片就成功了一大半。常见的断点包括段落结束段落通常是作者表达一个完整意思的基本单元。章节标题前后新章节意味着话题切换非常适合切分。列表项之间每个列表项往往是一条独立信息。换行密集处很多时候连续的换行意味着内容的主题或语境发生了变化。不过要提醒一句很多PDF转出来的文本、扫描件识别出的内容段落并不是靠“空行”体现的往往是连续的一长串文字只有换行符而无空行。这种情况下对段落边界的判断就不能只依赖“空行”这一个信号而要靠标点符号、句子长度、主题连贯度等因素综合判断。2.2 块大小Chunk Size不是拍脑袋出来的块大小通常用“Token数”来标识因为向量模型和LLM都以Token为基本单位。我见过不少朋友直接用固定字符数比如“每500个字切一块”这其实是把“字”和“Token”混为一谈了。同样500个字英文可能对应600到700个Token中文可能是700到800个Token这直接影响了向量模型是否能完整编码。块大小没有一个万能值它取决于四个因素Embedding模型的输入上限比如某模型支持512或1024 Token块大小不能超过这个上限。内容本身的重复度与复杂度如果文档专业术语密集、逻辑环环相扣建议稍大一些如果是常见生活化内容稍小也能接受。下游生成模型的上下文窗口最终拼接给生成模型的内容越多越要考虑总成本块太大会导致一次请求的Token数量失控。检索测试的实际反馈这一点最重要。块大小应该由实验数据来定而不是拍脑袋。你先设一个初始值跑一批问题集看命中率和答案质量的变化。2.3 Overlap重叠的作用与代价重叠的意思是相邻两个块之间会保留一部分共用的文本。比如块1覆盖文本1到400块2覆盖文本351到750那351到400这一段就被两个块共同承保了。表面上看重叠浪费了一些存储空间但它能解决一个非常实际的问题避免一个完整的信息单元比如一句承上启下的关键句恰好落在块的边界上导致检索时它的后半段“跑”到上一个块里去了。重叠的另一个好处是即使查询点落在两个块的边界附近系统也能在至少一个块内看到完整的语境。缺点也很明显存储成本增加向量条数不变但每个块的Token量变大。检索时可能同时命中多个高度相似的块导致去重和排序变复杂。生成阶段如果多个块都包含同一段文本模型看到的上下文会有重复浪费Token。我的习惯是重叠部分一般控制在块大小的10%到20%之间。如果块大小是400 Token重叠可以设为40到80 Token再大往往收益降低。实际项目中可以调几次对比效果不要有洁癖。3. 六类常见分片策略的横向对比与选型思路3.1 固定长度分片最简单的方案也是最容易翻车的方案固定长度分片就是按固定Token数或字符数硬切完全不考虑文本结构。这种方案实现成本最低适合在快速原型阶段跑通流程时用。但如果文档结构复杂固定长度经常会把一句话、一个公式、一个表格拦腰砍断导致检索质量很不稳定。我做原型验证时用过这种方案结果发现只要切到代码片段、公式或中英文混合内容问题就特别多检索到的块经常是“半句话”。所以这个方案只适合当作基线不能当主力。3.2 递归字符分片目前最实用的通用方案递归字符分片是目前工程上最常用的通用方案。它的核心思想是按一组分隔符依次尝试切分如果当前切分结果仍然超过目标块大小就换用更小的分隔符继续切。比如一套典型的分隔符序列是“\n\n\n”、“\n\n”、“\n”、“。”、“\n”。意思是先按多个空行切大段落如果大段落还是太长再按单空行、按句子标点、按换行符逐级下探。这样做的好处是文本尽量保持自然段落结构每个块内部的语义完整性明显好于固定长度切分。这一策略几乎是目前做通用RAG的首选。选分隔符的顺序也有讲究通常把“段落级”的分隔符放在前面把“句子级”的分隔符放在后面这样切出来的块首先会尊重原文的结构层次。3.3 Sentence Level 分片适合需要精确引用的场景按句子切分的方案比固定长度聪明不少它能把每个句子作为独立单元特别适合法律条款、合同条款这类句子意思高度独立的文档。这类文档里一句话就是一个完整条款检索时只需要把相关条款捞出来即可过多上下文反而会干扰。不过纯按句子切分也有明显缺陷文档里很多信息是一几句话加几个解释句组合在一起的单独抽出一句可能丢失必要的限定条件。所以完整方案一般不是“只按句号切”而是按“句子聚类”或者“滑动窗口句组”来切比如一次取两到三个连续句子构成块必要时让相邻句组有重叠兼顾语义完整性和定位精度。3.4 语义分片Semantic Chunking算法更先进但要谨慎使用语义分片不依靠原文的显式结构而是先计算相邻句子或段落之间的语义距离再寻找“语义突变点”作为块的边界。实现上通常先把文本拆成句子列表用Embedding模型给每个句子编码然后计算相邻句子向量的余弦距离。距离比较大的地方意味着前后两句语义差异明显这就是可能的边界。这种方案的优点是块边界贴近“语义聚落”理论上效果最好。但实际工程中它有三个隐患语义距离阈值不好定不同的文档类型、不同领域阈值往往不一样。计算成本高需要额外调用Embedding模型处理每一个候选句子比递归字符分片贵。不可复现性有些实现依赖于局部距离的浮动稍微调整输入就可能改变边界。我的建议是如果文档内容高度结构化、且原始结构标记很清晰语义分片不如直接用结构分片如果文档是小说、混排内容这类无明显结构的文本语义分片可以考虑但也一定要先做成本测算。3.5 面向结构的感知分片充分利用文档自带的标记很多文档本身自带结构信息Markdown的标题层级、HTML的标签、LaTeX的章节命令、代码的缩进层级、PPT的页面边界等。面向结构的分片就是把这类标记当作天然切分点。以Markdown为例可以先按一级标题分再按二级标题分如此类推直到每个块的Token量控制在目标范围内。这种方案的核心优势是语义边界几乎不需要猜测标题本身就是作者给的“答案”检索时还能用标题作为块的上下文提示。具体实现时可以把标题信息存成块的元数据。比如一个块的正文来自某个二级标题下的段落我们就把“二级标题文本”和“一级标题文本”一起作为元数据存入向量库。检索时即便命中的块本身很短系统也可以带着标题节点去参与匹配这种“上下文提示”能明显改善检索效果。3.6 基于模型的语义拆分边际收益和成本问题还有一种思路是用短文本摘要模型或语言模型来判断文本边界甚至让模型输出理想的切分方案。效果确实不错但成本也最高因为需要对整篇文档的每个候选切分点都推理一次。除非你的场景特别依赖高质量检索、数据量又可控否则我不建议在通用场景里直接用模型分片。一块文档只有几十KB算下来拆分成本可能比后续检索成本还高性价比很低。下面把这六类策略放在一起直观对比分片策略切分依据优点缺点典型场景固定长度Token/字符数实现简单、速度快破坏语义、切割代码和表格易出错快速原型、基线对比递归字符多层分隔符通用性强、兼顾结构对无结构内容不敏感各类通用文本首选方案句子级句号/语气词检索精度高信息碎片化法律条款、FAQ语义分片相邻Embedding距离理论上最优成本高、阈值难调无明确结构的混合文本结构感知标题/标签/代码缩进语义边界准、可带元数据依赖文档结构完整Markdown、HTML、代码文档模型拆分LLM/摘要模型效果强成本高、延迟高小数据量精品知识库4. Chunk Size与Overlap的调优实验方法4.1 设计一套可控的对比实验分片调参最忌讳凭感觉。正确做法是先准备一个有标准答案的问题集然后在同一套向量库、同一个Embedding模型、同一个检索参数下只改变分片策略和块大小观察指标变化。问题集要贴近真实使用场景建议不少于50条。每道问题对应一个或多个期望命中的文档块这个“标准答案”可以用人工标注来建立。如果你没有人工标注预算至少也要记录“期望包含答案的文档片段”然后判断检索结果是否覆盖。用到的指标主要有三个命中率Hit Rate检索返回的前K个结果中有多少条命中了包含标准答案的块。这个指标最直观也最容易理解。MRRMean Reciprocal Rank考虑命中结果在排序中的位置。如果正确答案排第一记1分排第二记0.5分。它能衡量检索结果排序质量。** faithfulness忠实度/答案一致性**最终生成答案与标准答案的一致性此项由人工或模型打分用来兜底前两个指标无法体现的“内容可用性”。大致流程可以这样组织确定多个候选方案例如递归字符分片块大小取300/500/800 Token重叠取50/80/100 Token组成若干组。依次为每组方案构建向量库索引注意保持文档集、向量模型、检索的TopK完全一致。跑同一批问题分别记录上述三项指标。排序对比选综合表现最好的方案。4.2 一个可参考的Python验证代码思路下面是一段伪代码展示了如何快速测算“命中率”和“MRR”你可以按需改造成本地环境可跑的脚本import numpy as np # chunk_list: 每个分片文档入库时记录的唯一ID或文本 # expected_chunk_ids: 每个query期望命中的chunk ID列表 # retrieved_chunk_ids: 每个query实际检索返回的TopK chunk ID列表 def evaluate(retrieved: list[list[str]], expected: list[list[str]], k5): hit_count 0 mrr_sum 0.0 for ret_list, exp_list in zip(retrieved, expected): exp_set set(exp_list) # 只看前k个结果 ret_k ret_list[:k] hit_flag False for rank, cid in enumerate(ret_k, start1): if cid in exp_set: hit_flag True mrr_sum 1.0 / rank break if hit_flag: hit_count 1 n len(retrieved) hit_rate hit_count / n mrr mrr_sum / n return {hit_rate: hit_rate, mrr: mrr}注意这段代码里的retrieved要确保来源是同一个向量库在不同分片参数下的检索结果而不是不同库之间的混跑结果。4.3 常见实验结论和我的经验参考从我在多个文档集上的实验经验看有几个规律可以作为起点块大小在500到800 Token之间命中率普遍高于300以下的小块原因是块内信息量够用。块超过1000 Token后命中率往往下滑因为语义开始被杂质干扰向量表达不够聚焦。重叠设置对命中率的影响通常小于块大小但会影响排序质量MRR对重叠更敏感。如果你的文档本身就是问答对用句子级分片比用递归字符分片效果好很多。这些规律不是金科玉律但作为第一轮实验的候选参数非常好用。跑完第一轮后你再围绕表现最好的一组参数做细粒度调整比如从500 Token起步分别试450、500、550、600找到峰值的拐点。4.4 别只看检索指标务必看生成质量我提醒过很多同行Hit Rate上去不代表生成答案质量就同步上去。有个典型场景是块大小恰到好处检索命中的块标题、摘要都匹配但块里包含正确答案的句子太靠后实际生成模型读到时已经信息衰减导致回答不够准确。所以调参一定要“检索指标生成答案人工抽检”双轨并行。每次调完参数后固定抽10到20道测试题把检索到的块和生成答案打印出来人工看一遍。这个过程很花时间但非常值得。曾经有一位同事调整分片后看到Hit Rate提升了0.15但人工检查发现生成答案出现了更明显的重复引用现象差点上线后才发现我建议他一定要先跑人工抽检后来果然救了一版。5. 工程落地中容易踩的坑与我的应对思路5.1 元数据必须和分片绑定否则知识库就是“黑盒”分片之后每个块如果只保存“原文文本”和“向量”那么当生成模型引用某个块的信息时你甚至无法追溯它来自哪份文档、哪个章节。工程上一定要给每个块附带元数据常见的元数据包括文档ID和文件名章节标题路径如一级标题/二级标题块在原始文档中的起始位置和结束位置文档来源链接或页码这些元数据可以被检索系统用来构造更丰富的返回结果也可以在生成阶段做引用溯源。我习惯把“标题路径”作为向量检索的前缀拼入文本比如“税法总则 - 纳税人权利 - 第12条”这样即使块内只提到“该条”模型也能从上下文中理解确切指向。5.2 不同文档类型混用时不要强行统一分片参数一个常见错误是一个知识库里既包含合同条款、产品手册、技术支持FAQ还包含长篇文章笔记却用同一组分片参数跑全库。这会导致某些文档检索效果差得离谱。其实合理的做法是按文档类型设定不同分片策略和参数并在元数据里标注“分片策略类型”。检索时让向量库支持按元数据过滤再结合业务场景选择性地检索某一类文档。比如FAQ类内容直接用句子级分片产品手册用结构感知分片长篇文章笔记用递归字符分片效果会好很多。你可以先按文档类型分别做实验再决定是否统一参数。5.3 Overlap并不总是越多越好前面我给出了10%到20%的建议范围但这里要补充一个反例如果你的文档是层层递进的比如数学证明、教程代码重叠设多了检索到的多个块之间会频繁包含同一段解释文字导致生成模型在拼接时出现前后矛盾。因为模型看到两段话都在讲“上一步的结论”会误以为需要强调或者重复最终答案出现冗余信息。所以重叠多少既要看块大小也要看文档的叙事节奏。我在处理连续性很强的技术文档时会故意把重叠压得很低甚至设为零换取检索结果之间的“信息差”让每个块尽量呈现新材料。5.4 处理中英文混合内容时的Token换算问题中文和英文的单位Token差异极大。英文大约4个字符对应1个Token中文大约1个字对应0.6到1.5个Token具体取决于模型和分词方式。如果你按字符设置块大小很容易超出模型上限。我建议所有分片实现都用Token级参数并且在代码里接入模型自带的Token计数函数。另外混合内容最好单独处理。比如一篇介绍API的文档英文代码注释多中文说明多就不能用同一个字符数去切通常我会把代码块和文字段落分开分块后分别管理。5.5 查询端的分片策略也要同步思考很多人只关注“入库端”的分片却忘了检索时查询语句同样会被Embedding模型编码。如果查询很长很乱模型对查询的理解也会被噪音左右。目前的实践对查询端的处理相对成熟入库时怎么切查询时尽量保持相似的粒度和风格。比如入库时每个块是段落级的那么查询最好不要是超长的整篇文章否则检索效果会受影响。如果业务上确实有长查询需求可以尝试“查询重写”先用一个轻量模型把长查询压缩成关键词列表或数条短查询再用短查询分别去检索最后合并去重。这个方法在长段落匹配场景里很有效。5.6 边界情况的处理表格、公式、代码块这三个数据类型可以说是分片界的“老大难”。表格表格行之间通常有紧密的对应关系单独切几行会导致数据断裂。我的方法是把整个表格作为一个块过长的表格再按“行组”切并保留表头信息重写到每个行组块里。公式公式内部的语义不依赖上下文但公式说明文字依赖。建议把“公式块”和“说明文字块”分开存并在说明文字块的元数据里引用公式块ID。代码块不要按行数直接切代码否则一个函数容易断在中间。按照函数、类、导入区块等代码结构来切或至少按空行分效果远好于固定长度切分。如果代码很长可以保留“所在函数名/类名”作为元数据前缀。5.7 长期维护视角分片逻辑和版本管理知识库不是一次性建好的文档会更新分片逻辑也会调整。我踩过的坑是更新了一部分文档后新旧两种分片方案混在一个库里检索结果非常混乱。所以现在我的做法是每次调整分片逻辑都重建新版索引并且保留版本号。线上检索时可以灰度切流让一部分请求走新索引、一部分走旧索引收集真实用户反馈后再全面切换。伪代码上只需要在元数据里增加一个“分片版本号”字段检索时按该字段过滤就行。6. 最后再分享两个我在分片调优中学会的实操技巧第一个技巧不要忽视“标题 首句 尾句”的组合作用。很多情况下一个块即使内容丰富检索匹配时也只依赖其中一两句话的语义如果这一两句话被埋没在大量中间内容里命中率就会下降。你在做一个分片方案时可以试着在向量化之前给每个块创建一个“摘要前缀”把块的标题、关键要点压缩成一小段文本放到块的前面再一起向量化。这相当于给每个检索单元加了一个“快照索引”能显著降低信息被淹没的概率。第二个技巧先把“任务分解”这件事做好再用分片解决“检索单元”。RAG应用中能不能检索到正确答案通常不只看分片也看问题拆得好不好。我的做法是把用户问题拆成几个子问题每个子问题对应检索一类文档最后把结果合并。这样即使某些块检索不到位整体答案也不会断链。分片和查询设计是一对拍档单独调分片而不优化查询并不会让你达到最优效果。回头看我做过的几个RAG项目凡是提前在分片策略上花过心思的后来的调试成本都低很多。分片看起来是链路里最“笨”的一环却承载着整个系统的记忆精度。希望这次分享能让你在自己的项目里少走几步弯路。