1 什么是 Chunk
P0 · rag
🏷 标签：rag, chunking, retrieval
1️⃣ 考察意图
面试官想考察你对 RAG 系统基础组件的理解深度，而非单纯背定义。这题看似简单，但刁钻点在于：Chunk 不是“切一刀”就完事，而是检索精度与生成质量的平衡点。答好了能展示你对信息检索（IR）和 LLM 上下文窗口的工程直觉，以及从“调参侠”到“系统设计者”的跃迁。考察类型：概念 + 工程取舍。
2️⃣ 标准答
Chunk 定义Chunk 是文档被切分后的文本片段，是 RAG 中检索和生成的基本操作单元。它决定了：① 检索时，query 匹配到哪一段文本；② 生成时，LLM 能看到多少上下文。
为什么不能直接用整篇文档？
- 检索噪声：整篇文档可能包含无关段落，导致检索召回率低（Recall@K 下降 20-30%）。
- 上下文窗口限制：LLM 有固定长度（如 GPT-4 的 128K tokens），但长文档会挤占 prompt 空间，影响生成质量。
- 语义粒度：用户 query 通常针对局部信息（如“2023 年营收”），而非整篇财报。
常见切分方法（含 trade-off）
- 固定长度切分 - 做法：按 tokens 数（如 256/512）切分，可设 overlap（如 10-20%）。 - 优点：实现简单，计算快（O(n)）。 - 缺点：可能切断句子或段落，破坏语义完整性。 - 工程取舍：overlap 越大，检索召回越高（减少边界丢失），但索引膨胀（存储成本 + 30%），且生成时可能重复信息。 - 实际坑：用
tiktoken或transformers的 tokenizer 统计 tokens，别用字符数（中文 1 字符 ≈ 1.5 tokens）。 - 语义切分 - 做法：基于段落边界（
\n\n）、句子边界（。！？）或 NLP 工具（spaCy 的 sentencizer）。 - 优点：保留语义完整性，检索命中率更高（Recall@5 提升 10-15%）。 - 缺点：段落长度差异大（如代码块 vs 散文），导致 chunk 大小不均，影响 embedding 质量。 - 实际坑：Markdown 文档中，表格或列表可能被误切（如| col1 | col2 |被当成多行）。解法：用unstructured库解析结构后再切。 - 递归切分（RecursiveCharacterTextSplitter） - 做法：按优先级尝试分隔符（
\n\n>\n>。> 空格），直到 chunk 大小达标。 - 优点：兼顾语义完整性和长度控制，LangChain 默认推荐。 - 工程取舍：递归深度过大会增加延迟（O(n log n)），且对非结构化文本（如日志）效果差。
切分参数调优
- 块大小：256 tokens 适合短 query（如问答），512 tokens 适合长文档摘要。
- overlap：10-20% 是安全区间，超过 30% 收益递减（边际召回提升 < 2%）。
- 实验方法：用
Recall@K和ROUGE-L评估，在 3-5 个数据集上交叉验证。
总结：Chunk 是 RAG 的“原子单位”，切分策略直接影响检索精度和生成质量。没有银弹，必须结合文档类型和业务场景做 A/B 测试。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从定义、切分方法、参数调优三个层面回答。定义上，Chunk 是文档切分后的文本片段，是检索和生成的基本单元。切分方法上，固定长度简单但破坏语义，语义切分保留完整性但长度不均，递归切分是折中方案。参数上，块大小和 overlap 需实验调优，256 tokens + 15% overlap 是常见起点。总结一句：Chunk 设计是 RAG 系统的‘第一性原理’，决定了后续所有环节的上限。”
4️⃣ 高频追问 & 应对
追问 1：如果文档是 PDF 表格或代码，怎么切？
表格：用
pdfplumber或camelot提取表格结构，按行或单元格切分，保留表头作为元数据。代码：按函数/类边界切分（如ast解析 Python），或用tree-sitter提取语法树。坑：表格跨页时需合并，代码注释可能被误切。解法：对结构化文档，先解析再切分，而非直接按文本切。
追问 2：chunk 大小对生成质量的具体影响是什么？
太小（<128 tokens）：LLM 缺乏上下文，生成内容可能偏离事实（如摘要遗漏关键点）。太大（>1024 tokens）：LLM 注意力分散，长文本中关键信息被稀释（如问答中答案被淹没）。实验数据：在 MS MARCO 上，512 tokens 比 256 tokens 的 ROUGE-L 高 5%，但超过 1024 后下降 3%。取舍：短 query 用小 chunk，长文档用大 chunk + 滑动窗口。
追问 3：如何评估不同切分策略的好坏？
离线指标：检索用 Recall@K（K=5/10），生成用 ROUGE-L/BLEU。在线指标：用户点击率、答案采纳率。注意：离线指标可能不反映真实场景（如用户 query 分布不同）。解法：构建 3-5 个代表性 query 集（如事实型、推理型、摘要型），做 A/B 测试。工具：
ragas库可自动化评估。
5️⃣ 避坑 · 常见错误答法
- ❌ “Chunk 就是按固定长度切分，比如 256 tokens。”→ ✅ 切分方法有多种，固定长度只是基础，语义切分和递归切分更实用。面试官想看到你对 trade-off 的理解。
- ❌ “overlap 越大越好，能避免信息丢失。”→ ✅ overlap 过大（>30%）导致索引膨胀和生成重复，收益递减。需在召回和成本间平衡。
- ❌ “chunk 大小统一就好，比如 512 tokens。”→ ✅ 不同文档类型（如新闻 vs 代码）需要不同策略。统一大小会牺牲某些场景的检索精度。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从实际调参经历切入，如“在文档问答系统中，我对比了固定长度和语义切分，发现语义切分使 Recall@5 从 0.72 提升到 0.85，但延迟增加了 15%”。
- 如果你只做过传统 NLP：用 IR 概念类比，如“Chunk 类似信息检索中的文档片段，但多了 LLM 上下文窗口约束”。
- 如果你是校招无项目：聚焦论文复现，如“我复现了 LlamaIndex 的递归切分，并在 WikiQA 上验证了不同参数对 ROUGE 的影响”。
- LangChain 官方文档：
RecursiveCharacterTextSplitter实现原理 - 论文：
Chunking Strategies for Retrieval-Augmented Generation（2024） - 博客：
The Ultimate Guide to Chunking in RAG（Pinecone） - 工具：
unstructured库（解析 PDF/HTML/代码） - 论文：
Dense Passage Retrieval for Open-Domain Question Answering（Karpukhin et al., 2020）