去年在一个医学 AI 写作项目里,我第一次认真用 RAG 解决生产问题。团队需要让模型引用真实的医学文献来写综述,而不是一本正经地编造 DOI 号和论文标题——大模型真的会这么干,而且编得像模像样,不仔细核查根本看不出来。
RAG 上线之后,幻觉问题确实压下去了。模型开始老老实实地从我们灌进去的文献库里找引用,回答有了出处,准确率肉眼可见地提升。团队很高兴,觉得这事儿算是搞定了。
但没过多久,新的麻烦就来了。
先说 RAG 到底解决了什么
RAG 解决的核心问题其实就三个,每个都很实际。
第一个是知识截止日期。大模型的训练数据有时间边界,你问它上周发布的新政策,它不知道。这在很多业务场景里是硬伤——你总不能每出一个新规范就重新训练一次模型。
第二个是幻觉。这个问题在专业领域尤其要命。我见过模型编造药物相互作用的描述,格式完美、逻辑自洽,就是这个结论压根没有文献支持。如果下游有人拿着这个"结论"去做临床决策,后果不堪设想。RAG 让模型的回答有了依据——知识库里有就说,没有就闭嘴,至少方向对了。
第三个是私有数据。公司内部文档、项目记录、客户资料,这些东西从来没出现在任何模型的训练集里。你不喂给它,它永远不知道。
这三个问题,RAG 的解法都很直觉:别让模型硬背,让它开卷考试。问题来了先去知识库里查,查到相关内容再回答。听起来简单,原理也确实不复杂。
但"原理简单"和"做好"之间,隔着一条很深的沟。
第一个坑:文档分块策略,决定了 RAG 的上限
RAG 系统里有个看起来不起眼的环节叫"分块"——把文档切成小段存进向量数据库。这个环节我一开始没当回事,随手设了个固定长度,每 500 字切一刀,跑起来再说。
结果很快就翻车了。
某个项目里,我们把几十本建筑规范灌进知识库。用户问"高层住宅疏散走廊最小净宽度是多少",系统检索出来的文本块,刚好把那条规范从中间切断了——前半段在一个块里,后半段在另一个块里,两个块的相似度排名都不够靠前,结果模型拿到的上下文残缺不全,给了个模棱两可的回答。
后来改成按条款切分,每个条款作为独立的块,准确率从 78% 跳到了 91%。同样的数据,同样的模型,换个切法,效果天差地别。
这件事让我意识到一个判断:RAG 系统的瓶颈,往往不在模型,而在数据工程。你的文档清洗干不干净、分块策略合不合理、Embedding 模型和你的领域是不是匹配——这些"脏活"决定了系统的上限。很多团队把精力花在调模型参数上,其实方向搞反了。
第二个坑:向量检索的语义鸿沟与复杂查询
向量检索听起来很美好——把文本转成向量,用余弦相似度找最近的邻居,语义匹配,不依赖关键词。但实际用起来,你会发现语义匹配远没有想象中那么靠谱。
最典型的问题是语义鸿沟。用户说"怎么退货",文档里写的是"商品退换货流程及注意事项"。人看一眼就知道是同一件事,但向量检索未必能匹配上——这取决于你用的 Embedding 模型在这个领域的表现。通用 Embedding 模型在垂直领域经常打折扣,比如法律文本里"不当得利"和"无因管理"在法律语境下强相关,但通用模型算出的向量距离可能很远。
然后是复杂查询的问题。用户问"上个季度华东区哪个产品卖得最好"——这里面包含时间限定、地区限定、排序比较,一次检索根本搞不定。这就是为什么后来出现了 Agentic RAG:在检索流程里加一个 Agent,让它像研究员一样拆解问题、多轮检索、评估结果质量。我测试过,复杂查询的准确率从 60% 出头提升到了 82% 左右。
但 Agentic RAG 又引入了新的复杂性——Agent 的行为不完全可控,有时候它会过度拆解一个简单问题,反而把事情搞复杂。检索链路越长,出错的环节越多,调试难度指数级上升。
这就是 RAG 让我最头疼的地方:每解决一个问题,就冒出两个新问题。
第三个坑:RAG 系统的评估与持续迭代
传统软件的测试逻辑很清晰——给定输入,期望输出,对比结果。RAG 系统不是这样的。
同一个问题,检索到不同的文本块组合,模型可能给出不同但都"说得过去"的回答。你怎么判断哪个更好?准确率只是一个维度,还有完整性、相关性、有没有遗漏关键信息。这些东西很难用自动化指标衡量,人工评估又贵又慢。
更麻烦的是,RAG 系统的效果跟数据强相关。你在测试集上跑到 90% 的准确率,换一批用户的真实问题,可能直接掉到 70%。因为用户的提问方式千奇百怪,你的测试集永远覆盖不全。
我现在的做法是:上线前用标注数据做基准测试,上线后持续收集用户的"踩空"案例(模型回答了"根据已有资料无法回答"或者用户给了差评的),定期用这些真实 bad case 来迭代。没有一劳永逸的评估方案,只有持续迭代的过程。
容易踩的坑:RAG 和微调的边界
还有一个我踩过的坑值得说。
在那个医学项目早期,团队遇到一个问题:模型输出的文献综述格式不对,术语用法也不够专业。我们的第一反应是"知识库里的参考样本不够多",于是拼命往知识库里灌更多高质量文献,指望 RAG 能让模型学会正确的写法。
折腾了两周,效果改善有限。后来换了个思路,用几百条标注数据做了一轮 LoRA 微调,专门教模型怎么写符合学术规范的综述段落。微调之后再配合 RAG 提供文献引用,效果立刻上了一个台阶。
这件事的教训是:RAG 解决的是"知道什么"的问题,微调解决的是"怎么说"的问题。 把格式和风格的问题扔给 RAG,就像指望图书馆能教你写作——它能给你参考资料,但教不会你怎么组织语言。分清楚哪个问题用哪个工具,比把一个工具用到极致更重要。
知识库的数据治理才是真正的硬仗
做了几个 RAG 项目之后,我越来越觉得,技术方案本身不是最难的部分。最难的是数据治理。
你的知识库里有几千份文档,谁来保证它们是最新版本?旧版文档没清理干净,模型检索到过时信息给了错误回答,这个责任算谁的?不同部门的文档格式五花八门,有的是 PDF 扫描件,有的是 Word,有的是网页截图——你怎么保证解析质量?
技术上,一个 RAG 系统可以一周搭起来。但建立一套靠谱的知识库运营机制——谁上传、谁审核、多久更新、怎么淘汰过时内容——这件事可能要几个月,而且永远没有"完成"的那一天。
我的判断:80% 的场景 RAG 够用
RAG 不是银弹,但它是目前让大模型在企业场景落地最务实的方案。80% 的场景,RAG 够用。剩下 20% 的场景,需要 RAG 加微调,或者更重的方案比如 GraphRAG。
但我想对正在做 RAG 项目的人说一句:不要低估工程复杂度。教程会让你觉得这事儿很简单——切块、向量化、检索、生成,四步搞定。实际落地的时候,你会发现 80% 的时间花在数据清洗、分块调优、评估迭代这些"不性感"的环节上。
这些脏活决定了你的系统是 demo 还是产品。