核心原则
固定长度切分可预测、易缓存，但容易把一个概念切到两个片段中。
递归和结构化切分通常更忠实，因为标题、段落、列表和表格不会被随意打断。
Overlap 能补边界上下文，但过高 overlap 会膨胀索引并让生成阶段看到重复证据。
长文档应区分父子节点：小 chunk 用于召回，父段落用于生成上下文。
不同文档类型应使用不同切分策略，FAQ、合同、表格和长报告不应共用一个默认值。
方法对比
| 方法 | 延迟 | 成本 | 最适合 |
|---|---|---|---|
| 固定长度 | 很快 | 低 | 同质语料和高吞吐系统 |
| 递归字符 | 快 | 低 | 通用文本和 Markdown |
| 语义切分 | 中 | 中 | 长篇分析、手册、白皮书 |
| 句子窗口 | 中 | 中 | FAQ、短章节、法律条款 |
大厂与框架实践
OpenAI file search 的托管默认值适合快速上线，但复杂表格仍需额外评测。
LlamaIndex sentence window 会先召回目标句，再扩展相邻句作为上下文。
企业 ACL 系统常把权限写入每个 chunk，切分太粗会导致可见性过宽。
研发文档适合按标题层级切分，因为用户通常询问模块、接口和异常场景。
合同条款适合按条款编号切分，并把定义条款作为可扩展上下文。
关键论文与参考
DPR，Karpukhin 等，2020
REALM，Guu 等，2020
FiD，Izacard 与 Grave，2021
RETRO，Borgeaud 等，2022
Atlas，Izacard 等，2023
深度讲解
切分可以从 chunk_size、overlap 和 evidence_density 三个维度调参。若 chunk_size=512、overlap=96，一个 10 万 token 文档大约生成 240 个 chunk；overlap 提到 256 后，索引量可能增加 35% 以上。经验上先用 384、512、768 三档做 Recall@5 和 citation accuracy 对比，不要只看向量相似度。伪代码：for size in [384,512,768]: build_index(size); score = recall_at_k(gold_queries, 5)。最终选择应同时满足召回、生成可读性和成本。
最佳实践
先按文档结构切，再用 token 长度兜底。
把 chunk_size 和 overlap 写入索引版本。
对表格、代码和 FAQ 建立专用切分器。