作者：先说一个可能不太中听的判断：多数 RAG 项目答案不准，把模型从开源小模型换成旗舰大模型，几乎不会有改善。因为 RAG 准确率优化这件事，八成功夫在检索侧——让系统找对资料，而不是让模型更聪明。下面七个手段，是我们做过十几个项目之后按投入产出比排出来的，前三个做完，命中率的改善通常就非常明显了。
先分清：不准的锅在哪一层
拿到 bad case 先别急着调提示词。把一次问答的中间过程打开看：资料根本没被检索到，是检索的锅；资料检到了但被切碎，是切分的锅；资料对、答案还是错，才轮到生成侧。三口锅不分清，优化就是盲人摸象。我们评审别人的项目时，第一件事永远是看召回列表，而不是看答案。有个速判法：把检索到的资料直接拿给人看，人能答对而AI答错，才是生成侧的问题；人都答不对，就别折腾模型了。
检索侧的四个手段
第一，切分要有语义边界。按固定字数硬切的年代该翻篇了，按章节、条款、问答对来切，一段话就是一个完整意思。经验值是每段两三百字，宁可多切几刀，也别让两个话题挤在一段里。进阶做法是父子块：检索时用小段，命中后把它所在的大段整段喂给模型，既搜得准，又读得全。
第二，混合检索。纯向量检索对型号、编号、专有名词这类精确词很不敏感，“RX-3200”和“RX-3020”在向量空间里近得像邻居。工程师搜故障码、财务搜科目编号，撞的都是这种墙。向量加关键词的双路检索再合并结果，这类问题立刻缓解。
第三，加重排。初检出二十条候选，用重排模型精挑五条再交给大模型。这一步的调用成本每月几十到几百元（以2026年市场行情为参考），见效快，属于“加两行配置”级别的改造。
第四，元数据过滤。给文档打上部门、产品线、年份的标签，提问时先按标签缩小范围再检索。用户问A产品的售后政策，就别让B产品的文档混进候选。时间也是常打的标签——问“最新的报销标准”，就得先滤掉前年的旧文件。
生成侧的两个手段
第五，强制引用出处。要求答案后面必须带资料来源，模型有依据可循，编造的空间就被压住了；用户能自己核对，信任度反而上升。引用还有个副作用：倒逼你把资料整理清楚，因为用户真的会点开看。
第六，给“不知道”留出口。提示词里明确写：资料里没有的，直接说没有，不许猜。很多答非所问，本质是系统被逼着每问必答。宁可让AI说一句“这个问题我查不到，帮你转人工”，也别让它一本正经地编。这块展开讲内容不少，之前写过治理答非所问的专门文章，可以对照着改。
容易被忽略的第七个：文档保鲜
检索和生成都调好了，文档本身过期了，前面全白搭。停产产品的旧手册、废止的制度文件还躺在知识库里，AI会拿着旧答案一本正经地回答，用户还挑不出毛病——因为话术没破绽，只是内容死了。我们见过一个项目，知识库里躺着三版价格表，AI看心情挑一版答，客户三天内收到三个报价，追到最后发现是旧文档没下架。下架机制要跟更新机制一起建，这件事没有技术难度，难的是有人负责。
改完能到什么水平
按我们手上的项目经验，上述手段做完，常见结果是命中准确率从五六成提到八成以上，剩下的一两成靠运营期的bad case回流慢慢磨。如果你的项目正卡在这一两成里，换个思路：先看检索中间结果，再动生成，顺序别反。另外改一版测一版，别攒一把改完才测——多项改动同时上线，好了不知道谢谁，坏了不知道怪谁。顺带把微调还是RAG的选择想清楚，别在错误的路线上做优化。
遇到怎么调都上不去的项目，欢迎把几个典型的失败问答发到联系我们，附上当时的检索结果更好——看到中间过程，我们基本能指出问题出在哪一层。