为什么你的RAG效果不佳核心痛点LLM强大,Prompt精心调校,但答案仍不准确检索算法和Embedding已优化,却忽略分块(Chunking)关键结论“不恰当的分块给模型喂’坏数据”分块质量决定RAG性能的下限分块的本质分块的必要性LM上下文长度限制-向量检索对语义完整性的依赖理想分块标准平衡信息密度与上下文完整性用chunk_size控制大小,chunk_overlap保连续关键参数chunk_size每一个分块的长度:256/512/1024(token或字符)chunk_overlap相邻块之间重复部分重叠是为了防止语义断裂: 10%-20% of chunk_size分块的策略基础分块固定长度核心思想按固定字符数切割文本,不考虑语义结构优点实现简单缺点易破坏句子完整性不推荐语义割裂风险高递归字符推荐保段落/句完整、通用性强、绝大多数场景核心思想按优先级分隔符递归切分(/n/n→4/n→ ,尽量保留段落、句子完整性适用场景绝大多数通用文本的首选策略首选方案平衡效果与效率按句切分语义完整、中文需特殊处理、法律、新闻核心思想以完整句子为单位进行组合,确保语义完整适用场景法律文书、新闻报道、对句子完整首选方案高语义要求领域结构感知利用文档“骨架”进行分块。Markdown/HTML按照标题层级切分自动保留元数据。对话记录按发言人/轮次切分保持对话逻辑。优势上下文更完整支持后续元数据过滤与处理。语义/主题语义分块(Semantic Chunking)使用Embedding模型把每一个句子转化成向量再去计算相邻的句子之间的向量相似度如果向量相似度超过一定的阈值那么就合并成一块然后再把下一个句子和合并后的块再做一个比较如果相似度下降不满足阈值了那么就进行切分。原理:计算句向量相似度,在语义突变处切分工具:langchain_experimental.SemanticChunker调参关键:breakpoint_threshold_amount(70起调)主题分块(LDA)适合长文档,但不稳定,需大量调参高级策略小-大分块小的文本块利于检索但是上下文少因此生成答案时信息不做大的文本块信息很丰富但是噪声很大命中率会下降结合小块检索的高精度和大块生成的高上下文优势。检索时使用细粒度的小块确保相关性,生成回答时则将其对应的大块父文档作为上下文,提供更丰富的信息核心工具:ParentDocumentRetriever代理式分块赋予LLM判断能力,使其能像人类专家一样,根据问题动态识别文档中的知识单元。这种方法能产生极高质量的分块,但抖算成本也最高。适用场景:高价值小规模知识库混合分块——复杂文档的最佳实践策略死的人是活的实际分块可以灵活使用策略。策略:先结构粗切→再语义/递归细切结合文档的天然结构(如章节、段落)进行初步划分,再对大块内容进行语义或递归的精细切割。适用场景:技术白皮书、年报、多格式混合文档特别适合处理包含多种元素(文本、图表、代码)或逻辑层次复夏杂的长文档如何选择最佳策略看数据类型:结构化文档(如PDF、Markdown)?对话记录?还是无格式纯文本?看业务需求:追求高精度的检索效果?还是需要支持长上下文的生成任务?看资源成本:能否承受LLM语义分块带来的计算开销和延迟?策略对比速查表策略复杂度适用场景推荐度固定长度★★☆☆☆简单文本★★☆☆☆送归字符★★★☆☆通用首选★★★★★结构感知★★★★☆技术文档★★★★☆语义分块★★★★★多话题文本★★★☆☆小-大分块★★★★☆高要求QA★★★★☆代理分块★★★★★实验性项目★★☆☆☆没有银弹:必须根据数据迭代优化。始于简单,终于复合:从递归分块建立基线。分块即建模:你怎么切,就怎么理解知识。实用建议清单优先用RecursiveCharacterTextSplitter做基线中文分句:用正则或HanLP,别用 nltk.punktchunk_overlap 设为10%-20%长文档→混合策略语义分块从 percentile70开始调小-大分块→高要求系统首选代理分块→慎用于生产掌握分块,就是掌握RAG系统的命脉。