RAG准确率卡在73%？问题不在生成，在检索给错了上下文
上周我们团队在做一个内部知识库问答系统，准确率死活卡在73%。老板跑来问我怎么回事，我把日志调出来一看——好家伙，检索返回的前5个文档里，有3个跟用户问的东西完全不沾边。但模型是真的敬业，硬是拿这些不相关的上下文编了一段像模像样的回答，老板边听边点头，还挺满意。
就那一刻，我突然想明白一个事。
RAG系统里最可怕的不是模型瞎编，而是它编得有理有据，连你自己都差点信了。
那个让我失眠两周的“检索幻觉”
去年Q3，我带着团队给一个金融客户做财报分析助手。需求听起来特简单：上传PDF财报，问什么答什么。就CRUD的活儿嘛，我当时是这么想的。
第一版上线那天，客户在群里发来个测试问题：“我们Q3的毛利率是多少？”系统秒回：“根据财报数据，Q3毛利率为42.3%。”客户回了个大拇指表情。
我正得意呢。结果半小时后，客户又发来一条：“我翻遍了整个财报，根本没找到42.3%这个数字。你们系统是怎么算出来的？”
后背瞬间一凉。
翻日志才发现，检索模块从财报里抽出了几段关于“毛利”的文字，但全是Q2的数据。模型拿到这些上下文之后，自动推断“Q3应该也差不多吧”，然后编了个看起来特合理的数字。更讽刺的是，编得还挺准——真实值是41.8%。
等等，这里我要更正一下。准确说不是“编得准”，是蒙得巧。因为后来我们发现，换一份财报再测，它能给你蒙出个完全离谱的数。
这就是RAG系统里最典型的“检索质量塌方”：检索给错了上下文，生成模型却把它包装成了正确答案。而且包装得特别自信。
后来我们加了一堆验证逻辑，又调了检索参数，准确率勉强提到85%。但那次经历让我彻底明白一件事：在RAG架构里，检索和生成根本不是两个独立环节，它俩是一对互相甩锅又互相背锅的冤家。
三个让我重新理解RAG的案例
案例一：Chunk Size的蝴蝶效应
去年帮一个电商团队做商品描述生成，我们纠结了一个特别基础的问题：文档切片到底切多大？
先用512 token试了一周。检索速度倒是挺快，但用户问“这款手机的续航怎么样”的时候，返回的片段全是“大容量电池”“持久续航”这种泛泛的营销话术。模型拿不到具体参数，就开始自由发挥——“续航长达两天”，实际上官方数据是18小时。
后来改成256 token，检索精度上来了，新问题也跟着来了。用户问“这款手机和友商X相比哪个好”，因为切片太小，检索只能命中其中一个产品的描述，模型完全不知道友商X是什么东西，然后开始一本正经地对比两个它根本不了解的产品。
嗯...这个其实挺难搞的。
最后我们搞了个动态切片加重叠窗口的方案：技术参数类内容用256 token精确切，描述性内容用512 token保留上下文，相邻切片之间保留50到100 token的重叠区。检索准确率从68%提到了89%，但工程复杂度直接翻倍。我记得当时用的是LangChain 0.1.16，那个版本的Document Transformer对重叠窗口的支持还不太完善，我们改了三天源码才搞定。
案例二：Embedding模型选型翻车
很多人觉得Embedding模型越新越好，我实实在在地踩过这个坑。
今年初做法律文书检索系统，我图省事直接上了当时最新的BGE-M3。测试的时候发现一个诡异现象：用户问“劳动合同解除条件”，检索返回的前三条里，有一条是关于“劳务派遣协议终止”的。语义上确实相关，但在法律实务里这完全是两码事——我专门问过合作律师，他说这俩概念搞混了是要出事的。
后来换了针对法律领域微调过的BERT模型，准确率立刻提了12个百分点。但代价也来了：推理速度慢了大概40%。最后不得不在检索流程里加了个Rerank环节——先用通用模型粗筛，再用领域模型精排。我记得用的是Cohere的Rerank API，v3版本，贵是真贵，但效果确实好。
这个架构现在看起来挺合理的，但当时为了说服CTO多花这40%的推理成本，我写了整整两页A4纸的ROI分析，还拉上了法务总监一起argue。大概花了两周才批下来。
案例三：当检索太“好”反而坏事
说个反直觉的发现。我觉得这个是我做过这么多RAG项目里，最让我重新思考问题的一个。
有次给医疗问答系统做优化，我们把检索准确率从80%提到了95%，心想这下稳了。结果用户满意度反而下降了。
查了半天才找到原因：检索太精准，返回的全是高度专业化的医学文献原文。模型拿到这些内容后，生成的答案里全是“糖皮质激素”“血管紧张素转换酶抑制剂”这种术语，普通用户根本看不懂。
之前检索质量差一些的时候，模型反而会自己“翻译”成通俗语言，用户觉得挺好懂的。
这就很讽刺了。检索质量的衡量标准，可能根本不是“准不准”，而是“对生成有没有用”。这两个指标在很多时候是矛盾的。
我现在用的实战策略
踩了这么多坑之后，我总结了一套土办法。不一定是最优解，但在我们团队跑下来还算靠谱：
1. 检索质量用“生成友好度”来衡量
传统的Recall、Precision这些指标当然要看，但最终要落到一个问题上：模型用这些上下文，能生成正确答案的概率是多少？我们现在每个检索实验都会跑一遍端到端评测，而不是只看检索本身的指标。这个流程大概要跑40分钟，但值。
2. 给检索结果打“可信度标签”
在检索返回的每个文档片段上，我们会附加一个信号：精确匹配、语义相似、还是弱相关。生成模型拿到这个标签之后，会调整自己的“编造倾向”——精确匹配的时候就大胆用原文，弱相关的时候就主动说“我不太确定”。这个思路我是从Anthropic的System Prompt设计里学来的，具体实现上我们用了Langfuse来追踪标签的准确率。
3. 故意构造“对抗样本”来测
每次上线前，我们会专门构造一批“检索一定会出错”的问题。比如问财报里根本不存在的数字，问跨文档才能回答的问题。就看模型在这些情况下是老实说不知道，还是继续硬编。
2024年11月的那次测试，我们发现模型在12%的对抗样本上还是会“自信地瞎编”，后来在Prompt里加了一句“如果你不确定，请明确说明”，比例才降到3%。
4. 检索失败时的降级策略
这个是最容易被忽略的。我现在要求所有RAG系统必须有“检索置信度低于阈值”时的兜底逻辑——要么拒答，要么明确告诉用户“以下回答基于不完整信息，仅供参考”。阈值我们设的是0.65，这个数字是我拍脑袋定的，后来AB测试发现0.7更好一点，但差别不大。
说到底，RAG系统里检索和生成的博弈，本质上是个信息传递问题。检索说“我找到了这些”，生成说“那我根据这些来回答”。但检索不会告诉生成它有多不确定，生成也不会告诉检索它需要什么样的信息。
我现在带团队做RAG项目，第一件事不是选模型，不是搭架构，而是先拉上产品和业务方，把一个问题聊透：当检索出错的时候，你希望系统是宁可不说，还是宁可说错？
这个问题没有标准答案。医疗场景和电商场景的容忍度完全不同。但必须在一开始就想清楚。
你们在做RAG系统的时候，遇到过检索明明很准但生成结果依然翻车的情况吗？或者反过来，检索一塌糊涂但模型硬是猜对了？评论区聊聊，我特别想听听你们踩过的坑。最近在看字节的豆包和Kimi的RAG方案，感觉大家都在往多路召回上卷，你们觉得这方向靠谱吗？
#RAG #大模型应用 #检索增强生成 #AI工程化 #技术管理
读者评论 4