RAGRAG 效果不好十有八九先怪检索模型或者大模型但我们的复盘经验是一半以上的问题出在分块chunking上。块切得太碎语义断裂切得太大检索噪声多。本文记录我们对比四种分块策略的实测过程。四种主流策略固定长度切分按 token 数硬切加 10-20% 重叠。简单粗暴对结构化差的纯文本够用。递归字符切分按分隔符层级段落 → 句子 → 词递归切尽量保留自然边界。LangChain 的RecursiveCharacterTextSplitter是代表是大多数场景的合理默认。语义分块用 Embedding 计算相邻句子的语义距离在语义突变处切分。质量好但成本高每篇文档要多跑一遍 Embedding。父子块Small-to-Big用小块做检索匹配精度高命中后返回其所属的大块上下文完整。这是我们认为性价比最高的进阶方案。实测数据语料320 篇公司内部技术文档含大量表格和步骤说明150 条人工标注测试 query。策略 chunk大小 Recall5 答案准确率 固定256 token 256 0.71 62% 固定512 token 512 0.78 68% 递归512父子块 128/1024 0.86 79% 语义分块 动态 0.84 77%两个反直觉的发现检索指标和答案质量不同步。512 固定块的 Recall5 和语义分块相差不大但答案准确率差 9 个点——大块里混入了干扰段落模型被噪声带偏。这说明评估不能只看检索指标要端到端看答案。父子块赢在两头小块128让检索更精准大块1024让答案更完整等于用两套粒度各干各的活。落地代码fromlangchain_text_splittersimportRecursiveCharacterTextSplitter# 父块给大模型看的完整上下文parent_splitterRecursiveCharacterTextSplitter(chunk_size1024,chunk_overlap100,separators[\n\n,\n,。,,])# 子块进向量库的检索单元child_splitterRecursiveCharacterTextSplitter(chunk_size128,chunk_overlap20)fordocindocs:parentsparent_splitter.split_documents([doc])forpinparents:forcinchild_splitter.split_documents([p]):store.child_vectors(c.embedding,c.text,parent_idp.id)# 检索命中子块后按 parent_id 取回父块送给大模型## 按文档类型定制我们的最终方案不是全局统一而是按文档类型路由 text FAQ/工单类 → 一条一 chunk不切 手册/教程类 → 按标题层级切Markdown 标题就是天然边界 合同/制度类 → 递归切分父子块 表格密集型 → 表格整表一个 chunk附上下文说明分块没有银弹但有方法论先看文档结构再选策略最后用真实 query 验证。别在向量库和模型上猛调参数而让最便宜的分块环节拖后腿。