考察点
这道题出自 Amazon 大模型应用岗的技术面试，DSPrep 把它标成 Google/Amazon/OpenAI 三家常考，是 RAG 八股里最能区分「做过」和「背过」的一题。面试官想听的不是一个魔法数字，而是你的调参方法论：chunk 大小影响检索链路的哪个环节、和 embedding 模型/下游 LLM 窗口的耦合关系、怎么用评测而不是拍脑袋来定值。追问会往切分策略（递归切分 vs 语义切分）、overlap、父子文档检索走。
参考答案
先想清楚 chunk 大小影响了什么
chunk 是 RAG 里「索引粒度」和「喂给模型的上下文粒度」的合一，所以它的选择是在两个目标之间拉扯：
- 检索精度：embedding 是对整段文本取语义的「平均」。chunk 越大，里面混的主题越多，向量越「糊」，和用户问题的相似度区分度越差。一块 2000 token 的文本里只有一句话相关，整块的向量也会被这句话稀释。
- 生成质量：chunk 太小，答案需要的上下文被切断——「该政策的例外情况是……」切到下一块去了，模型拿到半句话只能瞎编或者拒答。
所以小 chunk 利好检索、大 chunk 利好生成，「最优值」本质是你业务里这两个环节哪个更容易成为瓶颈。
工程上的定值方法
第一步，按内容结构定基线，而不是按token数拍。 技术文档按小节切、FAQ 按问答对切、代码按函数/类切。结构化内容用 RecursiveCharacterTextSplitter 按 ["\n\n", "\n", "。", ""] 这类分隔符层级递归切，让它尽量在语义边界断开。只有无结构的流水文本才纯按长度切。
第二步，给基线一个合理初始区间。 经验值：通用中英文文档 300-800 token 是常见起点；embedding 模型的训练分布也要考虑，比如 BGE、OpenAI text-embedding 系列在几百 token 的段落上表现最好，塞 4000 token 的长块进去向量质量反而下降。overlap 设 chunk 大小的 10%-15%，防边界切断关键句。
第三步，也是面试加分项——用评测闭环调，别拍脑袋。 准备几十条带标准答案的「问题-相关段落」对，固定其他参数，扫几档 chunk size（比如 256/512/1024），看 hit rate（正确段落是否进 top-k）和端到端答案正确率。不同库的最优值可能差很远：API 文档往往偏小好，合同、论文偏大好。
比调大小更高级的做法
成熟的 RAG 系统基本不在「一个 chunk 走天下」上纠结，而是解耦检索粒度和生成粒度：
- 父子文档检索（Parent Document Retriever）：小块（比如 200 token）建索引保证检索精度，命中后返回它所属的父块（比如 1000 token 的完整小节）喂给 LLM。检索用小粒度、生成用大粒度，两头都占。
- 多向量索引：一个 chunk 生成多个向量——原文向量 + 摘要向量 + 假设性问题向量，任一命中都召回原文。相当于从多个「角度」提高召回，对长短不一的文档尤其有效。
- 按文档类型差异化：日志类小 chunk、报告类大 chunk，一个库里存多种粒度，检索时按意图路由。
还有一个常被忽略的耦合：top-k × chunk 大小 = 喂给模型的总 token 数，这个数必须给系统提示和输出留出余量。chunk 调大一倍，top-k 就得砍一半，否则上下文爆了，延迟和成本也跟着上去。
可能的追问
1. overlap 是不是越大越好？
不是。overlap 是拿存储和召回噪声换边界完整性。超过 20% 之后收益递减，重复内容还会让相似度分数虚高、挤占 top-k 名额。10% 左右通常够。
2. 语义切分（semantic chunking）值得用吗？
按 embedding 相似度找语义断点，理论上最优，但切分阶段要对全文做 embedding 计算，建库成本明显上升，且收益不稳定。建议作为常规切分效果不达标后的升级选项，而不是默认方案。
3. 表格、代码这种内容怎么切？
别用纯文本切分器硬切。表格转成 markdown 或按行组保留表头整体成块，代码按语法结构（函数/类）切；切完块内还要补上下文，比如给表格块加上所在章节的标题，否则检索出来模型看不懂孤立的一堆格子。