做RAG项目踩过坑的人都明白一个道理：真正决定问答质量上限的，往往不是选哪个大模型，而是文档进检索之前的“预处理”做到什么程度。很多人把精力全花在提示词调优上，结果检索回来的片段压根不对，模型再强也答不出正确答案。这也是为什么聊RAG技术，文档分块和向量化这两个环节值得单独拿出来深挖。我打算用这篇把分块策略的取舍逻辑、向量化的底层原理，以及我实际落地时踩过的一些坑一次性讲清楚。无论你是刚接触RAG的新手，还是已经在调检索效果的老手，这篇都值得花十分钟看完。

1. 先想清楚：分块为什么是RAG的第一道闸门

很多人第一次接触RAG，最先做的事情就是把文档丢进去，然后调用某个嵌入模型把整篇文档转换成向量。结果做出来效果惨不忍睹：问什么答什么，答出来的东西前言不搭后语，甚至引用错误。这里面的核心问题，出在“整个文档向量化”这个思路上。

1.1 分块大小直接影响检索粒度和召回质量

检索的本质是“从一堆候选里找到最相关的片段”。如果只把一篇几万字的文档变成一个向量，它代表的语义粒度太粗了。你问“这个项目的预算审批流程是什么”，整篇文档向量返回的是一堆平均化的语义，既包含预算审批，也包含项目进度、人员安排、风险管理，所有信息被混合在一起，向量根本无法精准指向你想要的段落。相反，把文档切成小块，每块只承载一个相对集中的主题，查询向量就有机会在更细的粒度上命中正确答案。

但块越小就越好吗？也不是。切得太碎会带来另一个问题——语义断裂。比如一段话里“这个方案”指代的是前一段的某个名词，你把前后切成两块分别向量化，检索的时候模型只看到“这个方案”，却看不到它到底指代什么。没有上下文，再强的模型也只能靠猜。

我在实际项目里最常用的做法是：给不同业务场景设置不同的块大小，而不是全公司统一一套参数。技术文档和合同条款的切法就完全不一样，前者要尽量保住技术逻辑的完整性，后者则要按条款编号来切，保证每一个块都有明确的法律语义边界。

1.2 语义完整性与上下文窗口之间的博弈

这里面最核心的矛盾，是“上下文窗口”和“语义完整性”的互相拉扯。块越大，语义越完整，但进到模型上下文里的噪声也越多；块越小，检索结果越精准，但是上下文信息丢失越严重。你可以把每个向量块想象成一个“外卖盒子”：盒子太大，什么菜都往里装，味道混杂；盒子太小，一道菜装不下，吃的人还得自己拼凑。

实际工程里通常怎么平衡？两个维度：一个是业务数据的性质，一个是最终问答的粒度要求。如果业务场景是“客服问答”，问题通常聚焦在某个具体操作上，块可以切小一点，256到512个字符左右；如果场景是“报告解读”，用户往往会问一整段逻辑，块就得大一些，512到1024个字符都不算夸张。

这里有个非常实用的量化指标：块的平均长度应该和你的“平均问题长度”正相关。问题越短、越具体，块越小；问题越长、越宽泛，块越大。你可以在上线前手动整理一百条真实用户问题，统计平均长度，反向推算合适的块大小，这个动作比任何理论参数都有说服力。

1.3 分块处理的完整流程总览

先给大家一个宏观视角，后续章节再逐一拆解。整套分块加向量化的流水线大致可以分为四个阶段：读取与清洗、结构识别、切块、向量化入库。读取与清洗解决的是格式问题，PDF里的页眉页脚、表格里的多余空格，都得在这一步处理掉。结构识别负责判断文档是Markdown、HTML还是纯文本，不同结构对应不同的切分逻辑。切块阶段就是把清洗好的文本按策略切成片段，这一步最关键，也是本文要重点展开的部分。向量化入库则是把每个片段变成一条向量记录，连同元数据写进向量数据库。四步环环相扣，任何一步偷懒，后续都要付出成倍的调优代价。

2. 分块策略实操：从固定窗口到语义切分

分块策略的选择，基本决定了你检索系统的上限。我拆成三个层级来讲：最开始级的固定窗口切分，中间层级的递归结构切分，以及高级的语义切分。不同阶段的项目用不同层级的方案，完全没必要一上来就追求最复杂的。

2.1 固定窗口分块的参数计算思路

固定窗口分块是最朴素的方案：设置一个块大小（chunk_size），再设置一个相邻块之间的重叠长度（overlap），然后从头到尾按这个规则切下去。重叠部分的目的是避免语义断裂，比如一个关键句子刚好落在两个块的边界上，如果没有重叠，这句话就会被硬生生切断。重叠其实就是“给边界加一层保险”。

实际操作中，我通常会这样定初始参数：先按500个字符作为块大小，重叠80到100个字符，跑一轮评测，再根据结果调整。如果发现检索命中率低，就把块缩小，或者加大重叠；如果发现答案内容冗余、模型抓不住重点，就把块放大，减小重叠。有一个简单的换算逻辑你需要理解：重叠比例越高，向量库里产生的冗余块越多，检索时间变长，存储成本变大，但召回率通常会更好。这是一个需要根据数据量权衡的取舍。

以下是固定窗口分块的简化实现思路，核心逻辑一目了然：

def fixed_size_chunk(text, chunk_size=500, overlap=80): chunks = [] start = 0 while start < len(text): end = start + chunk_size chunk = text[start:end] if chunk.strip(): chunks.append(chunk) start += chunk_size - overlap return chunks

这段代码里最关键的是最后一行：每次前进的步长是 chunk_size 减去 overlap，所以相邻两个块之间会保留重叠片段。这个逻辑不能搞反，否则重叠就变成了“跳读”。实际处理时还要加一个条件：如果剩余文本长度不足 chunk_size 的一半，就直接并入前一个块，避免生成大量无意义的残片。

2.2 递归结构切分：尊重文档本身的层次

固定窗口最大的问题是无视文档结构。一篇标准的操作手册，通常有章、节、小节，每个小节讨论一个特定主题。固定窗口可能把一个章节的中间部分切开，导致前面的部分在第一个块里没有开头，后面的部分在第二个块里没有结尾。递归结构切分就是为了解决这个问题。

思路很简单：先按段落切，如果某个段落超过预设块大小，再按句子切，如果句子还是太长，再按标点或分隔符切。这个过程可以写成一套优先级清晰的递归逻辑。与之配套的一个关键操作是“标题注入”：在切块时把当前片段所属的章节标题和上级标题一并拼接进去，比如“第二章 安装部署 > 2.3 环境变量配置”。这个前缀信息进到向量里以后，检索命中率提升非常明显。

为什么这么做有效？因为标题本质上是对下文语义的高度概括，它相当于给向量块增加了一组“锚点”。用户提问时，查询向量既匹配正文细节，又匹配标题语义，双通道命中比单通道更可靠。我在一个操作手册类的项目里做过对比实验：注入两级标题前缀之后，Top5命中率提升了大概9个百分点，这个收益不需要任何模型调优，纯粹是预处理方式的改变。

2.3 语义分块：让模型告诉你哪里是边界

语义分块是当前效果最好的方案之一，核心思路是：不按字符数硬切，而是计算相邻句子之间的语义相似度，相似度发生显著下降的地方就是天然的切分边界。具体实现思路是：先用句子分割器把文档拆成句子列表，然后对每个句子依次做嵌入，计算相邻两个句子向量的余弦相似度，找出相似度曲线上的“谷底”，把谷底处作为分块位置。

我在实际项目里对这套方案做了一点改动，效果更稳：不直接比较原始相似度，而是计算“相似度的一阶差分”。差分大的地方，才是真正的语义转折点。之所以这么做，是因为原始相似度波动太频繁，直接用绝对值切会产生很多碎块。你可以设置一个阈值，当差分超过某个值才触发切分，这样可以在“敏感”和“稳定”之间取得折中。

不过语义分块也有它的代价：计算成本高、处理速度慢。一个几百页的文档，如果逐句嵌入，耗时可能是固定窗口方案的十几倍，但对离线入库的场景来说完全能接受。这也是为什么我建议初学RAG的朋友不要一上来就上语义分块：先把固定窗口和递归切分调好，确认检索效果已经达到七八十分，再考虑用语义分块做进一步提升。否则你连参数调优的参照基线都没有，出了问题很难定位是分块的问题还是后续检索的问题。

2.4 不同文档类型的分块策略参考

这是我多次项目迭代后总结的一张参考表，分享给大家当作初始模板：

表格里面有个容易忽略的点：FAQ数据的问题和答案一定要拼在一个块里。否则你按“问题”检索到内容之后，还得回去关联“答案”，这在一些实现不严谨的流程里很容易搞丢对应关系。拼在一个块里，检索和生成就能直接用，少一层关联逻辑就少一个出错点。

3. 向量化：把文本变成可比较的数学对象

分块做完，下一步就是把每一块文本变成向量。这也是很多初学者容易犯迷糊的地方：向量到底是什么，它是怎么生成的，不同的嵌入模型有什么区别，向量维度又意味着什么。这一章我就把这几个问题一次讲透。

3.1 嵌入模型的选择逻辑

嵌入模型的作用是把一段文本映射成一个固定长度的数值数组。这个数组在数学上叫向量，它承载的是这段文本的语义信息。好的嵌入模型，会把语义相近的文本映射到向量空间中相近的位置，语义无关的文本则距离较远。

选择嵌入模型时，我建议直接关注四个指标，其他花里胡哨的宣传都可以忽略。

第一个是语义表征能力，也就是在公开评测集上的表现。文本相似度任务里的准确率、检索任务里的召回率都是直接参考值。第二个是向量维度，维度越高，理论上表征能力越强，但存储和计算开销也越大。既要看精度表现，也要评估线上资源能不能扛住这个维度的数据量。第三个是输入长度限制，有些模型限制512个token，有些支持更长，如果你的块比较大，选模型时就要留意这一项。第四个是语言适配性，中文场景要重点看模型在中文语料上的表现，很多通用模型英文很好，中文却不那么理想。现在有一些开源中文嵌入模型确实做到了不错的水平，实际落地之前你最好用自己业务领域的数据集小范围测试，不要只依赖公开评测分数。

再看看维度的影响。一个768维的向量在存储上的开销大约是4字节乘以768，也就是3KB上下；如果数据量到了百万级，光向量存储就要几个GB。更高维度的模型可能带来小幅精度提升，但成本上升非常明显。生产环境里，我的习惯是优先选择能满足业务精度要求的最低维度模型，除非特别需要，否则不用维度换精度。

3.2 余弦相似度、点积与距离度量怎么选

向量化之后，检索的核心动作就变成计算相似度。最常见的度量方式是余弦相似度，它衡量的是两个向量在方向上的接近程度，对向量的长度不敏感，所以在文本检索里最常用。还有一种方式是点积，它同时包含方向信息和长度信息。如果嵌入模型输出的向量已经做了归一化，点积和余弦相似度在数学上是等价的；但如果没做归一化，点积的结果就会偏向长度更长的向量，这在检索里可能带来偏差。

可以有效和可靠的实现方式是：在向量入库时统一做归一化处理，检索阶段直接用点积计算。这样既能享受点积的高效计算，又规避了向量长度带来的干扰。这里要特别说明的是，不同的向量数据库默认的相似度算法可能不同，有的是余弦，有的是点积，有的是欧式距离。你在建表或创建Collection时就要明确规定好度量方式，而不是等数据入库之后再去切换算法。一个索引的度量方式一旦固定，想要换算法，往往意味着全量重建，代价很高。

3.3 索引构建与混合检索

向量化之后你得到的是一堆浮点数数组，要从几十万甚至上百万个向量里快速找到最相似的TopK，如果暴力遍历，耗时长到无法接受。所以工程上都要建索引。目前最常用的近似最近邻索引是HNSW（分层可导航小世界图）。这个算法的核心思路是分层的“跳跃表”结构：高层稀疏连接用于快速定位，低层稠密连接用于精确搜索。理解HNSW不需要深入数学细节，只需要记住几个关键参数：M控制每个节点的最大连接数，数值越大，图越稠密，召回越准，但内存占用也越大；efConstruction控制建图时的搜索范围，影响建图质量；efSearch控制查询时的搜索宽度，影响查询精度和速度。

这些参数在项目初期可以直接用默认值，等到检索效果稳定后，再根据线上延迟和召回要求去调整。我的建议是永远不要在一开始就执着于索引参数调优，先把“召回结果对不对”这件事搞清楚，再考虑“召回速度快不快”。

再来说混合检索。只用向量检索会漏掉一种情况：用户问题里的某个专有名词或者编号，与文档里的写法不完全一样，但它包含同一组字符，向量检索可能因为语义差异而漏掉。这时传统的关键词检索反而能保证精确匹配。混合检索的做法是：把向量检索和关键词检索的结果都拿回来，再用RAG融合算法把两路结果合并排序。这个融合算法本身并不复杂，核心逻辑就是同时出现在两路结果里的文档权重更高，只出现在一路里的按排名给一定比例的分数。很多团队上线RAG以后第一版只做向量检索，效果不理想，加上关键词召回后就明显改善，原因就在于混合检索兼顾了语义理解与精确匹配。

4. 常见坑与排查实录：那些真正影响效果的隐藏问题

这一章分享的内容都来自真实的项目经历，基本是常规文档不会告诉你的部分。每一项都值得在你自己项目里对照检查一遍。

4.1 块太小导致答案碎片化

有一个客服知识库项目，最初把FAQ数据切成一百多字符的小块，Top5检索看起来命中率很高，但最终答案却总是不完整。排查之后发现问题出在“答案的上下文被切断了”：一个完整的解决方案被拆成三段，检索只拿到其中一段，模型没有足够的上下文拼出完整步骤，答出来的东西自然残缺。解决方式就是我前面说的，把问题和完整答案拼接为一个块，块大小放到300到500字符，完整性立刻好了很多。

这个案例想说明一个原则：检索命中率高并不等于问答效果好。块太小的时候，每一块都“像”正确答案，但没有一块能真正回答完整问题。你调优时不能只看检索指标，要综合看最终生成答案的完整性和可读性。

4.2 块太大导致检索噪声

和碎片化相反的问题也很常见。某个文档解读项目，我把块大小设到了1500字符，想着“反正模型上下文够大，喂多点信息总没错”。结果实际问答中，模型经常答非所问——不是因为它理解能力不行，而是因为块里的无关信息太多，干扰了注意力。尤其是一些技术方案文档，一个块里既有背景介绍、又有实施方案，还有预算表格，用户问预算，检索回来的块把背景和实施也塞给了模型，它自然容易被干扰。

后来我把这个文档的块大小下调到700字符，并且在切块阶段把“预算”“背景”“实施方案”这些主题尽量拆开，问答准确率提升非常明显。调参这件事，方向对了比幅度大了更重要。

4.3 相似度阈值设置的两个极端

很多RAG系统会设置一个相似度阈值，低于阈值的检索结果直接丢掉。太低会让无关内容混进来，太高又会把正确答案全过滤掉。这个临界值在不同业务里的表现差异很大，不能拍脑袋定一个固定值。

要避免这个问题，最稳妥的办法是先看线上检索结果的相似度分布，再做统计。具体做法是：抽一批用户真实问题，把Top20检索结果的相似度全部输出，观察“正确答案”和“错误答案”各自落在哪个区间。如果两个区间的分布有明显隔离，阈值就设在中间；如果重叠很大，说明问题不在阈值，而在向量本身的质量，这时候调阈值也没有用，得回到分块策略和嵌入模型的选择上找原因。

4.4 向量归一化与维度不一致

这个坑比较隐蔽，排查难度也大。有次我在跨环境迁移时发现，同一批文档在两个环境里检索结果差异很大，后来才找到原因：一个环境里的向量做了归一化，另一个环境没有，而我用的相似度度量方式对归一化敏感。类似的坑还有：上游换了嵌入模型，向量维度从768变成了1024，旧库里的数据还是768，线上检索时维度不一致直接报错，或者静默返回空结果。做向量数据迁移时，建议先写一个校验脚本，抽检向量维度、归一化状态、范数值，确认新旧数据一致再切换线上流量。

4.5 元数据过滤与时间衰减被忽略

RAG系统的检索范围不能永远是整个知识库。比如新闻资讯类项目，用户问“最近一周有什么政策变化”，如果向量库里一年前的政策文档和最近的混在一起，语义相近的旧文档可能排在新文档前面。解决办法是时间过滤：给每个块打上发布时间标签，在检索时叠加时间范围条件。同理，文档来源、部门、产品线这些业务维度也都可以作为过滤条件。这样的好处不仅是提升相关性，还能大幅度降低无效候选的数量，检索延迟也会跟着降下来。

5. 一版可参考的落地配方与评估闭环

分块和向量化这两个环节没有放之四海而皆准的最优参数，但有相对靠谱的落地流程。最后这一章我梳理一份可参考的初始配方和一套评估方法，照着走一遍，至少能保证你系统上线后不是靠运气工作。

5.1 初始参数模板

拿一套通用知识库项目举例，数据是几百篇技术文档和操作手册，问答场景偏内部员工自助查询。我的初始配置建议是这样：分块优先级从上到下按章节标题 > 段落 > 句子执行，块大小设为512个token左右，重叠设48个token，大约10%重叠率；标题前缀注入两级标题；每个块补充元数据，包括文档ID、来源、更新时间、章节路径；嵌入模型选择中文效果较好的开源嵌入模型，向量维度768，归一化后入库；索引用HNSW，M值设为16，efConstruction设为200，efSearch设为100；检索方式采用向量检索和关键词检索混合，TopK设置在20到50之间，后续加RAG重排或直接交给模型生成。

这只是起点，不是终点。上线后要以数据反馈来迭代，而不是凭感觉调整参数。

5.2 先建评估集，再谈调优

没有评估集的调优都是玄学。上线前我强烈建议先构建一个至少一百条左右的评测集，每条包含“用户问题”“标准答案”“覆盖到的文档片段ID”。不追求完美，但覆盖面要够，尽量把真实业务里可能出现的问题类型都放进去。然后定义两个核心指标来度量：一个是命中率，即标准答案是否出现在检索返回的TopK结果中；另一个是回答正确率，即最终生成答案与标准答案的一致性程度。命中率衡量检索环节，回答正确率衡量端到端效果，两个指标结合才能定位问题出在哪个环节。

调优流程可以这样走：先固定分块和嵌入配置，跑一遍评测集，记录命中率和正确率的基线；然后单次只调整一个变量，比如分块大小、重叠长度、TopK数量、是否开混合检索，记录每次变化的指标差异；等找到最优组合后，再统一调整索引参数和提示词。这样做的好处是，每个变量对最终效果的影响都能量化，后续给团队解释调参理由时也有数据支撑。

5.3 从离线到在线的持续迭代

一套RAG系统不是上线就结束的。文档会更新，用户问法会变化，嵌入模型也会升级。建议每季度或每半年重新跑一次评测集，重点检查两个点：一是文档更新后，需要更新的向量是否已经增量同步；二是评测集里的旧问题是否仍然命中，如果命中率明显下降，说明文档结构或用户问题分布发生了变化，需要重新调整分块策略。

增量更新这里有个细节值得强调：源文档一旦修改，最好把整篇文档涉及的块全部删除重建，而不是只更新变化的文本片段。否则上下文碎片残留，检索结果里会出现新旧混杂的内容，反而把答案搞乱。

我个人在实际项目里最深的一点体会是：分块和向量化做得好的系统，后面调提示词几乎不费劲；这两步敷衍了事，后面所有环节都在替它补窟窿。所以花时间把这一阶段调透，是投入产出比最高的选择。如果你正准备做一个RAG项目，先别急着去追新模型，把文档预处理这条链路稳扎稳打跑通，你会发现在检索质量上来之后，很多曾经困扰你的生成问题，都自然而然地消失了。