精炼回答
RAG系统的文档切分策略主要包括固定长度切分、语义边界切分和混合策略这几种思路。固定长度切分就是按字符数或token数硬切，实现简单性能好，但可能会把一个完整的段落或代码块从中间切断，破坏语义完整性。语义边界切分会基于段落、句子、章节等自然结构进行分割，保留语义连贯性，常用的像按换行符、标题层级来切，或者使用NLP模型识别语义单元。混合策略则是在语义切分基础上控制chunk大小范围，兼顾两者优势，还有更进阶的递归切分策略，先按大的语义单元比如章节切分，如果某个章节还是太大就继续按段落切，再大就按句子切，这种分层降级的思路在技术文档场景特别有用。
chunk size的选择需要平衡几个因素。首先看你的embedding模型能接受多长输入，比如很多模型限制在512 tokens。其次考虑检索精度，chunk太大会包含无关信息降低召回准确率，太小则上下文不足影响理解，一般200-500 tokens是个经验起点。还要看具体场景，技术文档可能需要更大的chunk保持代码完整性，问答类内容可以切得更细。实践中建议设置overlap重叠区域，比如chunk间重叠10-20%，避免关键信息被切断。最终还是要通过实验验证，用你的真实数据跑检索评估指标，观察不同size对召回率和答案质量的影响，找到最优配置。
扩展分析
切分策略的本质与选择逻辑
谈文档切分的时候，很多人会直接列举各种方法，但其实更重要的是理解为什么要切分这个本质问题。RAG系统中文档切分的核心矛盾是在检索粒度和语义完整性之间找平衡。整篇文档太大会导致检索不精准，切太碎又会丢失上下文，所以切分策略的设计直接影响检索效果。这个思路理顺了，后面选择具体方法就有了明确的决策依据。
固定长度切分看起来最简单，但要说清楚它的适用场景。这种方式本质上是把文档当作字符流处理，不关心内容语义，优势是实现成本极低，而且处理速度快，适合做baseline或者处理格式非常规整的数据。但问题也很明显，处理客服对话记录时，如果一段500字的用户咨询被硬切成两半，前半段单独看可能完全理解不了用户在问什么。这就是不考虑语义边界的代价。
语义边界切分的核心思想是让每个chunk成为一个完整的信息单元。最常见的是按自然段切分，因为一个段落通常表达一个完整意思。如果文档有结构化标记会更好处理，比如Markdown文档可以按标题层级切，一个二级标题下的所有内容作为一个chunk，这样检索时能保证返回的内容是完整表达某个主题的。有些场景会精细到按句子切分，特别是问答类数据。很多问题的答案可能就藏在某一句话里，比如FAQ文档，"退货需要多久处理？我们承诺48小时内完成退款审核"，这一句话就是完整的QA对。这时候句子级切分的召回精度会比段落切分高很多。
递归切分其实是在平衡语义完整性和chunk大小的一种动态策略。它会先尝试用最大的语义单元切分，比如先按章节切，如果某个章节有5000个token超过了chunk size上限，就对这个章节继续按段落切，还超就按句子切。这种分层降级的思路能保证大部分chunk都是语义完整的，同时又不会因为某个章节特别长就产生超大chunk。处理API文档时，理想情况是一个接口的完整说明作为一个chunk，但有些接口文档可能包含很长的请求示例、响应格式、错误码说明，总长度超过2000 token，这时候就需要递归切，把请求参数、响应说明、错误码分别作为独立chunk，但都保留接口名称作为上下文。
chunk overlap的本质是用空间换容错性。假设chunk size是500，overlap是50，意味着chunk1的最后50个token会和chunk2的前50个token重复。这样设计是为了解决一个实际问题——如果关键信息正好跨越两个chunk的边界，比如一句话的前半段在chunk1末尾，后半段在chunk2开头，没有overlap的话这句话会被拆散，检索时可能两个chunk都召回不了。有了overlap，这句话至少会完整出现在其中一个chunk里。但overlap不是越大越好，设置太大会导致存储成本增加，而且检索时可能返回大量重复内容。实践中10-20%是个经验值，比如chunk 500的话overlap设置50-100。
chunk size对检索质量的影响是个跷跷板关系。chunk太小，比如只有100个token，检索时确实能精准定位到最相关的那几句话，但问题是这么小的片段可能缺乏足够的上下文，导致大模型理解不了这段话在讲什么。反过来chunk太大，比如2000个token，虽然上下文很丰富，但里面混杂了很多无关信息，会稀释真正相关内容的权重，导致检索排序不准确。从向量检索的角度看，embedding模型会把整个chunk编码成一个固定维度的向量，比如1536维。如果chunk包含3个主题，这个向量本质上是这3个主题的某种混合表示，查询某个具体主题时，匹配度肯定不如只包含这一个主题的chunk。这也是为什么chunk size不是越大越好的技术原因。
文档类型不同，切分策略会有明显差异。对于技术文档，特别是包含代码的内容，需要特别注意保持代码块的完整性，因为一段代码被拆成两半基本就失去意义了。这种场景下可能会用语义切分，以代码块作为不可分割的最小单元，即使某个代码示例有800个token，也要完整保留在一个chunk里。客服对话或者聊天记录的切分逻辑又不一样，因为对话是多轮交互，上下文依赖很强。一种常见做法是按对话轮次切分，比如3-5轮对话作为一个chunk，这样能保留完整的问题-回答-追问-解答这样的交互链。如果只按固定长度切，可能把用户的问题和客服的回答拆到不同chunk，检索时就会出现只有问题没有答案或者只有答案看不懂问什么的情况。
对于新闻报道、研究论文这种长文本，段落切分通常是个稳妥选择，但要注意处理特殊结构。比如论文的摘要、方法、结论这些章节，即使很长也最好不要切碎，因为摘要本身就是全文精华，切碎了反而降低了它的检索价值。这时候可以用混合策略，核心章节作为独立chunk即使超过常规size限制，其他部分正常按段落切。选择切分策略时，思考顺序应该是先看文档结构，有明显的章节段落结构就优先用语义切分，结构不明显或者需要高性能就用固定切分。然后看内容特点，代码、表格这种不可拆分的内容多就用递归策略保护它们。最后根据检索场景调整size，精确匹配场景用小chunk，需要丰富上下文的场景用大chunk。
实践中的落地与调优
实际项目中会用LangChain这类框架来处理文档切分，它已经封装好了常用的切分器。比如用RecursiveCharacterTextSplitter处理技术文档，先定义按什么符号切分，像双换行符代表段落边界，单换行符次之，如果这些都不够用才按空格切。这个设计的关键是定义切分优先级，代码里可以这样配置：
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=50,
separators=["\n\n","\n","。"," ",""]
)
# 对于中文文档，可以增加中文特有的分隔符
chinese_splitter = RecursiveCharacterTextSplitter(
chunk_size=256,
chunk_overlap=30,
separators=["\n\n","\n","。","！","？","；"," ",""]
)
chunks = splitter.split_text(document_text)chunk_size设置512是因为考虑到常见embedding模型的舒适区，overlap设置50大概是10%的重叠，separators列表定义了切分的优先顺序，先尝试按段落切，不行就按句子切，最后才按空格切。这样既保证了语义完整性，又能控制chunk大小在合理范围内。
确定chunk size需要通过实验验证。可以先准备一个测试集，比如选20-30个典型问题，每个问题人工标注出正确答案应该在文档的哪些部分。然后用不同的chunk size配置跑检索，对比召回率和排序质量。主要看两个指标，一个是Top-K召回率，比如Top-3的chunk里有没有包含正确答案，这个反映切分粒度是否合适。另一个是答案质量，把召回的chunk喂给大模型生成答案，人工评估答案的准确性和完整性，这个能反映chunk的上下文是否足够。
假设处理常见问题文档，一开始用512的chunk size，发现有些复杂问题的答案被拆到两个chunk里，大模型回答的时候信息不完整。这时候有两个方向调整，一是增大chunk到768，但可能引入更多噪声；二是保持512但把overlap从50增加到100，让跨边界的内容有更大概率完整出现在某个chunk里。实际测试往往会发现第二种方案效果更好，既保持了检索精度又补全了上下文，召回率能从75%提升到88%。
实践中最容易踩的坑是chunk过大导致检索不准。比如某个chunk包含了商品的介绍、规格、评价三部分内容，用户问"这个商品的尺寸"，这个chunk的embedding向量是三部分的混合表示，相似度得分可能反而不如只包含规格参数的小chunk高，导致排序靠后。发现这种情况时，要检查是不是文档结构切分不够细，比如应该把规格参数作为独立chunk而不是和其他内容混在一起。
另一个常见问题是chunk过小丢失上下文。如果chunk只有100个token，检索确实很精准，但拿到的片段可能只有一两句话，大模型看不懂这句话在什么背景下说的。比如chunk里只有"支持7天无理由退货"，但没说这是针对什么品类的，大模型就可能给出不准确的答案。这种情况要么增大chunk size，要么在chunk里加上文档元信息，比如给每个chunk标记它属于哪个章节，检索时把章节标题也拼到chunk前面，帮助大模型理解上下文。
验证切分策略的效果，可以设计简单的对比实验。比如同时部署两个版本，A版本用chunk size 512，B版本用768，让真实用户的查询分别打到两个版本上，收集一周数据后对比用户的点击率和满意度。在学习阶段可以用开源数据集模拟，比如用MS MARCO这类问答数据集，用标注好的问题-答案对来评估不同配置的召回效果。
基于实践经验，有几个常见配置可以作为起点。对于中文文档，chunk size在256-512字符比较稳妥，英文的话512-1024 tokens。overlap一般设置chunk size的10-15%，太小容易切断关键信息，太大会浪费存储。对于特定场景，比如代码文档建议用RecursiveCharacterTextSplitter并且把代码块标记加到separators的优先级前面，确保代码不会被切碎；对话数据建议按轮次切分，3-5轮作为一个chunk；FAQ这种问答对可以按条目切，一问一答作为最小单元。但这些都只是经验起点，最终还是要根据具体数据分布和检索效果来调整。
除了看召回率这种定量指标，还要做case study，就是挑一些badcase人工分析。比如发现某个问题总是检索不到正确答案，就去看这个答案在原文档的什么位置，是被切碎了还是和无关内容混在一起了，然后针对性调整切分策略。这种定性分析能帮助你理解数据特点，比纯看指标数字更有指导意义。
进阶策略与工程权衡
评估切分效果其实是个多维度的问题。首先是检索层的召回率，用标注好的测试集跑检索，看Top-K结果里有没有包含正确答案，这个反映切分粒度是否合理。其次是生成层的答案质量，把检索到的chunk喂给大模型，人工评估生成答案的准确性和完整性，这能反映chunk的上下文是否充足。最后还要看系统层的性能指标，比如检索延迟、存储成本，因为chunk切得越细索引越大，这是个需要权衡的工程问题。
跨chunk信息丢失是文档切分的固有问题，完全避免很难，但有几种缓解办法。最直接的是增加overlap，让相邻chunk有重叠区域，关键信息就有更大概率完整出现在某个chunk里。进阶一点的做法是在chunk里注入元信息，比如给每个chunk加上它所属的章节标题或者上一级标题，这样即使内容被切分了，大模型也能通过元信息理解这段话在讲什么主题。还有一种思路是检索时不只返回匹配的chunk，连它前后的chunk也一起返回，这样能补全上下文，代价是会引入一些噪声。这几种方法各有利弊，选哪种要看具体场景，比如对话类数据overlap效果好，技术文档注入元信息更有用。
小-大切分是个很巧妙的设计，它的思路是切分和检索用小chunk，但生成答案的时候用大chunk。具体来说就是文档按小粒度切分比如256 tokens，embedding和检索都基于这个小chunk，保证检索精度。但实际存储的时候会记录每个小chunk对应的大chunk是什么，可能是整个段落或者章节。检索命中某个小chunk后，实际喂给大模型的是对应的大chunk，这样既保证了检索准确性又给了足够的上下文。实现上需要维护一个映射关系，记录小chunk ID到大chunk内容的对应，这会增加一些存储开销，但对答案质量的提升是很明显的。
设计切分策略的时候，要优先考虑业务目标，是追求极致的检索精度还是要控制成本。如果是核心业务场景，可以接受更大的存储开销用小chunk配大overlap；如果是辅助功能，可能512的chunk不设overlap就够了，节省资源。这种权衡思维在实际工程中特别重要，因为很多时候最优解不是技术上最先进的方案，而是业务约束下的平衡选择。通用场景下可以先从512 token起步测试，因为很多embedding模型在这个长度训练得比较充分。然后根据召回率指标调整，如果发现检索结果经常缺少关键信息，说明chunk太小，可以增加到768或1024；如果返回结果有很多无关内容，说明chunk太大，可以降到256或384。overlap一般固定在chunk size的15%左右，这个比例在多数场景下表现都比较稳定。
最终文档切分没有一套参数走天下，必须根据数据特点调整。这个调优过程其实是在不断理解你的数据分布和用户查询模式，找到最适合当前场景的平衡点。保持数据驱动的意识，通过实验验证而不是拍脑袋决定，这比记住所有技术细节更重要。