What is 「chunking「 and why is it important in RAG
1️⃣ 考察意图
面试官想考察你对 RAG 系统核心预处理环节的工程理解，而非单纯背定义。刁钻点在于：chunking 看似简单，实则直接影响检索精度与生成质量之间的 trade-off。答好了能展示你对信息检索（IR）与 LLM 上下文窗口的平衡能力，以及实际调优经验（如 chunk 粒度、重叠策略、评估指标）。这是 P1 进阶题，要求候选人从“知道是什么”升级到“知道怎么调优”。
2️⃣ 标准答
定义：Chunking 是将长文档分割成较小、语义连贯的片段（chunk）的过程，用于 RAG 的检索阶段。每个 chunk 被向量化后存入索引，检索时返回最相关的 top-k 个 chunk 给 LLM 生成。
为什么重要：它决定了检索的粒度与质量。chunk 过小（如 64 tokens）会丢失上下文，导致检索结果碎片化；过大（如 2048 tokens）会引入噪声，降低检索精度，并浪费 LLM 的上下文窗口。核心 trade-off 是：检索精度 vs. 上下文完整性。
主流策略：
- 固定大小分割：按 token 数（如 256 tokens）或字符数切分，简单高效。但会切断句子或段落，破坏语义。实际中常用
RecursiveCharacterTextSplitter（LangChain 实现），按段落→句子→字符递归切分，保证边界在语义完整处。 - 语义分割：基于句子边界（如 spaCy 的句子分割器）或段落边界，保留自然语义单元。代价是 chunk 长度不固定，索引时需处理变长向量。
- 基于模型的分割：用 embedding 模型（如 BERT）检测语义边界，在相似度骤降处切分。精度高但计算开销大，适合离线预处理。
重叠策略：相邻 chunk 重叠部分（如 10-20% tokens）可缓解边界信息丢失。例如，chunk 大小 256 tokens，重叠 50 tokens，确保关键实体（如“Transformer”）不会因切分被截断。但重叠会增加索引大小和检索延迟，需权衡。
实际落地的坑 + 解法：
- 坑：固定大小分割导致“Transformer 架构”被切成“Transformer”和“架构”，检索时无法匹配完整概念。
- 解法：使用
RecursiveCharacterTextSplitter并设置separators=["\n\n", "\n", ".", "!"]，优先在段落或句子边界切分。同时，对关键实体（如技术术语）做正则保护，避免分割。 - 评估方法：在 Natural Questions 数据集上实验不同 chunk 大小（128/256/512 tokens）和重叠比例（0/10%/20%），记录检索 Recall@5 和生成答案的 ROUGE-L 分数。通常 256 tokens + 10% 重叠是平衡点。
工程取舍：固定大小分割适合高吞吐场景（如实时问答），语义分割适合精度优先场景（如法律文档分析）。重叠策略需根据索引存储成本（如 FAISS 的向量数）和检索延迟调整。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：定义、重要性、调优策略。定义上，chunking 是将长文档分割成语义连贯片段的过程。重要性在于它直接决定检索粒度与生成质量的平衡——chunk 过小丢失上下文，过大引入噪声。调优上，我常用递归分割（如 LangChain 的 RecursiveCharacterTextSplitter），结合 10-20% 重叠，并在 Natural Questions 上通过 Recall@5 和 ROUGE-L 验证。总结一句：chunking 是 RAG 的‘第一道关卡’，策略选错，后续检索和生成都会崩。”
4️⃣ 高频追问 & 应对
追问 1：你如何选择 chunk 大小？有没有通用规则？
没有绝对规则，但有个经验起点：基于 LLM 的上下文窗口（如 GPT-4 的 8K tokens），chunk 大小设为窗口的 1/8 到 1/4（即 1K-2K tokens），保证能塞入 3-5 个 chunk。然后通过网格搜索（如 128/256/512 tokens）在验证集上优化 Recall@k。实际中，我常用 256 tokens 作为默认值，因为它在大多数 QA 数据集上平衡了精度和延迟。
追问 2：重叠比例怎么设？设高了有什么坏处？
重叠比例通常 10-20%。设高（如 50%）会：1）索引向量数翻倍，增加存储和检索延迟；2）检索时返回重复内容，浪费 LLM 上下文窗口。我常用 10% 作为起点，如果发现边界信息丢失（如实体截断），再逐步上调。一个技巧：对高频实体（如“GPT-4”）做统计，如果它们频繁出现在 chunk 边界，就增加重叠。
追问 3：语义分割比固定分割好在哪里？代价是什么？
语义分割（如按句子边界）能保留自然语义单元，检索结果更连贯。代价是：1）chunk 长度不固定，索引时需用变长向量（如 ColBERT 的 late interaction），增加复杂度；2）计算开销大，尤其用模型检测边界时。固定分割适合实时系统（如客服机器人），语义分割适合离线批处理（如文档分析）。
5️⃣ 避坑 · 常见错误答法
- ❌ “chunk 越大越好，因为上下文更完整。” → ✅ “chunk 过大会引入噪声，降低检索精度。实际中需平衡，比如 256 tokens 是常见起点。”
- ❌ “重叠越多越好，能保证信息不丢失。” → ✅ “重叠增加索引大小和检索延迟，通常 10-20% 即可，过高会浪费资源。”
- ❌ “chunking 就是简单按字符数切分。” → ✅ “需要优先在语义边界切分（如段落、句子），否则会破坏实体和逻辑关系。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从实际调优经验切入，比如“我在法律文档 RAG 中实验了 128/256/512 tokens 的 chunk 大小，发现 256 tokens + 10% 重叠在 Recall@5 上提升 15%”。
- 如果你只做过传统 NLP：用信息检索类比，比如“chunking 类似传统 IR 中的文档分块，但多了 LLM 上下文窗口的约束，我通过 BM25 和 DPR 对比验证了 chunk 大小的影响”。
- 如果你是校招无项目：聚焦论文复现，比如“我复现了《Chunking Strategies for RAG》中的实验，在 Natural Questions 上验证了 256 tokens 是最优解，并分析了重叠比例的影响”。
- 《Chunking Strategies for RAG: A Systematic Evaluation》—— 论文，对比固定/语义/模型分割
- LangChain 官方文档：RecursiveCharacterTextSplitter —— 工具，实战分割实现
- 《Dense Passage Retrieval for Open-Domain Question Answering》—— 论文，DPR 与 chunking 的关联
- FAISS 官方教程：索引优化与向量存储 —— 工具，处理变长 chunk 的索引策略
- 《Lost in the Middle: How Language Models Use Long Contexts》—— 论文，chunk 大小对 LLM 生成的影响