RAG切片策略：固定长度、语义切分与四档预设

结论先行：切片不是“切多长”一个参数，而是“按什么结构切”。固定长度粗暴切块会造成语义断裂；按文档类型用四档预设，才能兼顾召回与上下文完整。

一、固定长度的坑

固定长度切块实现起来最省事：设定一个字数，从头到尾等分，再留一点重叠，几十行代码就能上线。但它也是语义断裂的第一来源。一个定义可能正好落在切点上，被切成两半，前半段单独检索时语义不完整，向量表示随之失真；表格与正文混排时，等长切分还会把行列关系切碎，数字从此和它所属的指标分了家。表现到线上，就是明明库里有一模一样的条款，检索却总是差半句。

这类损伤在结构强的内容上尤其明显：技术文档有编号的小节，合同有层层嵌套的条款，问答对自带一问一答的天然边界，等长切分把这些结构全部抹平。行业里普遍观察到约 80% 的 RAG 效果问题源于数据处理不当，而切块策略是其中最容易被低估的一环。它只适合无结构的纯文本流，不应该作为企业文档库的默认做法。

二、按结构切：章节树到父子 Chunk

更稳的做法是沿文档自身的结构走：先解析出章节树，再把段落原子化，然后按尺寸约束做装箱切片，最后组织成父子 Chunk。顺序是关键——先尊重文档结构，再在结构内做尺寸约束，而不是反过来拿字数去硬套结构。作者把文档分成章节是有语义意图的，切块应该顺着这个意图走。

这样切出来的块有两点保障：一是单块不超过模型上下文窗口，装箱时超长段落会被继续拆分；二是语义边界与写作边界对齐，一个小节讲什么，块里就是什么，命中即相关、引用即完整。文档预处理在企业 RAG 工程里约占 40%–50% 的工作量，把切块做对，是这条流水线里性价比最高的投入之一。反过来，结构错了再调参数也是白费：块与块的边界落错了地方，排序里永远混着邻居话题的干扰块。

三、四档预设按文档类型选

不同文档类型对块大小和重叠的敏感度不同，一套参数通吃注定顾此失彼。我们按文档类型提供四档预设（chunk_size / overlap）：

取值逻辑可以直接照搬：技术文档小节短、术语密，800/150 让块更紧凑，避免一个块里混进三个主题；法律文档条款环环相扣，1500/300 保住上下文，防止引用时断章取义；问答对天然独立，500/100 就够；拿不准时用通用 1000/200 起步，再靠评测数据回调。overlap 的作用是给切点附近的句子留一次被完整看见的机会：太小容易漏，太大则制造大量近似重复块，白白浪费索引空间。

四、切完还要增强

切片不是终点。裸块只有一段原文，检索时能用的信号很有限。每块还应做四级增强：面包屑（章节路径）、关键词、摘要、HyDE 假设问题，让检索时既能精准命中又能理解上下文。这些增强项都在入库前一次性算好存下来，检索时零额外开销。增强细节见 Chunk 四级增强。

工程节奏上也要留心：财报季批量入库时几百份公告一次涌进来，切块参数错了，后面的检索与生成全部跟着返工。稳妥的做法是先用小规模语料做检索冒烟测试，确认参数无误再放量。

切片承接在脱敏与压缩之后。前置的数据处理见 文档清洗 与 脱敏流程；切完如何做父子块见 父子 Chunk。

落地要点：四档预设怎么选

切片参数不需要拍脑袋，按文档类型从预设出发再微调即可：

选档之后还要验证：跑评测看 HitRate@K 与 MRR 有没有因为切片变更回退，而不是凭感觉认为「切得更细 = 更准」。父子两层结构如何在细粒度检索与完整上下文之间取平衡，见父子 Chunk；切片参数变更加回归门禁的做法，见RAG 回归门禁与控制变量实验。

常见问题 FAQ

Q1：固定长度切块为什么不好？

它按字数硬切，容易把一个定义或段落切成两半，单独检索时语义不完整，是语义断裂的第一来源。技术文档、合同这类结构强的内容损伤最明显，建议改按结构切分并配合类型预设。

Q2：四档切片预设分别适合什么？

通用 1000/200、技术 800/150、法律 1500/300、问答对 500/100。技术文档更短更密，法律文档更长保上下文，问答对短小独立；拿不准就从通用档起步，再靠评测数据回调。

Q3：按结构切分的流程是什么？

沿文档章节树 → 原子化 → 装箱切片 → 父子 Chunk。先尊重文档自身结构，再在结构内做尺寸约束，切出的块既不超模型上下文，也不割裂语义边界。

Q4：切片之后还要做什么？

每块做四级增强：面包屑（章节路径）、关键词、摘要、HyDE 假设问题，让检索既能精准命中又理解上下文。同时建议先小规模冒烟再放量，避免参数错了整体返工。