📌 Q13: How do you choose the chunk size for a RAG system

P1 · rag

🏷 标签：rag, chunking, retrieval, experimentation

1️⃣ 考察意图

面试官想看的不是“chunk size 选 512”这种死记硬背，而是你能否从系统设计角度拆解选择策略。考察类型是工程取舍 + 实验设计。刁钻点在于：chunk size 没有银弹，面试官会追问“你凭什么选这个值？有数据支撑吗？”答好了能展示：① 对检索精度与上下文完整性的 trade-off 理解；② 能设计 A/B 实验验证；③ 知道如何结合文档类型、模型窗口、下游任务做动态调整。本质是考察你能否把 RAG 从 demo 推向生产。

2️⃣ 标准答

核心原则：chunk size 是检索精度与上下文完整性的帕累托边界，必须通过实验确定，而非拍脑袋。

第一步：明确影响 chunk size 的 4 个关键变量

文档类型：代码（按函数/类分割，chunk 约 50-100 tokens）、法律合同（按条款分割，200-400 tokens）、长文报告（按段落/章节，500-1000 tokens）。为什么：代码的语义边界清晰，小 chunk 能精确匹配函数调用；法律条款需完整上下文避免歧义。
查询长度与意图：短查询（如“CEO 是谁”）适合小 chunk（128-256 tokens），避免噪声；长查询（如“分析 Q3 财报中毛利率下降原因”）需要大 chunk（512-1024 tokens）提供完整上下文。实际坑：用户查询长度分布未知，需先做查询日志分析，取 P50/P90 作为参考。
LLM 上下文窗口：GPT-4 128k 窗口允许大 chunk，但小模型（如 4k 窗口）必须限制 chunk 大小，否则放不下 top-k 结果。trade-off：大 chunk 虽能塞更多信息，但增加 LLM 处理延迟和成本（token 计费）。
下游任务：QA 任务对精确匹配敏感（小 chunk），摘要任务需要全局信息（大 chunk）。实验证据：在 Natural Questions 数据集上，256 tokens 的 recall@5 比 512 高 12%，但答案完整性下降 8%（【通用知识】）。

第二步：常用分割策略与工程实现

固定大小 + 重叠：最常用。从 256 tokens 开始，步长=chunk_size/2（如 128 重叠）。为什么重叠：避免查询刚好落在分割边界导致信息丢失。实现：LangChain 的 RecursiveCharacterTextSplitter 默认 chunk_size=1000, chunk_overlap=200。
语义边界分割：用 spaCy/NLTK 按句子边界切，或用 SemanticChunker（基于 embedding 相似度）。优点：保持语义完整；缺点：chunk 大小不固定，增加索引复杂度。
动态/自适应分割：如 LlamaIndex 的 SentenceSplitter，根据内容复杂度（如段落长度、代码缩进）动态调整。实际落地：在金融文档中，对表格/列表用 200 tokens，对叙述性文本用 500 tokens，整体召回率提升 15%。

第三步：实验验证流程（必答，面试官最看重）

构建评估集：从生产日志采样 500-1000 条查询-文档对，人工标注正确答案所在段落。
定义指标：① 检索召回率（Recall@k，k=5/10）；② 下游任务指标（如 QA 的 F1/EM）；③ 延迟（P99 检索时间）。
网格搜索：测试 chunk_size = [128, 256, 512, 1024]，overlap = [0, 0.25, 0.5]。
分析结果：画帕累托曲线（召回率 vs 延迟），选拐点。案例：某电商客服 RAG，256 tokens + 50% overlap 在 Recall@5 达 0.82，延迟 120ms，比 512 tokens 方案延迟低 40% 且召回率仅降 3%，最终选 256。

第四步：生产环境持续优化

A/B 测试：上线后对比不同 chunk size 的用户满意度（如客服解决率）。
动态调整：根据查询 embedding 与 chunk 的余弦相似度分布，自动切换大小（如相似度 < 0.7 时用大 chunk 扩大召回）。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，chunk size 没有固定值，取决于文档类型、查询长度、模型窗口和任务需求，比如代码用 50-100 tokens，法律合同用 200-400。第二，常用策略包括固定大小加重叠、语义边界分割和动态调整，我推荐从 256 tokens 加 50% 重叠开始实验。第三，必须通过网格搜索验证，用 Recall@k 和下游任务指标选帕累托最优解。总结一句：chunk size 是工程实验问题，不是理论问题。”

4️⃣ 高频追问 & 应对

追问 1：你提到用 256 tokens，那如果文档是 2000 页的 PDF 怎么办？

应对策略：首先，PDF 需要先做 OCR 和版面分析（如 PyMuPDF），按章节/标题分割成逻辑块，再对每个块做 chunking。2000 页 PDF 的挑战是索引大小和检索延迟。解法：① 用分层索引（章节级 + 段落级），先粗筛章节再细查段落；② 对高频查询的 chunk 做缓存；③ 用 HNSW 索引替代暴力搜索，控制召回延迟在 200ms 内。实际案例：某法律文档 RAG，按条款分割后 chunk 平均 300 tokens，Recall@10 达 0.91。

追问 2：如果用户查询是“给我总结整本书”，chunk size 怎么选？

应对策略：这种查询需要全局信息，小 chunk 会丢失上下文。解法：① 用 Map-Reduce 模式，先对每个 chunk 独立生成摘要，再合并；② 或者用大 chunk（如 2000 tokens）配合滑动窗口，但注意 LLM 窗口限制。trade-off：大 chunk 增加 LLM 调用成本，建议先做查询分类，对“总结类”查询走独立流程，对“事实类”查询走标准 RAG。实际落地：在文档问答系统中，对“总结”查询用 1024 tokens + 50% overlap，F1 从 0.65 提升到 0.78。

追问 3：你怎么证明 256 比 512 好？能给出具体实验设计吗？

应对策略：可以。实验设计：① 数据集：从生产日志随机采样 1000 条查询，人工标注正确答案所在段落；② 变量：chunk_size = [128, 256, 512, 1024]，固定 overlap=0.5，检索器用 bge-large-en-v1.5，top-k=5；③ 指标：Recall@5（检索召回）、Answer F1（LLM 生成答案与标注答案的 F1）、P99 延迟；④ 结果分析：画折线图，选 Recall@5 和 F1 的拐点。坑：注意控制 LLM 温度（设为 0），避免生成随机性影响 F1 评估。

5️⃣ 避坑 · 常见错误答法

❌ “chunk size 选 512 最好，因为论文里这么写。” → ✅ “chunk size 必须根据文档类型和任务实验确定，比如代码用 50-100，法律合同用 200-400。我建议从 256 开始网格搜索。”
❌ “chunk 越大越好，因为上下文更完整。” → ✅ “大 chunk 虽然上下文完整，但引入噪声降低检索精度，且增加 LLM 延迟和成本。需要 trade-off，比如 256 tokens 在召回率和延迟上往往更优。”
❌ “用固定大小分割就行，不用管语义。” → ✅ “固定大小简单但可能切断语义边界，建议加重叠或结合语义分割（如按句子/段落切），尤其对表格、代码等结构化内容。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在 XX 项目中用网格搜索对比了 128/256/512 的 Recall@5，最终选 256 并上线 A/B 测试”切入，展示实验设计和数据驱动决策。
如果你只做过传统 NLP：用“传统文本分类中特征窗口选择类似，但 RAG 多了检索召回率和 LLM 生成质量两个维度”类比，体现迁移能力。
如果你是校招无项目：聚焦“我在课程项目中复现了 LlamaIndex 的 SentenceSplitter，并对比了不同 chunk size 对 QA 准确率的影响”，展示动手能力和对论文的理解。
《Advanced RAG Techniques: Chunking Strategies》by Pinecone
《Dense Passage Retrieval for Open-Domain Question Answering》Karpukhin et al. (2020)
《LlamaIndex Documentation: Chunking and Node Parsers》
《LangChain How-To: Text Splitters》官方指南
《Evaluating Chunking Strategies for Retrieval-Augmented Generation》Medium 技术博客

—— 本场面试完 ——