文档切分（Chunking）怎么做？块切多大合适？

先这样答

先给一个数量级：常见起点是每块 256 到 512 个 token，块与块之间留 10% 到 20% 的重叠，防止句子被切断后两边都检索不到。但这只是起步值，真正管用的是按文档结构切。

结构化切分的做法：按标题层级切，一个章节一块，章节太长再往下按段落细分；表格绝不能从中间切断，整表一块，找不到边界就退而求其次把表转成文字描述；代码按函数切；问答对、FAQ 这种天然成对的，一问一答就是一块。

再往上有两个进阶技巧，面试说出来很加分。一个是父子块检索：检索时用小块去匹配（小块语义单一，向量更准），命中后把它的父块（整节）喂给模型（上下文完整）。另一个是句子窗口：只把命中句子前后各扩展几句的窗口给模型，控制噪音。两个思路的共同点是「检索粒度和生成粒度分开」，这是切分问题里最核心的设计判断。

块切多大没有标准答案，受三个因素拉扯：块太小，语义不完整，检索命中了也答不了；块太大，一条向量揉进好几个主题，检索时容易失焦，而且挤占上下文窗口；Embedding 模型本身有最大输入长度，超长文本会被截断。所以最终数值要靠评测集定，不能凭感觉。

面试官会怎么追问

• 重叠设多少合适？ 起步 10% 到 20%。重叠太多，库里全是重复内容，浪费存储还会把不相关段落带进来。
• 怎么判断切得好不好？ 别看块本身，看检索结果：拿一批真实问题跑召回，统计命中的块是不是完整表达了答案。块内截断句、跨块答案，都是切分问题的信号。
• 多模态文档怎么办？ 图片先走视觉模型生成描述或转表格再入库；纯扫描件先 OCR，OCR 质量差就先修解析，切分救不了解析的锅。

回答的坑

• 只报一个数字（比如「512 token」）不解释依据。数字要跟着三个拉扯因素一起说。
• 忘了提「结构优先」。固定长度滑窗是入门做法，实际项目里文档结构信息是免费的，不用是浪费。