1. 别急着调Prompt先看看RAG系统的五段链路前阵子有个团队带着评测数据来找我说他们做的大模型知识库问答系统上线之后效果一直不理想用户问一个跟公司制度相关的问题答非所问是常态偶尔答对了追问一句依据在哪模型又能把完全不存在的文件编号编得有模有样。他们一开始的判断是提示词写得太弱结果换了三轮话术分数纹丝不动。我接手之后做的第一件事是让他们把模型回答质量差这个问题拆到一条完整的链路上看。RAG系统看起来是检索一下、拼一下、让大模型回答实际上至少串着五个环节知识入库、检索召回、重排筛选、上下文组装、大模型生成。任何一个环节出问题最后背锅的都是生成出来的答案。调Prompt当然有作用但那只是五段链路里的最后一段前面四段如果喂进来的东西是脏的、错的、不完整的Prompt写得再漂亮也无非是把错误包装得更流畅。我把这个系统里最常见的故障信号和对应的根因环节整理成了一个对照表排查时基本就按这个表定位系统表现大概率出问题的环节检索结果总是一堆无关片段知识入库的分块策略、检索算法单一检索到的片段沾边但不解渴缺少重排序Top结果被粗召回里的噪声占据用户问题带指代、口语化怎么都查不准查询改写缺失或改写不到位上下文塞满之后模型开始自由发挥缺少上下文压缩与去重组装方式太粗糙答案流畅但引用是编造的生成阶段没有任何边界约束与溯源机制同一个问题时好时坏无法复现没有评估闭环每次改完了靠感觉验收这篇文章讲的11个策略就是针对这五段链路逐个打补丁的实操方案。它们不是坐在实验室里推导出来的理想架构而是我在多个真实知识库问答项目里反复用过的组合拳。核心思路只有一个别把效果差一股脑归因于模型不够聪明先把RAG系统自己该干的活干明白。下面先把完整的策略清单亮出来后文会逐一展开知识库分块优化按语义边界切而不是按字数硬切混合检索关键词检索与向量检索并行再融合分数查询改写与扩展先帮用户把问题问清楚重排序精排粗召回负责广撒网精排负责选Top N上下文压缩与去重别让无关内容挤占模型注意力结构化上下文把检索段落组织成带编号的证据列表引用溯源答案必须带出处编号无答案分支证据不够时明确说不知道动态检索决策不是每个问题都有必要检索提示词边界规则用规则约束模型而非花式人设评估闭环与分阶段回归没有评测口径优化就是盲人摸象2. 召回侧优先加固混合检索、重排、改写、切块一个都不能少2.1 混合检索把关键词能对上和语义能对上的结果一起捞回来很多RAG项目第一版只做向量检索原因是实现简单、对语义理解友好。但上线之后就会发现一个典型场景用户问ABC-2024-001号合同的违约金条款是什么向量检索很容易把语义相似的合同违约责任文档捞出来反而对那个精确的合同编号不敏感。反过来如果只用关键词检索用户说最近那个项目的成本有点失控怎么降下来关键词检索基本捞不到任何语义相关的内容。所以第一条策略不是二选一而是两个都要。我的做法是同时跑关键词检索和向量检索各自取Top 50然后对两路结果做分数归一化再融合。融合权重一般从关键词0.3、向量0.7起步具体比例靠评测集调。归一化这一步特别关键关键词分数和向量相似度分数不在一个尺度上直接用原始分数相加等于让数值大的一方主导结果。我常用的归一化方法是min-max或者排名倒数融合后者更省心——直接把两路结果的排序位置换算成分数再按权重合并。混合检索引擎做起来不复杂但要注意两路检索的并发与超时。我的习惯是让两路并行执行统一等最慢的一路返回避免串行把延迟翻倍。2.2 重排序粗召回负责广撒网精排才决定最终进Prompt的Top N粗召回阶段为了召回率通常会放进来很多看起来沾边的内容直接把这几十个片段全部塞进Prompt既不现实也没必要。更好的做法是在中间加一层精排序用交叉编码器对每一条查询-片段对打一个更精细的相关性分再从粗召回结果里挑出Top 5到Top 6进Prompt。为什么粗召回用双编码器、精排用交叉编码器因为双编码器把查询和文档分别编码后算相似度速度快但丢失了查询和文档之间的细粒度交互交叉编码器把查询和文档拼在一起过模型能捕捉到两者之间的精确匹配关系精度明显更高代价是每个候选对都要单独过一遍模型慢很多。所以合理的分工是粗召回负责从整个知识库里快速捞出50个候选重排序再在这50个里精挑细选。这里有一个非常容易踩的坑重排序模型对领域敏感。通用的重排序模型在通用语料上表现不错但你拿来做的是某个垂直行业的问答比如合同条款、设备手册、内部制度排序效果可能直接打对折。我遇到过一种情况重排后排在第一位的片段反而是错误答案真正对的证据排在第三位排查了很久才发现是重排模型没有针对该领域微调。所以在垂直场景里要么先收集一批查询-文档-相关性标注数据做微调要么至少用人工抽检的方式验证一下重排结果是否符合直觉再决定是否沿用通用模型。2.3 查询改写与扩展先帮用户把问题问清楚用户发起的问题很少是标准查询。最常见的两类一是带了指代我们2024年的营收是1.2亿那毛利率呢那毛利率呢如果直接拿去检索注定捞不到东西二是过于口语化咱公司请假咋弄这种句子直接检索关键词匹配度很低。查询改写就是先把用户问题转换成更适合检索的形态。具体做法可以是把对话历史拼接进当前问题让模型把指代关系消解清楚也可以做查询扩展让模型基于原问题生成3到5个不同侧重点的候选查询分别检索后合并结果。我一般在线上用一个小模型做改写控制延迟和成本。改写链路设计成判断是否需要改写 改写 改写结果可信度检查如果模型自己都觉得改写没把握就退回原问题检索。这里要特别提醒查询改写不是万能药。对已经写得很精确的问题改写反而可能引入歧义。比如用户精确提问编号XS-2033的设备检修记录改写模型可能会画蛇添足扩展成设备检修记录相关的所有内容结果召回了一堆不相关的历史记录。所以我的原则是优先处理指代消解和错别字其次才是扩展而且扩展结果必须与原始查询做一次相关性过滤。2.4 分块策略按语义边界切而不是按固定字数硬切知识库里的文档要喂给嵌入模型受模型最大输入长度限制必须先切成块。很多项目图省事直接按500字硬切结果就是一段完整的技术流程被拦腰截断表格被劈成两半检索时经常只命中半截信息后半截在另一个块里最终答案自然残缺。更好的分块策略是围绕语义完整性来做优先按照标题、段落、列表项、表格结构这样的天然边界切如果一段内容太长再考虑在句号、分号这些语义相对完整的节点上二次切分。比如一份设备操作手册会先按章节边界切每个章节内部再按小节边界切每块控制在200到500词之间相邻块保留50到100词的重叠避免边界处的关键信息被切断。还有一个很有效的补充为每个块生成若干条假设性问题作为索引。意思是在入库阶段用大模型为每个块生成3到5个可能的用户问题比如某个块讲的是退款流程就生成退款需要什么材料退款多久到账退款申请怎么提交等。检索时候选用用户问题的向量去匹配这些假设性问题命中率往往比直接匹配原文更高。代价是入库成本增加但换来的是召回效果的明显改善性价比不错。3. 生成侧的五件套压缩、结构化上下文、溯源、动态检索、提示词3.1 上下文压缩检索出来的东西不能全都塞给模型我见过不少项目的Prompt里塞了七八个检索片段加起来三四千token模型输出质量反而不如只给三个片段的时候。原因有两个一是模型对长上下文的注意力分布并不均匀夹在中间的信息容易被忽略二是检索片段里原本就混着大量噪声这些噪声会引导模型跑偏。所以生成侧的第一件事不是优化Prompt而是压缩进Prompt的内容。我的标准做法是重排后先做一次**最大边际相关性MMR**去重把内容高度重复的片段筛掉然后根据重排分数和篇幅上限确定最终保留的片段数量最后对每个片段做句级重要度筛选只保留与查询相关性最高的句子或句子群。这里要小心一个反面情况压缩过头会丢掉关键数字或限定条件。比如一个片段里大部分是背景描述只有最后一句写了该条款仅适用于2024年之前签署的合同如果压缩策略只看句级相关性很可能把最后那句限定语丢掉模型就会把适用范围扩大化。我的经验是在做压缩的同时保留原片段中的数字、日期、专有名词和限定性短语哪怕它们的相关性分数不是最高。压缩的目标是去噪声不是去信息密度。3.2 把上下文组织成证据列表模型才不容易跑偏同样的内容直接扔一堆段落进Prompt和把这些段落组织成带编号的证据列表模型的表现可以差一大截。原因不难理解模型在没有编号的连续文本里很难把哪条证据对应哪个来源建立起来出错了也没法追踪。我现在习惯把所有检索片段整理成统一的格式类似[1] 来源设备运维手册-第三章-3.2节内容设备每月需要进行一次预防性维护重点检查液压系统压力值正常范围应在80-100bar之间[2] 来源设备运维手册-第五章-5.1节内容年度大修周期不得超过12个月维修记录需存档备查...这样做的直接好处有三个第一模型在生成时可以明确引用根据[1]或多个材料[2]、[3]均提到引用行为更可控第二如果两个片段互相矛盾模型更容易发现冲突并直接指出而不是强行融合出一句错误内容第三后续做引用溯源时只需要解析模型输出的编号即可不需要再在长文本里找来源。这个改动几乎不增加任何成本但效果非常显著我甚至觉得它是11个策略里性价比最高的一条。3.3 引用溯源与无答案分支宁可说不知道也不能瞎编RAG产品的用户体验有一个分水岭答案错了用户还能忍受但模型言之凿凿却完全是编的用户绝对不会忍。大模型本身并没有区分知识边界的能力不给它规则它就会把检索材料里没有的信息也顺着用户的问题编出来。我做的第一件事是在提示词里明确要求回答必须标注引用来源编号不允许出现没有编号支撑的内容。第二步是设置一个无答案分支——当重排之后所有候选片段的相关性分数都低于某个阈值或者模型在生成时发现自己需要依赖超出材料的知识就明确回答当前知识库中没有找到相关信息然后列出几个可能相关的文档标题让用户进一步确认。这个分支看起来会让系统显得不够聪明但实际用户满意度反而是提升的。原因很简单用户更信任一个会说不知道的助手而不是一个把所有问题都答得无限自信的助手。3.4 动态检索决策不是每个问题都需要翻知识库很多RAG系统不管用户问什么都先做一轮检索再喂给模型。这会在两类问题上浪费资源一类是你好谢谢这种寒暄完全不需要检索另一类是用户直接明说根据你的常识回答或者问的是普适性问题检索反而可能把不相关的内容带进来。动态检索决策就是在生成之前加一个判断层根据意图或规则决定要不要检索、检索多少条。我的做法是先做意图分类把问题分成不需要检索和需要检索两类需要检索的问题再进一步分成单轮查询和可能需要多轮查询前者检索一次后者可以根据中间结果再补一次检索。这个策略带给我最大的收益其实是降低了噪声比例。不需要检索时就不检索系统的答案相关性和响应速度同时提升。要注意的是分类层本身也可能出错所以我的规则里有一条兜底如果用户的问题里带帮我找一下根据我们公司制度查询等明显意图词直接强制走检索不依赖分类结果。3.5 提示词工程在RAG里的真正角色约定规则而不是花式话术很多人以为提示词工程是把人设写得活灵活现但对RAG系统来说提示词最重要的作用是划边界。我会在系统提示里固定放这几条只能依据给定的材料回答优先引用带编号的片段材料没有覆盖的内容必须明确说明信息不足或未找到禁止编造文件编号、日期、数值或来源名称如果多个材料存在冲突指出冲突的位置和内容让用户自行核实回答最后列出用到的编号清单。另外我会在提示词里放一个简短的few-shot示例展示好的回答和不好的回答之间的差别。但示例要精简一两个足够。整个提示词我控制在几百字以内因为RAG系统里真正承载信息的是检索上下文不是指令本身。如果提示词写得比上下文还长反而会压缩模型处理材料信息的空间。4. 组合方案怎么排优先级54%的提升从哪来4.1 我的组合打法分三阶段逐步加固链路这11个策略不建议一次性全上。原因很实际如果同时改十个地方效果提升了你不知道是哪个改动起的作用效果变差了你也找不到罪魁祸首。我习惯分成三个阶段推进。第一阶段做地基加固只改两件事分块优化和混合检索。这两个改动主要影响召回数量和质量动作最小、风险最低。地基打完之后跑一轮评测确认基线水平。第二阶段做召回精排加查询改写和重排序。这一阶段会让进入Prompt的片段更精准噪声明显减少。但要注意重排序之后原本排在前面的结果可能被打下去如果业务依赖原来的排序逻辑需要提前规避。第三阶段做生成侧约束上上下文压缩、结构化上下文、引用溯源、无答案分支和动态检索决策。这个阶段会直接改变模型的输出风格建议在一批有代表性的问题上做人工抽检确认模型的不知道行为没有伤到正常问题。4.2 效果提升的数据口径立项前先定好评测集54%这个数字不是拍脑袋拍出来的也不是某个模型突然变聪明了而是建立在同一套评测集、同一个评分标准上的前后对比。我在那个项目里用的评测集是一批覆盖典型业务的200个问题每个问题都预先标注好了标准答案和答案来源文档。评分维度分成三项答案忠实度是否忠于材料、答案完整性关键信息有没有漏、引用准确度来源编号是否对得上每项0到5分加权合成百分制。初始版本跑下来这个系统的端到端可用性评分只有62分左右。经过三阶段优化之后再测评分到95.5分换算下来相对提升了54%。需要强调一句这个数字只代表那个特定项目不代表任何一个团队照着抄就能得到54%。但这个口径模型很有价值——它逼着所有人先回答一个问题什么叫效果变好了 如果这一点不定义清楚后面做多少优化都无法评估。所以我的建议是优化RAG系统之前先花两三天建一个20到50条问题的小型评测集把关键指标跑通。哪怕起步粗糙也比没有测评强。每个改动上线前跑一遍用数据说话而不是靠感觉拍板。4.3 一组可供参考的配置参数实录为了让这套组合方案更好落地我把一个比较稳定的配置清单放在这里可以作为起点不要当成标准答案环节配置参考说明分块块大小200-500词重叠50-100词按段落/标题切长文档优先按章节切再按段落切混合检索关键词0.3权重 向量0.7权重各取Top50后融合权重需用评测集微调重排序对融合后Top20-30做精排取Top5-6垂直领域建议微调重排模型上下文压缩保留5-6个片段总token控制在2000以内数字、日期、限定语必须保留无答案阈值重排得分低于满分的35%时走无答案分支阈值靠人工抽检校准动态路由意图分类 强制检索关键词兜底分类模型要小而快答案格式强调引用编号结尾列出引用清单禁止无编号内容这套配置在离线评测和在线灰度里的表现都比较稳定。但要提醒的是这些参数都跟具体知识库的规模、文档类型和模型能力有关系换一个场景就要重新调。我把它们列出来是希望给你一个可以抄的起点而不是必须套的终点。4.4 延迟与成本平衡重排序虽好也不能让它拖垮在线响应加了重排序之后性能一定会多一块开销。交叉编码器对每个候选对都要单独前向计算如果粗召回是50个片段那就要算50次。实测下来小规模的精排模型在CPU上处理50个短片段大概要增加40到100毫秒GPU上会快一些但也要20到50毫秒。对某些延迟敏感场景这个开销不能忽略。我的取舍是在线服务只对融合后的Top20做重排而不是对全部候选做重排这样既能把噪声压下去又不会让延迟翻倍。如果响应速度压力特别大还可以对缓存命中率高的热问题直接返回缓存答案完全跳过检索和重排。另外混合检索的两路如果其中一路返回很慢可以给那一路设置更短的超时时间不让它拖慢整体链路。成本方面重排序增加的开销主要是推理资源但换个角度想如果重排序能让最终答案质量提升减少用户反复追问的次数总成本反而可能下降。这个账要按线上流量具体算不能只盯着单次调用的CPU消耗。5. 实测中的意外情况与我的取舍记录5.1 哪些策略在某些场景下反而拖后腿这套组合拳不是每个策略在每类场景里都有效我挑几个实际遇到的反例说一说。查询改写在一类场景下确实会拖后腿用户提的是法律条文编号、合同编号、设备型号这类精确标识符。我的改写模块曾经把根据合同CX-2022-0815第4条回答扩展成了根据合同相关条款回答导致检索结果里混入了大量无关合同重排之后真正的目标合同反而掉出了Top5。后面我做了硬编码保护检测到编号年份关键词格式时禁止改写直接按原查询检索。上下文压缩也出过问题。有一次系统把一段技术手册压缩成了需要定期维护注意压力值原片段里80-100bar和每月一次被当成冗余句子丢掉了结果模型给出的建议变成应定期维护但未说明具体周期和压力范围导致用户追问三次。之后我的压缩逻辑增加了对数值型和单位型短语的强制保留。重排模型同样有过翻车记录。通用重排模型在某设备维修知识库上表现不稳定经常把如何更换滤芯这类高频问题排在滤芯型号对比前面而后者其实才是真正的答案所在。后来我收集了2000条人工标注的查询-片段-是否相关数据做了微调排序才逐渐符合业务直觉。所以垂直领域里重排模型不要直接裸跑至少要抽一批数据验证。5.2 数据质量这个变量被我低估了优化做到后期我发现一个扎心的事实策略能带来的提升是边际递减的而数据质量才是决定RAG系统上限的根本变量。同一个知识库如果里面存在大量过期版本、互相矛盾的条款、残缺的章节无论检索和生成侧怎么优化用户都会在某一次查询中碰到错误信息。有一次我们排查某类问题的错误率定位到最后发现知识库里有新旧两版员工手册同时存在新版说年假10天旧版说年假7天检索系统有时候召回新版有时候召回旧版模型没有能力判断版本差异就只能随机抽到一个答案。这让我意识到在上重排序、上提示词之前先把知识库做一次标准化整理可能性价比更高文档需要标注版本号、生效日期、适用范围同一类的知识尽量统一格式明显过期或冲突的文档先标记或下架。我后来养成了一个习惯每到一个RAG项目先花时间摸清楚数据资产是什么形态、怎么流转、有没有责任人。如果数据本身一团糟那11个策略只能让你从很差变成不太差想达到好用会很吃力。5.3 如果只保留三个策略我会选这三个每次被人问如果时间有限哪三个策略必做我的答案都很固定结构化上下文、引用溯源与无答案分支、混合检索加重排。结构化上下文和引用溯源解决的是用户最敏感的问题——模型一本正经地胡说八道。模型一旦必须按编号引用证据并且被允许说不知道幻觉比例会肉眼可见地下降。混合检索加重排解决的是答非所问的问题保证进到模型嘴里的材料跟用户问题有真实的关联。这三个策略覆盖了RAG体验的两条生死线召回相关性和生成可信度。至于动态检索、查询改写、缓存这些都属于在有基础之上的进阶优化。先把地基打好再去追求极致的成本和延迟路会走得稳很多。最后说点个人体会RAG系统的优化没有一个固定的做完状态它更像是对着一台有很多旋钮的设备做持续校准。每调一个旋钮都要知道为什么调、调完怎么验证这比盲目堆策略重要得多。如果你正在做类似的项目我的建议是不妨先从本文的11个策略清单里选最容易落地的两三条试起建立一个最小评测集用两周时间跑一轮前后对比。数据会告诉你下一步该往哪里使劲。