分块（Chunking）

分块是 RAG 索引阶段的第一步，决定了后续向量化与检索的基本单元粒度。

• 核心目标：将原始文档切分成语义相对完整、长度适合嵌入模型处理的片段
• 块大小的权衡：块太大，单条向量难以准确表示内部多个语义主题，检索精度下降；块太小，丢失关键上下文，模型缺乏足够信息作答
• 重叠窗口（Overlap）：相邻两块之间保留一段重复文本，缓解块边界截断语义的问题
• 核心超参数：Chunk Size（块大小，业界常用起点为 512 Token，范围 256–1024 Token）与 Overlap（重叠量，常见 10%–20%，即 50–100 Token），最优值高度依赖文档类型与检索任务

文档经分块后，每个片段独立进行向量化并存入向量数据库，检索时按语义相似度命中对应片段再送入 LLM。

• 固定大小分块（Fixed-size Chunking）：最基础方式，按固定字符数或 Token 数截断，实现简单但可能切断句子或段落
• 嵌入模型约束：块大小上限受嵌入模型最大输入长度限制（常见为 512 或 8192 Token）
• 上下文窗口约束：检索回来的若干块会拼接送入 LLM，总长不能超过 LLM 的 Context Window 限制
• 评估闭环：更改块大小后需重新评估检索召回率（Recall）和端到端答案质量，实验表明合理的分块策略可使准确率从 65% 提升至 92%

围绕固定大小分块的局限，业界发展出多种更精细的策略。

• 递归字符分块（Recursive Character Text Splitting）：LangChain 等框架中常用折中方案，优先按段落分割，段落仍过长则依次按句、词缩小粒度，是大多数 RAG 应用的基线方法
• 语义分块（Semantic Chunking）：计算相邻句子的嵌入余弦相似度，在相似度骤降处（即语义跳跃点）断开，生成主题更内聚的块
• 结构感知分块（Structure-aware Chunking）：利用文档格式信息（Markdown 标题、HTML 标签、段落分隔符）确定切割位置，保留文档逻辑层次
• 父子块（Parent-Child Chunking）：用小块（Child）做向量检索，命中后返回其所属大块（Parent）作为 LLM 输入上下文，兼顾检索精度与上下文完整性
• 基于 LLM 的分块：由 LLM 自行判断语义边界来切分文档，质量高但成本显著高于规则方法

不同文档类型对分块策略有不同要求，需按场景选择。

• 技术文档与法律合同：语义分块或结构感知分块能较好保留条款的完整含义，避免跨条款混淆
• 代码检索：固定大小分块容易破坏代码结构，通常按函数或类为单元切分（LlamaIndex 提供专用 CodeSplitter）
• 多模态文档（含图表、公式）：需先解析并格式转换，再进行文本级分块
• 企业知识库与客服问答：分块质量对最终答案质量的影响往往不亚于模型本身的选择

分块作为独立工程概念随 RAG 框架的普及而系统化。

• 2020：Lewis 等人提出 RAG 框架（《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》），文档切分概念初现，但尚未形成系统方法论
• 2022 年 10 月：LangChain 发布，TextSplitter 模块将固定大小分块与递归分块标准化，成为开发者首选工具
• 2022 年末：LlamaIndex（原 GPT Index，Jerry Liu 创建）专注 RAG 数据索引，引入 NodeParser 与 SentenceSplitter，进一步细化分块抽象
• 2023–2024：语义分块、父子块等高级策略在社区中广泛实验；Weaviate、Pinecone 等向量数据库厂商相继发布分块最佳实践指南
• 2025 至今：随 LLM 上下文窗口扩大（百万 Token 级别），「是否还需要分块」被重新讨论，但对于大规模企业文档库，分块仍是经济高效的必要手段

分块策略中有几类常见误区值得警惕。

• 照搬经验参数：将他人场景的块大小直接套用，忽视自身文档类型与查询模式的差异
• 过度依赖重叠：增大重叠能减少边界截断，但同时增加向量数据库存储量与检索成本，重复内容还可能干扰排序
• 忽视文档解析质量：PDF 解析后若存在乱码或表格被拉平为散乱文本，再好的分块策略也无济于事
• 不做评估就上线：更改分块参数后需重跑检索评估（如 Recall@K），而非仅凭人工抽查几条样例判断效果