考察点
切分是 RAG 里投入产出比最高的优化点，面试官想看你有没有为切分策略踩过坑、做过对比实验，而不是只会调 LangChain 的默认参数。好的回答要覆盖：有哪些切分方法、粒度怎么定、overlap 的作用、特殊内容（表格、代码、FAQ）怎么处理。追问一般往语义切分、父子索引、不同文档类型的差异化策略走。
参考答案
主流切分方法
最朴素的是固定长度切分，按字符数硬切，问题是一刀下去经常把一句话、一个表格拦腰截断，基本不能直接用。
工程上最常用的是递归字符切分，LangChain 的 RecursiveCharacterTextSplitter 就是这个思路：按分隔符优先级递归切，中文场景一般配 ["\n\n", "\n", "。", "！", "？", "；", ""]，先保段落，段落装不下再按句子切，尽量让 chunk 边界落在自然语义边界上。
再好一点是结构化切分：markdown 按标题层级切，每个 chunk 带上「一级标题 > 二级标题」的路径前缀；HTML 按标签结构切。这样每个 chunk 自带上下文，「3.2 退款条件」这样的小段落不会丢失它属于哪章哪节的信息。
更进阶的是语义切分：先按句子切，计算相邻句子的 embedding 相似度，在相似度骤降的地方下刀。优点是边界最贴语义，缺点是每条文档要多算一批 embedding，成本高，而且对榜单类、条目类文档提升不明显。
粒度怎么定
没有普适值，但有经验起点：中文知识库场景一般从 300-500 字开始试，英文对应 200-400 token 左右。粒度选择本质是权衡两件事——chunk 越小，向量表达越聚焦、检索越准，但上下文越不完整；chunk 越大，答案素材越全，但噪声越多、embedding 越稀释。正确答案只有一个来源：拿你的评测集跑实验，对比不同 chunk size 下的召回命中率和端到端答案质量，让数据说话。
Overlap 怎么定
重叠是为了防止答案恰好落在切分边界上被切断。经验值是 chunk 长度的 10%-15%，比如 500 字的 chunk 配 50-80 字 overlap。再大就有副作用了：重复内容进库，同一个语义被多个近乎重复的 chunk 占据，召回 top-K 时容易把名额浪费在重复 chunk 上。所以 overlap 不是越大越好，见过有人配 30%，召回结果前 5 条里有 3 条内容几乎一样。
特殊内容的处理
表格绝对不要按字符切，整表作为一个 chunk，转成 markdown 表；表太大就按行组切并给每组重复表头。代码块同理，按函数或类边界切。FAQ 类文档最舒服，一问一答天然就是一个 chunk，甚至可以直接对问题做索引、答案做正文。对于「短 chunk 检索准、长 chunk 生成好」的矛盾，可以用父子切分（small-to-big）：用 100-200 字的小 chunk 做 embedding 和召回，命中后把它所属的完整段落或章节喂给 LLM，检索精度和上下文完整性两头都占。
别忘了元数据
每个 chunk 存上文档名、标题路径、页码、更新时间。生成答案时能做引用溯源，过滤时（比如只查最新版文档）也用得上，这是低成本高收益的做法。
可能的追问
- 语义切分值不值？答：看文档类型和预算。叙述性长文档（报告、论文）提升可见；条目化文档提升有限。它本质是离线成本换召回质量，文档量小可以上，量大先上结构切分。
- 怎么验证切分策略改对了？答：固定其他环节，只变切分，用评测集看召回命中率（标准答案所在 chunk 是否进 top-K）和端到端答案正确率两个指标的变化。
- 多模态文档（图、表、公式）怎么办？答：图表用视觉模型生成文字描述后一起入库，原文保留图床链接，生成时按引用还原。