长文档 Chunking 怎么选?

这道题其实问的是，在专业领域里怎么在语义完整性和检索效率之间做平衡。说白了，[[切块]]本身不是目的，目的是让召回的内容既准又全，还不丢上下文。

先说常见的切分策略，它们的适用边界其实很清楚。固定长度切块最简单，按字符或token硬切，但很容易把一句话或一个逻辑链条切成两半，比如医学里'症状-诊断-治疗'这种长链条，切断了召回就废了。所以它只适合快速原型，线上我一般不用。语义边界切块，比如按句子或段落切，能保住语义完整，但句子长短不一，法律条文里一条可能就几十个字，而医学指南一个段落能上千字，处理起来很麻烦。递归切块算是折中，先按大结构切，超长了再细分，能保留文档的层次感，比如论文的章节、法规的条款编号，这类结构化文档就特别适合。

真正到业务里，我很少只用单一策略。举个例子，处理法律合同或法规文档时，条款之间互相引用很常见，'依据第X条'这种，如果按段落切，引用关系就断了。我的做法是优先做结构化解析，按条款编号切分，同时把父级标题比如'第三章 合同履行'作为上下文前缀拼进去。这样每个chunk自带层级信息，检索时能理解'这个条款属于哪一章'。

这里有个坑，就是切块粒度太小会丢上下文，太大又带进噪声。比如医学指南里一个诊疗流程可能跨好几页，切小了召回不完整，切大了top-K里混进不相关的部分。所以落地时我倾向于多粒度索引，小chunk用来做初排，大chunk或者[[父文档]]用来在生成阶段补充上下文。这样检索精度和生成质量都能兼顾。

另外，光切块还不够，专业领域里术语和[[实体链接]]很重要。比如法律里的'甲方'、'乙方'，医学里的'阿司匹林'和'乙酰水杨酸'是同一种药，如果切块时不考虑实体归一化，检索可能对不上。这块我一般会配合[[NER]]和实体链接来做，但切块本身的设计是基础。

最后，评估很关键。上线前我会拿一批典型query测Top-K命中率和MRR，再人工抽检生成答案的引用准确率。说白了，切块策略没有银弹，得根据文档结构和业务场景反复调。我更倾向先用递归切块加结构化解析打底，再用多粒度索引兜底，配合评估闭环持续优化。