What are some common chunking methods used in RAG

1️⃣ 考察意图

面试官想考察你对 RAG 系统基础组件的掌握深度，而非简单背诵分块方法名称。这道题看似基础，但刁钻点在于：分块是检索质量的“第一道关卡”，直接影响后续检索和生成效果。答好了能展示你对文档结构、语义边界和工程效率的权衡能力。考察类型为“工程取舍+系统设计”，需要你从方法原理、适用场景、实际坑点三个维度展开，并给出可落地的选择逻辑。

2️⃣ 标准答

RAG 中分块的核心目标是：在保留语义完整性的同时，控制块大小以匹配检索和生成需求。常见方法分四类：

固定大小分块（Fixed-size Chunking）
原理：按固定字符数（如 512 tokens）或词数切分，可叠加重叠（overlap）窗口（如 20% 重叠）避免边界截断。
优点：实现简单，计算开销低，适合快速原型。
缺点：语义截断严重，例如一句话被切到两个块，导致检索时上下文丢失；重叠窗口虽缓解但增加存储和检索噪声。
工程取舍：重叠比例越高，检索召回率提升但索引膨胀（如 50% 重叠使块数翻倍），需根据存储成本权衡。实际落地坑：对代码或公式文档，固定切分可能破坏语法结构，导致检索到无意义片段。
递归分块（Recursive Chunking）
原理：从文档结构层级（段落→句子→短语）递归切分，优先保留自然边界。LangChain 的 RecursiveCharacterTextSplitter 是典型实现，默认分隔符顺序：["\n\n", "\n", " ", ""]。
优点：保留语义完整性，适合通用文本（新闻、报告）。
缺点：对无结构文本（如日志）效果差；分隔符优先级需手动调参。
实际落地坑：Markdown 文档中，标题后紧跟列表时，\n\n 分隔可能将标题和列表内容拆开，需自定义分隔符（如 ["\n## ", "\n\n", "\n- "]）。
基于文档结构分块（Document Structure-based Chunking）
原理：利用文档的层次结构（如 HTML 的 <h1>、PDF 的标题、Markdown 的 #）按章节/小节切分。工具如 unstructured 库或 pdfplumber 解析布局。
优点：语义边界最自然，适合结构化文档（论文、手册）。
缺点：依赖文档格式一致性；非结构化文档（如纯文本）无法使用。
工程取舍：结构分块块大小差异大（如摘要块小、正文块大），需设置最大块阈值（如 1024 tokens）并递归切分超长块。
语义分块（Semantic Chunking）
原理：用 embedding 模型（如 Sentence-BERT）计算句子/短语的相似度，当相邻片段相似度低于阈值（如 0.7）时切分。典型实现：LlamaIndex 的 SemanticSplitterNodeParser。
优点：动态适应语义边界，适合主题频繁切换的文档（如问答集）。
缺点：计算成本高（需多次 embedding 推理），延迟增加 2-5 倍；阈值选择敏感，过低导致块过大，过高导致碎片化。
实际落地坑：对长文档（如 100 页 PDF），全量语义分块耗时过长，可先按段落粗分再对超长段语义细分。

选择逻辑：通用场景用递归分块（默认 chunk_size=512, overlap=20%）；结构化文档用结构分块；高精度场景（如法律合同）用语义分块。关键 trade-off：检索粒度越细（块越小），召回率越高但上下文丢失风险越大，需结合生成模型的最大输入长度（如 GPT-4 的 128K）调整。

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

“这个问题我从方法分类、工程取舍、选择逻辑三个层面回答。方法层面，固定大小分块简单但语义截断严重，递归分块保留自然边界，结构分块利用文档层次，语义分块动态适应。工程取舍上，重叠窗口提升召回但膨胀索引，语义分块精度高但延迟高。总结一句：分块方法没有银弹，需根据文档类型、检索粒度和计算资源选择，通用场景推荐递归分块加 20% 重叠。”

4️⃣ 高频追问 & 应对

追问 1：如何评估分块方法的好坏？

用两个指标：检索召回率（Recall@K）和生成质量（如 BLEU/Rouge）。具体做法：在标准数据集（如 Wikipedia 的 QA 对）上，固定检索器和生成器，只换分块方法。注意控制变量：embedding 模型、检索算法（如 HNSW）和生成模型保持一致。实际坑：Recall@K 高不代表生成好，因为块内噪声可能误导生成，需结合人工评估（如 5 分制相关性打分）。

追问 2：分块大小如何确定？有没有经验值？

经验值：chunk_size 在 256-1024 tokens 之间，取决于生成模型的最大输入长度和检索器的 embedding 维度。例如，用 BGE-small 模型（384 维）时，512 tokens 的块 embedding 质量稳定；用 GPT-4 时，可放大到 1024 tokens 以保留更多上下文。工程取舍：块越大，检索精度下降（因为 embedding 被稀释），但生成上下文更完整；块越小，检索精度高但生成可能缺信息。建议用网格搜索（如 256/512/1024）在验证集上调参。

追问 3：如何处理多模态文档（如图文混排）？

分两步：先用 OCR（如 Tesseract）提取文本和图片位置，再按布局切分。例如，PDF 中图片下方有文字说明时，将图片和说明文本作为一个块。工具可用 LayoutLM 或 pdfplumber 解析坐标。实际坑：图片 embedding 需单独用多模态模型（如 CLIP）编码，与文本 embedding 拼接后检索，但会增加延迟和存储成本。取舍：对纯文本场景，忽略图片；对高精度场景（如产品手册），必须保留图文关联。

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

❌ 只列举方法名，不讨论适用场景和 trade-off → ✅ 必须结合具体场景（如“固定分块适合日志，递归分块适合新闻”），并给出选择逻辑。
❌ 说“语义分块最好，其他方法过时” → ✅ 语义分块计算成本高，不适合实时系统；递归分块在通用场景下性价比更高，需强调“没有银弹”。
❌ 忽略重叠窗口和块大小调参 → ✅ 必须提到重叠比例（如 20%）和 chunk_size 经验值（256-1024 tokens），展示工程落地细节。

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在项目中用递归分块处理用户手册，发现标题和列表被错误切分，于是自定义分隔符”切入，展示调参和 debug 能力。
如果你只做过传统 NLP：用“文本分类中的句子分割类比分块，但 RAG 需要保留语义边界而非语法边界”迁移，强调对检索和生成的影响。
如果你是校招无项目：聚焦“我复现了 LlamaIndex 的语义分块 demo，用 Sentence-BERT 计算相似度，发现阈值 0.7 时 Recall@5 提升 15%”，展示论文理解和动手能力。
LangChain 文档：RecursiveCharacterTextSplitter 源码与参数详解
LlamaIndex 博客：SemanticSplitterNodeParser 原理与实验
论文：Chunking Strategies for Retrieval-Augmented Generation（2024, arXiv）
工具：unstructured 库的文档结构解析方法
博客：RAG from Scratch: Chunking and Embedding（Pinecone 官方教程）

—— 本场面试完 ——