1. 被忽视的切片为什么它才是RAG系统的隐形天花板做RAG检索增强生成的人十有八九把精力砸在了模型选型、向量库调参、Prompt工程上却对切片Chunking这一步草草了事。我见过太多项目embedding模型用的是顶配向量数据库也是企业级方案但最终问答效果就是上不去——答案要么缺胳膊少腿要么检索出一堆无关内容。排查到最后问题往往出在最开始那一步文档切片没做好。切片之所以不起眼是因为它太“前处理”了。大家潜意识里觉得把文档按固定字数切开扔进向量库就完事了。但实际情况是切片策略直接决定了检索系统能“看到”什么粒度的信息。切得太碎语义被割裂检索出来的片段缺乏上下文生成模型拿到手里也拼不出完整答案切得太粗一个片段里混了好几个主题向量表示被稀释检索精度断崖式下跌。更麻烦的是这两种错误在系统上线初期往往不会暴露——简单问题还能应付一旦用户问得稍微具体一点短板立刻现形。这篇文章面向的是正在搭建或优化RAG系统的开发者无论你用的是LangChain、LlamaIndex还是自研管线切片这一步都绕不开。我会从切片的本质目标讲起拆解几种主流策略的适用场景和坑点给出可落地的参数建议最后分享一些我在实际项目中踩过的坑和验证过的调优手法。读完你至少能判断自己手头的切片方案到底合不合格以及该往哪个方向改。2. 切片的本质在语义完整与检索精度之间找平衡2.1 切片到底在解决什么问题RAG系统的核心链路是用户提问 → 检索相关文档片段 → 把片段塞进上下文 → 生成答案。切片就是这条链路的起点它决定了“相关文档片段”这个中间产物的质量。理想情况下每个切片应该是一个语义自洽的单元——它独立存在时人能看懂它在说什么它被检索出来时能直接回答或支撑某个具体问题。但现实很骨感。一份文档的语义结构是树状的章包含节节包含段段包含句。切片本质上是在这棵树上找一个切割面把连续文本切成离散块。切在哪里直接决定了每个块的语义边界是否清晰。切在段落之间语义完整度高但块可能很长切在句子之间块短了但上下文可能断裂。这就是切片的核心矛盾语义完整性和检索精度之间的权衡。2.2 固定长度切片的致命缺陷最常见的做法是按固定字符数切比如每500个字符一刀。这种做法实现简单但问题很致命。假设一段文本正好在“该方案的优势在于”后面被切断下一个块以“成本低、部署快”开头。检索时如果用户问“这个方案有什么优势”第一个块可能被召回但答案的后半截在第二个块里生成模型拿到的上下文是残缺的。更糟糕的是第二个块单独看完全不知道在说什么向量表示会非常模糊检索时容易被漏掉。固定长度切片还有一个隐蔽问题它完全无视文档的天然结构。技术文档有标题、段落、列表、代码块法律合同有条款论文有摘要和章节。这些结构本身就是语义边界的强信号按固定长度切等于把这些信号全部丢弃。我做过一个对比实验同一份技术文档固定长度切片和按结构切片在相同检索问题下的召回率差了将近30个百分点。2.3 语义完整性与检索精度的量化关系要理解这个权衡可以看一个简化模型。假设文档总长度为L切片长度为c切片数量n≈L/c。检索时系统从n个块中召回top-k个。每个块的语义信息量可以粗略认为与c正相关但块内主题纯度与c负相关——块越长混入多个主题的概率越大。当c很小时每个块主题纯度高向量表示尖锐检索精度高但块内信息量不足生成模型可能拿不到完整答案。当c很大时块内信息量足但向量表示被多个主题平均检索时容易召回“什么都沾一点”的块精度下降。存在一个最优c使得检索精度和答案完整度的乘积最大。这个最优值取决于文档类型、问题类型和embedding模型的能力没有万能数字。注意不要迷信网上流传的“最佳切片长度是512 tokens”这类说法。那是在特定数据集、特定模型下的经验值换一个场景可能完全不适用。3. 主流切片策略的实战拆解与选型逻辑3.1 按字符数硬切什么时候可以用什么时候绝对不能用按字符数硬切是最简单的策略代码几行就能实现。它的适用场景非常有限文档结构极其规整比如每段都是独立的知识点段与段之间没有依赖关系。比如FAQ文档每个问答对就是天然切片硬切反而不会出大问题。但在绝大多数场景下硬切都是灾难。技术文档、研究报告、法律文书、产品手册这些文档的语义是跨段落的。一个概念的定义可能在第一段展开在第二段举例在第三段。硬切会把它们打散检索时只能召回其中一块生成模型拿到的信息是碎片化的。如果非要用硬切至少加一个重叠窗口overlap。比如每500字符切一刀但相邻块之间重叠100字符。这样即使切在了句子中间下一个块也能包含前一个块的尾部内容缓解语义断裂。重叠比例一般设在10%到20%之间太小起不到作用太大则冗余严重检索时容易召回大量重复内容。def fixed_size_chunk(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks这段代码看起来没问题但实际用的时候要注意如果文档里有代码块或表格硬切可能把代码从中间截断导致语法错误。表格被切散后行列对应关系丢失检索出来完全没法用。所以硬切之前最好先把代码块和表格单独提取出来不要参与常规切片。3.2 按段落和标题切利用文档的天然结构大多数文档都有天然的结构信号标题、子标题、段落分隔符。按这些信号切能最大程度保持语义完整性。具体做法是先按标题层级把文档拆成树状结构每个叶子节点最小标题单元下的内容作为一个候选切片。如果某个叶子节点内容太长再按段落进一步切分。这种策略的好处是每个切片都有明确的主题归属。检索时如果用户的问题匹配到某个标题可以直接定位到对应切片精度很高。而且切片自带层级信息可以在检索时利用标题做过滤或加权。但要注意标题层级不一定规整。有些文档标题层级混乱或者根本没有标题。这时候可以退而求其次按段落切。段落是作者有意划分的语义单元按段落切比按字符切合理得多。如果段落本身太长比如超过1000字再考虑按句子切分。import re def paragraph_chunk(text, max_length800): paragraphs re.split(r\n\s*\n, text) chunks [] current for para in paragraphs: if len(current) len(para) max_length: current para \n\n else: if current: chunks.append(current.strip()) current para \n\n if current: chunks.append(current.strip()) return chunks这个实现有个细节它不是简单地把每个段落单独成块而是尽量把短段落合并到接近max_length。这样避免产生大量过短的切片影响检索效率。但合并时要注意不要把不同主题的段落硬凑在一起。一个简单的判断方法是看相邻段落的相似度如果相似度低于阈值就不合并。3.3 递归切分LangChain的默认策略到底靠不靠谱LangChain的RecursiveCharacterTextSplitter是很多人用的默认方案。它的逻辑是先尝试用第一优先级分隔符比如双换行切如果切出来的块还是太大就用第二优先级分隔符比如单换行继续切以此类推。分隔符列表通常是[\n\n, \n, 。, , ]从粗到细。这个策略比硬切聪明因为它优先在语义边界处切。但它也有问题分隔符列表是固定的不感知文档的实际结构。比如一份Markdown文档标题是用#标记的但分隔符列表里没有#递归切分可能把标题和正文切开导致切片丢失标题信息。另外递归切分的终止条件是块大小小于chunk_size但它不保证块内语义完整。如果文档里有一段很长的连续文本没有任何换行或标点递归切分最后会退化成按字符硬切。所以用这个策略时要针对文档类型定制分隔符列表。比如处理Markdown时把## 、### 加进去处理代码时把\nclass 、\ndef 加进去。3.4 语义切片用embedding找真正的语义边界语义切片是更高级的做法先对文本按句子切分然后计算相邻句子的embedding相似度。如果相似度低于某个阈值说明这里可能是主题转换点就在这里切一刀。这样切出来的块内部语义一致性高块与块之间的边界也更有意义。具体实现上可以用sentence-transformers计算句子向量然后计算相邻句子的余弦相似度。阈值一般设在0.5到0.7之间具体取决于文档类型。技术文档的阈值可以低一点因为技术概念之间的关联性本身就弱叙事类文档的阈值可以高一点因为故事线是连贯的。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) def semantic_chunk(sentences, threshold0.6): embeddings model.encode(sentences) chunks [] current_chunk [sentences[0]] for i in range(1, len(sentences)): sim np.dot(embeddings[i-1], embeddings[i]) / ( np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i]) ) if sim threshold: chunks.append( .join(current_chunk)) current_chunk [sentences[i]] else: current_chunk.append(sentences[i]) if current_chunk: chunks.append( .join(current_chunk)) return chunks语义切片的缺点是计算成本高。一份长文档可能有几千个句子每个句子都要算embedding耗时可能几十秒甚至几分钟。而且阈值不好定需要针对具体文档调。我的经验是语义切片适合对精度要求极高的场景比如法律合同检索、医疗文献问答。对于一般的技术文档或产品手册按结构切分已经够用了。3.5 策略选型对照表策略适用场景优点缺点推荐参数固定长度硬切FAQ、短文本集合实现简单速度快语义断裂严重chunk_size300-500overlap10%-20%按段落/标题切结构清晰的文档语义完整自带层级依赖文档结构质量max_length500-1000递归切分通用场景平衡了结构和灵活性分隔符需定制chunk_size500-800分隔符按文档类型调整语义切片高精度要求场景语义边界准确计算成本高阈值难调相似度阈值0.5-0.74. 切片参数调优从500到1500我踩过的那些坑4.1 chunk_size不是拍脑袋定的很多人设chunk_size就是拍脑袋看别人用500就跟着用500。但chunk_size应该由文档类型和问题类型共同决定。如果用户的问题通常很具体比如“XX功能的配置参数是什么”那切片应该小一点让检索能精确定位到参数所在的段落。如果用户的问题比较宏观比如“这个系统的架构设计思路”那切片可以大一点包含更多上下文。我一般会先分析用户问题的平均长度和具体程度。如果问题平均在10个字以内且大多是事实型查询chunk_size设在300到500之间比较合适。如果问题平均在20字以上且涉及推理或总结chunk_size可以放到800到1200。另外embedding模型的最大输入长度也是一个硬约束。比如all-MiniLM-L6-v2最大支持256个token如果chunk_size超过这个数后面的内容会被截断等于白切。4.2 overlap设多少才不浪费overlap的作用是防止语义在边界处丢失但它不是越大越好。overlap太大相邻切片重复内容多检索时会召回大量相似结果浪费上下文窗口。overlap太小起不到缓冲作用。我的经验是overlap设在chunk_size的10%到15%之间比较合理。比如chunk_size500overlap设50到75。但有一种情况需要加大overlap文档里有很多跨段落的指代关系。比如第一段说“该方案有三个优势”第二段分别展开。如果切片正好切在第二段中间第一个切片可能只包含第一个优势第二个切片包含后两个优势但第二个切片开头没有“该方案”的上下文检索时可能匹配不上。这时候把overlap加大到20%到30%让第二个切片也包含“该方案有三个优势”这句话就能解决。4.3 切片长度分布比平均值更重要调参时不要只看平均切片长度要看长度分布。如果大部分切片在500字左右但有几个切片超过2000字这几个超长切片就是隐患。它们可能包含多个主题向量表示模糊检索时要么召不回要么召回了但生成模型被无关信息干扰。我一般会统计切片长度的百分位数。如果90分位数超过平均值的2倍说明切片长度分布不均匀需要调整切分策略。比如对超长段落做二次切分或者对过短切片做合并。理想情况下切片长度应该集中在目标值附近标准差不要太大。4.4 用检索指标反推切片质量切片好不好最终要看检索效果。我习惯在切片完成后构造一批测试问题然后看检索的召回率和精确率。具体做法是对每个测试问题人工标注哪些切片是相关的然后看系统召回的top-k里有多少是相关的。如果召回率低说明切片粒度太粗或语义边界不清如果精确率低说明切片粒度太细或重叠太多。这个评估过程不需要很复杂几十个测试问题就能看出趋势。关键是测试问题要覆盖不同类型的查询事实型、推理型、总结型。如果某类问题的指标明显偏低就针对性地调整切片策略。比如事实型问题召回率低就把chunk_size调小总结型问题召回率低就把chunk_size调大或增加overlap。5. 特殊文档的切片处理代码、表格、多语言混排5.1 代码块切片别把函数从中间切断技术文档里经常夹杂代码块。代码的语义单元是函数或类从中间切断会导致语法错误检索出来也没法用。处理方法是先用正则表达式把代码块提取出来单独作为一个切片或者按函数/类边界切分。如果代码块太长可以按逻辑块切比如一个函数一个切片但要在切片开头保留函数签名和注释。import re def extract_code_blocks(text): pattern r(\w*)\n(.*?) blocks [] for match in re.finditer(pattern, text, re.DOTALL): lang match.group(1) code match.group(2) blocks.append({lang: lang, code: code, start: match.start(), end: match.end()}) return blocks提取出来后代码块不参与常规文本切片而是单独建立索引。检索时如果问题涉及代码可以优先从代码块索引中召回。这样既保证了代码完整性又不会干扰文本切片的语义纯度。5.2 表格切片保留行列对应关系表格被切散是另一个常见问题。一个表格如果被切成两半前半部分有表头没有数据后半部分有数据没有表头检索出来完全没法解读。处理方法是把整个表格作为一个切片如果表格太大按行切分但每个切片都要带上表头。具体做法是解析表格结构提取表头然后按行分组。每组行数根据表格宽度和chunk_size决定但每组都必须包含表头。这样每个切片都是一个自包含的小表格检索出来可以直接用。5.3 多语言混排文档的切片陷阱中英文混排的文档按字符数切分会出现严重偏差。中文一个字符的信息量远大于英文一个字符同样500字符中文可能只有一段话英文可能有好几段。如果按字符数统一切中文切片会偏长英文切片会偏短。解决办法是按token数切而不是字符数。用tokenizer把文本转成token序列然后按token数切分。这样中英文的信息量就对齐了。大多数embedding模型都有对应的tokenizer直接用就行。如果不想引入tokenizer也可以按语言分别处理中文按字符数切英文按单词数切然后合并。6. 切片之后存储、索引与检索的联动优化6.1 切片元数据别只存文本切片存进向量库时不要只存文本和向量。元数据至少应该包含来源文档ID、切片在文档中的位置起止字符或页码、所属标题层级、切片类型正文/代码/表格。这些元数据在检索时非常有用。比如可以按标题层级过滤只召回特定章节的内容或者按切片类型加权代码类问题优先召回代码切片。元数据还有一个用途是溯源。生成模型给出答案后可以展示答案来自哪个文档的哪个部分方便用户验证。这在企业场景下尤其重要用户不会盲目相信模型生成的内容需要能追溯到原始文档。6.2 父子切片用小块检索用大块生成这是一个很实用的技巧建索引时用小块生成时用大块。具体做法是把文档切成两层父块和子块。父块较大比如1000字保证语义完整子块较小比如200字保证检索精度。检索时用子块匹配问题命中后返回对应的父块给生成模型。这样既解决了小块检索精度高但信息不足的问题又解决了大块信息足但检索不准的问题。实现上每个子块存一个父块ID检索到子块后根据ID取出父块。LangChain的ParentDocumentRetriever就是干这个的但自己实现也不复杂。6.3 切片与embedding模型的匹配不同embedding模型对切片长度的敏感度不同。有些模型在短文本上表现好有些在长文本上更稳。选切片策略时要结合embedding模型的特点。比如OpenAI的text-embedding-ada-002对512 token以内的文本效果最好超过后性能下降。而有些开源模型支持更长的输入但长输入下的向量质量未必好。我的做法是先用目标embedding模型跑一个切片长度扫描从200到1500每隔100取一个值看检索指标的变化。通常能找到一两个峰值选峰值对应的长度作为chunk_size。这个扫描过程可能要多跑几轮但比拍脑袋定参数靠谱得多。7. 我踩过的三个真实坑与修复过程7.1 坑一切片太碎导致答案拼不完整早期做一个产品手册问答系统为了追求检索精度把chunk_size设成了200。测试时发现简单问题回答得挺好但稍微复杂一点的问题答案总是缺一部分。排查后发现用户问“如何配置XX功能”相关说明分散在三个切片里第一个讲配置前提第二个讲具体步骤第三个讲注意事项。检索时只召回了第二个切片生成模型只看到了步骤没看到前提和注意事项答案自然不完整。修复方法是把chunk_size调到600同时增加overlap到100。这样三个切片被合并成两个且相邻切片有重叠检索时更容易召回完整上下文。调整后复杂问题的答案完整度明显提升。7.2 坑二表格被切散导致检索失效另一个项目处理的是财务报表文档里有大量表格。最初用递归切分表格被切得七零八落。用户问“第三季度的营收是多少”检索召回的切片里只有数字没有表头生成模型根本不知道这个数字对应哪个季度。修复方法是单独处理表格解析出表格结构后把每个表格作为一个独立切片并在切片开头加上表头。如果表格行数太多按行分组每组都带表头。这样每个切片都是自解释的检索出来直接能用。7.3 坑三多语言文档切片长度失衡一个中英文混排的技术文档按字符数切分后中文切片平均800字英文切片平均300字。检索时英文问题召回的中文切片太长噪音多中文问题召回的英文切片太短信息不足。后来改用tokenizer按token数切分中英文切片长度对齐到相同的token数问题才解决。这个坑的教训是切片策略要跟文档的语言特性匹配。纯中文文档可以按字符数切纯英文文档可以按单词数切混排文档最好按token数切。虽然tokenizer会引入额外依赖但为了检索质量这点成本值得花。8. 切片策略的迭代节奏与评估闭环切片不是一次调好就完事的。文档在更新用户问题在变化embedding模型也可能升级。我一般会建立一个评估闭环定期用一批标注好的测试问题跑检索指标如果指标下降超过阈值就触发切片策略的重新评估。评估时不要只看整体指标要分场景看。事实型问题、推理型问题、总结型问题的指标可能差异很大。如果某类问题指标持续偏低就针对性地调整切片参数。比如事实型问题召回率低就减小chunk_size总结型问题召回率低就增大chunk_size或增加overlap。另外用户反馈也是重要信号。如果用户经常抱怨“答案不完整”或“答非所问”大概率是切片出了问题。这时候不要急着调模型或Prompt先回头看看切片策略是不是跟当前文档和问题类型匹配。很多时候把切片调好比换一个更大的模型效果更明显。提示切片调优的投入产出比很高。花半天时间调切片可能比花一周时间调Prompt带来的提升还大。但这一步太靠前容易被忽略。建议在RAG项目启动时就把切片策略作为独立模块来设计和评估不要等到效果不好了才回头补课。 
长河君 · 2026/10/20 23:54:29 · 阅读 1.2k RAG系统切片策略全解析：从固定长度到语义切分
1. 被忽视的切片为什么它才是RAG系统的隐形天花板做RAG检索增强生成的人十有八九把精力砸在了模型选型、向量库调参、Prompt工程上却对切片Chunking这一步草草了事。我见过太多项目embedding模型用的是顶配向量数据库也是企业级方案但最终问答效果就是上不去——答案要么缺胳膊少腿要么检索出一堆无关内容。排查到最后问题往往出在最开始那一步文档切片没做好。切片之所以不起眼是因为它太“前处理”了。大家潜意识里觉得把文档按固定字数切开扔进向量库就完事了。但实际情况是切片策略直接决定了检索系统能“看到”什么粒度的信息。切得太碎语义被割裂检索出来的片段缺乏上下文生成模型拿到手里也拼不出完整答案切得太粗一个片段里混了好几个主题向量表示被稀释检索精度断崖式下跌。更麻烦的是这两种错误在系统上线初期往往不会暴露——简单问题还能应付一旦用户问得稍微具体一点短板立刻现形。这篇文章面向的是正在搭建或优化RAG系统的开发者无论你用的是LangChain、LlamaIndex还是自研管线切片这一步都绕不开。我会从切片的本质目标讲起拆解几种主流策略的适用场景和坑点给出可落地的参数建议最后分享一些我在实际项目中踩过的坑和验证过的调优手法。读完你至少能判断自己手头的切片方案到底合不合格以及该往哪个方向改。2. 切片的本质在语义完整与检索精度之间找平衡2.1 切片到底在解决什么问题RAG系统的核心链路是用户提问 → 检索相关文档片段 → 把片段塞进上下文 → 生成答案。切片就是这条链路的起点它决定了“相关文档片段”这个中间产物的质量。理想情况下每个切片应该是一个语义自洽的单元——它独立存在时人能看懂它在说什么它被检索出来时能直接回答或支撑某个具体问题。但现实很骨感。一份文档的语义结构是树状的章包含节节包含段段包含句。切片本质上是在这棵树上找一个切割面把连续文本切成离散块。切在哪里直接决定了每个块的语义边界是否清晰。切在段落之间语义完整度高但块可能很长切在句子之间块短了但上下文可能断裂。这就是切片的核心矛盾语义完整性和检索精度之间的权衡。2.2 固定长度切片的致命缺陷最常见的做法是按固定字符数切比如每500个字符一刀。这种做法实现简单但问题很致命。假设一段文本正好在“该方案的优势在于”后面被切断下一个块以“成本低、部署快”开头。检索时如果用户问“这个方案有什么优势”第一个块可能被召回但答案的后半截在第二个块里生成模型拿到的上下文是残缺的。更糟糕的是第二个块单独看完全不知道在说什么向量表示会非常模糊检索时容易被漏掉。固定长度切片还有一个隐蔽问题它完全无视文档的天然结构。技术文档有标题、段落、列表、代码块法律合同有条款论文有摘要和章节。这些结构本身就是语义边界的强信号按固定长度切等于把这些信号全部丢弃。我做过一个对比实验同一份技术文档固定长度切片和按结构切片在相同检索问题下的召回率差了将近30个百分点。2.3 语义完整性与检索精度的量化关系要理解这个权衡可以看一个简化模型。假设文档总长度为L切片长度为c切片数量n≈L/c。检索时系统从n个块中召回top-k个。每个块的语义信息量可以粗略认为与c正相关但块内主题纯度与c负相关——块越长混入多个主题的概率越大。当c很小时每个块主题纯度高向量表示尖锐检索精度高但块内信息量不足生成模型可能拿不到完整答案。当c很大时块内信息量足但向量表示被多个主题平均检索时容易召回“什么都沾一点”的块精度下降。存在一个最优c使得检索精度和答案完整度的乘积最大。这个最优值取决于文档类型、问题类型和embedding模型的能力没有万能数字。注意不要迷信网上流传的“最佳切片长度是512 tokens”这类说法。那是在特定数据集、特定模型下的经验值换一个场景可能完全不适用。3. 主流切片策略的实战拆解与选型逻辑3.1 按字符数硬切什么时候可以用什么时候绝对不能用按字符数硬切是最简单的策略代码几行就能实现。它的适用场景非常有限文档结构极其规整比如每段都是独立的知识点段与段之间没有依赖关系。比如FAQ文档每个问答对就是天然切片硬切反而不会出大问题。但在绝大多数场景下硬切都是灾难。技术文档、研究报告、法律文书、产品手册这些文档的语义是跨段落的。一个概念的定义可能在第一段展开在第二段举例在第三段。硬切会把它们打散检索时只能召回其中一块生成模型拿到的信息是碎片化的。如果非要用硬切至少加一个重叠窗口overlap。比如每500字符切一刀但相邻块之间重叠100字符。这样即使切在了句子中间下一个块也能包含前一个块的尾部内容缓解语义断裂。重叠比例一般设在10%到20%之间太小起不到作用太大则冗余严重检索时容易召回大量重复内容。def fixed_size_chunk(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks这段代码看起来没问题但实际用的时候要注意如果文档里有代码块或表格硬切可能把代码从中间截断导致语法错误。表格被切散后行列对应关系丢失检索出来完全没法用。所以硬切之前最好先把代码块和表格单独提取出来不要参与常规切片。3.2 按段落和标题切利用文档的天然结构大多数文档都有天然的结构信号标题、子标题、段落分隔符。按这些信号切能最大程度保持语义完整性。具体做法是先按标题层级把文档拆成树状结构每个叶子节点最小标题单元下的内容作为一个候选切片。如果某个叶子节点内容太长再按段落进一步切分。这种策略的好处是每个切片都有明确的主题归属。检索时如果用户的问题匹配到某个标题可以直接定位到对应切片精度很高。而且切片自带层级信息可以在检索时利用标题做过滤或加权。但要注意标题层级不一定规整。有些文档标题层级混乱或者根本没有标题。这时候可以退而求其次按段落切。段落是作者有意划分的语义单元按段落切比按字符切合理得多。如果段落本身太长比如超过1000字再考虑按句子切分。import re def paragraph_chunk(text, max_length800): paragraphs re.split(r\n\s*\n, text) chunks [] current for para in paragraphs: if len(current) len(para) max_length: current para \n\n else: if current: chunks.append(current.strip()) current para \n\n if current: chunks.append(current.strip()) return chunks这个实现有个细节它不是简单地把每个段落单独成块而是尽量把短段落合并到接近max_length。这样避免产生大量过短的切片影响检索效率。但合并时要注意不要把不同主题的段落硬凑在一起。一个简单的判断方法是看相邻段落的相似度如果相似度低于阈值就不合并。3.3 递归切分LangChain的默认策略到底靠不靠谱LangChain的RecursiveCharacterTextSplitter是很多人用的默认方案。它的逻辑是先尝试用第一优先级分隔符比如双换行切如果切出来的块还是太大就用第二优先级分隔符比如单换行继续切以此类推。分隔符列表通常是[\n\n, \n, 。, , ]从粗到细。这个策略比硬切聪明因为它优先在语义边界处切。但它也有问题分隔符列表是固定的不感知文档的实际结构。比如一份Markdown文档标题是用#标记的但分隔符列表里没有#递归切分可能把标题和正文切开导致切片丢失标题信息。另外递归切分的终止条件是块大小小于chunk_size但它不保证块内语义完整。如果文档里有一段很长的连续文本没有任何换行或标点递归切分最后会退化成按字符硬切。所以用这个策略时要针对文档类型定制分隔符列表。比如处理Markdown时把## 、### 加进去处理代码时把\nclass 、\ndef 加进去。3.4 语义切片用embedding找真正的语义边界语义切片是更高级的做法先对文本按句子切分然后计算相邻句子的embedding相似度。如果相似度低于某个阈值说明这里可能是主题转换点就在这里切一刀。这样切出来的块内部语义一致性高块与块之间的边界也更有意义。具体实现上可以用sentence-transformers计算句子向量然后计算相邻句子的余弦相似度。阈值一般设在0.5到0.7之间具体取决于文档类型。技术文档的阈值可以低一点因为技术概念之间的关联性本身就弱叙事类文档的阈值可以高一点因为故事线是连贯的。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) def semantic_chunk(sentences, threshold0.6): embeddings model.encode(sentences) chunks [] current_chunk [sentences[0]] for i in range(1, len(sentences)): sim np.dot(embeddings[i-1], embeddings[i]) / ( np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i]) ) if sim threshold: chunks.append( .join(current_chunk)) current_chunk [sentences[i]] else: current_chunk.append(sentences[i]) if current_chunk: chunks.append( .join(current_chunk)) return chunks语义切片的缺点是计算成本高。一份长文档可能有几千个句子每个句子都要算embedding耗时可能几十秒甚至几分钟。而且阈值不好定需要针对具体文档调。我的经验是语义切片适合对精度要求极高的场景比如法律合同检索、医疗文献问答。对于一般的技术文档或产品手册按结构切分已经够用了。3.5 策略选型对照表策略适用场景优点缺点推荐参数固定长度硬切FAQ、短文本集合实现简单速度快语义断裂严重chunk_size300-500overlap10%-20%按段落/标题切结构清晰的文档语义完整自带层级依赖文档结构质量max_length500-1000递归切分通用场景平衡了结构和灵活性分隔符需定制chunk_size500-800分隔符按文档类型调整语义切片高精度要求场景语义边界准确计算成本高阈值难调相似度阈值0.5-0.74. 切片参数调优从500到1500我踩过的那些坑4.1 chunk_size不是拍脑袋定的很多人设chunk_size就是拍脑袋看别人用500就跟着用500。但chunk_size应该由文档类型和问题类型共同决定。如果用户的问题通常很具体比如“XX功能的配置参数是什么”那切片应该小一点让检索能精确定位到参数所在的段落。如果用户的问题比较宏观比如“这个系统的架构设计思路”那切片可以大一点包含更多上下文。我一般会先分析用户问题的平均长度和具体程度。如果问题平均在10个字以内且大多是事实型查询chunk_size设在300到500之间比较合适。如果问题平均在20字以上且涉及推理或总结chunk_size可以放到800到1200。另外embedding模型的最大输入长度也是一个硬约束。比如all-MiniLM-L6-v2最大支持256个token如果chunk_size超过这个数后面的内容会被截断等于白切。4.2 overlap设多少才不浪费overlap的作用是防止语义在边界处丢失但它不是越大越好。overlap太大相邻切片重复内容多检索时会召回大量相似结果浪费上下文窗口。overlap太小起不到缓冲作用。我的经验是overlap设在chunk_size的10%到15%之间比较合理。比如chunk_size500overlap设50到75。但有一种情况需要加大overlap文档里有很多跨段落的指代关系。比如第一段说“该方案有三个优势”第二段分别展开。如果切片正好切在第二段中间第一个切片可能只包含第一个优势第二个切片包含后两个优势但第二个切片开头没有“该方案”的上下文检索时可能匹配不上。这时候把overlap加大到20%到30%让第二个切片也包含“该方案有三个优势”这句话就能解决。4.3 切片长度分布比平均值更重要调参时不要只看平均切片长度要看长度分布。如果大部分切片在500字左右但有几个切片超过2000字这几个超长切片就是隐患。它们可能包含多个主题向量表示模糊检索时要么召不回要么召回了但生成模型被无关信息干扰。我一般会统计切片长度的百分位数。如果90分位数超过平均值的2倍说明切片长度分布不均匀需要调整切分策略。比如对超长段落做二次切分或者对过短切片做合并。理想情况下切片长度应该集中在目标值附近标准差不要太大。4.4 用检索指标反推切片质量切片好不好最终要看检索效果。我习惯在切片完成后构造一批测试问题然后看检索的召回率和精确率。具体做法是对每个测试问题人工标注哪些切片是相关的然后看系统召回的top-k里有多少是相关的。如果召回率低说明切片粒度太粗或语义边界不清如果精确率低说明切片粒度太细或重叠太多。这个评估过程不需要很复杂几十个测试问题就能看出趋势。关键是测试问题要覆盖不同类型的查询事实型、推理型、总结型。如果某类问题的指标明显偏低就针对性地调整切片策略。比如事实型问题召回率低就把chunk_size调小总结型问题召回率低就把chunk_size调大或增加overlap。5. 特殊文档的切片处理代码、表格、多语言混排5.1 代码块切片别把函数从中间切断技术文档里经常夹杂代码块。代码的语义单元是函数或类从中间切断会导致语法错误检索出来也没法用。处理方法是先用正则表达式把代码块提取出来单独作为一个切片或者按函数/类边界切分。如果代码块太长可以按逻辑块切比如一个函数一个切片但要在切片开头保留函数签名和注释。import re def extract_code_blocks(text): pattern r(\w*)\n(.*?) blocks [] for match in re.finditer(pattern, text, re.DOTALL): lang match.group(1) code match.group(2) blocks.append({lang: lang, code: code, start: match.start(), end: match.end()}) return blocks提取出来后代码块不参与常规文本切片而是单独建立索引。检索时如果问题涉及代码可以优先从代码块索引中召回。这样既保证了代码完整性又不会干扰文本切片的语义纯度。5.2 表格切片保留行列对应关系表格被切散是另一个常见问题。一个表格如果被切成两半前半部分有表头没有数据后半部分有数据没有表头检索出来完全没法解读。处理方法是把整个表格作为一个切片如果表格太大按行切分但每个切片都要带上表头。具体做法是解析表格结构提取表头然后按行分组。每组行数根据表格宽度和chunk_size决定但每组都必须包含表头。这样每个切片都是一个自包含的小表格检索出来可以直接用。5.3 多语言混排文档的切片陷阱中英文混排的文档按字符数切分会出现严重偏差。中文一个字符的信息量远大于英文一个字符同样500字符中文可能只有一段话英文可能有好几段。如果按字符数统一切中文切片会偏长英文切片会偏短。解决办法是按token数切而不是字符数。用tokenizer把文本转成token序列然后按token数切分。这样中英文的信息量就对齐了。大多数embedding模型都有对应的tokenizer直接用就行。如果不想引入tokenizer也可以按语言分别处理中文按字符数切英文按单词数切然后合并。6. 切片之后存储、索引与检索的联动优化6.1 切片元数据别只存文本切片存进向量库时不要只存文本和向量。元数据至少应该包含来源文档ID、切片在文档中的位置起止字符或页码、所属标题层级、切片类型正文/代码/表格。这些元数据在检索时非常有用。比如可以按标题层级过滤只召回特定章节的内容或者按切片类型加权代码类问题优先召回代码切片。元数据还有一个用途是溯源。生成模型给出答案后可以展示答案来自哪个文档的哪个部分方便用户验证。这在企业场景下尤其重要用户不会盲目相信模型生成的内容需要能追溯到原始文档。6.2 父子切片用小块检索用大块生成这是一个很实用的技巧建索引时用小块生成时用大块。具体做法是把文档切成两层父块和子块。父块较大比如1000字保证语义完整子块较小比如200字保证检索精度。检索时用子块匹配问题命中后返回对应的父块给生成模型。这样既解决了小块检索精度高但信息不足的问题又解决了大块信息足但检索不准的问题。实现上每个子块存一个父块ID检索到子块后根据ID取出父块。LangChain的ParentDocumentRetriever就是干这个的但自己实现也不复杂。6.3 切片与embedding模型的匹配不同embedding模型对切片长度的敏感度不同。有些模型在短文本上表现好有些在长文本上更稳。选切片策略时要结合embedding模型的特点。比如OpenAI的text-embedding-ada-002对512 token以内的文本效果最好超过后性能下降。而有些开源模型支持更长的输入但长输入下的向量质量未必好。我的做法是先用目标embedding模型跑一个切片长度扫描从200到1500每隔100取一个值看检索指标的变化。通常能找到一两个峰值选峰值对应的长度作为chunk_size。这个扫描过程可能要多跑几轮但比拍脑袋定参数靠谱得多。7. 我踩过的三个真实坑与修复过程7.1 坑一切片太碎导致答案拼不完整早期做一个产品手册问答系统为了追求检索精度把chunk_size设成了200。测试时发现简单问题回答得挺好但稍微复杂一点的问题答案总是缺一部分。排查后发现用户问“如何配置XX功能”相关说明分散在三个切片里第一个讲配置前提第二个讲具体步骤第三个讲注意事项。检索时只召回了第二个切片生成模型只看到了步骤没看到前提和注意事项答案自然不完整。修复方法是把chunk_size调到600同时增加overlap到100。这样三个切片被合并成两个且相邻切片有重叠检索时更容易召回完整上下文。调整后复杂问题的答案完整度明显提升。7.2 坑二表格被切散导致检索失效另一个项目处理的是财务报表文档里有大量表格。最初用递归切分表格被切得七零八落。用户问“第三季度的营收是多少”检索召回的切片里只有数字没有表头生成模型根本不知道这个数字对应哪个季度。修复方法是单独处理表格解析出表格结构后把每个表格作为一个独立切片并在切片开头加上表头。如果表格行数太多按行分组每组都带表头。这样每个切片都是自解释的检索出来直接能用。7.3 坑三多语言文档切片长度失衡一个中英文混排的技术文档按字符数切分后中文切片平均800字英文切片平均300字。检索时英文问题召回的中文切片太长噪音多中文问题召回的英文切片太短信息不足。后来改用tokenizer按token数切分中英文切片长度对齐到相同的token数问题才解决。这个坑的教训是切片策略要跟文档的语言特性匹配。纯中文文档可以按字符数切纯英文文档可以按单词数切混排文档最好按token数切。虽然tokenizer会引入额外依赖但为了检索质量这点成本值得花。8. 切片策略的迭代节奏与评估闭环切片不是一次调好就完事的。文档在更新用户问题在变化embedding模型也可能升级。我一般会建立一个评估闭环定期用一批标注好的测试问题跑检索指标如果指标下降超过阈值就触发切片策略的重新评估。评估时不要只看整体指标要分场景看。事实型问题、推理型问题、总结型问题的指标可能差异很大。如果某类问题指标持续偏低就针对性地调整切片参数。比如事实型问题召回率低就减小chunk_size总结型问题召回率低就增大chunk_size或增加overlap。另外用户反馈也是重要信号。如果用户经常抱怨“答案不完整”或“答非所问”大概率是切片出了问题。这时候不要急着调模型或Prompt先回头看看切片策略是不是跟当前文档和问题类型匹配。很多时候把切片调好比换一个更大的模型效果更明显。提示切片调优的投入产出比很高。花半天时间调切片可能比花一周时间调Prompt带来的提升还大。但这一步太靠前容易被忽略。建议在RAG项目启动时就把切片策略作为独立模块来设计和评估不要等到效果不好了才回头补课。