字节面试官追问：你的 Chunk 为什么一刀切？RAG 切分策略怎么讲才像真做过

很多人做 RAG，最容易被面试官问穿的不是模型，也不是向量库，而是一个看起来最基础的问题：

你的 Chunk 是怎么切的？

表面上看，这像是个实现细节。

但只要面试官继续追几句，问题就会迅速变成：

• 标题和正文被分开了怎么办
• 表格切成两半了怎么办
• 列表项离开前导句之后还看得懂吗
• overlap 设多少，为什么不是更多也不是更少
• 你怎么证明切出来的块真的适合回答问题

这也是为什么很多人一上来回答“我们按 512 token 固定切分”之后，整段表达很快就开始发虚。

因为 Chunk 切分从来不只是“把长文本切短”。它真正决定的是：

• 检索到底召回的是完整信息，还是碎片
• 大模型拿到的是可回答单元，还是残缺语义
• 你的知识库更像资料库，还是更像噪声池

对 Interview AiBox 这种面试产品来说，Chunk 质量更重要。因为用户面对的是追问链路，不是一次性问答。块切坏了，第二轮第三轮很容易直接露馅。

先看主思路：我们不是按长度切，而是按“可回答单元”切

一、为什么固定长度切分经常不够用

固定长度切分的优点确实很明显：

• 简单
• 快
• 容易实现

所以它很适合做基线方案。

但它的问题也同样明显：它根本不知道语义边界在哪里。

如果一段条款刚好在“以下情况除外”那里被截断，你召回到的上一个块可能只剩“承保范围”；而免责条款已经跑到了下一个块里。

结果就是：

• 检索看起来命中了
• 生成看起来很流畅
• 但答案方向其实已经错了

这类错误在知识问答里已经很危险，在面试场景里会更糟。因为用户不是只问一次，后面还会继续追：

• 为什么这样设计
• 哪些情况例外
• 这个方案的风险在哪

如果系统拿到的是碎片化上下文，第二轮开始就会明显失真。

二、真正成熟的 Chunk 策略，通常会先理解结构

很多人讲切分，直接从 token 数开始讲。

但在真实系统里，先看结构往往比先看长度更重要。

因为文档里本来就存在天然的语义边界：

• 章节标题
• 子标题
• 段落
• 列表
• 表格
• 代码块
• 问答对

这些边界如果被保住，后面的召回和回答会自然稳定很多。

所以更像真做过的说法通常是：

三、表格、列表和标题，为什么最容易把人问住

面试官追问 Chunk，最喜欢从这些地方下手，因为它们最能区分你到底有没有处理过真实数据。

四、Overlap 不是越大越好，而是越有边界感越好

很多人一听到 overlap，就会本能地觉得“多一点更安全”。

但 overlap 不是越大越优。

它真正解决的是：

块与块之间断开后，最容易丢的那部分连续性。

如果 overlap 太小，语义衔接不够。

如果 overlap 太大，又会带来几个副作用：

• 重复信息太多
• 存储和检索开销变大
• 重排阶段容易被相似重复块干扰

所以更合理的说法不是：

我们固定 overlap 100 token。

而是：

我们会在保留连续性的前提下，让 overlap 尽量贴近完整句子、完整列表前导、或完整语义边界，而不是机械从字符中间截一刀。

这类表达更能说明你理解 overlap 的本质，而不是只记住了一个数字。

五、为什么我们更关心“可回答单元”，而不是“标准长度块”

在 Interview AiBox 的面试场景里，Chunk 的价值不在于整齐，而在于能不能支撑回答。

一个真正有价值的块，通常至少满足几件事：

• 主题明确
• 自包含程度高
• 带着必要的标题或来源上下文
• 不依赖太多前后块才能被理解
• 被召回后可以直接成为回答证据

这就是为什么我们更喜欢把 Chunk 看成“可回答单元”。

例如：

• 一个完整项目经历
• 一个完整问答对
• 一个完整对比表局部
• 一个完整系统设计子模块说明

如果块切出来之后，本身就适合被引用，那么后面的召回和生成层压力都会小很多。

六、Chunk 元数据常常决定你后面的上限

很多人把 Chunk 当成“文本加向量”就结束了，但这远远不够。

在实际系统里，Chunk 通常还应该带上足够的元数据，帮助后续：

• 过滤
• 重排
• 回溯原文
• 拉取相邻上下文

比较常见的元数据包括：

• 文档 ID
• 页码或段落编号
• 所属章节路径
• 内容类型
• 前后块关系
• 是否是关键条款或关键项目证据

这些信息在面试场景里尤其有价值。

因为很多时候用户不是只要“相关内容”，而是要：

• 最新版
• 当前岗位版本
• 更像项目结果的证据
• 更适合追问回答的素材

如果元数据层没有准备好，这些能力就很难在在线阶段再补回来。

七、面试里怎么把 Chunk 策略讲得更像真做过

如果面试官问：

“你的 Chunk 怎么切的？”

比较弱的回答是：

我们按 512 token 切，再加一点 overlap。

比较强的回答，通常会按这几个层次展开：

FAQ

固定长度切分是不是一定不行？

不是。它可以作为基线方案，尤其在数据相对规整时很实用。但如果文档结构复杂、表格多、追问多，通常需要更强的结构感知策略。

Overlap 应该设多少才对？

没有放之四海而皆准的数字。关键不是多大，而是是否保住了连续性，同时没有把重复信息推得过多。

为什么面试官这么喜欢追问 Chunk？

因为这个问题能快速分辨你到底有没有处理过真实知识库。只会背“512 token”通常不够，一旦涉及标题、表格、列表和异常结构，就很容易露出经验深度差异。

下一步

• 想看 Chunk 之前的知识底座怎么建，可以继续读面试场景下，我们的 RAG 方案
• 想看召回质量如何被切分策略直接放大，可以继续读知识库召回质量提升93%
• 想看 Query 为什么不能都走同一条检索链路，可以继续读为什么你的 RAG 不能把所有 Query 都丢进向量库
• 想看系统设计场景下怎么组织整条链路，可以继续读RAG 系统设计面试全攻略