去年冬天，我帮一家医疗信息公司看他们的”智能问答系统”。
演示环节，产品经理点开一个对话框，输入”布洛芬的禁忌人群有哪些”，系统秒回了一段工整的答案——看起来一切完美。
但我随手敲了个问题：”上周三下午急诊科那个胸痛病人的后续处理建议是什么？”
系统卡了12秒，吐出一段和问题没半毛钱关系的科普文字。产品经理的脸瞬间僵了。
这个场景在过去两年里，我在不下十家公司见过。大家热衷于”调个接口、搭个RAG、跑通一个Demo”，然后兴高采烈地准备上线。但一旦面对真实的业务数据、真实的用户提问、真实的高并发压力，整个系统就像纸糊的灯笼——一戳就破。
为什么？因为RAG从来不是一个”调接口”的问题，它是一个”建系统”的问题。
第一层：RAG落地最大的坑——”检索即答案”的幻觉
很多人对RAG的理解停在”把文档切一切、塞进向量库、问个问题就检索、检索完就喂给大模型出答案”。
这套流程在技术演示里百试百灵，但在企业场景里，漏洞多得像筛子。
举个真实的例子。一家律所的知识库里有上万份合同模板和判例文书，他们做了一个RAG系统让律师快速查案例。结果律师问”2023年北京地区涉及竞业限制的劳动争议案件中，员工胜诉的比例大概是多少”，系统检索到的top 3文档中，有两份是2020年的，一份是上海地区的。但系统不管，把这三份内容揉在一起生成了一段”看似专业”的回复。要不是律师经验丰富一眼看穿了问题，这份答案差点被写进庭审材料。
问题出在哪儿？检索阶段对”语义相似”的痴迷，遮蔽了”业务相关”的判断。 两篇文档在向量空间里挨得近，不代表它们在业务逻辑上应该被同时引用。
行业里有个广为流传的结论：RAG系统80%的错误，根源在检索阶段——要么检索漏了关键信息，要么检索到了错误信息，要么检索到的信息虽然相关但在时间、地域、业务范围上根本不适用。
解决方案不是换个更强的embedding模型，而是在检索链路里嵌入业务逻辑的”护栏”——时间衰减因子（新鲜文档权重更高）、业务标签过滤（只检索同品类/同区域文档）、层级化索引结构（先筛品类再查语义）。这套工程架构跑通之后，准确率能从Demo阶段的60%-70%拉到真实业务场景的85%以上。
但绝大多数团队连第一步”搞清楚自己的检索到底在检索什么”都没做到，就急着去调模型参数了。
第二层：微调不是”万能药”，微调是”手术刀”
很多人被”微调”这个词唬住了，觉得那是大厂算法工程师才能碰的东西。但另一群人恰恰相反——他们把微调当成了包治百病的灵丹妙药：RAG效果不好？微调一下。回答不够专业？微调一下。用户反馈不满意？微调一下。
这两种极端态度，其实都源自对微调本质的误解。
微调不是让模型”学会新知识” 。那个知识已经在预训练阶段塞进去了，微调做的是另一件事：让模型学会”用你的方式说话”。
我见过一个做金融投研RAG的团队，他们面临的问题很典型：底层的开源模型回答问题本身是准确的，但表述方式太”通用”了——它不会用投研报告的语气、不会在回答中自然地引用数据来源、不会按照”观点-论据-风险提示”的专业结构来组织语言。
他们花了三周时间，用5000条高质量的投研问答对做了一轮微调。效果立竿见影：回答的专业感、结构感、可信度都上了一个台阶，用户满意度从62%跳到了89%。
但另一个做客服系统的团队就没这么幸运了。他们花了一个月时间，用十几万条对话日志做微调，结果回答的”温度”确实是降下来了，不再像以前那样啰嗦，但事实性准确率反而掉了3个百分点。
为什么？因为微调的数据质量不够”干净”。客服对话日志里本身就包含了不少模糊回答、推诿话术和不完整的结论，模型在微调过程中”学坏了”。
微调的核心原则只有一条：你喂进去的是什么质量，模型吐出来的就是什么水平。 数据清洗、标注规范、测试集验证——这些”脏活累活”占到微调工作量的70%以上，真正跑训练的那几个小时反而是最省心的。
第三层：从”RAG”到”RAG+微调”——两条腿走路才稳
行业里长期有个争论：到底选RAG还是选微调？
这个争论本身就问错了问题。
RAG和微调不是二选一，它们解决的是不同层面的问题。 RAG解决的是”外部知识如何实时获取和引用”，微调解决的是”模型的表达风格和逻辑结构如何适配特定场景”。
一个真正能落地的企业级RAG系统，两条腿都得走。
RAG让模型”知道该查什么”——通过精心设计的检索链路、多级索引、业务规则过滤，保证每一次检索带回来的都是当下场景下最相关、最权威的信息片段。
微调让模型”知道该怎么答”——通过高质量的指令微调（instruction tuning）和偏好对齐（preference tuning），保证模型用你期望的专业语气、逻辑结构、表达习惯来组织答案，而不是直接复制粘贴检索片段。
这两者组合起来，才能在真实业务场景中跑出稳定的、可被用户信任的问答体验。缺了RAG，模型会”瞎编”；缺了微调，模型会”答对但不像你”。
所以回到最开始那个医疗问答系统的例子。
后来他们怎么改的？不是换模型。是重新设计了检索链路——加入科室标签、时间窗口、病人ID的联合过滤；是重构了召回策略——不只看语义相似度，还叠加了关键实体匹配和业务规则权重；是做了针对医疗报告风格的三轮微调——让模型学会用医生的语言习惯来组织回答，而不是照搬科普口吻。
花了大概六周，系统重新上线。这次再问”急诊胸痛病人的后续处理”，回答的准确度和可用性终于对得起公司的投入了。
你看，RAG落地从来不是”选哪个模型”的问题，是”怎么把检索、生成、业务规则、用户反馈串成一条稳定流水线”的工程问题。
能跑通的Demo遍地都是，能跑稳的生产系统百里挑一。而真正值钱的，从来都是后者。
