检索是 RAG 系统的搜索引擎分块则是这个搜索引擎的基础。分块太长、太短、有噪声、切错了位置——随便犯哪个错LLM 都会有问题。行业里有句话流传很广分块决定了 RAG 质量的 70%。这个说法不夸张好的分块让检索器拿到完整、有上下文、真正相关的信息差的分块把文档打成碎片上下文断裂LLM 只能靠编来填补空白。什么是分块RAG 的起点是文档收集与摄取把所有原始材料文档、文章、知识库条目汇聚到一起。在进入检索环节之前这些文档要经过文本分块处理也就是切分成更小的、有意义的片段。每个分块应当是连贯且自包含的这样检索器才能在面对查询时快速定位、排序并返回最相关的信息。分块就是在生成 Embedding 之前把大段文本拆成更小语义单元的过程。检索器真正搜索的对象而不是整篇文档就是这些分块。分块做得好文档中的内容就能被干净地捕获上下文得以保留LLM 能做出有意义的推理。分块做得差语义被割裂检索充满噪声。向量存储、Embedding 模型、Reranker——这些统统排在分块之后分块才是真正的起点。固定大小分块这是最简单的方式。按预设的字符数或 Token 数直接切分比如每 500 个 Token 一块完全不管句子和段落的边界在哪。速度快行为可预测处理大规模、结构混乱的数据集时很实用。但缺点也很明显——语义经常被拦腰切断。一个句子在这个分块里开了头到下一个分块才结束Embedding 的语义表达力就会打折扣。实践中一般会在相邻分块之间设置一定的重叠来缓解这个问题from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_text(long_text)切分文本时连续的分块之间通常会加入一小段重叠区域来维持上下文的连贯。所谓重叠就是前一个分块的尾部几句话在下一个分块的开头再出现一次。这么做是为了防止跨越分块边界的关键信息丢失。没有重叠的话检索器可能只拿到部分内容LLM 因此漏掉了关键上下文给出残缺甚至误导性的回答。重叠量一般控制在分块长度的 10% 到 20%在冗余和效率之间找一个平衡点。固定大小分块适合的场景包括日志文件、邮件、代码仓库以及结构参差不齐的大型语料库。基于句子的分块这种方式按完整句子来划分文本而不是按任意长度一刀切。每个分块至少包含一个或多个完整的句子语法完整语义连贯。好处是每个分块都是一个有意义的思想单元。检索器向 LLM 返回的信息更精确、更易理解碎片化回答的风险降低不少。实际使用中通常也会搭配小幅重叠进一步保证分块之间的衔接。基于段落的分块以完整段落为单位切分不再拘泥于单个句子或固定 Token 数。这种方式天然保留了文档的结构和行文节奏检索器更容易抓到完整的想法。每个分块往往对应一个独立的主题或子主题LLM 处理起来更从容也更容易给出准确的回答。对长篇文档、研究论文、综述类文章来说段落级分块效果不错。和句子级分块一样也可以加重叠来保持连贯。语义分块语义分块的切入点不是长度而是语义本身。它利用 Embedding 或相似度分数来识别文本中天然的断裂点——主题切换、上下文转折、章节边界。产出的分块语义清晰度更高边界和语义对齐检索质量有明显提升尤其在知识库、技术文档、结构化文章这类内容上效果突出。代价是计算开销更大而且分块长度不一致后续处理需要额外考虑。from langchain_experimental.text_splitter import SemanticChunker from sentence_transformers import SentenceTransformer model SentenceTransformer(all-MiniLM-L6-v2) chunker SemanticChunker(model, breakpoint_threshold0.4) chunks chunker.split_text(long_text)如果文档质量高、主题流转有明确脉络语义分块往往是精度最高的选择。递归分割递归分割是固定大小和语义分块之间的一个折中方案。核心思路是优先尊重文档结构只有在必要时才进一步拆分。具体做法是先尝试按标题切分。如果某个章节还是太长就按段落切。段落还不够就按句子。句子仍然超限最后才按字符兜底。这样得到的分块既保有语义完整性尺寸也在可控范围内。recursive_splitter RecursiveCharacterTextSplitter( separators[\n## , \n### , \n, . , ], chunk_size600, chunk_overlap80 ) chunks recursive_splitter.split_text(long_doc)开发者文档、技术手册、学术论文、研究报告——凡是层级结构明确的内容递归分割都很适合。滑动窗口分块有些文本的语义天然是跨句分布的。法律合同、科学论文、长段论证一个完整的意思可能横跨好几个句子。滑动窗口就是为这种场景设计的。它不生成彼此独立的分块而是创建相互重叠的窗口。比如窗口大小 400 Token每次滑动 200 Token这样相邻的分块之间有一半的内容是共享的语义在边界处不会断裂。上下文保持得很好但分块数量会膨胀存储和检索的成本都会上升。法律 RAG、金融分析、医学文献检索、合规审查——这些领域用滑动窗口的比较多。层次化分块层次化分块是一个多层级的架构小分块负责细粒度精确检索中等分块支撑平衡的推理大分块维持全局上下文。检索时系统先用小分块锁定精确位置再把关联的大分块拉进来补充完整上下文。这种组合能有效压制幻觉提升推理的深度。企业级 RAG 系统和 LlamaIndex 这类多粒度检索框架背后都有层次化分块的影子。实践中常见的分块失误多数 RAG 项目翻车根源都是分块层面的问题。分块过大模型被不相关的细节淹没。分块过小语义丧失殆尽。句子被拦腰切断、不相关的段落被混到一个分块里Embedding 质量直接垮掉。没有重叠上下文断裂。没有元数据检索器找不到方向。还有一个常见错误——所有类型的文档套用同一种分块策略。分块没有万能方案。政策文件和教科书不一样通话记录和研究论文不一样。策略必须跟着文档类型和检索任务走。总结分块不是一个可有可无的预处理环节它是 RAG 管道的脊梁。好的分块是一个有意义的、自包含的知识单元差的分块是一个孤零零的碎片把 LLM 带向歧途。检索是引擎分块是燃料。燃料的质量决定了整个系统是输出干净、可靠的结果还是不断产出噪声和幻觉。LLM 本身再好也救不了烂分块。