RAG 分块怎么定？先别争 256 还是 512

做知识库的第一天，大家最容易争的就是 chunk size：256，512，还是 1024？数字很整齐，问题却没有因此变简单。

先给一个能复述的答案

分块要同时满足结构完整、检索可区分和上下文可用三个条件。优先沿标题、段落、列表、表格和代码边界切分，再用 token 上限兜底；必要时用重叠窗口和父子块补上下文。最终方案要由真实问题集回放决定，不能脱离任务只比较块长度。

一、先按文档结构切，再按长度兜底

把标题层级、章节路径、来源、更新时间写进每个 chunk 的 metadata。这样召回到一段“缓存策略”时，系统还能知道它来自哪个产品、哪一章、哪个版本。

代码和表格不要当普通段落切。代码需要保留函数或类的边界；表格需要把表头和行绑定，否则召回到一行数字，模型根本不知道列名是什么。

二、四种常见策略怎么选

策略	适合场景	风险
固定长度	资料格式混乱、快速起步	容易截断语义
递归分割	标题和段落层级明显	复杂文档仍需清洗
语义分块	长文、主题变化明显	成本更高，边界需验证
父子块	需要精确召回又要保留上下文	索引与拼接更复杂

父子块是很实用的折中：小块负责被找到，大块负责给模型补充上下文。注意父块不是无限扩大，超过上下文预算后，补上下文反而会把真正证据冲掉。

三、重叠窗口不是保险丝

重叠能降低边界切断的概率，但会带来重复召回、索引膨胀和上下文浪费。经验上先从较小比例开始，拿“答案跨边界”的问题单独统计，再调整重叠量。不要看到召回漏了一句，就把重叠开到 50%；那只是把问题藏进账单里。

四、用问题集反推分块

为每个问题标记最小充分证据：一个段落、两个相邻段落，还是一张完整表格。然后回放检索，看 top-k 是否同时满足“包含必要前提”和“没有引入冲突版本”。这比单纯看向量分数更接近用户实际体验。

60 秒面试回答

“我们的分块不是固定切 512 token，而是先按标题、段落、代码和表格结构切，再用长度上限兜底。对需要精确召回的大章节采用父子块，小块命中后补父块上下文。我们用真实问题集检查证据完整率、无关内容比例、重复率和最终回答引用准确率，按结果调整 chunk size 和 overlap。”

继续追问

• PDF 双栏顺序错乱时，分块前怎么处理？
• 父子块在向量库里如何存储和去重？
• 表格问答为什么常需要结构化解析而不是纯文本切分？