一份合同，条款散在三个 chunk，检索只回一个，答案自然漏。切分不是切完就完，切法直接决定检索上限，很多人却从头到尾没评过。
一、切分策略无统一标准
常见四种，各有适用，也各有坑。先给一组工程里常用的经验值，方便参考落地。
固定长度按字数或 token 切，通用、实现简单，chunk 大小常取 300 到 500 token。
按句子切，适合正文文章，长句和列表仍可能断。
递归切分优先在段落、句子边界断，层级分明的文档友好，chunk 大小常取 512 token 配 10% 到 20% overlap。
语义切分按意思聚簇，主题混杂长文好用，但聚类参数敏感、成本高。
overlap（相邻 chunk 故意保留的重复内容）是缓解边界断裂的常规手段，默认留 10% 到 20%，太小边界仍裂，太大会让重复内容污染排序。
二、切分策略的四类典型缺陷
切分没有标准答案，但四个坑都在没想清边界就切。
最常被忽视的第一个：切太碎，语义拦腰断。固定 200 字把一句话切开，检索命中半句，生成拿到残片。实测一个 FAQ 用 200 字切，命中率比 500 字切低近三成，意味着答案常跨在两个碎片里，你捞回的只是半句，生成只能靠编补全。
第二个坑是第一个的反面：切太大，超了 context 大小。整篇文档当一个 chunk，检索是召回到了，但喂不进去，白召回。超长合同、整本手册最易踩，得按生成模型 context 上限反推 chunk 上限。不是切大点更稳，是大到喂不进就归零。
第三个坑在结构：表格、代码、条款按行硬切，一张参数表裂两半，语义碎一地。代码按 500 行切，一个函数被拦腰断开，检索命中上半截，生成补的下半截是编的。这种错最隐蔽，因为召回率正常，你以为没问题。
第四个坑最阴：上下文污染。检索命中目标 chunk，但相邻无关 chunk 一起进 context，噪声淹了重点，生成被带偏。召回率看着正常，答案却越来越离谱。前三坑是切坏，这一坑是切好但被邻居拖累。
四种边界适用场景及风险如下：
没有零风险的切法，评测该盯的是切完之后的检索命中质量，不是切法本身好不好看。
三、切分质量的度量与评测
核心不是比切法，是比切完后的检索表现。具体做法：固定同一批 query 集、固定同一个检索器和重排，只换切分配置，跑 Recall@K 和答案 Faithfulness，哪个高用哪个。这样排除了其他变量，结论才干净。
污染怎么量化？定义污染率等于进入 context 的无关 chunk 数 / 进入 context 的 chunk 总数。目标 chunk 进 context 时，看旁边跟着多少无关邻近 chunk。污染率建议压到 30% 以下，超过就说明 overlap 太大或邻近窗口太宽，要收。
overlap 也要做消融：固定切法，分别试 0%、10%、20% overlap，看 Recall@K 和污染率怎么走，取平衡点。常见是 10% 到 15% 最稳，再往上污染率涨得快、召回收益却变小。
四、成熟度适配参照
五、落地实践：分步落地，兼容现有体系
切法不宜盲从，应以数据择优。以下两个实例。
代码文件按 500 行切，一个函数被拦腰断开，检索命中上半截，生成补的下半截是编的。改成按函数边界切、overlap 留 15%，同一 query 的召回从 0.5 提到 0.82。政策 PDF 按页切，一条跨页条款裂成两页，检索只回一页，答案缺后半句；改成按条款块切、保留结构，Faithfulness 通过率从 0.7 拉到 0.91。
切分配置清单，第一次评测照着填就行：chunk 大小、overlap 比例、边界按句还是段还是结构、要不要保留表格代码这类结构块、邻近窗口宽度。这五项定下来，切法才算被定义过，不定下来，评测无从谈起。
本文建议
- S（具体）：两周内对核心知识库对比至少 2 种切法，以检索指标选优并定污染上限。
- M（可衡量）：query 集大于等于 30 条；Recall@5 与 Faithfulness 双指标对比；邻近无关 chunk 占比设阈值。
- A（可达成）：复用现有切分与向量库，只加对比脚本。
- R（相关）：承接 F-01 拆分与 F-02 检索质量，是检索命中的前置地基。
- T（时限）：知识库结构变更前重测切法；切法配置随 CI 版本化。
