先交代个背景：我做 RAG 相关项目四五年了，从最早的“拿向量库拼个 demo”到后来给多个业务线做生产级知识问答。前 12 章更多在讲“怎么把 RAG 跑起来”，而真正的麻烦从来不在搭骨架，而在调优——你明明把文档灌进去了、接口也通了，可一问就露馅：要么答非所问，要么拿着答案胡说，要么检索结果跟上下文完全对不上。第 13 章就把这件事摊开聊：RAG 系统调优到底在调什么、按什么顺序调、用什么工具调、怎么用数据证明它真的变好了。适合正在做知识库问答、客服助手、智能文档检索的研发同学，也适合那种“demo 能跑但不敢上线”的团队。
这一章的思路很直白：把一条 RAG 链路拆成数据、检索、生成、评测四段，每一段分别讲可落地的调优手段。顺手还会把几个被问烂的词拉出来划清边界——RAG 和 MCP 到底什么关系、Agentic RAG 和普通 RAG 有什么区别、Ontology RAG 该不该碰。内容以 langchain / langchain4j / semantic kernel 这类常见框架为背景，但核心方法论不绑定任何框架，你听完直接拿到自己项目里套。
1. 调优之前先想清楚：RAG 系统到底在调什么
1.1 摆正调优视角：别一上来就换模型
很多人调 RAG 的第一反应是“再换个更强的 LLM”。这句话不能说错，但大多数线上问题根本轮不到模型背锅。一条 RAG 链路至少有七个环节：数据清洗、切块、Embedding、向量存储、检索召回、重排序、提示词组织，最后才是生成。任何一个环节糊了，下游都会跟着崩。
打个比方，这像你去图书馆找资料写论文，不是“写”这个动作出毛病，而是“查”这一步出的毛病：图书馆里压根没有那本书（数据缺失）、书被乱放在错误的楼层（切块与索引不对）、你只看了书目没翻正文（检索策略太弱）、抄了一段没抄出处（生成时没有引用上下文）。这些问题在链路上叫“数据侧问题”“检索侧问题”，唯独不是“模型侧问题”。
所以调优第一步不是动手，而是给问题归因。我的经验是：先把链路里每一个环节的“可观测点”列出来。比如：
- 数据入库后，抽样看 20 个 chunk，肉眼扫一遍内容是否完整、有没有乱码、表格是否被截断。
- 检索出来的 top5 结果，人工判断相关还是不相关。
- 把检索结果原样拼进提示词，但让模型“不回答、只判断这些上下文是否够用”。
- 最后才看生成质量。
这套归因做完，一半的问题已经暴露了。剩下那些确实是模型导致的问题，再讨论换模型也不迟。
1.2 瓶颈先测量，再动手
别凭感觉调参。RAG 调优没有评测集，就等于盲人摸象。我建议任何项目开工第一件事，就是先做一份 50~100 条的高质量问答对，覆盖业务里最常见的问题类型。不需要太复杂，但必须记录：标准答案、出自哪份文档、问题属于哪一类（事实型、比较型、流程型、多跳型）。
有了这套基线，先原样跑一遍，统计出三个最基础的指标：
- 检索命中率：正确答案对应的文档片段有没有出现在 top5 / top10 里。
- 忠实度：回答里有多少内容是有上下文依据的，有多少是模型自己脑补的。
- 答案相关度：最终回答是不是用户想问的那个东西。
这三个指标不是学术概念，是线上事故的预报器。我在实际项目里见过很多团队，折腾一周调整了各种参数，最后回头一看，评测集的命中率反而降了 5 个百分点。没有基线，你的“优化”就是随机游走。
1.3 RAG、Agentic RAG、MCP 先划清边界
搜索热词里高频出现的“rag和mcp区别”，其实是问错了对象，这俩根本不是同一层级的东西。RAG（检索增强生成）是一种“把外部知识喂给大模型”的模式，解决的是模型不知道、记不住、易胡诌的问题。MCP（Model Context Protocol）是一种标准化接口协议，解决的是“模型怎么调用外部工具/服务”的问题——比如查天气、查数据库、操作业务系统。RAG 甚至可以做成 MCP 里提供的一个服务端能力。
Agentic RAG 则在两者之上加了一层“自主决策”：模型不再只是“固定先检索再生成”，而是自己决定要不要检索、检索几次、查不到要不要换一种查法、要不要把多轮查询拆开。Ontology RAG 更进一步，把知识组织成带关系图谱的形式，适合回答“A 和 B 有什么关系”这种单靠向量相似度很难命中问题。
这里我要给一个非常实际的观点：别为了追热点把架构搞复杂。80% 的知识问答场景，普通 RAG + 一层查询改写就可以打得很稳；只有当业务确实需要多步推理、需要访问多个业务系统、需要应对复杂查询意图时，才考虑引入 Agentic 循环和 MCP 组合。
2. 数据侧调优：切块、清洗与表格入库
2.1 文档清洗：垃圾进不了知识库，也出不了好答案
RAG 调优最容易见效、也最容易被忽略的一个环节，就是数据清洗。很多人从内网拖下来一堆 PDF、Word、Excel，直接切块灌进向量库，然后抱怨检索结果差。我抽样看过不少这类数据，问题触目惊心：PDF 里带页眉页脚，被切进 chunk 后变成“第 3 页”“XXX 公司密件”；表格被解析成乱序文字；列表项被拦腰截断。
基础的清洗至少要做这几步：
- 统一文本格式，去掉 PDF 残留的换行符、多余空格、OCR 噪声。
- 识别页眉页脚、目录、水印，能去就去，去不掉就标记成 metadata，检索时不参与内容匹配。
- 对扫描件先过 OCR，但 OCR 结果务必人工抽检，识别错一个字可能让整个 chunk 失真。
- 对 Excel / CSV 类文件，不要直接按行切割，先转成结构文本再看。
这里分享一个我自己的习惯：清洗之后，把前 100 个 chunk 打印出来从头读一遍。这不光是验证解析效果，更是建立“这个 chunk 看起来像不像一段能回答问题的话”的直觉。
2.2 切块策略：从“越短越准”到“语义切分”
切块可能是调参最敏感的一环。固定窗口切分最简单，直接chunk_size=512、overlap=50，但代价是出现半句话问题，以及多段高度相关的信息被拆到相邻两个 chunk 里，导致检索时两个片段都只命中一半。
实际项目里我一般按“内容结构”决定切分方式：
| 切分方式 | 适用场景 | 优点 | 风险 |
|---|---|---|---|
| 固定窗口 + overlap | 长文本、无明显结构的新闻/报告 | 实现简单、参数好调 | 容易切断语义、检索噪声大 |
| 按段落/标题切分 | 产品文档、帮助手册、Markdown 文档 | 颗粒度合理、结构完整 | 段落太长时还得二次切 |
| 语义切分 | 会议纪要、对话记录、逻辑跳跃多的文本 | 按语义边界切，关联度更好 | 计算成本高，边界判断有误差 |
| 小 chunk + 大 context | 需要精确定位原文片段 | 检索准、上下文丰富 | 流程复杂，要维护两级索引 |
我比较推荐的通用方案是“段落切分 + 区块内补全”：以 Markdown 标题层级或空行为主边界切分，如果单段超过 800 字再按句子二次切，并保留前文摘要作为补充上下文。这套方式在常见框架里都有现成实现，比如 LangChain 的MarkdownHeaderTextSplitter，LlamaIndex 也有对应 splitter。注意，切块参数没有标准答案，业务字频、回答颗粒度都会影响最优参数。建议做一组 A/B：固定chunk_size=384/512/768，每组跑同样的评测集，看命中率和忠实度的变化，通常半小时就能找到相对较优档位。
2.3 表格和结构化数据入库：系列产品表怎么处理
搜索热词里有“系列产品表格怎么存入rag知识库”，这是个好问题。表格类数据直接按行切块，检索时上下文会支离破碎；直接按整表切块，又会超过上下文窗口、浪费 token。我见过最常见也最不可取的做法，是把 Excel 转成 CSV 后按行塞进向量库，然后让模型“看图猜答案”，效果自然惨不忍睹。
根据数据用途不同，我会分三种方案处理：
- 方案 A：按行为语义转成自然语言。比如“仓库编号 WH-001，产品名 LK-300，库存 120，单价 899 元”，然后把这一行以一条“记录文本”的形式作为一个 chunk，存的时候保留“这条记录属于哪个表的哪个字段”作为 metadata。适合点查类问题，比如“某某产品还有多少库存”。
- 方案 B：以“表头 + 多行片段”组合切块。比如每个 chunk 带上表头，再带 10 到 20 行数据，然后用标题或描述性字段做索引。适合需要对比多个产品的场景。
- 方案 C：结构化查询，不硬走向量检索。当前面两种方案都喂不准时，直接上 Text-to-SQL 或 Query Rewrite + 数据库查询。比如问“价格低于 500 的产品有哪些”，向量检索和文本生成都容易翻车，而结构化查询一次就能算对。这类场景如果硬塞进 RAG 知识库，换来的是幻觉和算力浪费。
我做了一个实践原则：表格数据先问“用户要的是数据，还是要的是信息”。要数据，走结构化查询；要信息，走语义化 chunk；两者都有，就把 RAG 和 SQL 并行跑，再让模型从两个结果里综合。这样比把表格硬塞进一个流程里稳得多。
3. 检索链路调优：召回、重排与过滤
3.1 向量召回不是万能的：混合检索才稳
只要做过 RAG 的线上项目，都会遇到同一个尴尬：向量检索对“意思相近但用词不同”的问题很敏感，但对“精确名称、型号、编号”这类强标识符信息反而记不住。比如用户问“仓库 WH-011 的库存”，如果 Embedding 模型没把 WH-011 和文档里的 WH-011 对齐，向量相似度可能排到十名开外。
我前几年接手一个 ERP 知识库项目，检索质量一直上不去，后来做了个改动：把 BM25 关键词检索和向量检索做混合，用 RRF（Reciprocal Rank Fusion）合并排序。BM25 擅长精确匹配术语编号，向量检索擅长同义改写和语义匹配，两者互补后，检索命中率直接涨了一截。
用 LangChain 实现一个混合检索器很直接：
from langchain.retrievers import BM25Retriever, EnsembleRetriever from langchain.vectorstores import Chroma bm25_retriever = BM25Retriever.from_texts(texts, k=10) vector_retriever = Chroma(embedding_function=embedding_model).as_retriever(search_kwargs={"k": 10}) ensemble = EnsembleRetriever( retrievers=[bm25_retriever, vector_retriever], weights=[0.4, 0.6], ) docs = ensemble.invoke("仓库存量 WH-011 多少")权重比例建议按数据形态试：如果数据里型号、编号多，BM25 权重给到 0.5 甚至更高；如果文档偏自然语言，向量侧可以再压一压。这个步骤简单，收益却很稳定。
3.2 重排：小模型解决大问题
向量检索先召回 top50 到 top100，再用重排模型精排取 top5，这是线上 RAG 的标配。重排的价值在于，把“语义相似但可能不必要”的候选过滤掉，留下真正能支撑答案的片段。跨编码器（Cross-Encoder）重排效果公认最好，因为它把 query 和 doc 直接拼接在一起打分，能捕捉更细的交互语义。
我用 bge-reranker 类模型做重排后，评测集上的命中率经常能从 60% 提到 80%。一个我不断强调的细节是：重排只看相关度还不够，还要看上下文完整性。有些候选片段高度相关，但只有一句半截话，单独支撑不起回答。这时可以把“片段是否含完整语义”作为重排的后置规则，或者直接用小 chunk 检索 + 大 chunk 拼接解决。
重排阈值也别拍脑袋设。比如 top5 里第 5 名的相关度得分如果和 top1 差出一大截，宁可只给 LLM 前 3 个片段，也不要喂噪声。否则模型会被不相关内容带偏，反而出现“检索对了答案却也错了”的奇异情况。
3.3 元数据过滤与权限隔离
很多团队忽略 metadata 的用法。数据入库时，给每个 chunk 打上文档来源、部门、品类、时间范围、权限级别等标签，检索时先按权限过滤再召回，既能提升准确率，也是合规必需。比如同样的产品文档，销售部门想看价格策略，研发部门只能看技术规格，如果不做 metadata 过滤，模型可能把不该披露的内容答出来。
在业务复杂一点的项目里，我还会给 chunk 增加“知识类型”标签，比如“规格参数”“操作流程”“FAQ”“价格政策”，然后在检索时根据用户意图倾向去过滤。这个做法的迭代空间很大，很多所谓“检索不准”的问题，其实只是忘了利用你本来就有元数据。
4. 生成链路调优：提示词设计、上下文与多轮对话
4.1 上下文工程：不是把检索结果一股脑丢给 LLM
检索做得再好，生成阶段如果把一堆片段不加整理地塞给模型，照样会水土不服。上下文组装有三个原则：去噪、按相关度排序、标明出处。
去噪指重排后只保留高相关片段；排序指从最相关到次相关排列，让模型优先看到核心答案；标明出处则是把每个片段的文件名、章节号、原文位置写进提示词，方便模型引用。我自己常用的提示词结构是：
请基于下面的“参考资料”回答问题。参考资料可能包含不相关内容，请只使用与问题直接相关的部分。 如果参考资料不足以回答问题，请直接回答“资料不足，无法确定”，不要自行编造。 参考资料： [1] 来源：产品手册-第3章-仓库管理 内容：…… [2] 来源：库存规范-V2.1-第7条 内容：……这样一个提示词结构看着简单，但能把很多模型的“幻觉”压下去不少。模型在明确被告知“资料不足就当不知道”之后，编答案的概率会明显降低——前提是你真的给了它够用的资料。
4.2 多轮对话怎么设计：查询改写与指代消解
RAG 接多轮对话，最大的坑是“指代丢失”。用户先问“A 产品什么时候发货”，接着问“它的价格呢”，如果第二个问题原样拿去检索，模型完全不知道“它”指的是 A 产品。常见的解法是让大模型先做一次查询改写：把当前问题结合历史对话转成独立的、完整的查询语句，再用改写后的查询做检索。
Python 伪代码大概长这样：
rewrite_prompt = """ 根据历史对话和当前问题，生成一个更适合检索库的独立问题。 要求：不遗漏关键实体，不改变原意。 历史对话：{history} 当前问题：{question} 独立问题：""" rewritten = llm.invoke(rewrite_prompt.format(history=history, question=question)) docs = retriever.invoke(rewritten)除了改写，还要控制历史窗口。把七八轮之前的闲聊内容也塞进 prompt，只会白白消耗 token 和干扰模型。我一般只保留最近 3~5 轮，并且做一个“历史摘要”字段，如果对话太长就先摘要再拼接。这个设计在很多框架里都有现成模块，但默认参数不一定合你业务，用自己评测集调一遍更有底。
4.3 RAG 和 Skill、Agentic 怎么结合
再说一个热词：“skill怎么和rag结合起来”。在 Semantic Kernel、LangChain4j 这类框架里，Skill / Tool / Function 其实就是一个“能力单元”。RAG 完全可以作为一个技能暴露给模型调用，比如“search_knowledge_base(query)”，模型在回答时主动决定“这个问题需要查知识库”。这样做的好处是，当用户问“今天天气如何”这种不需要知识库的问题时，模型不会白白检索一遍。
更复杂一点，可以把 RAG 和其他 Skill 组合成 Agentic 流程。比如一个客服场景：先通过 RAG 查产品资料，再调用订单查询技能查用户订单状态，最后综合两部分内容回答。这就是 Agentic RAG 的典型形态。MCP 的作用则是把这些 Skill 标准化封装成统一协议的 Server，让不同 Agent 都能复用。所以区别可以记成一句话：RAG 是知识手段，MCP 是工具协议，Agentic RAG 是调度的思想，三者不是竞争关系，而是可以叠在一起用。
5. 评测体系与调优回归
5.1 从“肉眼感觉”到量化指标
没有评测体系的调优，约等于靠运气上线。我在前面的章节提过 RAGAS 这类评测思路，实际使用下来，最值得盯的四个指标是：
| 指标 | 关注的问题 | 计算方式参考 |
|---|---|---|
| 上下文命中率/召回率 | 正确片段是否被检索到 | 答案对应的 ground truth chunk 是否在 topN |
| 忠实度 | 回答是否忠于检索上下文 | LLM 逐句判断，是否有上下文支撑 |
| 答案相关度 | 回答是否正中问题 | 语义相似度或 LLM 打分 |
| 端到端延迟 | 用户体验是否可接受 | 检索 + 重排 + 生成耗时 |
实际操作中，我先用检索命中率兜底，因为如果答案片段压根没被检索出来，生成阶段再怎么调都没用。命中率达标之后，再去优化忠实度和答案相关度。这套顺序能帮你少走很多弯路。
5.2 5 分钟搭建一个简易评测集
评测集不用一步到位。我通常的做法：
- 从真实用户日志里抽 50~100 条高频问题。
- 人工给每条问题找答案来源文档，并标出正确答案的原文片段。
- 把每条问题记录成
{"question": "...", "context": "标准答案片段", "doc_source": "xxx.pdf"}。 - 用脚本批量跑 RAG 流程，输出检索结果和生成答案。
- 人工或 LLM 打分，生成一份对比表。
一个几十条问题的小评测集，半小时就能建好。它最大的价值不是准确反映线上效果，而是给你一个“回退坐标”：任何一次调整，如果评测集分数下降超过 2~3%，就说明这次调整有风险，可以及时回滚。
5.3 回归与基准库：调优的护城河
有些团队在评测集上狂调，把分数刷得很漂亮，一上线立刻翻车。原因通常是评测集过拟合，或者评测集没有覆盖长尾问题。我建议把评测集拆成两层：一个是“核心回归集”，几十条高频必须全对；另一个是“冒烟集”，覆盖各种边界情况、多轮对话、表格问题，定期混入新出现的问题类型。
每次调整代码或参数，就重新跑一遍核心回归集，连续跑上一周，你就能看出“看似变好”的调优是不是真的稳定。这个习惯救过我很多次，尤其当团队同时有好几个人在改不同环节时，回归集就是最后的守门员。
6. 常见问题与排查技巧实录
6.1 三个典型 Bad Case 复盘
Case 1：检索到了，但模型答错。有一次用户问“商品退换货期限”，检索结果里明明有“自签收之日起 7 天内可无理由退换”，但模型却回答“15 天”。排查发现，同一份文档里有“会员可享 15 天退换”的另一段，模型基于更靠后的上下文回答了。解决方法是重排后按相关度排序，并明确告诉模型“优先采用最匹配的片段，片段之间有冲突时标注版本范围”。同时，把退换货政策做成结构化的“政策时效表”，在生成阶段加入版本提示。
Case 2：回答含糊，像在套话。用户问“A 和 B 套餐哪个划算”，系统答案却是复述两段原文，没有对比。问题出在检索阶段把两段内容分散在不同 chunk，重排 top1 只选了其中一段。我尝试对这种“比较型问题”做意图识别，单独走“多文档混合 chunk + 对比模板”的流程，效果立刻清晰很多。
Case 3：表格数据答不到点子上。“今年 3 月各区域销售额排名”这类问题，向量检索很难命中。最后我放弃了硬塞向量库的方案，改成 Text-to-SQL 直接查数，再把查询结果交给模型总结。RAG 链路不是只能有一种形态，遇到结构化数据，结构化路数才更可靠。
6.2 资源受限的调优路线
不是每家团队都有充足 GPU。对“本地知识库”“个人免费版”这类需求，可以用开源 embedding 模型、本地小型 LLM、轻量向量库（如 Chroma、sqlite-vec）搭建一套能跑的 RAG，构建成本很低。但要注意，模型变小时，幻觉未必减少，反而可能增加，所以“小模型 + 高质量检索 + 严格提示词”就格外重要。
开发阶段先用免费或低价的托管 API 打通链路，评估业务效果之后，再把推理迁移到本地，是我比较推荐的路线。这样你把成本集中花在“值得本地化”的模型上，而不是一上来就硬啃全套自建。
6.3 框架选型速查
最后整理一张工具选型速查表，算是我做调优时的默认偏好：
| 框架 | 适合人群 | 特点 | 调优友好度 |
|---|---|---|---|
| LangChain / LangGraph | Python 生态，灵活 DIY | 组件齐全，可控性高 | 高，但版本变化快 |
| LlamaIndex | Python 生态，偏数据索引 | 对文档切分、索引引擎封装很深 | 高，特别适合索引调优 |
| LangChain4j | Java/Spring 生态 | 适合已有 Java 技术栈的团队 | 中高，但社区物料少 |
| Semantic Kernel | .NET / Python 生态 | Skill/Plugin 体系，适合企业应用 | 中，需要自己搭检索逻辑 |
我个人没有“最好框架”的执念。项目用了多年 Java 就上 LangChain4j，Python 团队就 LangChain 或 LlamaIndex。真正决定上线质量的，永远是数据质量、检索策略和评测闭环这“老三样”，框架只是壳。
最后分享一个我踩过 N 次坑之后的经验：RAG 系统调优，调的不是某一个“魔法参数”，而是一个可迭代的闭环——数据侧做清洗和结构化，检索侧做混合召回和重排，生成侧做上下文工程和多轮改写，评测侧做回归集守门。每次只动一个环节，改完立刻跑基准，分数不降再上线。按这个顺序来，你大概率能在两周内把一套 “勉强能跑” 的 RAG，调成 “用户愿意用” 的 RAG。
