完整题目
在RAG或文档处理项目中，文本分块（chunking）有哪些常用策略？请比较不同分块方法的优缺点和适用场景。
答案要点
- 固定长度分块（Fixed-size）：实现简单但可能切断语义
- 递归分块（Recursive）：按层级结构分割，保留上下文
- 语义分块（Semantic）：基于语义相似度，切分更自然但计算成本高
- 文档结构感知（Document-specific）：利用标题、段落等天然边界，适合结构化文档
- 重叠窗口（Overlap）策略缓解边界信息丢失问题
文本分块是RAG系统的关键预处理环节，直接影响检索质量和生成效果。常用策略可分为以下几类：
1. 固定长度分块（Fixed-size Chunking）
- 按固定token数或字符数切分，具体长度作为候选变量
- 优点：实现极简，便于批量处理，向量化效率高
- 缺点：硬截断可能切断句子语义，边界信息易丢失
- 适用：快速原型、对语义连贯性要求不高的场景
2. 递归分块（Recursive/Hierarchical）
- 按段落→句子→词的层级递归切分，优先在天然边界（换行、句号）处分割
- 优点：保留文档层级结构，块内语义相对完整
- 缺点：块大小不均匀，可能产生过短块
- 适用：Markdown、HTML等有结构标记的文档
3. 语义分块（Semantic Chunking）
- 先按句子切分，计算相邻句子embedding相似度，低相似度处作为切分点
- 优点：切分点符合语义边界，检索相关性高
- 缺点：计算成本高，需预设相似度阈值
- 适用：高质量问答系统、对精准度要求高的场景
4. 文档结构感知分块
- 利用PDF的标题、章节、表格等元信息，按逻辑单元切分
- 优点：块与业务语义对齐，检索结果可直接用于生成
- 缺点：依赖文档解析质量，需针对不同格式定制
- 适用：合同、论文、报告等结构化文档
工程实践建议
- 多数场景应先比较结构分块、递归分块与不同重叠窗口，用同一评测集权衡效果与成本
- 块大小候选由Embedding输入限制、文档结构、查询类型和LLM上下文预算共同决定
- 复杂场景可组合策略：先结构分块，大块再语义细切
换一种问法，检查是否真正理解
场景切入
假设你在做一个企业内部的知识库问答系统，文档有长有短，有的几百字，有的几万字。你打算怎么把这些文档切成小块去索引？你实际项目里试过哪些分块方法？
层层追问
RAG里文本分块一般怎么做？……那如果文档是Markdown或者PDF带标题的呢，你会怎么切？……好，那要是对检索质量要求很高，比如法律合同问答，你又怎么选？
直球架构
说说文本分块的常用策略，比较一下固定长度、递归、语义、文档结构感知这几种的优缺点和适用场景。
练习口述回答 · 约4分钟
- 定位：分块本质是平衡语义完整和检索粒度
- 固定切分 vs 语义切分：场景边界
- 业务案例：企业SOP文档的分块策略
- 落地风险：块大小与重叠窗口的工程选择
- 收尾：我的取舍和延伸可延伸点
这道题其实不是在问你会哪几种切法，而是在考你，面对一个真实业务，你知不知道怎么在语义完整和检索粒度之间做取舍。说白了，[[分块]]没有银弹，只有场景匹配。
先说最直接的固定长度分块，按token数直接切分，具体长度作为候选变量，实现简单。原型阶段我经常先用它，因为快，[[向量化]]批量处理效率高。但你要是拿它去搞客服退款政策这种场景，用户问「我退货了怎么还没退款」，固定切块很可能把「退货条件」和「退款流程」切成两块，检索出来上下文就不全。所以它的边界很清楚：只适合对语义连贯性要求不高的场景，比如快速验证、或者文档本身就没啥逻辑结构。
反过来，语义分块就聪明多了。先按句子切，算相邻句子的 Embedding 相似度，相似度低的地方断开。这招在高质量问答系统里特别好用，比如企业内部的SOP文档，每个操作步骤之间语义天然有断点，按这个切，检索出来的块基本就是完整的一步操作，生成答案时几乎不用再拼上下文。但代价也明显：计算成本高，而且相似度阈值很难调，调高了切太碎，调低了又切不断。所以它的适用前提是，你对检索精度要求极高，且愿意为离线处理花时间。
真实业务里，大部分场景我会走混合路线。举个例子，处理企业合规文档，比如合同或操作手册，我会先用文档结构感知分块，利用PDF里的标题、章节号这些天然边界，把文档切成逻辑单元。然后对每个大块，比如一个章节，再用递归分块按段落和句子切，同时比较零重叠、短窗口和较长窗口，用同一评测集验证是否缓解边界信息丢失。这样既能保证块和业务语义对齐，又不会漏掉跨段落的上下文。
这里有个坑。很多人觉得块越小检索越准，其实恰恰相反。块太小会导致检索结果碎片化，生成阶段拼起来容易 [[Hallucination]]。块太大又会让检索结果模糊，召回一堆不相关的。我会根据Embedding输入限制、文档结构、查询类型和LLM上下文预算提出多组块大小候选，再以评测结果选择。上线我会特别关注块大小的分布，如果发现很多块长度差异过大，比如有的20 tokens有的500 tokens，那就要调整递归的层级参数。
其实还有一个方向值得深挖，就是分块策略怎么和 [[Rerank]] 配合。比如语义分块切出来的块，有时边界还是不够准，如果后面接一个 [[Cross-Encoder]] 重排，就能把切得不好的块里真正相关的片段捞出来。但这就引出另一个问题，重排的延迟怎么控制，对吧？
所以总的来说，我更倾向把分块看成一套可配置的管道，而不是一个固定的算法。先根据文档类型选主策略，再用重叠和重排兜底，最后用线上指标比如 Recall@K 去反推分块参数合不合理。