标准回答
chunk_size 与 overlap 没有放之四海皆准的值，本质是在「语义完整」与「信息密度」之间找平衡，并要结合文档类型和 embedding 模型。
chunk_size 的权衡
- 太大：一个块塞进多个主题，embedding 向量被「平均」稀释，相关信息被无关内容淹没；噪声多、检索精度下降，还可能超出 embedding 模型的最大输入长度被截断。
- 太小：语义被割裂，单块缺乏足够上下文，LLM 拿到碎片难以作答，相关信息也可能分散在多个块里增加召回负担。
经验起点
- 常用 256～512 token 作为起步，具体取决于内容类型与所用 embedding 模型的最佳输入长度（密集技术文档可偏小，叙述性长文可偏大）。
- overlap 取块大小的 10～20%：相邻块保留部分重叠，防止关键句正好落在边界被切断、跨块上下文丢失。overlap 太小仍可能丢边界信息，太大则增加冗余存储与重复召回。
比固定长度更好的做法
- 结构感知切分：优先按文档自然边界切——按标题/章节、段落、句子，保持语义单元完整，而非机械按字符数硬切。
- 语义分块（semantic chunking）：用句向量相似度判断语义是否连续，在语义发生跳变处断开，使每块主题内聚。
- 对 Markdown、表格、代码等保留结构，避免破坏格式。
怎么定最终值
不要凭感觉拍板。在固定验证集上测不同 chunk_size / overlap 组合的检索质量：Context Recall、Context Precision、命中率/MRR，再看端到端的答案正确率与 Faithfulness，选指标最优的配置。
常见误区
⚠️ 常见踩坑
误以为存在一个「最优固定 chunk_size」（比如固定 512）适用于所有场景。最佳值高度依赖文档类型、embedding 模型与问题粒度；只按字符数机械硬切、不考虑语义和结构边界，容易把完整语义拦腰切断，必须用检索指标实测调优。
追问
追问 1：overlap 设成 0 行不行？它到底解决什么问题？
可以但有风险。overlap 的作用是防止关键信息正好落在两个块的边界处被切断，导致任一块都不完整、检索时两边都召不全。设为 0 在边界连续性强的文档里容易丢上下文；通常取块大小的 10-20%。如果用的是按句子/段落的语义切分、边界本身就在自然停顿处，overlap 可以适当减小。
追问 2：固定长度切分和语义分块各有什么优缺点，怎么选？
固定长度切分实现简单、速度快、块大小可控，但会无视语义把句子或段落拦腰切断。语义分块按内容相似度在主题跳变处断开，块内更内聚、检索更准，但计算成本更高、块大小不固定。工程上常折中：先按结构（标题/段落）粗切，再在过长段落内按固定长度加 overlap 细切，兼顾质量与成本。
追问 3：如果同一块要兼顾「精确召回」和「足够上下文」，有什么办法？
用父子块（small-to-big）策略解耦这对矛盾：用细粒度小块做向量匹配以提高召回精度，命中后不直接把小块给 LLM，而是返回它所属的父块（更大段落）作为上下文。这样既保留小块的精确定位，又给模型完整上下文，避免被迫在「chunk 太小丢上下文」和「太大引噪声」之间二选一。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习