那么为什么要进行文本分块？一方面当前 LLM 的上下文长度是有限制的，直接把一篇长文全部作为相关信息放到 LLM 的上下文窗口中，可能会超过长度限制
1️⃣ 考察意图
面试官想看你是否真正理解 RAG 系统中“分块”不是简单切文本，而是检索质量与生成质量的平衡点。考察类型是工程取舍 + 系统设计。刁钻点在于：很多人只背“LLM 上下文有限”这个表面原因，却答不出分块粒度如何影响检索召回率、embedding 语义密度、以及 chunk 重叠对长上下文理解的副作用。答好了能展示你对 RAG pipeline 的端到端理解，包括检索精度、推理成本、以及实际落地时的调优经验。
2️⃣ 标准答
文本分块的核心驱动力不是“LLM 窗口不够大”，而是检索效率与语义保真度的 trade-off。下面从三个层面拆解。
1. 检索层面的必要性：向量化与语义密度
- 每个 chunk 独立通过 embedding 模型（如
text-embedding-3-small或bge-large-en-v1.5）编码成向量。如果 chunk 太大（比如整篇论文），向量会坍缩成“平均语义”，丢失局部细节。例如一篇讲“Transformer 架构”的文章，中间一段讨论“RoPE 位置编码”，大 chunk 的向量可能只捕捉到“注意力机制”这个宽泛概念，导致检索时用户问“RoPE 如何实现”却召回不到。 - 工程取舍：小 chunk（如 128 tokens）语义更聚焦，但向量数量爆炸，增加存储和检索延迟；大 chunk（如 1024 tokens）语义更丰富，但容易淹没关键信息。实践中常用 256-512 tokens 作为起点，再根据文档类型微调。
2. 生成层面的必要性：上下文窗口与噪声控制
- LLM 的上下文窗口（如 GPT-4 的 128K tokens）虽大，但有效注意力长度远小于窗口上限。研究表明，当输入超过 4K tokens 时，模型对中间位置信息的召回率显著下降（Liu et al., 2023, “Lost in the Middle”）。所以即使窗口够大，直接塞整篇长文也会导致生成质量下降。
- 实际落地的坑：很多人用
RecursiveCharacterTextSplitter（LangChain 默认）时，只设chunk_size=500，但没设chunk_overlap=50。结果一个关键句子被切到两个 chunk 边界，两边都不完整，检索时都匹配不上。解法：重叠 10-20%，确保边界语义不丢失。但重叠过多会引入冗余，增加检索噪声——这是另一个 trade-off。
3. 分块策略的选型与调优
- 固定大小分块（如按 tokens 数切）：简单高效，适合日志、代码等结构均匀的文本。但容易切断语义单元（比如把一个表格拆成两半）。
- 语义分块（如
SemanticChunker基于 embedding 相似度切分）：保留完整段落或句子，适合新闻、论文等自然语言。但计算开销大，且对短文本（如产品描述）效果差。 - 递归分块（
RecursiveCharacterTextSplitter按["\n\n", "\n", " ", ""]优先级切）：平衡了语义完整性与实现复杂度，是工业界默认方案。但需要调separators顺序，否则中文文档可能按标点符号乱切。 - 实战建议：先用固定 512 tokens + 50 overlap 做 baseline，然后用
NQ或HotpotQA数据集跑检索召回率（Recall@5）。如果召回率低于 70%，尝试语义分块或调整 chunk 大小。同时监控生成阶段的 faithfulness（用ROUGE-L或BERTScore），因为 chunk 太小会导致生成时缺乏上下文，产生幻觉。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从检索效率、生成质量、工程调优三个层面回答。检索层面，分块是为了让 embedding 向量聚焦局部语义，避免大 chunk 的语义坍缩；生成层面，即使 LLM 窗口够大，过长输入也会导致‘中间丢失’问题，分块能控制噪声；工程层面，常用递归分块加 10-20% 重叠，但需要根据文档类型和召回率指标调 chunk 大小。总结一句：分块是 RAG 中检索精度与生成保真度的平衡点，没有万能参数，必须实验驱动。”
4️⃣ 高频追问 & 应对
追问 1：如果 LLM 上下文窗口无限大，还需要分块吗？
需要。因为检索阶段依赖向量相似度，而 embedding 模型（如
text-embedding-ada-002）的输入长度通常有限（8K tokens），且大 chunk 的向量会丢失局部语义。即使窗口无限，检索召回率也会因语义坍缩而下降。另外，生成阶段的长上下文会导致注意力分散，增加推理成本（O(n²) 复杂度）。所以分块是检索系统的固有需求，不因 LLM 窗口变大而消失。
追问 2：你如何确定最优 chunk 大小？给具体实验设计。
用网格搜索：固定 embedding 模型（如
bge-large-en-v1.5）和检索器（如HNSW），在NQ数据集上测试 chunk_size = [128, 256, 512, 1024] 和 overlap = [0, 10%, 20%]。指标用 Recall@5（检索召回）和 F1（生成答案）。通常 512 tokens + 20% overlap 是安全起点。如果文档是代码，降到 256 tokens；如果是长报告，升到 768 tokens。注意：chunk 大小变化会影响向量库大小，需要评估存储和检索延迟。
追问 3：中文文档分块有什么特殊坑？
中文没有空格分隔，递归分块按
\n\n切可能切到句子中间。解法：先用jieba或spaCy做句子分割，再按句子边界切 chunk。另外，中文 embedding 模型（如m3e-base）对短文本（< 50 tokens）的语义区分度差，所以 chunk 不宜太小，建议 256-512 tokens。如果文档包含中英文混合（如技术文档），需要统一 tokenizer 计数（用tiktoken的cl100k_base），避免按字符数切导致 token 溢出。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“分块是为了适应 LLM 的上下文窗口大小，窗口大了就不需要分块了” → ✅ 正确切入：分块是检索系统的需求，即使窗口无限，embedding 模型的输入长度和语义坍缩问题依然存在。
- ❌ 说“chunk 越小越好，因为语义更精确” → ✅ 正确切入：chunk 太小（< 128 tokens）会导致 embedding 向量缺乏上下文，检索时容易匹配到无关片段，且生成时缺乏背景信息，增加幻觉风险。需要 trade-off 精度与召回。
- ❌ 说“直接用 LangChain 默认的 RecursiveCharacterTextSplitter 就行，不用调参” → ✅ 正确切入：默认参数（chunk_size=1000, chunk_overlap=200）适合英文新闻，但对中文、代码、表格等文档效果差。必须根据文档类型和任务指标（如 Recall@5）手动调参。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在 XX 项目中对比了固定分块与语义分块，发现语义分块在 Recall@5 上提升 12%，但推理延迟增加 30%，最终用递归分块 + 动态 chunk 大小做折中”切入，展示实验驱动思维。
- 如果你只做过传统 NLP：用“文本分块类似于传统信息检索中的文档分段（如段落分割），但多了 embedding 语义密度和 LLM 生成质量的约束”类比，强调迁移能力。
- 如果你是校招无项目：聚焦“我复现了 ‘Lost in the Middle’ 论文，验证了分块对 LLM 生成准确率的影响，并用 NQ 数据集做了 chunk 大小调优实验”，展示论文理解和动手能力。
- “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023)
- LangChain 官方文档：Text Splitters 模块（RecursiveCharacterTextSplitter 源码）
- “Dense Passage Retrieval for Open-Domain Question Answering” (Karpukhin et al., 2020)
- “Semantic Chunking: A Practical Guide” (Weaviate 博客)
- OpenAI Cookbook: “How to chunk text for RAG” (tiktoken 使用示例)