chunk 大小怎么定的
P1 · rag · 🏢 字节
🏷 标签：chunk-size, context-window, experimentation
1️⃣ 考察意图
面试官想看你是否理解 chunk 大小不是拍脑袋的“最佳值”，而是受 LLM 上下文窗口、检索精度、语义完整性三者制约的工程决策。考察类型是工程取舍 + 系统设计，刁钻点在于：候选人常背“300-500 token”这个数字，却说不清为什么是这个范围、怎么实验验证、以及不同场景下如何调整。答好了能展示你对 RAG 整条链路（检索→生成）的耦合理解，以及从“调参”到“设计实验”的工程思维。
2️⃣ 标准答
chunk 大小没有银弹，核心原则是：让每个 chunk 语义自洽，且能被 LLM 上下文窗口有效容纳。具体分三步走：
- **第一步：确定 LLM 上下文窗口的“有效利用率”**假设 LLM 窗口是 8K token，但实际生成时，你需要预留 1K-2K 给 prompt 指令 + 用户问题 + 输出空间。所以可用窗口约 6K-7K token。如果 chunk 是 1K token，你最多能塞 6-7 个 chunk；如果 chunk 是 500 token，能塞 12-14 个。更多 chunk 意味着更多候选片段，但每个片段信息密度可能下降。这里有个 trade-off：chunk 越小，检索召回越细，但 LLM 需要拼接更多片段，容易丢失跨 chunk 的语义连贯性。
- 第二步：用实验确定“语义完整性”阈值我一般从 256、512、1024 token 三个粒度开始，用 BM25（默认 k1=1.5, b=0.75）或 DPR 做检索，再用 GPT-4 或开源模型（如 Qwen2-7B）做生成，对比三个指标：检索命中率：chunk 是否包含答案所需的关键实体/关系。
- 生成准确率：LLM 能否基于 chunk 给出正确回答。
- 延迟：chunk 越大，检索和生成都更慢。实际经验：对于技术文档（如 API 文档），512 token 效果最好，因为每个 chunk 能完整描述一个函数或参数；对于新闻摘要，256 token 足够，因为信息密度高；对于长篇小说，1024 token 才能保持人物和情节连贯。 第三步：设置 overlap 解决“边界截断”问题无论 chunk 大小，都会遇到语义被截断在边界的情况。比如一个 chunk 结尾是“小明打开了”，下一个 chunk 开头是“门”。LLM 只看第一个 chunk 会误解。解法是 overlap：一般设为 chunk 大小的 10%-20%。512 token 的 chunk，overlap 设 50-100 token。注意：overlap 会增加总 token 数，导致检索时重复内容，但能明显提升召回质量。实际落地的坑：overlap 太大（如 30%）会导致检索时多个 chunk 包含相同内容，浪费窗口且可能让 LLM 重复回答。我踩过这个坑，后来改成动态 overlap：根据句子边界（句号/换行符）对齐，而不是固定 token 数。第四步：结合 embedding 模型做二次验证如果用 dense retrieval（如 bge-large-en-v1.5），chunk 大小会影响 embedding 质量。实验发现：512 token 的 chunk 在 embedding 相似度计算中表现最稳定，因为太短（<128 token）的 chunk 语义稀疏，太长（>1024 token）的 chunk 会被 embedding 模型平均化，丢失局部细节。可以用 Cohere 的 rerank 模型（如 rerank-english-v3.0）对 top-10 候选做二次排序，进一步过滤掉语义不完整的 chunk。
总结：chunk 大小 = f(LLM 窗口, 文档类型, 检索方法, 延迟预算)。先定窗口利用率，再跑 256/512/1024 实验，最后用 overlap 和 rerank 兜底。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，chunk 大小受 LLM 上下文窗口约束，比如 8K 窗口实际可用 6K，决定了你能塞多少个 chunk；第二，通过实验对比 256/512/1024 token 三个粒度，用检索命中率和生成准确率做决策，技术文档通常 512 token 最优；第三，设置 10%-20% 的 overlap 解决边界截断，并用 rerank 模型过滤语义不完整的 chunk。总结一句：chunk 大小是检索精度和生成质量的平衡点，必须实验驱动，没有固定值。”
4️⃣ 高频追问 & 应对
追问 1：如果文档是 PDF 表格或代码，chunk 大小怎么调？
表格和代码对语义完整性要求更高。表格：按行或按表头分组，chunk 大小设为 256 token 以内，因为表格一行通常信息独立；代码：按函数或类分块，chunk 大小可以到 1024 token，但必须保留缩进和注释。实际坑：代码 chunk 如果按 token 切分，会破坏语法结构，导致 LLM 生成语法错误。解法是用 AST 解析器（如 tree-sitter）按函数边界切分，再设 overlap 为 50 token 覆盖函数注释。
追问 2：如果 LLM 窗口是 128K（如 GPT-4-128k），chunk 还需要切吗？
需要，但策略不同。窗口大不代表 chunk 可以无限大，因为检索效率会下降。128K 窗口下，chunk 可以放大到 2K-4K token，但必须保证每个 chunk 语义自洽（比如一个完整章节）。同时，检索方法要从 BM25 切换到 dense retrieval（如 ColBERT），因为 BM25 在大 chunk 上会丢失细粒度匹配。trade-off：大 chunk 减少检索次数，但生成时 LLM 需要处理更多冗余信息，可能产生幻觉。我建议保持 1K-2K chunk，配合 sliding window 检索（每次取 top-5 chunk 拼接）。
追问 3：怎么量化“chunk 大小对生成质量的影响”？
用两个指标：Faithfulness（忠实度）和 Completeness（完整性）。Faithfulness 用 NLI 模型（如 DeBERTa-v3）判断生成内容是否被 chunk 支持；Completeness 用人工标注或 LLM-as-judge（如 GPT-4 打分）看是否遗漏关键信息。实验设计：固定其他参数（embedding 模型、rerank 策略），只变 chunk 大小，跑 100 个 query，计算平均分。实际经验：512 token 的 chunk 在 Faithfulness 上比 256 token 高 5-8%，但 Completeness 低 2-3%，因为大 chunk 可能包含无关信息。
5️⃣ 避坑 · 常见错误答法
- ❌ “chunk 大小固定为 512 token，因为这是最佳实践。”→ ✅ “chunk 大小取决于文档类型和 LLM 窗口，必须通过实验验证。技术文档 512 token 效果好，但新闻摘要 256 token 更优。”
- ❌ “overlap 越大越好，能避免信息丢失。”→ ✅ “overlap 过大会导致检索重复，浪费窗口。一般设为 chunk 大小的 10%-20%，并基于句子边界对齐。”
- ❌ “chunk 大小和 embedding 模型无关。”→ ✅ “embedding 模型对 chunk 长度敏感，太短语义稀疏，太长被平均化。建议用 bge-large-en-v1.5 在 512 token 上做验证。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在某项目中用 256/512/1024 三组实验对比，发现 512 token 在检索命中率上提升 12%”切入，强调实验设计和指标选择。
- 如果你只做过传统 NLP：用“文本分类中的滑动窗口类比 chunk 切分，窗口大小影响特征提取，类似 chunk 大小影响语义完整性”迁移，展示类比思维。
- 如果你是校招无项目：聚焦“复现 LlamaIndex 的 chunk 实验 demo，用 GPT-4 做 LLM-as-judge 评估 256/512/1024 三个粒度”，展示动手能力和论文阅读（如《RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval》）。
- 《RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval》
- 《Lost in the Middle: How Language Models Use Long Contexts》
- LlamaIndex 官方文档：Chunking Strategies
- 《Dense Passage Retrieval for Open-Domain Question Answering》
- Cohere Rerank 模型最佳实践