RAG系统搭建实战：从文档切分到混合检索的完整调优指南

RAG 这个词，做过大模型应用的人肯定都不陌生。我第一次系统接触它，是在做一个企业知识库问答项目的时候。那会儿大模型刚火起来，团队的第一反应是"把文档直接扔给模型让它回答"，结果不用多说：幻觉严重、答非所问、编造数据。后来才慢慢意识到，RAG 就是为了同时解决"模型不知道的东西"和"模型胡说八道"这两个问题而存在的。

简单说，RAG 就是给大模型配一个外挂知识库。回答之前先从资料库里检索相关内容，把检索结果塞进上下文，再让模型基于这些资料作答。它解决的是三个实际问题：其一是知识时效性，模型训练完参数就定格了，RAG 能让它读到最新内容；其二是领域知识，企业内部文档、专业规范模型根本没学过，RAG 可以现学现用；其三是可解释性，回答能溯源到具体文档，这个特性在企业场景里几乎是一票否决的硬需求。

这篇文章是我自己从零搭建 RAG 系统、反复调优大半年的完整记录。我会把学习路径、踩过的坑、最后沉淀下来的调优方法论全部整理出来。适合正在做知识库问答、智能客服、内部搜索增强的开发者参考，也适合刚入门、被网上零散资料搞得一头雾水的朋友从头看一遍。

1. RAG 完整链路：先画地图再动手

1.1 从"提示词硬刚"到"外挂知识库"的转变

最早我试过把资料直接塞进提示词里。短文档还行，稍微长一点就爆上下文。一份 100 页的规范文档根本塞不下，就算硬塞进去，模型也会被大量无关内容干扰，抓住中间几段就开始自由发挥。我后来做过一个很简单的实验：同一个问题，往提示词里掺入越多不相关文档，回答质量下降得就越明显。这个实验让我明白一个道理：不是资料越多越好，而是"最相关的资料恰好出现"才重要。

RAG 的思路就是用检索代替暴力拼接，把"喂给模型的内容"从"全部资料"变成"最相关的几段"。这个转变在工程上要付出的代价不小，但效果上是一次质的提升。我把整个链路拆成五个环节：文档加载与解析、文本切分、向量化、检索召回、重排与生成。每个环节都有独立的调优空间，这也是 RAG 好上手但难精通的根本原因——你永远不知道当前的问题到底出在哪一环。

1.2 一次典型 RAG 请求的完整流转

拿知识库问答举例，一次用户提问会走这么一条流水线：

1. 用户输入问题，系统先做清洗和改写，把口语化的提问转成适合检索的表述。
2. 把改写后的问题向量化，得到查询向量。
3. 在向量库中做相似度检索，取出 TopK 个候选片段。
4. 同时跑一路关键词检索，把字面精确匹配的结果也取出来。
5. 两路结果合并、去重，交给重排模型精排，挑出最相关的 3-5 段。
6. 把挑出来的内容拼进提示词的"参考资料"区，连同用户问题一起发给大模型。
7. 模型基于资料生成答案，系统把答案连同引用来源一起返回给用户。

这条链路里，任何一个环节出问题都会直接影响最终答案的质量。我发现很多人调 RAG 只盯着"换个更好的 embedding 模型"或者"把 chunk 调大一点"，忽略上下游环节，结果怎么调都不见起色。这也是我写这篇文章的初衷：把整条链路讲透，而不是堆一堆单点技巧。

2. 文档处理与切分：效果好坏的隐形分水岭

2.1 文档加载远比想象中复杂

PDF、Word、PPT、扫描件、网页，每种格式都有自己的坑。我踩过最大的坑是 PDF 里的表格：按行解析出来，表格内容全部被打散，检索时根本对不上。后来换了带结构感知的解析方案，把表格转成 Markdown 格式再入库，这个问题才算解决。另一个坑是扫描版 PDF，压根没有文本层，必须先跑一遍 OCR 才能继续处理。

解析完成后一定要做"可见性检查"，把切出来的片段打印出来人工抽查。我自己会随机抽 10%-20% 的文档看解析结果，重点检查标题层级是否保留、表格结构是否完整、页眉页脚有没有混进来。页眉页脚是最恶心的，每一页都会带，如果不清理，检索出来的 TopK 可能全是"某某公司内部资料"这种重复内容，真正有效的信息反而排到了后面。

提示：解析效果的好坏，直接决定了后面所有环节的上限。这一步偷懒，后面调再多参数都是白费。

2.2 chunk size、overlap 与分隔符的选择逻辑

切分这块网上说法很多，但本质上就一句话：尽量让每个片段保持"语义完整、边界干净"。我分别试过固定字符切分、按段落切分、按标题层级切分三种方式，对比下来的结论是：

• 固定字符切分（比如 500 字符一块、重叠 50 字符）最省事，但经常从句子中间切开，召回效果随机性很大。
• 按段落切分比固定字符好一些，前提是源文档的段落本身写得规整，结构化差的文档段落长短参差，效果会打折扣。
• 按标题层级切分效果最好，前提是文档有清晰的大纲结构。企业内部手册、规范类文档通常都适合这种方式，切出来的每个片段天然对应一个小主题。

chunk size 不是越大越好。大片段信息全，但召回时容易误伤——明明只有一小段相关，却把整个片段带回来，答案里混入大量无关信息。小片段精准，但容易把上下文切断，答案经常是半截话。我的经验值是中文场景下以 400-800 字为一片、overlap 设置 50-100 字作为起点，比较稳妥。之后再根据检索命中情况微调：如果答案总是"半截话"，就加大 overlap；如果检索回来的片段经常不相关，就缩小 chunk size。

2.3 元数据与清洗：容易被忽略的工程细节

文档切完要打元数据，这一步很多人会漏。我的做法是给每个片段记上：文档编号、标题、章节路径、页码、创建时间、文档类型、所属部门。别小看这些字段，后面的过滤、溯源、排查问题全都要用到。比如用户问"上季度的数据"，如果元数据里有时间字段，就可以在检索前先过滤掉过期内容；再比如答案末尾要附引用出处，没有元数据就只能瞎编。

数据清洗方面，除了页眉页脚，还要注意特殊符号、超链接、乱码字符、重复的空白行。我遇到过一个很隐蔽的问题：某些 PDF 解析出来会在每个字符间插入空格，导致整个文档的向量化效果全面崩坏。这类问题光靠肉眼抽查很难发现，后来我写了个脚本统计字符密度才揪出来。

3. 向量化与检索：召回质量的核心战场

3.1 embedding 选型：开源还是商用，维度怎么选

embedding 模型的作用是把文本变成向量，让语义相近的句子在向量空间里的距离更近。选型的核心指标是：领域适配度、语言支持、向量维度、延迟和成本。

我自己的对比经验是：开源的双语 embedding 模型在中文场景下效果相当好，而且可以本地部署，不用担心里面数据外泄；商用 API 的 embedding 接口胜在省事，但涉及企业内部敏感数据时会有合规顾虑。大部分企业知识库场景，我建议优先考虑开源模型本地部署，哪怕初期效果差几个百分点，长期来看可控性要高得多。

很多人有个误区：以为向量维度越高越好。其实维度越高，向量库占用空间越大、检索延迟越高，而且效果提升到一定阶段就饱和了。我的建议是：如果知识库规模在百万级文档以下，开源模型默认维度完全够用，不必刻意追求高维度。真正影响召回效果的，往往是文档处理质量、切分策略和检索方式，而不是 embedding 模型中那几个百分点差异。

3.2 相似度计算与 TopK 选择

向量检索底层是相似度计算，常见的距离度量有内积、余弦相似度、欧式距离。文本场景我用得最多的是余弦相似度，它关心方向、不关心长度，对文本表示比较友好。需要注意的一点是，不同的向量库对"相似度分数"的定义不一样，有的返回余弦相似度，有的返回距离，调阈值时先搞清楚你用的库到底返回的是什么。

TopK 的选择很讲究。我一般从 20 开始，检索阶段先取 20-50 个候选，后面还有重排环节再压缩到 3-5 个。很多人直接把 TopK 设成 3，直接让模型用这 3 段生成答案。这样做的问题是：万一这 3 段里没有真正相关的内容，模型就只能硬编。先取足够多的候选，再用重排精挑，命中率会明显高一个档次。

3.3 混合检索：稠密检索加稀疏检索的组合拳

稠密检索（vector 语义检索）对"意思相近但字面不同"的表达很友好，但有一个致命弱点：对专有名词、编号、精确术语不敏感。比如用户搜索"RAG-1024 型设备"，语义检索可能把它理解成"检索增强设备"，结果跑得完全没边。这时候 BM25 这类关键词检索反而更准。

所以我现在做知识库基本都是混合检索：向量检索走一路，关键词检索走一路，两路结果合并后交给重排。实测下来，混合检索的召回率比单路至少能提高 10-20 个百分点，尤其是涉及型号、编号、代码、公式这类内容的场景，优势极其明显。代价是系统复杂度增加，以及关键词检索的结果噪声会大一些，需要靠重排把所有候选重新排序，把噪声压下去。

4. 重排与生成：从"检索到"到"答得好"

4.1 重排模型是投入产出比最高的优化点

重排是 RAG 链路里性价比最高的一环。它的原理是用交叉编码器把"问题-候选片段"逐对打分，比单纯看向量相似度精细得多。很多人以为向量检索完直接生成就行，实际上检索出来的片段顺序是向量相似度排序，这个顺序并不等于"最符合当前问题"的顺序。加了重排之后，输出质量通常有明显的、可以直观感知的提升。

选重排模型时注意两点：一是和 embedding 模型的语言、领域保持一致，跨语言的模型搭配会互相拖累；二是关注延迟，重排对候选逐对打分，候选一多耗时明显上升。我常用的模式是"粗排 50，重排 10"，即向量检索取 50 个候选，重排时只精排其中 10 个，质量和速度都能兼顾。

4.2 上下文组装：不是把 TopK 全塞进去

重排完了，怎么把内容喂给大模型同样有讲究。我踩过的问题是：把重排后的 10 个片段全部塞进提示词，结果模型被不相关内容干扰，重点反而抓不住。后来我把规则改成：重排后取前 3-5 个片段，每个片段控制在 500 字以内，并且给每个片段编号。提示词里明确要求模型"只能基于参考资料回答，引用时必须标注编号"。这样回答的可追溯性一下子就建立起来了。

还有一个很实用的小技巧：把"参考资料不足"作为一种合法输出显式写进提示词。很多模型在被逼着回答时会强行编造，如果给它一个"承认不知道"的出口，反而能显著降低幻觉概率。我的提示词里固定有一句：如果参考资料不足以回答用户的问题，请直接说明无法回答，不要推测。实测下来，答非所问的情况少了很多。

4.3 查询改写：用户的问题不一定适合直接检索

用户提问经常是口语化的："那个设备怎么老出问题""上次说的那个方案到底行不行"。这种问题直接拿去检索，效果通常很差。我在接入层加了一个查询改写模块：先让大模型把用户问题改写成几个适合检索的独立问句或关键词组合，再分别检索、合并结果。

这一步成本很低，但效果非常显著。尤其是多轮对话场景，用户说"它呢""那个呢"这种指代词，不结合前面几轮上下文根本没法检索。改写的时候把历史上下文里的关键实体补全到当前问题里，检索命中率会有质的提升。有的人会觉得多一次大模型调用增加了延迟，但实测下来几百毫秒的额外延迟，换取的是回答质量的大幅改善，非常划算。

5. 调优方法论：从"凭感觉"到"靠数据"

5.1 建评估集是调优的第一步

调优最怕的就是没有标准。我一开始也是凭感觉：试几个参数，人工看几条回答，觉得"好像变好了"就继续。后来发现直觉常常靠不住——改一个参数好了两条测试用例，同时把另外十条搞坏了。

我的做法是先从真实用户日志里随机抽 200 条问题，人工标注好每条问题对应的标准答案和参考文档段落，做成固定评测集。以后每次改动方案，都在同一份评测集上完整跑一遍，记录下检索命中率和答案质量评分。有了这条基准线，所有改动都能做成量化对比，而不是靠嘴说"感觉好了一点"。

5.2 检索质量评估：Recall@K 与 MRR

评估检索环节，两个指标最直观：Recall@K 是前 K 个结果里有没有包含正确答案，MRR 是正确答案在排序里的位置有多靠前。我一般看 Recall@10 和 MRR@10，只要调 chunk size、embedding、检索策略，就看这两个指标的变化。理想状态是 Recall@10 稳定在 90% 以上；达不到就优先调检索侧，而不是去改生成侧的提示词。

表格整理一下我常用的指标口径：

5.3 生成质量评估：忠实度与完整性分开打

生成环节我用的评估维度有三个：忠实度、完整度、可读性。忠实度看的是答案是否完全基于参考资料、有没有幻觉；完整度看的是标准答案涉及的知识点是否都被覆盖；可读性看的是表达是否自然流畅。三个维度分开打分，不要揉成一个模糊的"行还是不行"。

诊断逻辑是这样的：忠实度低，问题大概率出在检索侧或提示词约束不够，检索回来的内容里混了不相关信息，或者模型没有被约束得足够死；完整度低，往往是上下文容量不够，或者检索漏了关键的多个片段。按照这个思路去定位问题，比盲目试参数高效得多。

6. 踩坑实录：常见问题与排查技巧

6.1 检索结果与问题对不上

最典型的表现是：答案内容看着合理，但去核对来源文档，里面根本没有相关信息。我的排查顺序固定是：

1. 把用户问题单独拎出来，直接看检索召回列表，确认前 10 个片段里到底有没有包含答案的片段。
2. 如果召回列表里没有，问题在检索侧：检查 embedding 是否适配领域、文档切分是否把关键内容切碎了、关键词检索是否漏了术语。
3. 如果召回列表里有，但最终答案没用上，问题在生成侧：检查上下文组装环节是否截断了内容、提示词约束是否够强。

6.2 答案总是"半截话"

这个问题通常出在 chunk 切太小或者 overlap 不够。比如一份设备说明书，操作步骤前半段在第一片、后半段在第二片，检索只命中了第一片，答案自然只有半截。我一般先把 overlap 从 50 字提到 100 字试一下，如果还是不行，就去检查切分策略是不是把同一段落从中间截断了，改成按段落切分通常能缓解。

6.3 检索延迟超标

知识库规模变大之后，检索延迟会明显上升。我的排查顺序是：先看向量库用的索引类型能否支撑十万级以上的数据量；再看检索接口有没有按元数据做预过滤，如果没有，每次检索都在全量扫描，速度自然慢；最后看重排候选数是不是太大，50 个候选逐对打分耗时比 10 个高出好几倍。一个很实用的优化是：根据元数据先做粗过滤，比如限定部门、限定时间范围，把检索范围缩到原来的十分之一，速度能提升一个量级。

6.4 引用来源与答案对不上

RAG 的价值就在于可追溯，但很多项目跑起来之后，发现系统给的引用和答案内容对不上。我排查之后发现根因通常是：参考片段在组装提示词时被截断了，或者重排后片段顺序变了，模型引用的编号对错了位置。解决办法是：组装上下文时给每个片段一个稳定编号，要求模型引用时必须带上编号，展示层再把编号映射回真实文档链接。这套流程走通之后，引用不可信的问题基本不会再出现。

6.5 增量更新后效果反而变差

我在实践里还踩过一个坑：增量更新知识库时，没有清理旧版本文档。结果同一个内容的多个版本会同时被检索出来，模型纠结"到底以哪个版本为准"，回答反而变得混乱。后来我加了一条"版本优先"规则：同一文档存在多个版本时，只把最新版本放入检索范围，除非用户明确要求查历史版本。这在知识频繁更新的企业场景里几乎是必踩的坑，建议一开始就设计好。

7. 我的学习路线与几条重要建议

7.1 如果重走一遍，我会这样安排

复盘整个学习过程，如果让我重新走一遍，路径大概是：

1. 先跑通一条端到端的最小 demo：文档切分、向量化、检索、生成全部串起来，感受整个链路是怎么流转的。
2. 立刻把评测集建起来，量化当前基线的 Recall 和忠实度。
3. 按顺序调优：先调召回侧（chunk 策略、embedding、混合检索），再加重排，最后调生成侧提示词。
4. 工程化落地时，优先解决引用溯源、权限过滤、增量更新三个问题，而不是急着优化延迟。

这条路径看起来简单，但每一步都有足够深的细节，够新手扎实钻研好几个月了。我后来带团队新人也是按这个顺序安排的，收敛速度明显比一上来就调模型参数快。

7.2 与其追技巧，不如吃透地基

我自己的体会是：与其追各种"RAG 调优技巧"的碎片文章，不如先把三块基础知识吃透——大模型的上下文机制、文本向量化的原理、信息检索的经典方法。这三块地基打好了，RAG 里的绝大多数技巧你都能自己想通。技巧天天在变，但原理不会变。

最近业内也在讨论长上下文和 RAG 的取舍问题。我的观点是：长上下文方案在简单场景下确实方便，但到了企业级应用，权限控制、版本管理、引用溯源、成本控制这些硬需求，仍然要靠 RAG 这类外挂知识库架构来承载。两者不是替代关系，而是各管一段，按场景选型就好。

最后分享两个实践体会

说点个人经验。RAG 这东西，看起来门槛不高，跑通一个 demo 可能几个小时就够了，但要真正调到"能用、好用、值得信"，它是一个系统工程。我在里面投入的时间，一大半不是花在模型上，而是花在数据处理和评测上。这也是我最想告诉后来者的一句话：别在模型参数上折腾太久，先把文档处理干净，把评测集建起来，你的调优效率会翻倍。

再分享一个小技巧：每次调完一组参数，我会把改动内容和当时的评估指标记录在文档里，哪怕只是"chunk size 从 500 改成 600，Recall@10 从 88% 涨到 91%"这样一行，坚持记几个月，你会积累出一本完全属于自己的调优手册。这份手册比网上任何现成教程都值钱，因为它记录的是你真实场景里的数据变化，是你以后判断任何新方案时最可靠的参照。