【RAG】为什么 RAG 不能跳过分块
前言
做 RAG 时，很多人的第一反应是：既然知识都在文档里，那就把整份文档直接交给大模型，让它自己读完再回答。这个思路看起来简单直接，但在真实系统里往往既昂贵又不稳定。问题不只在于上下文窗口有限，更在于“看得下”并不等于“找得准”。要让检索真正可用，关键不是喂给模型更多文本，而是先把文本切成适合检索的高质量片段，这就是分块的意义。
目录
三、分块的两个核心参数：chunkSize 和 overlap
1. 固定大小分块（Fixed Size Chunking）
一、为什么不能直接把整篇文档喂给大模型？
假设你在一家电商公司做智能客服。公司内部有一份几百页的《客服知识库》，内容覆盖退货政策、物流规则、会员权益、售后流程等。用户提问：
买了 7 天的商品还能退吗？
系统需要从知识库中找到相关规则，并生成准确回答。
最直觉的方案是：把整份知识库直接作为提示词输入给大模型，让模型自己从中找答案。这个方案看似合理，但一旦落地，通常会遇到两个根本问题：上下文窗口限制，以及全量输入带来的检索失焦。
1. 上下文窗口不是无限的
大模型一次能够处理的输入长度有限，这个限制通常称为上下文窗口。可以把它理解为模型的一张工作台：一次能摊开的内容越多，模型能同时参考的信息越多；但这张工作台始终是有限的。
企业知识库往往包含大量规则、条款、流程说明和例外条件。即使不考虑图片、表格和版式，只看抽取后的纯文本，整体长度也可能非常可观。把整份文档直接输入模型，通常会面临几个现实问题：
- 输入长度可能超限，无法一次提交；
- 即使放得下，推理成本也会明显上升；
- 输入越长，响应延迟越高；
- 在高并发业务场景中，整体吞吐能力会显著下降。
因此，问题不只是“能不能塞进去”，更是“是否值得这样做”。
2. 全量长上下文不等于更高准确率
即使假设模型窗口足够大，能一次装下整份文档，也不意味着回答质量就会更好。
用户问“生鲜商品支持七天无理由退货吗”，真正相关的信息，可能只藏在知识库中的一两段文字里。如果把几十万字全部交给模型，相当于要求它在大量噪音中自行定位、筛选、组合答案。这会带来两个典型问题：
- 检索范围过大：模型容易把相关但不关键的信息一起带入回答；
- 规则边界模糊：模型可能忽略例外条件，或把多条规则混在一起解释。
换句话说，更多上下文并不天然等于更强答案，过多无关信息反而会干扰模型判断。
这也是为什么在知识问答、企业搜索、智能客服等场景里，实际系统通常不会把全量文档直接交给模型，而是采用 RAG（Retrieval-Augmented Generation，检索增强生成） 的方式：
- 先从知识库中检索出最相关的少量内容；
- 再把这些内容交给大模型生成最终答案。
这个流程的核心思想很简单：先缩小信息范围，再让模型推理。
但这就带来一个新的前提：如果要检索，文档就不能以“整本书”的形式存在，而必须先被拆成可检索的文本单元。这个过程，就是分块（Chunking）。
二、分块到底在做什么？
1. 分块是 RAG 数据准备中的关键步骤
在 RAG 的数据处理流程中，文档通常会先经过文本抽取，变成纯文本。比如从 PDF、Word、网页或扫描件中提取出文字内容。但纯文本只是原始材料，还不能直接用于高质量检索，因为它通常太长、粒度太粗、语义边界也不清晰。
因此，文本抽取之后，通常还要做两步关键处理：
- 分块：把长文本切成适合检索的小段；
- 向量化：把每个文本块转换成向量，供后续相似度检索使用。
分块看起来只是预处理的一步，实际上会直接影响后续检索质量。块切得合理，检索更准；块切得粗糙，后面再换模型、调提示词，效果提升也会很有限。
2. 为什么整篇文档不能作为检索单元？
因为粒度太粗。
一整份知识库往往同时包含多个主题，例如退货、换货、会员、物流、售后。如果用户只问退货政策，但检索返回的是整章甚至整本内容，那么虽然“答案在里面”，对模型来说依然是噪音很重的输入。
理想的检索单元需要同时满足两个条件：
- 足够小，便于精准命中；
- 足够完整，能独立表达一个相对清晰的意思。
分块的本质，就是在“检索精度”和“语义完整性”之间找到平衡。
三、分块的两个核心参数：chunkSize 和 overlap
1. chunkSize：每个块应该切多大？
chunkSize 表示单个文本块的长度上限。这个长度可以按字符数计算，也可以按 token 数计算。
它没有统一标准，但有非常明确的权衡关系：
- 块太大：信息更完整，但容易混入不相关内容，降低检索精度；
- 块太小：定位更精准，但可能把一条完整规则切散，导致上下文丢失。
以客服知识库为例，如果一个块同时包含“退货条件、例外品类、运费责任”三类信息，那么检索时可能会召回过多附带内容；但如果一个块只有几十个字，又可能不足以独立表达完整规则。
所以，chunkSize 的目标不是越大越好，也不是越小越好，而是让每个块既能表达一个相对完整的语义单元，又不过度混杂多个主题。
2. overlap：为什么相邻块之间要重叠？
overlap 指的是相邻两个文本块之间共享的内容长度。
它的作用是：避免关键信息刚好落在分块边界上而被切断。
例如一条规则写的是：
自签收之日起 7 天内，商品未经使用且不影响二次销售的，消费者可申请七天无理由退货。生鲜食品、定制商品、贴身衣物等特殊品类不适用此规则。
如果切分时不考虑重叠，“七天无理由退货”这几个关键词可能刚好被分到两个块中，导致两个块都不完整。加入适量重叠后，边界附近的关键内容会在相邻块中重复出现，从而降低漏召回的概率。
当然，overlap 也不是越大越好。重叠越多，重复文本越多，存储、向量化和检索成本也会随之上升。实践中通常会从一个适中的比例开始，再结合效果微调。
3. 字符和 token 有什么区别？
很多人在设置分块参数时，会同时看到“字符数”和“token 数”两种口径。
- 字符（Character）：就是我们肉眼看到的字母、汉字、空格和标点；
- Token：是模型在内部处理文本时使用的最小单位。
大模型的上下文窗口和计费通常都以 token 为单位，因此从理论上说，基于 token 的分块更精确。但在很多业务系统中，按字符数分块也完全可行，因为它更简单、更直观，也更便于快速试验。
一个常见做法是：
- 原型阶段先按字符切分；
- 方案稳定后，再根据模型特点切换到 token 级控制。
四、主流分块策略有哪些？
分块并不是一种固定方法。不同文档结构、不同检索目标，适合的策略也不同。下面是几种常见方案。
1. 固定大小分块（Fixed Size Chunking）
这是最简单的方式：不考虑文本语义和结构，只按固定长度切分，比如每 500 个字符切一块。
它的优点很明显：
- 实现最简单；
- 性能稳定；
- 易于快速上线和验证。
但缺点同样明显：
- 完全不关心句子、段落或章节边界；
- 很容易把一条完整规则从中间切开；
- 生成的块在语义上往往不自然。
因此，固定大小分块更适合结构不重要的文本，例如日志、流水文本，或者作为其他复杂策略的兜底方案。
2. 重叠分块（Overlapping Chunking）
重叠分块是在固定大小分块的基础上加入了重叠区域。相邻两个块共享一部分文本，以减少边界处的信息损失。
它的优势在于：
- 实现依旧简单；
- 能有效缓解句子被切断的问题；
- 适合作为通用入门方案。
但它的本质仍然是“规则切分 + 局部补偿”，并没有真正理解文本结构，只是用重复内容来降低边界风险。因此，它适合作为基础方案，但未必是长期最优解。
3. 递归分块（Recursive Chunking）
递归分块是实践中非常常见的默认选择。
它的核心思路是：优先按照较大的自然边界切分，如果某个块仍然过大，再逐层使用更细的分隔符继续切。
例如可以按这样的优先级逐步尝试：
- 空行或章节分隔；
- 换行；
- 句号；
- 逗号；
- 空格；
- 最后才按字符硬切。
这种策略的好处是，它会尽可能保留文档原有结构。能按章节切就不按句子切，能按句子切就不按字符切。这样既能控制块大小，又尽量保证语义完整性。
对于知识库、产品手册、政策文档、FAQ 等结构相对清晰的文本，递归分块通常都是最稳妥的默认方案。
4. 语义分块（Semantic Chunking）
前面几种方法本质上都属于规则分块：按长度切、按标点切、按层级切。它们并不真正理解文本“在讲什么”。
语义分块的思路不同。它会借助 Embedding 模型，或者直接借助大模型的语义理解能力，在主题发生明显变化的位置切分文本。
典型流程通常是：
- 先按句子拆分；
- 为每个句子生成向量表示；
- 计算相邻句子之间的语义相似度；
- 在相似度显著下降的位置切分。
它的优势非常明显：
- 切分点更符合真实语义边界；
- 每个块内部主题更集中；
- 对高精度检索场景更友好。
但代价也同样明显：
- 计算成本更高；
- 实现复杂度更大；
- 处理速度通常慢于规则分块；
- 还需要调节阈值和策略。
因此，语义分块更适合对准确率要求很高的场景，例如法律、医疗、金融合规等高价值知识库。
5. 混合分块（Hybrid Chunking）
真实项目里，单一策略往往无法覆盖所有文档类型。更常见的做法是把多种策略组合使用。
例如：
- 产品手册使用递归分块；
- FAQ 按问答对切分；
- 合同文本使用语义分块；
- OCR 文本采用重叠分块来缓解结构破碎问题；
- 分块完成后，再做一次后处理：合并过短块、拆分过长块、补充标题和来源等元数据。
混合分块的优点是适应性更强、整体效果更好；缺点是实现和维护成本更高。因此它更适合文档来源复杂、质量要求较高的企业级 RAG 系统，而不适合一开始就用于简单 Demo。
五、分块策略应该怎么选？
1. 先看文档结构，再决定策略
很多人在做 RAG 时，一上来就纠结 chunkSize 应该设多少。实际上，参数通常不是第一决策点，文档类型和结构才是。
一个更合理的思路是：
- 知识库 / 产品手册：优先递归分块；
- FAQ / 问答集：优先按问答对切分；
- 合同 / 法律条款：优先语义分块；
- 日志文本：按行切分或固定长度切分；
- 代码文件：按函数、类、模块等结构切分；
- HTML 页面：先清洗标签，再做递归分块；
- OCR 或格式混乱文本：优先重叠分块，再结合清洗或后处理。
结论很简单：先理解文本天然结构，再设计分块方式，而不是先拍脑袋设一个统一参数。
2. 参数应该如何起步？
分块参数没有放之四海而皆准的最优值，但可以遵循一个务实原则：先用经验值启动，再用真实查询验证。
调参时可以重点观察两个现象：
- 如果检索结果经常过于发散，说明块可能太大；
- 如果检索结果经常缺少必要上下文，说明块可能太小，或重叠不足。
也就是说，参数调整的目标不是追求理论上的最佳值，而是在你的文档分布和用户问题分布上，找到更适合业务的平衡点。
六、企业级 RAG 中，分块往往不是唯一问题
很多团队在检索效果不理想时，会把问题全部归结为分块策略不对。但在真实系统中，效果差往往不只是“切得不对”，而是上游文本本身就不干净。
尤其是 PDF、扫描件、复杂版式文档，常见问题包括：
- 页眉页脚、页码、目录混入正文；
- 一句话被错误断行，段落结构被打散；
- 表格被拆成碎词，字段顺序错乱；
- OCR 误识别过多，导致原始语义变形。
如果抽取出来的文本已经充满噪音，那么再好的分块策略也很难稳定发挥作用。因此，更可靠的工程流程通常是：
- 文本抽取；
- 文本清洗与结构修复；
- 分块；
- 向量化；
- 检索评估与迭代优化。
此外，在一些中小规模但高价值的知识库中，纯自动分块未必总是效果最好。很多时候，先自动分块，再做少量人工二次编排，反而更符合真实业务问题。这种做法虽然不够“全自动”，但在企业场景里往往更实用。
七、如何评估分块是否有效？
一个常见误区是：只看分块结果“读起来顺不顺”，却不验证它是否真的提升了检索效果。实际上，分块的好坏最终应该用检索表现来衡量。
至少可以从三个角度去判断：
1. 召回是否准确
同样一个问题，系统召回的内容是不是明显更聚焦？是否更容易命中真正相关的条款，而不是一大段泛泛而谈的背景信息？
2. 语义是否完整
召回的块能不能独立表达清楚规则？如果一个块命中了关键词，却因为边界切分不当而缺失前提条件、例外说明或结论，那么它在检索层面其实是不合格的。
3. 回答是否更稳定
高质量分块带来的好处，不只是“命中答案”，更是让模型在生成答案时更稳定。因为它拿到的是更干净、更聚焦的上下文，而不是一堆相关但混乱的信息。
从这个角度看，分块不是单纯的数据处理问题，它会直接影响最终回答的可解释性与一致性。
结语
在 RAG 系统里，分块不是一个可有可无的预处理步骤，而是决定检索效果上限的关键环节。
把整篇文档直接交给大模型，看似省事，实际上既不经济，也不稳定。更合理的做法是：先把长文本拆成大小合适、语义尽可能完整的文本块，再通过检索把真正相关的内容交给模型推理。
从工程实践看：
- 固定大小分块 最简单，但也最粗糙；
- 重叠分块 能缓解边界断裂问题；
- 递归分块 是大多数场景下的默认选择；
- 语义分块 精度更高，但成本也更高；
- 混合分块 更适合复杂企业知识库。
最终要记住的一点是：没有一种分块策略适合所有文档，只有适合当前业务场景的分块方案。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
3
0- 0
已为社区贡献3条内容
所有评论(0)