考察点
出自多家公司面经的 RAG 深挖题（「给你一部长篇小说怎么切」是常见变体）。面试官想看你是否真的处理过脏数据：只会说「按 500 字切」的人没干过活，能讲出语义断裂、表格、上下文补全这些坑的才是实战派。追问常往「具体项目里你怎么切的」走。
参考答案
为什么切分是 RAG 的地基
Embedding 模型对单个向量的信息容量是有限的：一段话越长，向量越是对全文的「平均表达」，具体到某个知识点就被稀释了。但切得太碎，一个完整的论述被拆到三个 chunk 里，召回任何一个都答不全。切分的本质是在「语义完整性」和「检索精度」之间找平衡。
四种主流切分策略
1. 固定长度切分：每 N 字切一刀，配 overlap 重叠窗口（比如 500 字 chunk、50-100 字重叠）。实现最简单，但容易在句子中间、表格中间下刀，只适合格式极规整的纯文本兜底。
2. 递归切分（Recursive Character Text Splitting）：LangChain 默认方案。按优先级依次尝试分隔符——先按章节标题切，切完还超长就按段落，再按句子，最后才按字符。保证「能整不切碎」，是通用文档的稳妥起点。
3. 结构化切分：解析文档的固有结构。Markdown 按 # 标题层级切，每个 chunk 带上父级标题路径（如「第三章 > 退货政策 > 特殊情况」）；HTML 按 DOM 树切；代码按函数/类边界切。这是企业知识库的主力方案，因为标题路径本身就是宝贵的上下文。
4. 语义切分（Semantic Chunking）：先按句子切，计算相邻句子的 Embedding 相似度，相似度骤降处认为是话题边界再下刀。切分质量最好但成本高，且对 Embedding 模型本身有依赖，适合高价值文档（法律条款、医疗指南）。
语义被切断的补救手段
- Overlap 重叠：相邻 chunk 保留 10%-20% 重叠，防止答案正好横跨边界。代价是索引膨胀和重复召回。
- 上下文补全：给每个 chunk 前加上所属文档标题、章节路径，甚至用 LLM 生成一句「本段出自 XX 文档，讲的是 XX」（Anthropic 的 Contextual Retrieval 思路），让 chunk 脱离原文也能被独立理解。
- 父子索引（Parent-Child）：小 chunk 用于检索（精度高），命中后返回它所属的父段落给模型（上下文全）。检索粒度和生成粒度解耦，是我项目里效果提升最明显的一招。
- 表格单独处理：表格绝不按行切碎。整表转 Markdown 或 HTML 保留结构，超大表格额外生成一段文字摘要用于检索，命中后返回原表。
经验值
中文通用文档：chunk 300-500 字、overlap 50 字起步，按结构切分 + 标题路径注入，配合父子索引。chunk 大小没有银弹，最终靠评测集说话——固定检索模型，扫 256/512/1024 三档看 Recall@5 选最优。
可能的追问
Q：给你一部长篇小说怎么做切分？ 按章节结构切分，每章先让 LLM 生成摘要建两级索引：摘要做粗召回定位章节，章节内段落做细召回。人物关系、时间线这类跨章节的实体信息单独抽出来建实体表，不走通用切分。
Q：overlap 是不是越大越好？ 不是。overlap 超过 20% 后，索引体积和重复召回（Top-K 被同一处内容占掉多个名额）的代价开始超过收益，一般在 10%-15% 折中。
Q：PDF 里的图表怎么切？ 图表本质是模态问题不是切分问题。工程上两种路：多模态 Embedding 直接把图编码进索引；或者让多模态模型先把图表转成文字描述再入库，检索命中后按需取原图。