Chunking 粒度怎么定?固定切分会出什么问题?

Q2-03Chunking高频Chunkingchunk sizeoverlap参数调优

谁在问:一面必问;是验证「有没有真跑过数据」的第一道探针

口语化问法

  • 你们 chunk 切多大?为什么是这个数?
  • overlap 设多少?
  • 直接按 512 个字切有什么问题?

考察意图

看似送分,实则是参数题里最好的探针。面试官想看:① 你能不能讲清「太大太小各坏在哪」这对矛盾;② 你的参数是抄来的还是测出来的;③ 你知不知道 token 和字符的区别(中文场景踩这个坑的人极多)。答一个数字就结束的,基本被判定为只跑过 demo。

参考答案

图 2 · 60 分与 90 分差在哪:代价、演进、怎么验证

60

60 分答案(及格线)

核心是平衡语义完整性和检索精度。切太大:一块里混了多个主题,向量被稀释,检索精度下降,还浪费上下文预算;切太小:语义不完整,代词失去指代,模型拿到碎片答不对。工程上常用 300–500 token,overlap 取 chunk 的 10%–20%(比如 512 配 64~100)。固定长度切分的问题是完全不管语义边界,可能把一句话从中间切断——一句关键的话被切成两半,两块单独看都不成话,检索就永远捞不到。

90

90 分答案(有生产经验的回答)

补三层:

  • 不用固定切分做生产:递归字符切分才是默认起点(按 \n\n\n → 句号逐级递归,尊重自然边界又控制长度);规范文档(手册、法规、API 文档)用结构感知切分按标题层级切,效果通常最好。
  • 参数是测出来的:给 chunk 大小和 overlap 各测两三档,用自建评测集看分桶 recall@k,取拐点。同时说出中文的坑——按字符数设参会超预期,中文同样字数比英文更耗 token
  • 对 overlap 保持清醒:10–20% 是常见起点,但有研究在特定检索配置下测出 overlap 没带来可测收益、只增加索引成本。所以它是「默认开启的保险」而非必然有效;如果已经用了结构感知或父子分块,overlap 的必要性会明显下降,因为边界本身就落在语义分界处。

再加一个加分动作:最有效的排查手段是随机抽 20 个 chunk 人眼读一遍——语义断裂肉眼可见,比调任何参数都快。

追问链

图 1 · 五层追问树:面试官会往哪儿挖
参数题探针:从「切多大」一路挖到「一套参数够不够用」

  1. 这个 512 是你测出来的还是默认值?怎么测的?

    期望建 100–200 条评测集 → 按问题类型分桶 → 对比几档参数的 recall@k / MRR;答「用的默认值」不扣分,但必须说得出怎么验证默认值够不够
    信号说不出任何验证方法 → 参数就是抄的
  2. 中文场景设这个参数要注意什么?

    期望token ≠ 字符,中文 token 效率低于英文、同样字数消耗更多 token;应按 token 数设参并用对应 tokenizer 计数;还要看 embedding 模型的最大输入长度,超限会被静默截断
    信号完全没意识到中英 token 差异 → 多半没处理过中文语料
  3. 一句话正好切在两个 chunk 边界上,除了 overlap 还有什么解法?

    期望结构感知切分(按标题/段落边界,边界天然落在语义分界);父子/小到大分块(小块检索、回溯父块作答,同治「切大了检索不准」与「切小了上下文不全」);语义切分(按句间相似度断崖下刀)
    信号只知道 overlap 一种解法 → 基础级;说得出父子分块 → 明显进阶
  4. 什么时候值得上语义切分?它的代价是什么?

    期望代价是每个句子都要算一次 embedding,索引成本明显上升;所以顺序是先用递归切分做基线 → 评测显示分块确实是瓶颈时再上,不要一上来就用最贵的方案
    信号把语义切分当默认推荐、不谈成本 → 缺乏工程节制
  5. 你们知识库里有大量表格和长条款,这套参数还适用吗?

    期望先否掉前提:「一套参数走天下」本身就是错的 → 按文档类型分流:表格整表作为一个 chunk(Markdown 格式)并额外生成一句自然语言摘要做检索向量;长条款按条目边界切;代码按函数/类边界(AST)切
    信号坚持用一套全局参数 → 说明只处理过同质语料
看似送分,第 1 层就分流:报得出数字却说不出怎么测的,当场判定只跑过 demo;第 5 层再看你会不会按文档类型分流,而不是一套参数走天下。

评分要点

  1. 讲清「太大太小各坏在哪」这对矛盾
  2. 给出具体参数量级(如 300–500 token、10–20% overlap)
  3. 知道固定切分不适合生产,递归/结构感知才是默认起点
  4. 说得出参数的验证方法(评测集、分桶)
  5. 知道中文 token 与字符的差异
  6. 加分:知道父子分块或语义切分及其代价
  7. 加分:对 overlap 的收益保持实证态度而非教条

常见错误

只报一个数字(「512 加 50」)就没了,答不出理由和验证方法。
按字符数设参且完全没意识到中文 token 消耗更高。
把 overlap 当成必须且越大越好。
认为存在一个「最佳 chunk size」——真实答案是取决于语料和问题类型,必须自测
从没检查过切分结果的样本,纯靠参数玄学。

关联学习