长文档 Chunking 怎么选?

回答与解析

核心策略对比

专业领域特殊考量

医学场景

• 特点：术语长、症状-诊断-治疗链条长、表格多
• 推荐：递归切块+语义边界混合，保留完整病例段落；表格单独处理或作为metadata
• 块大小：512-1024 tokens，过小会切断诊疗逻辑

法律场景

• 特点：条款引用多（"依据第X条"）、层级结构严格（编-章-节-条）
• 推荐：结构化解析优先，按条款编号切分；添加父级标题作为上下文前缀
• 特殊处理：法条引用关系需建图索引，不依赖纯文本切块

关键权衡

• 粒度vs召回：块越小检索准但可能丢上下文，块越大完整但噪声多
• 建议：实际采用多粒度索引——小chunk用于精排，大chunk（或父文档）用于生成时补充上下文

评估方法

• 检索侧：Top-K命中率、MRR
• 生成侧：答案完整性人工评分、引用准确率

学习建议

建议从基础切块方法（如固定长度、按段落）入手，理解其在专业文档中的局限；再学习语义切块等高级策略，结合实际案例练习分块设计。

口语版讲法(约4分钟)

• 本质：在语义完整和检索效率之间做平衡
• 边界划分：固定长度 vs 语义边界 vs 结构化切块
• 业务场景：法律条款引用，按编号切+父标题前缀
• 落地风险：切块破坏引用链，多粒度索引兜底
• 工程师判断：混合策略+评估闭环

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

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

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

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

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

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

关键一句:切块时如果不做实体归一化，同义术语会导致检索遗漏。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们给医院做个病历问答系统，用户问‘糖尿病患者的用药禁忌’，病历里可能包含一整段医嘱。你怎么把几页的病历切成小块，既保证检索时能找到，又不会丢失‘禁忌’和‘用药’的关联？

2. 问法 2 · 层层追问

   做RAG时文档切块你会怎么切？……如果文档是法律条文，有编章节条款，直接按固定长度切好不好？……那对于医学指南，里面有很多术语和逻辑链条，你用什么策略来保留语义完整？

3. 问法 3 · 直球架构

   设计一个面向专业领域的RAG系统的文本切块模块，要系统性地列出常见策略，分析它们的原理、优缺点，并针对医学和法律场景说明你推荐哪种切法以及为什么。