RAG检索质量上不去？先搞懂文档分块和向量化：原理、参数与调优指南

做RAG的人早晚会撞上同一个尴尬：模型选了最好的，向量库也搭得像模像样，可一问就露馅——系统检索回来的片段，要么干脆答非所问，要么和问题沾边但关键信息全丢。我最早在某知识库项目里排查了三天，最后发现整条链路的病根不在模型，而在最容易被忽略的文档分块和向量化环节。这篇就围绕 RAG 里最基础也最关键的两件事——文档分块和向量化，把原理、选型、参数、调参路线和翻车案例一次讲透，适合正在做 RAG 落地、对检索质量不满意的同学参考。

先说一个重要结论：在一套 RAG 系统里，分块方式和向量化模型的选择，对最终效果的影响往往比生成模型本身更大。因为生成模型看到什么，完全取决于检索结果，而检索结果的质量上限，在文档切分和向量表示那一刻就已经定死了。后面所有重排、提示词优化，都是在"检索上限"下面做小修小补。

1. 为什么"切文档"才是决定检索上限的第一步

1.1 检索粒度与语义稀释问题

很多刚接触 RAG 的人会把"向量化"想成一种神奇操作：把整本文档丢给模型，得到一个向量，查的时候拿问题向量跟它比相似度就行。这个思路错在粒度。整篇文档的向量是一长段文本里所有语义的总和，做相似度匹配时，细节会被"平均"掉。

举个我实际处理的例子。某产品手册里有一段三千字的安装说明，其中有一句"墙板与立柱之间使用 M10 螺栓，拧紧力矩 25N·m"。如果把整段塞进一个向量，这个向量的主导成分是"安装、装配、工具、步骤"这类通用语义，当用户问"这个支架要用多大扭矩固定"时，检索系统很可能把这段和其他包含"扭矩"字眼但完全无关的段落混在一起，排序上不去，答案自然也找不对。

我通常用一个直白的类比来解释：向量检索本质上是"在地图上找离你最近的坐标点"，文档分块决定了地图上到底有多少个坐标点、每个点代表多大范围的语义。坐标点定得太稀（块太大），你想找的具体位置就会被淹没；定得太碎（块太小），每个点又都太片面，看不出全景。分块要做的，是找到"信息自洽的最小单元"——一个块最好只讲一个主题，并且单独拿出来也能被读懂。

1.2 模型上下文不是拿来装整本文档的

有人会说：既然大模型的上下文窗口越做越大，干脆把整篇文档都塞进去，不用分块不就行了？这个想法在演示阶段很诱人，生产环境却站不住脚。

首先是成本和延迟。每多一万个 token，生成时的计算量、显存占用和响应时间都会明显上升，线上服务扛不住把几十份文档全文都推进去。更关键的是，RAG 的核心理念不是"让模型读全部"，而是"让模型读该读的那一小块"。如果上下文里塞满无关内容，模型即使窗口足够，也容易把注意力分散到噪声上，甚至被无关段落里的错误信息带偏。窗口再大，一块文本里混着五个主题，生成质量依然不可控。

所以分块要解决的第一层问题就是：让检索的对象从"整篇文档"细化到"语义单元"，保证真正包含答案的那一小段文本，在相似度计算时能露出头来。

1.3 分块质量会一路传导到生成阶段

这条链路经常被低估：分块边界切得不好 → 检索召回残缺片段 → 生成模型拿残缺片段硬编答案，答案要么缺关键条件，要么干脆编造。我在某法律问答系统里就遇到这种情况：一份裁决文书的"争议焦点"和"裁判结果"被切到了两个块里，用户问"法院最终怎么判的"，检索回来的块只包含后半句，前半句的赔偿基数丢了，系统就自己脑补了一个数字。

这说明一个很简单的道理：分块不是预处理的小事，而是 RAG 管线的"第一因"。它决定了检索命中率、决定了喂给生成模型的上下文质量、决定了最终答案的可靠性。所以做任何调优之前，先把分块和向量化这一层夯实，比直接换一个更大的生成模型有效得多。

2. 分块策略全景：从"按字数硬切"到"按语义软切"

2.1 固定长度切分：最省事，但是"文字屠宰场"

固定长度切分是最朴素的做法：设定一个最大长度，比如每 500 个字符或每 200 个 token 一块，超出就截断，然后从上一个切点往前挪一段距离再切下一块，挪动的距离就是 overlap。

它的优点非常明显：实现简单、计算量可控、不需要理解文档结构，适合日志、流水记录、模板化表单这类本身没有太多语言结构的文本。但它的问题也很突出。我在测试某客服 FAQ 时，用 500 字符固定切分，把一句"退款流程分三步：提交申请、审核、原路返回，其中审核需要提供订单号和付款凭证"硬生生切断，后面半个句子被切进了下一块，检索"退款要准备什么材料"时，只召回到含"退款流程"的那块，材料清单信息整段丢失。

所以固定切分适合拿来当基线，不适合作为严肃知识库的默认方案。它最大的价值是：让你先有一个"能跑"的管线，再在这个基线上对比其他切分方式的提升幅度。

2.2 递归字符切分：目前最值得默认的选择

现在绝大多数开源的 RAG 框架里，默认推荐的都是"递归字符切分"。它的思路是把文档看成有层级的文本：段落靠空行分隔，段内靠换行和标点分隔，英文里还有空格分词。切分时从最粗的分隔符开始尝试，如果切出来的块仍然超过限制，就降级到下一层更细的分隔符继续切。

实际操作时，分隔符的优先级一般这样排：

• 先按段落之间的空白行（\n\n）切；
• 段落仍超长，再按单个换行符切；
• 仍超长，按句号、问号、感叹号切；
• 仍超长，按分号、顿号切；
• 最后才按空格或字符硬切。

这个策略的好处是，只要文档不是极端病态，大部分句子都是完整的，切点通常落在段落或句子边界上，块内的语义相对自洽。

我把递归切分当作默认起点，参数建议从 chunk_size=250（token 数）、overlap≈50（token 数）开始，中英文都很稳妥。后面调优时上下浮动，但不太建议一上来就极端调小或调大，后面第四节会展开讲。

2.3 语义切分与结构感知切分：什么时候值得"上强度"

递归切分虽然保留了句子完整性，但它不考虑"语义是不是在这里拐弯了"。"语义切分"的做法是先对句子的向量编码，然后计算相邻句子的相似度，如果相似度发生明显下降，就认定这里是一个新话题的断点。

语义切分对散文、新闻、叙事类文档效果好，因为这类文本的话题边界不是靠标点而是靠内容切换的。缺点也很明显：逐句调用向量模型计算成本高、处理速度慢，而且阈值不好定，设得太敏感会把一个大段落切成碎片。我只在"招不到相关片段"且确认递归切分已经尽力的情况下，才会把它作为候选方案。

结构感知切分是另一个思路：不猜语义，直接用文档自带的章节结构。比如 Markdown 里的二级标题、三级标题，或者 Word 文档里的标题层级，每个标题下的内容作为一个块。更讲究的做法是，切块时把父级标题拼到块内容的前面，比如"3.2 安装步骤：墙板与立柱之间使用 M10 螺栓……"，这样向量化时，标题就成了块的"语义前缀"，检索"墙板固定扭矩"就能多一层主题约束。

我自己的经验是：如果知识库文档本身结构良好，优先试结构感知切分；结构不好但重复频繁的，优先语义切分；都没有明显优势的，就用递归切分。三种方式的取舍可以用下面这张表概括。

2.4 某法律问答系统的分块选型实测

空谈没用，说一个我经历的真实案例。某法律问答系统要检索裁决文书和法规条文，文档平均长度一二十页，结构非常规整，每条法规都有"第 X 条"的标号，裁决文书则有"查明""本院认为""裁判结果"这些固定段落。

我先后做了三版对比。第一版固定 500 字符切分，检索"交通事故责任如何认定"时，召回内容里经常只含"本院认为"的开头，把结论部分甩到了下一块，回答质量惨不忍睹。第二版换成递归切分，句子完整度上来了，但长条款还是会被拦腰截断，个别条款超过了两千字，始终没有一个块能完整覆盖它。第三版改成结构感知切分：按"第 X 条"标号和文书固定段落切块，块会自动继承条目标号和段落标题作为前缀。

结果很直观。在同样的测试集上，用同样的向量化模型，第三版把 recall@5（正确答案出现在前五个检索结果里的比例）从 0.42 提到了 0.71，生成答案里"张冠李戴"的错误也基本消失了。这个案例给我的启发是：别一上来就迷信某个切分算法，先看你文档里有没有现成的结构，有结构就用结构，没有结构再谈参数。

3. 向量化的本质：把文本映射进语义空间

3.1 Embedding 到底在算什么

分块解决的是"切哪一段"的问题，向量化解决的是"怎么让计算机判断这些片段和你的问题像不像"。Embedding 做的事情，是把一段文本编码成一个高维向量，常见维度有 384、768、1024、1536 等。在一个训练好的向量空间里，语义相近的文本，向量之间的距离就近；语义无关的文本，向量就远。

模型是怎么训练出来的？主流方法是对比学习：把大量"上下文相关的文本对"当作正样本，把"随机拼凑的无关文本对"当作负样本，让模型学会把相似文本的向量拉近、把不相似文本的向量推远。所以一个 Embedding 模型好不好，本质是看它在多大程度上对人类认为的"语义相关"建立了正确的空间映射。

检索时的相似度一般用余弦相似度，公式就是两个向量夹角的余弦值，落在 -1 到 1 之间，越接近 1 表示方向越一致。针对检索场景，大于 0.75 是"明显相关"，0.5~0.75 是"可能相关"，低于 0.3 基本可以判定无关。但要注意，这个区间和具体模型强相关，不同模型的分数分布差异很大，不要跨模型比较，更不要把 A 模型的阈值直接搬到 B 模型上。

3.2 中英文场景下的模型选型核心指标

选 Embedding 模型时，我看四个指标，按重要程度排序：

1. 语料语言覆盖。中文文档优先看模型在中文语料上的表现，而不是它在英文评测榜单上的分数。很多英文强模型对中文长文本的支持一般，会把咬文嚼字的差分词义编码到一起。
2. 最大输入长度。它决定了你的块最大能到多少 token。如果模型最长只能吃 512 token，你却想用 1000 token 的大块，后面的内容会被截断，向量信息直接丢失。
3. 向量维度。维度越高，单条向量的表达力通常越强，但存储和检索开销也越大。几千到几万条片段的应用，维度差异几乎无感；上了百万级再认真权衡。
4. 部署方式。接口调用和本地部署的选择主要看隐私、成本和并发。文档要出网加密，最好本地；查询量大且希望低延迟，也建议本地。另外别忽略批处理能力，批量向量化的速度差能有几倍到十几倍。

还有一个常被忽略的：领域词汇的覆盖。我在某医疗健康知识库里试过两个模型，一个把"心悸""心律失常"编码得离得很近，另一个更偏通用语义，相似度低了不小。所以选型时不要只看榜单，拿自己领域的三五十个查询词，跑一遍小样本检索对比，比看任何指标都靠谱。

3.3 查询和文档必须"同模同源"

这是最容易踩的隐性坑。向量检索的前提是：文档向量和查询向量处在同一个向量空间里。如果你用 A 模型给文档做向量化，用 B 模型给用户查询做向量化，两个空间根本不对齐，余弦相似度失去了可比意义。

我见过有人为了省接口费，文档用本地开源模型批量向量化，查询走闭源接口，结果召回率骤降还不明所以，最后花了整整一天排查才发现问题。另一个坑是用同一家模型的不同版本，新旧版本的向量空间也可能不一样。规矩只有一条：换了向量化模型，全库必须重新 Embedding，查询侧和文档侧永远用同一个模型、同一个版本。

3.4 向量索引与检索的底层：暴力扫描、近似近邻与参数取舍

向量化之后落到向量数据库，就涉及索引策略。最朴素的检索是暴力扫描：把查询向量和所有文档向量做余弦相似度，取 TopK。对十万以内的片段量级，暴力扫描完全够用，不折腾、不丢精度。

数据量再上去，就要用近似最近邻检索，典型的是图结构索引（把向量组织成一张图，检索时从起点逐步扩散逼近最近邻居）和聚类倒排索引（先聚类缩小范围，再在候选簇内检索）。前者调召回率相关的参数时，越大越准但越慢，后者则要权衡聚类数和探测范围。

我给一个务实建议：大部分 RAG 项目初期就是几千到几万条片段，别上来就在索引策略上堆配置。先在暴力扫描下跑通质量，确认是这块卡性能瓶颈了，再上近似检索，并且用相同查询集对比召回率有没有明显下降。否则你根本分不清质量问题到底来自索引近似，还是来自分块和向量化本身。下面是一段最简单的余弦相似度计算，方便校验检索逻辑。

# 计算两个向量的余弦相似度（伪代码，依赖纯数学计算） import math def cosine_similarity(vec_a, vec_b): dot = sum(x * y for x, y in zip(vec_a, vec_b)) norm_a = math.sqrt(sum(x * x for x in vec_a)) norm_b = math.sqrt(sum(y * y for y in vec_b)) return dot / (norm_a * norm_b + 1e-9)

4. 分块参数与检索质量的真实关系：chunk_size、overlap 与 top-k 怎么搭配

4.1 一个能落地的调参流程

分块参数里最先要定的是 chunk_size。它直接决定粒度和检索命中的概率。块太大，语义被稀释，查询向量和整块向量的相似度会普遍偏低；块太小，块里只含着半句话，即使命中，也没法支撑生成模型组织出完整答案。

我推荐的默认调试流程是：

1. 固定检索返回数量 top_k 为 5；
2. 固定文本切分器的分隔符层级为递归切分同款；
3. 分别用 chunk_size = 100、200、300、500 跑一遍同一份测试集；
4. 看 recall@5 和答案完整性，选出最优区间；
5. 锁定 chunk_size 后，再调 top_k，观察 3、5、10 的差异；
6. 最后才算表演示层的相似度阈值。

为什么要先固定 top_k 再调 chunk_size？因为 top_k 是检索的出口参数，它的作用是最后兜底，而 chunk_size 是入口参数，决定检索候选本身的质量。入口歪了，出口怎么兜都兜不回来。实测里有一个挺典型的现象：chunk_size 从 200 调到 400，recall 可能会先升后降，升是因为上下文更完整了，降是因为语义稀释超过了上下文完整带来的收益。曲线拐点对应的就是你这批文档的最优块大小。

4.2 overlap 设置的逻辑

overlap 是为了解决一个非常实际的问题：切点可能正好落在一句关键论述中间。如果下一块的开头丢了这句，相关信息就断了。让相邻块有一定的重复区域，等于给关键句子上了"双保险"，无论切点怎么落，总有一块包含了完整内容。

中文场景下我常用 chunk_size 的 10%~20% 作为 overlap，也就是 250 token 的块配 30~50 token 的重叠。对法规、合同这类一字不能差的文档，我会把 overlap 提到 25%~30%，防止条款衔接处被切丢。

但 overlap 不是越大越好。重叠区域本身也是噪声，会让邻近块之间相似度异常接近，检索时可能连续返回好几个语义几乎一样的重复块，白白浪费候选名额。另外，每块里多了重复内容，向量会更"平均"，精细语义更不容易凸显。所以默认 10%~20%，特殊场景再往上加，不要盲目堆。

4.3 混合检索与重排：分块之外的保底手段

分块和向量化做得再细，纯语义检索也有盲区。最典型的是专有名词、编号、型号这类精确匹配需求。比如用户问"FN-X200 的保修期"，语义检索可能把"FN-X200"和"FN-X300"当近义词，返回一堆类似型号的内容；但关键词检索能精确锁定只有一个字符差异的字符串。

所以成熟一点的系统会做混合检索：一路走向量语义相似度，一路走关键词匹配（比如 BM25 这类词频-逆文档频率算法），两路结果合并后统一排序。实测里，混合检索对含编号、型号、法律条款号的查询提升最明显。以某电商售后知识库为例，纯向量检索对"退款流程"这类问题容易召回同义替换内容，加上关键词路和重排之后，相关片段稳定进入前 3。

重排这一步也很关键。把两路召回合并后的候选，交给一个更强的排序模型二次打分，把最相关的排到最前面。它的计算量比向量相似度大，但只作用于少量候选，成本可控。我的习惯是：前期先不加重排，等确认分块和向量化已经调到稳定水平，再加重排，因为重排能掩盖底层的检索问题，会干扰你对真正瓶颈的判断。

5. 检索翻车现场：我踩过的分块和向量化坑

5.1 现象一：查询没召回任何相关片段

症状是用户问了一个很明确的问题，检索返回的全是些八竿子打不着的块。排查链路我一般这样走：

• 第一步，打印命中的相似度分数分布。如果全部低于 0.3，大概率不是排序问题，而是根本没有相关片段被编码成可检索的向量。
• 第二步，把命中的块内容打印出来，看块是否完整。如果发现关键信息在分块时被切飞了，问题就出在切分粒度。
• 第三步，把 chunk_size 调小一档再试。块太大导致语义稀释、相似度被压平的情况，调小立竿见影。
• 第四步，仍然无效，检查文档里用的词和问题里的词是不是根本不在同一套表达体系里。比如文档写"故障排除"，用户问"机器坏了怎么办"，这种纯语义匹配失效的场景，加关键词路混合检索效果很好。

我印象最深的一次，是某知识库把所有产品规格表放在一个大表格里，一个块装了几百个参数，用户问"某型号重量是多少"，整块向量的相似度被十几个同类参数平摊了，排名极低。改成按表格行切分后，recall 直接翻了倍。

5.2 现象二：召回了语义相似但完全答非所问的内容

这个坑最烦人，因为检索结果"看起来相关"。比如某医疗健康库里有大量讲"失眠"和"熬夜"的段落，问"长期熬夜有什么危害"，返回的却是"如何改善睡眠质量"——语义上确实沾边，但答非所问。

根因是语义空间里这些高频词共现太密，向量区分度不够。针对这类问题，我的修复手段依次是：

1. 把结构感知切分加上，让块继承标题前缀，用标题做主题约束；
2. 给块打元数据标签，比如疾病类别、文档来源章节，检索时按元数据过滤；
3. 引入重排模型做二次精排，它能看到查询和文档的全量 token，能更好地识别"话题一致但意图不一致"的情况。

注意一点：向量检索本质是"找相似"，不是"找正确"。相似度高的块未必包含答案，这是语义检索的天生局限，单纯调参数很难根治，要靠混合检索和重排来补。

5.3 现象三：换一种切法，结果天差地别

同一个文档库，不同切分方式之间，检索指标波动大到离谱的情况，我见得太多了。这其实不奇怪：切分方式变了，块边界变了，向量隶属关系全变了，检索结果自然翻天覆地。这不是 bug，是正常现象，但也提醒我们：切分实验必须系统性做，每次只改一个变量，否则你根本不知道是哪个改动带来了提升。

快速定位切分问题有个小技巧：直接抽几个典型块出来人眼过一遍。统计一下有多少句子被拦腰切断、有多少块混着两个主题，基本就能预判检索水平。我习惯每换一套切分参数，就把边界样本打印成文本，肉眼扫一遍，比盯着指标瞎猜快得多。

5.4 向量化环节的隐性坑

向量化流程里也有几个容易被忽视的坑。第一，Embedding 模型吃的是纯文本，如果你的文档里有扫描件、PDF 图片、复杂表格，OCR 和版面解析的质量会直接决定向量化的质量，源头解析烂，后面怎么调都徒劳。第二，超长输入会被截断，如果一块文本超过模型最大长度，后半段的语义会静默丢失，块越大这个问题越严重。第三，文本的细微差异也会带来向量抖动，比如全角半角空格、换行符残留、PDF 换行造成的单词断裂，都会让同一句话编码出的向量略有偏移。所以在向量化之前，做一次干净的文本清洗，收益非常可观。

6. 检索质量评估：别靠感觉，用数据说话

6.1 构建测试集的最小可行方案

很多团队调 RAG 全靠"试几个问题看看效果"，这是最危险的调优方式，因为你不知道一次改动究竟是普遍提升还是碰巧对某几个问题有效。我的做法是建一个最小可用的检索测试集。

步骤不复杂：从知识库里挑 30~80 个有代表性的片段，每个片段人为构造 1~3 个用户可能会问的问题，记录该片段作为这个问题的"标准答案块"。构建问题可以借助大模型辅助生成，但最后一定要人工抽查，防止生成的问题和原文对不上。测试集的质量比数量重要，我宁可要 30 个人工核对过的，不要 300 个草草生成的。

6.2 核心指标怎么读

评估检索质量，我日常只看三个指标，先看命中再看排序：

• recall@k：标准答案块是否出现在检索结果的前 k 个里。这是最基础的命中率指标。
• hit@1 / hit@5：按排序位置看的命中率，hit@1 表示第一个结果就对。
• MRR：标准答案块排在第几位，取倒数的平均值，衡量"正确答案靠前到什么程度"。

下面这段是评估逻辑的骨架，任何检索器都可以套用。

# 检索质量评估（伪代码，替换为你的检索器实现） def evaluate_retrieval(test_set, retriever, top_k=5): hits = 0 for item in test_set: results = retriever.search(item["query"], top_k=top_k) chunk_ids = [r["chunk_id"] for r in results] if item["golden_chunk_id"] in chunk_ids: hits += 1 return hits / len(test_set)

但一定要说清楚：召回指标衡量的是"相关片段有没有被捞回来"，不等于"最终答案对不对"。生成模型可能拿到正确的片段仍然答错，也可能靠推理把不完整的内容补对。所以调完检索层，还要抽一批问题做端到端的口语化评测，两层分开看，问题才定位得准。

6.3 持续优化的迭代闭环

有了测试集，调优就变成了可重复的实验：固定基线，改一个变量，跑一次测试集，记录指标，对比前后差异。每轮改动只动一个因素——要么 chunk_size，要么 overlap，要么向量化模型，要么是否加重排。多变量一起动会让实验结果彻底失去解释力。

我自己的收敛标准是：连续三轮修改，在测试集上的 recall@5 不再明显提升，就认为当前检索方案已经稳定，再投入精力到生成侧的提示词优化或答案校验上。这里再分享一个我觉得性价比极高的习惯：每发现一个检索失败的问题，就把它记进一个单独的"失败案例集"，标注失败原因和当时的环境参数。这个集合攒到几十条之后，比任何工具都能帮你快速判断"这次效果变差，是不是又踩了老坑"。我后来几套知识库的调优，都是靠这份失败案例集合，而不是靠记忆。

分块和向量化看着是 RAG 里最"不起眼"的一环，可它偏偏是整个系统效果的承重墙。把这一层做扎实了，你会发现生成模型的压力小很多，很多"看起来是模型不行"的问题，其实是墙没砌稳。