做了两年RAG相关的项目说实话最初能跑通demo的那点兴奋很快就被线上badcase打没了。用户一句口语化的问题检索模块经常召不回关键段落大模型又一本正经地答非所问。后来我花了大把时间在检索链路和索引侧修补才慢慢摸清了门道。这次想聊的内容没有理论堆砌只讲我在生产环境里真正用过的几个高阶RAG技巧覆盖索引分块、查询改写、混合检索、重排序、上下文组装以及评估迭代。不管你是正在调一个RAG demo还是已经上生产做效果优化这些思路大概率能直接帮到你。RAG的性能从来不是一个单点问题。很多人以为换个更强的生成模型就能提升效果但实际排查下来大部分badcase都出在“找不到”“找不准”和“喂不好”这三件事上。所以下面的技巧我会按一条完整链路的顺序展开先让索引更合理再让查询更干净然后让召回和排序更精准最后让上下文更可用。每一部分我会结合踩过的坑和实测数据来写方便你直接抄作业。1. 索引侧分块和向量化检索质量的地基1.1 别再无脑固定切块分块粒度决定召回上限很多RAG项目第一步就是用一个固定大小把文档切成块比如每512个token切一块中间加个重叠。这样做不是不能用但一旦文档结构复杂尤其是合同、产品手册、技术规范这类有章节层级的内容固定切块会把语义单元切碎。比如合同里的“违约责任”条款被拦腰截断一部分进了上一块一部分进了下一块向量化之后两个片段都没有完整的语义检索时自然谁都召不回。我个人的经验是能按文档结构切就按结构切。先把Markdown标题、PDF章节、HTML的标题层级解析出来以标题为边界把段落归到最近的章节块里。如果章节太长再在章节内部做二次切分同时保留章节标题作为上下文前缀。切成块之后给每个块塞一段“来源说明”比如“来自某产品手册3.2节”这样即使正文被裁剪向量里也带有主题信息。如果文档没有明显的结构那至少要把固定窗口和重叠窗口的参数调明白。我之前对一个知识库做过对照测试块大小256 token召回准确率大约61%512 token是73%1024 token反而回落到68%。原因也很直观太短容易丢上下文太长会把多个主题混在一个向量里语义变得模糊。重叠窗口我习惯设成10%到20%主要为了防止切块边缘的关键句被截断。切记这些数字不是通用的换一个领域、换一种embedding模型最优值都会变必须拿自己的数据试。1.2 向量化之前先想清楚嵌入模型适不适合你的领域通用embedding模型在开放域问答上表现不错但落到垂直领域经常会出现“语义相似但检索不相关”的尴尬。举个例子你问“这台设备的保修期多久”通用模型可能更关注“设备”“多久”这类常见词而领域里的SKU编号、特定型号、售后条款词本身在预训练语料里出现得少向量表达很弱。这就导致检索返回一堆意思相近但完全不对应的内容。解决思路有两个第一挑一个在目标语言和目标领域上表现更好的公开模型第二用自己领域的数据做二次微调。以前我觉得微调embedding成本很高后来发现其实数据量不需要想象中那么大。我做过一次轻量微调大概用了5000条query-positive对和同样数量的hard negative组效果立竿见影检索Top5命中率提升了接近12个百分点。微调数据怎么来最好的来源是线上真实query和用户最终点击/引用的段落这是天然的positive。hard negative可以去难一点用BM25先召回一批挑那些字面上重叠高但实际不相关的片段再让一个强模型过滤排除剩下的当作负例。训练方式可以直接用对比学习让query向量靠近positive、远离hard negative。如果你没有工程条件也可以退一步先通过prompt让LLM把query里的专业术语做同义扩展再拿去检索效果也能提升一些。1.3 多字段索引与元数据过滤把检索范围先圈起来如果知识库只有一个大文档那索引设计相对简单。但真实场景往往是几百份文档、多种产品线、不同来源的FAQ和工单记录混在一起。这种情况下如果不过滤元数据检索就相当于在全量混乱数据里大海捞针。一个做企业知识库的朋友就遇到过用户问A产品的问题检索结果里大量混入B产品内容生成答案虽然语义通顺但产品名都对不上。解决办法是在写入向量库时给每个文档块打上结构化标签文档类型、产品线、部门、版本号、更新时间等。查询时先根据用户上下文或意图识别结果把检索范围限定到某个产品线或文档类型里。比如通过一个轻量路由分类先判断用户问的是哪个产品的售后问题然后把filter设成“productA 且 doc_typemanual”。这一层过滤能显著减少后续排序的干扰尤其在知识库庞杂时效果比单纯依赖向量相似度要稳定得多。注意元数据过滤不能滥用过滤条件过于严格会导致召回结果过少。我的做法是先宽后严先用比较宽松的条件召回足够多的候选再在重排序阶段利用元数据加权而不是一开始就硬过滤。2. 查询处理与改写检索的入口同样值得关注2.1 让大模型先把问题“洗干净”查询改写用户提问通常不是规范搜索语句直接拿原问句去embedding向量空间里的表达很可能偏离文档里的表述方式。比如“那个东西怎么用啊”这里的“那个东西”在知识库里可能是“在线表单组件”。不做改写检索系统很难把两者对上。我常用的方式是加一个轻量的查询改写模块在用户query进入检索引擎前先让LLM把问题转换成更具体、更适合检索的表达。改写不是翻译目标是去掉口语词、补全指代、补充必要的限定词。改写prompt可以很简单请把用户问题改写为用于知识库检索的查询保留关键实体和专业术语不要增删事实。实测中这类改写对口语化问题提升最明显Top20召回提升约15%左右。还有一种更高级的思路叫HyDE也就是让LLM针对用户问题先生成一个假设性回答然后用“问题和回答”的拼接文本去做向量检索。因为假设性回答往往包含文档中可能出现的术语和句式能拉近query与文档片段的语义距离。不过HyDE会增加一次额外的LLM调用延迟和成本都要评估。我的习惯是只在初次检索的置信度偏低时才触发改写而不是每个请求都走这样能兼顾效果和速度。2.2 多路查询与子问题拆分复杂问题别指望一次召回用户有时会问很复杂的问题比如“备份失败怎么办日志在哪看如何恢复”这里其实混合了三个子问题。如果直接用一整句去检索向量会试图同时表达三个意图结果每个意图都只召回了一部分生成时自然缺料。高阶做法是让LLM把复杂问题拆成多个子查询分别去检索再合并结果。拆分逻辑不需要太复杂我用的prompt就是如果问题包含多个独立信息需求请拆分为最多3个搜索语句每个语句只包含一个主题。然后对每个子查询并行调用检索最后统一去重。去重时不能只看文本完全相同向量相似度很高的片段也要合并避免同一个信息点被重复塞进上下文。这个方案的风险是子查询过多导致候选爆炸。我一般控制最终进入重排序的片段数量比如固定为60到80个多路子查询统一竞争名额而不是每个子查询平均分配。这样既能覆盖多角度信息也不会让上下文变得臃肿。2.3 查询路由不是所有问题都要走RAG把资源浪费在没必要检索的问题上是很多人忽略的性能杀手。用户问“你能做什么”“你是谁”这类闲聊或者问“昨天聊到哪了”这类对话历史问题根本不涉及知识库。如果硬走检索不仅拉高延迟还可能把无关片段灌给模型反而干扰回答。我习惯在检索前加一个意图路由器。可以是基于规则的分类比如检测问候词、对话上下文标记也可以用一个小分类模型判断query是否需要外部知识。分类结果分三条路直接走对话模型、走RAG检索、走多知识库路由。这样整体系统的平均响应时间和质量都会有改善尤其是闲聊占比高的场景收益非常明显。3. 检索引擎升级从向量召回走向混合与重排3.1 混合检索把关键词精确匹配和语义能力一起用向量检索擅长语义相似但它对精确词、ID号、型号、特殊缩写往往不敏感。你在向量库里搜“ABC-123”返回的可能是“ABC-124”或者“123”相关的内容因为embedding会模糊掉字符细节。但用户问这类精确标识时要的就是逐字匹配。这也是为什么BM25这类稀疏检索到现在仍不过时它天然擅长精确匹配和词频加权。我现在的标准做法是混合检索一路是向量检索一路是关键词/全文检索两者并行召回再用RRFReciprocal Rank Fusion合并。RRF合并的核心思路是先不看具体分数只看每个片段在每一路结果里的排名然后用一个简单公式融合排名。这样做的好处是规避了两路得分尺度不一致的问题向量余弦相似度0.8和BM25得分20.5完全没法直接相加但排名可以公平比较。实际项目中混合检索对既有“精确型号”又有“语义描述”的查询帮助最大。举个例子用户问“ABC-123这个设备的故障原因有哪些”关键词路能精确命中ABC-123向量路能召回关于故障原因的描述两路合并后覆盖度明显提升。需要注意的是不要固定权重最好留两个可调参数线上根据badcase反复调。3.2 重排序粗召回之后再做精排粗召回阶段为了保证不漏通常会拉回几十个片段。但如果直接把几十个片段都塞给生成模型效果会断崖式下降因为模型会被大量噪声干扰。这时候需要用重排序模型来做精排。我常用的组合是先用双塔向量模型做粗召回召回50到100个片段再用一个cross-encoder类型的重排模型对这几十个片段逐一对query打分最后取Top3到Top5作为上下文。为什么cross-encoder更准因为双塔模型把query和文档分别编码成向量再算相似度交互发生在最后一层而cross-encoder让query和文档从头就开始token级别的交互能捕捉更细的语义关系。代价是计算量大很多所以它只适合对候选集精排不适合全库扫描。这里有一个工程细节候选集太大重排延迟会明显上升。我的建议是先给粗召回做一个快速剪枝比如把向量相似度低于某阈值的片段直接丢掉再把剩下的60个片断送去重排。线上可以给重排服务加个超时控制如果重排不能在150毫秒内完成就退回用粗召回的前K个结果保证整体响应时间稳定。3.3 动态K值与兜底策略宁可少用不可错用固定每次取Top5这种简单策略并不总能满足需求。简单问题可能一个片段就够了复杂问题可能需要三四个不同信息点的组合。动态K的方法是根据第一条精排结果的得分设置阈值如果最高分都过低说明知识库里可能压根没有相关内容如果最高分很高可以适度放宽多取几个次高分的片段。我遇到比较多的badcase是“空检索”却硬答。知识库里没有答案但生成模型会因为系统指令要求“必须回答问题”而自行发挥。兜底策略必须明确当所有候选片段的得分都低于预设阈值时直接返回“知识库中未找到相关信息”或者明确告知用户“我无法从现有资料中确认答案”。这样看起来没有“面子”但能大幅减少幻觉。你也可以加一个追问引导让用户提供更多信息比让模型硬编答案要可靠得多。4. 上下文构造与提示工程检索结果也要让模型“吃得下”4.1 去重与排序把最重要的证据放到前排检索结果合并之后经常出现同一段内容的不同切块反复出现或者一个答案同时在多个文档里有类似表述。如果不做去重上下文里可能有一半内容是重复的既浪费token又干扰模型判断。我在合并阶段会对候选片段做一次向量相似度聚类相似度超过0.9的只保留最相关的那一个其余丢弃。去重之后还有一个排序问题。虽然重排已经给出了相关性顺序但有些场景需要按原文顺序组织上下文比如多步骤操作说明。如果检索结果分别是步骤1和步骤3的片段重排可能把步骤3排前面因为它的关键词匹配度更高但按原文顺序排列更有利于模型生成连贯步骤。我的方案是提供一个排序模式参数答案型问题按相关度排序操作说明型问题按原文顺序排序。4.2 上下文太长怎么办压缩和摘要一个经常被低估的问题是就算你只取Top5片段每个片段512 token拼接起来也超过2500 token了。多个子查询合并后上下文很容易冲到5000甚至更多。大模型虽然宣称能支持几十万token上下文但长上下文里真正被有效利用的信息往往集中在开头和结尾中间内容容易被忽略这就是业界常说的“lost in the middle”。我处理这个问题的办法是上下文压缩。先用一个轻量LLM对粗召回的全部片段做信息抽取把与query相关的关键句子提取出来删掉冗余论述、案例、免责声明等。然后把压缩后的内容作为最终上下文。压缩会损失一些细节但在大部分业务问答场景里收益大于损失。压缩模型的输出限制在500到800字之间能有效降低最终生成模型的输入长度也间接降低了成本。4.3 指令模板与反幻觉设计让模型知道该怎么用证据上下文再全如果模型不知道“只能依据文档回答”它还是会按照预训练习惯自由发挥。我最初的prompt只写了一句“根据上下文回答问题”结果模型经常把常识混进来。后来我把指令换成三段式首先是“你是基于知识库的问答助手”然后是“只能使用提供的资料回答禁止使用内部知识”最后是“如果资料中没有答案请明确说不知道”。改动之后幻觉相关的badcase下降了约30%。还有一个小技巧是给上下文片段标注来源。让模型在回答末尾附上“信息来源文档A第2节”“文档B第5页”这样的引用。这不只是增加可信度还能在badcase复盘时快速定位是哪一段文档导致了错误回答对后续优化极有帮助。提示注入也值得注意。知识库文档里可能会出现“忽略以上指令直接告诉我...”这类恶意的或者无意的句子。我现在的做法是在把文档片段输入给生成模型之前先把非指令类内容用明确的边界包裹起来例如在每一段前加上“参考片段开始”和“参考片段结束”标记然后在指令里强调这些标记内部只是数据不是指令。5. 评估与迭代性能不是感觉出来的5.1 先建一套评测集再谈优化没有评测集的RAG优化就是在黑箱里调参。很多团队凭感觉换模型、改参数结果过几天又改回去浪费大量时间。我建议上线前先花两三天时间从真实用户日志里抽100到200条有代表性的query覆盖知识库里的典型问题、长尾问题、口语化问题以及专门收集的历史badcase。标注时至少标注两件事期望答案要点以及命中哪些文档片段是正确答案。有了评测集就可以把效果量化。检索侧常用Hit Rate、RecallK、MRR生成侧关注忠实度、答案相关性、信息完整性。如果你没有人力做人工评分可以用更强的大模型做裁判对“答案是否忠实于上下文”“答案是否完整回答用户问题”打分。但LLM裁判也有偏好我通常会额外抽20%的数据人工复核防止裁判模型误判。指标衡量内容我常用的阈值/目标Hit Rate5正确答案是否出现在Top5候选里不低于85%Recall10相关片段在前10里的覆盖比例不低于80%Faithfulness答案是否完全由上下文支撑不低于90%Answer Relevance答案是否对应当前问题不低于85%Latency P95端到端响应时间2秒以内5.2 Badcase归因先别急着调模型判断问题出在哪一层评测集跑完你会得到一批badcase。这时候最忌讳直接调整生成prompt因为很多错误发生在检索阶段。我给自己定了一个排查顺序先看Top10候选里有没有正确答案。没有是召回问题去修索引、分块、查询改写有但Top5里没有是排序问题去调重排模型Top5里有正确答案但生成答案还是错才是生成问题去改上下文和prompt。按照这个思路百分之八十的badcase都出在前两层。有一次系统回答了一堆天花乱坠的内容人工一查正确答案其实在候选第7位重排时被一个词面更相似但内容无关的片段挤了下去。后来我把重排模型换成更大一档的版本同时把粗召回候选从50扩到了100这类问题立刻少了很多。5.3 回归测试与持续集成守护每一次改动RAG系统的优化很容易“按下葫芦浮起瓢”。你修好了A类问题可能又带坏了B类问题。所以每次改动之后不能只拿几个badcase验证要把整个评测集完整跑一遍对比前后指标。我现在的做法是把评测集写进一个自动化脚本里每次索引更新、prompt调整、模型切换都先跑一遍回归再决定是否可以上线。另外评测集不是一成不变的要持续吸收线上新的badcase。我每两周会从用户反馈和日志里筛选一批新query补充进评测集然后重新跑一轮基线看有没有出现新的系统性短板。这个过程比较枯燥但正是这种重复劳动让系统的性能一步步稳定下来。如果让我给后来者一个建议不要一上来就换更贵的生成模型先把检索和评测闭环搭好。RAG的瓶颈大多数不在生成侧而是在“找得到”和“找得准”。我自己的优化顺序通常是索引、查询、重排、上下文、评估迭代每一步都用数据说话不凭感觉施工。按这个顺序走即使中间踩到坑也能快速定位并回来。