1. 调优前的自我拷问你的RAG到底卡在哪一环先说一个我反复遇到的场景同事跑过来跟我说我们的RAG问答效果太差了回答老是胡说八道然后第一反应就是换个大模型调温度参数把prompt写长一点。结果折腾一星期该错还是错。RAG系统调优之所以让人头疼就是因为它是一条完整的链路——召回、重排、上下文组装、生成每一个环节都会影响最终输出。你以为问题出在生成可能根子早在检索就烂掉了。这一章我不会讲RAG是什么直接讲怎么调、怎么定位瓶颈、怎么验证效果。1.1 先分清是检索烂还是生成烂这是调优的第一步也是很多人跳过的第一步。我习惯的做法是把检索结果直接打印出来不经过LLM人眼判断。如果你的检索Top5里本身就有一半是无关内容那你让再强的模型来也没用它又不是神仙能从一堆垃圾里挑出金子。反过来如果Top5里内容明明相关答案却还是错的那问题就出在生成侧——不是prompt没写清楚就是上下文塞了太多干扰。我自己最常用的一套排查方法分三步走检索结果裸检把query送进检索链路打印top-k条结果的标题、摘要、来源人工打分看相关性。上下文可视化把最终拼给LLM的prompt完整打印出来看有没有重复片段、有没有截断、上下文顺序是否合理。单条case走查挑一个失败case从query改写、向量检索、重排序、prompt组装一步一步看数据流变化。这一套走完80%的问题都能定位到具体环节。很多朋友上来就拿RAGAS之类的框架跑一堆指标指标是红了但根本不知道在哪一步修。先裸检再上指标效率高得多。1.2 建立你的调优基线先能跑通再谈优化不少团队一上来就追求完美RAG什么图谱RAG、Agentic RAG、混合检索全上结果系统复杂度爆炸出了问题根本不知道是哪一环的锅。我的建议是先把最简单的Naive RAG跑通记下它的效果数据作为基线。基线长这样就行文档切块固定大小→ Embedding入库 → 向量检索Top-k → 拼进Prompt → LLM生成。把这个链路的准确率、召回率、响应延迟全部记录下来。后面不管做query改写、重排序还是多路召回都拿这个基线来对比效果有没有提升一眼就能看出来。我见过太多人调优失败不是因为方法不对而是没有基线。今天换个embedding模型明天加个rerank后天改切块参数全凭感觉走最后系统倒是复杂了效果反而更差了。记住每次只改一个变量不做对照实验也算不上调优顶多是玄学调参。2. 切块策略精度与语感之间的平衡术提起RAG调优切块Chunking是我最想说、也最容易被低估的一环。很多人随便定个chunk_size 500就丢进去跑这基本等于抽盲盒式RAG。2.1 切块不是越大越好也不是越小越准这里有个经典的矛盾块太小语义信息残缺检索能召回但上下文不完整LLM看不明白因果。块太大向量表征被稀释一个5000字的块里可能讲了五件事embedding算出来啥都像又啥都不像检索精度直线下降。块重叠为了缓解边界截断问题overlap设置多少直接影响召回质量。我自己的经验是先按文档类型定策略不要一套参数打天下。法律合同、技术文档、对话记录、新闻资讯它们的语义密度完全不同一刀切本身就是最大的问题。2.2 结构化切块的实战经验如果你处理的是技术文档、产品手册这类结构化文本我强烈建议优先用文档本身的层级结构做切块而不是硬按字符数切。比如Markdown标题、HTML的H1/H2、PDF里的章节标题这些都是天然的语义分界点。具体操作上我一般这么做先解析出文档骨架标题、段落、列表、表格。以标题为单位把内容归拢成一个chunk。chunk过长时再按段落或句子二次拆分并保留标题上下文。chunk过短时合并相邻章节避免出现一堆几十个字的碎片块。这里有个很实用的技巧把标题作为chunk前缀也就是每个chunk里带上它所属的章节路径。比如/产品文档/安装指南/环境要求再拼接正文。这样检索时标题层级信息会跟正文一起参与向量匹配。实际测试中这个做法对长文档的检索精度提升很明显原因是很多query本身就是为了找某个章节标题路径能提供强烈的相关性信号。2.3 切块参数的具体调节方法如果你还是决定用固定大小切块比如处理的是无结构长文本那参数调节可以参考我的这套方法参数建议起点调节思路chunk_size300-500字中文先按300跑基线再看失败case是信息缺失还是噪声太多chunk_overlap50-100字主要缓解句子被拦腰截断的问题不要设0是否带标题是标题提供上下文锚点别忘了分隔符优先级段落 句子 字符按优先级切避免句子被硬切一个值得注意的坑overlap不是越大越好。我见过有人把overlap设成200结果索引体积直接膨胀了40%检索时同一段内容反复命中上下文里全是重复信息。overlap的目的只是兜底不是提升精度的手段别本末倒置。另外别忽视关键词密度的问题如果某个chunk里核心关键词出现了三遍embedding对它的表征会明显偏向这些词这在检索时可能带来假阳性——看着相关度高实则内容很水。3. 检索链路优化从embedding到多路召回切块切好了接下来就是RAG的脸面——检索。这一步做得好不好直接决定了喂给LLM的上下文质量。3.1 嵌入模型选型能力边界与场景匹配关于embedding模型我的态度是不要盲目追新也别老守着一个用到死。嵌入模型的选择需要考虑三个问题语言支持你的语料是多语言的还是纯中文中文场景bge-m3、bge-large-zh这类明显比通用英文模型靠谱。语义粒度你的query是短词还是长句短词query适合粗粒度匹配长句query需要模型有更强的语义理解能力。行业术语如果你的素材里有大量专有名词通用embedding可能把它跟另一个常见词混为一谈这时候可以用行业微调或叠加关键词信号。我自己现在的惯例是主向量模型用一个通用双语模型同时记录一份BM25索引双路召回后融合。这俩模型各有侧重相互补位。3.2 混合检索BM25与向量检索的互补逻辑说实话纯向量检索在RAG里翻车的情况比大家想象中多得多。原因在于embedding擅长语义相似不擅长精确匹配。比如你问RAG第13章在哪如果文档里写的是深入浅出RAG系列纯向量检索可能就检索不到因为字面完全不同。但BM25呢它天生就是干字面匹配的专有名词、型号、编号这类东西它抓得死死的。所以我的做法很朴素BM25和向量检索一起上两边各自返Top-30然后用RRFReciprocal Rank Fusion融合排序。RRF的实现逻辑很简单就是给每个文档在每个召回列表里的名次取倒数然后把两边的分数加起来重新排序。它的好处是不依赖两个检索器的分数可比较——向量检索的分数是0.8BM25的分数是12.3这俩直接相加没有意义但名次倒数可以对齐。朴素的融合方式比较粗但实测够用。这里贴一下RRF的伪代码我觉得比纯理论描述好理解def rrf_fusion(results_list, k60): results_list为多个检索器返回的[(doc_id, score), ...]列表 fused_scores {} for results in results_list: for rank, (doc_id, _) in enumerate(results): fused_scores[doc_id] fused_scores.get(doc_id, 0) 1.0 / (k rank 1) return sorted(fused_scores.items(), keylambda x: x[1], reverseTrue)注意那个k值一般取60左右它负责平滑排名差异k越小名次靠前的文档权重越高。这个值可以调但不建议设太低否则融合结果基本被某一路检索器主导混合检索的意义就没了。3.3 重排序别让前排的垃圾结果浪费LLM的注意力检索完还不是终点我强烈建议加一层重排序Rerank。向量检索本质是把query和文档各自embedding后做相似度计算它的问题在于这个相似度是双向压缩的结果信息损失严重。而reranker是让query和文档原文做深度交互计算算的是真正的相关性。所以往往会出现Top1检索出来感觉挺相关但rerank一跑Top1直接掉到第8名。我的习惯是向量检索Top-30或者混合检索Top-30先取回来再送进reranker只保留Top-5作为最终上下文。这一步对最终效果的影响有时候比换一个LLM还要大。常见的中文场景下bge-reranker系列算是成熟方案英文场景cohere的rerank也不错。如果你不想额外部署服务也有一些轻量级方案可以跑在CPU上但响应时间可能增加100-300ms。RAG的检索链路本来就是延迟敏感环节rerank用不用、用多大的模型需要跟你的延迟预算一起考虑。3.4 多路召回与结果融合的落地细节除了BM25向量这种经典组合多路召回还可以往这几个方向扩展关键词/正则召回针对型号、日期、编号等模式明显的实体正则直接命中再插入召回列表。摘要库召回长文档切片后单独给每篇文档生成一个摘要query先匹配摘要库命中后再去取对应chunk。这很适合文档级问答场景。query扩展召回把用户的query换几种说法同义改写、中英翻译、添加修饰词分别检索再合并结果。但是多路召回是一把双刃剑。路数越多融合越复杂每路召回的结果质量参差不齐反而可能把噪声带进来。我的原则是先把两路做好验证收益后再加路数。别一上来就整五路召回结果每路都稀烂融合出来的东西更没法看。4. 生成侧调优把检索到的金子真正用起来检索做得好只是成功了一半。另一半在于你能不能把检索到的内容有效组织起来让LLM心甘情愿地按照你的预期作答。这一节讲生成侧的三个关键点上下文编排、提示词设计、多轮对话策略。4.1 上下文编排给LLM一段结构化材料很多RAG代码长这样把top-k结果咔咔拼接成一个字符串直接塞进prompt。这种做法不能说是错的但效率很低——LLM需要自己从一大坨文本里找到关键信息容易受干扰也容易编造。我建议把检索结果编排成结构化形式。举个实际的prompt模板例子你是一个知识库问答助手。请根据下面的参考资料回答用户问题。 【参考资料】 来源1产品安装指南_第3章 设备上电前需要确认电源电压与设备标称一致…… 来源2产品安装指南_第5章 常见故障代码E-204表示…… 【用户问题】 设备上电后显示E-204怎么处理 要求 1. 优先引用参考资料中的内容 2. 如果参考资料无法回答问题请明确说明 3. 回答时标注引用的来源编号这么做的好处是来源信息给LLM一个锚点它更倾向于从指定来源里找答案而不是凭训练记忆发挥。结构化分隔减少了上下文信息的互相干扰。加了一句话如果参考资料无法回答问题能让LLM在没底时承认自己不知道而不是强行凑答案。这对企业知识库场景尤其重要——一本正经地胡说八道比答不上来可怕得多。4.2 提示词该管到什么程度提示词是生成侧调优性价比最高的手段但它有个反直觉的地方提示词不是越长越好。动不动写2000字的提示词你以为约束得很细结果LLM的执行重点反而被淹没。我现在的风格是定义角色、给定材料、交代规则、明确输出格式四件事说清楚就够。举个例子规则部分怎么写不要写回答要准确这种空话毫无约束力。要写就写可检查的规则如果参考资料中没有明确答案回复抱歉知识库中未找到相关信息。回答开头直接给出结论再做补充说明。引用来源时用[来源编号]标注。不要输出与问题无关的背景知识。另外关于温度参数知识库问答属于低创造性任务温度建议设在0.1~0.3之间。我有段时间为了回答更自然把温度调到0.7结果模型开始自由发挥一本正经地编造产品参数。后来老老实实调回0.1准确性立竿见影。4.3 多轮对话的查询改写与历史管理多轮对话是RAG落地中最容易翻车的场景之一。用户第二句问那它的价格呢系统缺省地把这句话直接拿去检索——没有任何实体检索出来的自然是一堆乱七八糟的东西。解决办法是查询改写Query Rewriting先用一个轻量LLM把用户的模糊query补全成可检索的独立query。我常用的方案是把最近两三轮对话压缩成一段用户语境摘要跟当前query一起送入改写模型让它输出一条不依赖上下文的检索query。注意改写后的query只用来检索不要用来回答。这样当前轮的prompt里还是保留原始用户query避免改写引入信息偏差。这里还要提醒一个容易被忽略的点历史消息往prompt里塞多少塞太少query改写缺上下文塞太多直接把上下文窗口挤爆而且业务知识chunk都没地方放了。我目前的方案是历史消息做成可截断的滚动窗口最多保留最近三轮完整对话更早的用摘要代替。这个方案在长对话场景下非常实用既能保证上下文连续又不会过度挤占token预算。5. 评估闭环不建评估体系调优就是盲人摸象聊到这儿我得说句扎心的话很多人调优失败真不是因为方法不对而是压根没建评估体系改了一版也不知道是变好了还是变差了。5.1 离线评估与在线观测怎么配合RAG的评估至少要有两个层次离线评估用评测集跑指标。评测集怎么来有两种靠谱的办法。一是从历史日志里挖把线上用户真实的query捞出来人工标注标准答案和相关文档。二是用LLM辅助造数拿一批文档让LLM根据文档内容生成问题再人工审核。前者更真实后者更省力。在线观测记录线上系统的表现包括检索命中的点击率、用户对回答的投票/点赞、回答被复制/引用的次数。如果在线反馈率和离线指标的趋势一致说明你的评测集建得有代表性可以信任离线结果。5.2 关键指标解读与常见陷阱我平时主要看这几个指标也说一下常见的坑指标它回答什么问题常见陷阱Context Precision检索出的内容里有多少是真正相关的只看这个容易忽略召回不全的问题Context Recall标准答案里的信息点被检索出来多少需要有人工标注的标准段落工作量不小FaithfulnessLLM的回答是否忠于检索内容很多幻觉问题能从这看出来Answer Relevancy回答是否对得上问题LM生成的问题变体可能引入偏差需要人工抽检另外指标是死的业务是活的。假设你做一个法律问答系统检索召回率低了0.02但回答的引用可信度大幅提升——这在业务上可能是值得的。别盯着指标调优要把指标当作发现问题的线索而不是目的本身。6. 我踩过的坑与最终的调优心得最后这部分我分享几个真实踩过的坑。这些经验几乎没有什么文档会写但每一个都是真金白银的工时换来的。6.1 三个让我印象深刻的翻车现场翻车一召回率高但回答质量暴跌。有段时间我沉迷于提升召回率把Top-k从3调到了10又加了两路召回。结果离线指标确实好看但线上回答开始变得又臭又长。原因很简单太多了LLM分不清楚哪个是核心答案把多个相互矛盾的来源混在一起回答语气犹豫、信息堆砌。后来我控制最终上下文为Top-4并且要求prompt以来源1为主要依据来源2-4作为补充效果立刻恢复正常。翻车二表格数据切块后直接失忆。项目里有一批产品参数表每个chunk按行切碎之后Vector库建立起来了但检索时只能命中某一行无法还原整张表格的上下文。后来我调整策略表格先整表转成描述文本比如参数名参数值 单位拼接再作为一个chunk存进去。query检索时命中的是一段结构完整的描述文本LLM才能稳定回答这款设备的重量是多少。这个问题的本质是源数据类型和切块策略之间必须做适配而不是所有内容都按文本切。翻车三新模型上线老评测集满分线上却崩了。我换了一个新的embedding模型离线评测集得分大幅提升。但上线后我发现用户持续反馈找不到指定章节。后来排查才发现新模型的表征空间跟旧模型完全不一样但评测集本身是旧的覆盖的query模式已经过时了。我意识到评测集必须跟上模型迭代节奏定期补充新采集的线上query否则指标会骗人。6.2 调优的优先级排序建议最后说说如果只给你有限的时间RAG调优应该按什么顺序做。我自己的优先级是第一优先切块策略。这是地基。切块质量上不去后面所有的优化都是空中楼阁。优先做结构化切块带标题上下文。第二优先检索链路。混合检索加rerank这俩组合配合得好通常能让效果提升一个档次。第三优先上下文编排和prompt。把检索结果结构化组装、把规则写清楚这是在让LLM好好说话这件事上成本最低的手段。第四优先多轮对话和高级配置。这些属于锦上添花但建立在线上面三个都稳了之后再做。如果基础不稳直接上Agentic RAG只会在复杂链路上放大原有的错误。我个人始终觉得RAG系统调优比的不是谁掌握的新奇技术多而是谁能快速定位到真正卡住系统的那一环并用最小的改动换最大的提升。这个思路比任何具体参数都重要。上面这些方法是我在迭代了好几版知识库系统之后沉淀下来的实操方案。你如果正在做RAG调优不妨先照着这套排查顺序走一遍大概率能少走不少弯路。