| 13 | How do you choose the chunk size for a RAG system

P1 · rag

🏷 标签：rag, chunking, chunk-size, optimization, retrieval

1️⃣ 考察意图

面试官想考察你对 RAG 系统分块策略的系统性工程思维，而非死记硬背一个数字。这是典型的工程取舍题，刁钻点在于：候选人往往只回答“512 tokens 是默认值”，却说不清为什么、怎么调、以及分块与检索/生成之间的耦合关系。答好了能展示：① 对检索粒度与上下文窗口的权衡理解；② 实验调优方法论（如 grid search 或贝叶斯优化）；③ 对实际落地中噪声与信息丢失的敏感度。这直接映射到一线大厂 RAG 系统的性能调优能力。

2️⃣ 标准答

分块大小没有银弹，核心是在检索精度与上下文完整性之间找平衡。回答分三步：影响因素、调优方法、工程坑。

影响因素

文档类型与语义边界：法律合同、技术文档等结构化文本，适合按段落或章节分块（如 512-1024 tokens）；而新闻、对话等非结构化文本，固定大小分块（如 256-512 tokens）更高效。语义分块（如 LangChain 的 RecursiveCharacterTextSplitter 基于 ["\n\n", "\n", " ", ""] 递归分割）能保留自然边界，但计算开销增加 10-20%。
LLM 上下文窗口：GPT-4 支持 128K tokens，但长上下文会稀释注意力（attention dilution），导致“大海捞针”问题。经验法则：分块大小不超过窗口的 1/4（如 32K 窗口用 8K 块），避免检索结果被截断或噪声淹没。
检索粒度与下游任务：问答任务（如 HotpotQA 多跳推理）需要 512-1024 tokens 的块来保留实体关系；摘要任务则可用 2048+ tokens 块。关键取舍：小块（128 tokens）提高检索精度（precision），但可能丢失跨块上下文，导致生成阶段幻觉；大块（1024 tokens）保留上下文，但引入噪声，降低召回率（recall）。实际中，用 BM25 或 DPR 检索时，小块召回率通常比大块低 5-15%，但生成准确率可能更高（取决于 LLM 的推理能力）。

调优方法

实验驱动：在验证集上做 grid search，测试 chunk_size = [128, 256, 512, 1024] tokens，overlap = [0, 10%, 20%]。评估指标：检索召回率（Recall@k）和生成准确率（如 F1 或 ROUGE-L）。例如，在 WikiQA 数据集上，512 tokens + 10% overlap 通常是最优起点。
动态分块：基于文档复杂度动态调整。例如，用 spaCy 或 NLTK 做句子分割，然后合并句子直到接近目标 token 数。这比固定大小分块在长文档上提升 3-5% 的召回率（【通用知识】）。
工具链：LangChain 的 RecursiveCharacterTextSplitter 支持自定义分隔符和 chunk_overlap；LlamaIndex 的 SentenceSplitter 基于 token 数做语义感知分块。实际落地的坑：overlap 设置不当会导致重复检索，浪费 LLM 上下文预算。解法：overlap 设为 chunk_size 的 10-20%，并在检索后去重（如用 set 去重或余弦相似度阈值 0.95）。

工程坑与解法

坑 1：分块边界破坏实体。例如，“New York”被切成“New”和“York”，检索时丢失语义。解法：用命名实体识别（NER）预处理，强制实体不跨块（如 spaCy 的 doc.ents 做边界调整）。
坑 2：多模态文档。PDF 中的表格或图片被分块后，检索结果不完整。解法：先用 OCR（如 PyMuPDF）提取结构化内容，再按逻辑单元（如表格行）分块，而非按 token 数。
坑 3：生产环境延迟。分块太细（如 128 tokens）导致检索次数激增，增加 2-3 倍延迟。解法：用 HNSW 索引加速检索，或做预过滤（如先用 BM25 粗筛，再用 DPR 精排）。

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

“这个问题我从三个层面回答：第一，影响因素——文档类型、LLM 上下文窗口和任务粒度决定了分块大小的范围；第二，调优方法——通过 grid search 在验证集上测试 128-1024 tokens，结合 overlap 和语义边界，用 Recall@k 和生成准确率评估；第三，工程坑——注意实体跨块、多模态文档和延迟问题，用 NER 预处理和 HNSW 索引解决。总结一句：分块大小是检索精度与上下文完整性的 trade-off，必须实验驱动，没有默认值。”

4️⃣ 高频追问 & 应对

追问 1：如果文档是代码仓库（如 GitHub 上的 Python 文件），分块策略怎么调整？

代码分块不能按 token 数，必须按函数或类边界。用 tree-sitter 解析 AST（抽象语法树），提取每个函数体（如 def 块）作为独立块，保留 import 语句作为全局上下文。块大小通常 200-500 tokens（函数体），overlap 设为 0（避免重复）。检索时，用 BM25 匹配函数名和注释，DPR 匹配代码逻辑。坑：函数间依赖（如调用链）会丢失，解法：在块内注入调用关系（如“调用函数 A 在块 B”）。

追问 2：你提到 overlap 设为 10-20%，但为什么不是 50%？有什么 trade-off？

50% overlap 会大幅增加索引大小（约 2 倍）和检索延迟（约 1.5 倍），且重复内容导致 LLM 生成时注意力分散。10-20% 是经验值：在 MS MARCO 数据集上，10% overlap 比 0% 提升 3% 召回率，而 50% 只再提升 1% 但索引膨胀 40%。实际中，如果文档是连续叙述（如小说），overlap 可提高到 30%；如果是结构化文档（如 API 文档），0% 就够。

追问 3：如何评估分块策略对生成质量的影响，而不是只关注检索指标？

用端到端评估：在验证集上，对每个 query，用不同分块策略检索 top-k 块，输入 LLM 生成答案，然后计算生成准确率（如 F1）和忠实度（如 NLI 模型打分）。注意：检索召回率高不一定生成好，因为噪声块会误导 LLM。例如，在 HotpotQA 上，512 tokens 块比 256 tokens 块召回率高 5%，但生成准确率低 2%，因为大块引入了无关实体。所以，必须联合优化检索和生成指标。

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

❌ “默认用 512 tokens，因为 LangChain 推荐这个值。” → ✅ “512 tokens 是常见起点，但必须根据文档类型和任务调优。例如，法律合同用 1024 tokens 保留条款上下文，而 FAQ 用 256 tokens 提高精度。”
❌ “分块越小越好，因为检索更精确。” → ✅ “小块提高精度但丢失上下文，导致 LLM 生成时缺乏背景信息。例如，多跳问答中，128 tokens 块可能无法覆盖实体关系，生成准确率下降 10%。”
❌ “overlap 越大越好，避免信息丢失。” → ✅ “overlap 过大会增加索引大小和延迟，且重复内容稀释注意力。10-20% 是平衡点，具体取决于文档连续性。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在项目中用 grid search 调优 chunk_size，发现 512 tokens + 10% overlap 在问答任务上 F1 提升 8%”切入，强调实验设计和指标选择。
如果你只做过传统 NLP：用“分块类似文本分类中的滑动窗口，但 RAG 需要兼顾检索和生成”类比，展示迁移能力。补充：你用过 spaCy 做句子分割，可快速上手语义分块。
如果你是校招无项目：聚焦“在 HotpotQA 上复现分块实验，比较 128/256/512 tokens 对多跳推理的影响，并分析原因”，展示论文复现和数据分析能力。
《RAG 系统分块策略：从固定大小到语义感知》——LangChain 官方博客
《Dense Passage Retrieval for Open-Domain Question Answering》——Karpukhin et al., 2020
《Lost in the Middle: How Language Models Use Long Contexts》——Liu et al., 2023
《Evaluating RAG Systems: Metrics and Pitfalls》——LlamaIndex 文档
《Tree-sitter: A Parser for Code Chunking》——GitHub 开源项目

—— 本场面试完 ——