做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_size500, overlap80): 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 不同文档类型的分块策略参考这是我多次项目迭代后总结的一张参考表分享给大家当作初始模板文档类型推荐策略块大小建议特殊处理技术文档 / 操作手册结构化切分按标题层级递归500-800字符注入标题前缀保留代码块独立合同 / 法律条款按条款编号切分300-500字符保留条款编号和所属章节会议纪要 / 对话记录按发言人段落切分400-600字符保留发言人标识按时间线排序研究报告 / 行业分析语义分块600-1000字符保留图表标题和引用来源客服FAQ数据一问一答独立切块100-300字符把问题和答案拼接为一个块表格里面有个容易忽略的点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归一化后入库索引用HNSWM值设为16efConstruction设为200efSearch设为100检索方式采用向量检索和关键词检索混合TopK设置在20到50之间后续加RAG重排或直接交给模型生成。这只是起点不是终点。上线后要以数据反馈来迭代而不是凭感觉调整参数。5.2 先建评估集再谈调优没有评估集的调优都是玄学。上线前我强烈建议先构建一个至少一百条左右的评测集每条包含“用户问题”“标准答案”“覆盖到的文档片段ID”。不追求完美但覆盖面要够尽量把真实业务里可能出现的问题类型都放进去。然后定义两个核心指标来度量一个是命中率即标准答案是否出现在检索返回的TopK结果中另一个是回答正确率即最终生成答案与标准答案的一致性程度。命中率衡量检索环节回答正确率衡量端到端效果两个指标结合才能定位问题出在哪个环节。调优流程可以这样走先固定分块和嵌入配置跑一遍评测集记录命中率和正确率的基线然后单次只调整一个变量比如分块大小、重叠长度、TopK数量、是否开混合检索记录每次变化的指标差异等找到最优组合后再统一调整索引参数和提示词。这样做的好处是每个变量对最终效果的影响都能量化后续给团队解释调参理由时也有数据支撑。5.3 从离线到在线的持续迭代一套RAG系统不是上线就结束的。文档会更新用户问法会变化嵌入模型也会升级。建议每季度或每半年重新跑一次评测集重点检查两个点一是文档更新后需要更新的向量是否已经增量同步二是评测集里的旧问题是否仍然命中如果命中率明显下降说明文档结构或用户问题分布发生了变化需要重新调整分块策略。增量更新这里有个细节值得强调源文档一旦修改最好把整篇文档涉及的块全部删除重建而不是只更新变化的文本片段。否则上下文碎片残留检索结果里会出现新旧混杂的内容反而把答案搞乱。我个人在实际项目里最深的一点体会是分块和向量化做得好的系统后面调提示词几乎不费劲这两步敷衍了事后面所有环节都在替它补窟窿。所以花时间把这一阶段调透是投入产出比最高的选择。如果你正准备做一个RAG项目先别急着去追新模型把文档预处理这条链路稳扎稳打跑通你会发现在检索质量上来之后很多曾经困扰你的生成问题都自然而然地消失了。