降低幻觉的武器库RAG 不是唯一解微调什么时候该上作者利威尔xu | CSDN 专栏《RAG 保姆级实战从原理到落地》前言在这个专栏系列第一篇《RAG入门》里咱聊了大模型为什么会胡说以及 RAG 是怎么靠检索真实资料、约束生成空间来降低幻觉的。但当时留了个钩子——RAG 不是唯一解它也不是 100% 靠谱。这一篇咱把这个问题彻底掰开来讲。除了 RAG还有哪些手段能降幻觉Prompt Engineering 行不行微调行不行工具调用行不行什么时候该用谁它们各自的局限在哪如果你正在准备面试这些问题几乎是必问如果你是正在做 AI 落地这更是必须想清楚的问题。咱先说结论这几种手段不是替代关系是互补关系。每个都有自己的主场没有哪个能包打天下。一、Prompt Engineering给厨师更详细的指令咱先说最轻量的——Prompt Engineering中文叫提示词工程。你有没有遇到过这种情况问大模型同一个问题换了个问法答案质量完全不一样有时候加上请一步一步思考它就不胡编了加上如果不确定就说不知道它就收敛了。这就是 Prompt Engineering 在起作用。说白了Prompt Engineering 就是给厨师更详细的指令。你告诉厨师这道菜要少盐、要辣、不要放香菜。厨师收到指令做菜的方向就定了而不是凭自己感觉乱发挥。如图提示词工程有很多种这里不详细介绍感兴趣的话可以在我主页查看相关知识。具体怎么用几个常用技巧——最常用的是角色设定告诉模型你是一个有10年经验的后端工程师它回答技术问题的语气和专业度就会不一样。这相当于给厨师定了身份他是粤菜师傅还是川菜师傅做出来的菜风格就不一样。再一个是输出格式约束告诉模型用 JSON 格式回答包含 title 和 content 两个字段。它输出的结构就固定了没那么多自由发挥的空间。你说白了就是给它划了个框它只能在框里蹦跶。还有个技巧叫 Chain-of-Thought引导模型先思考再回答比如先问你觉得这个问题该怎么分析让它把推理过程说出来最后再给结论。推理过程一出模型自己就会纠错胡编的概率下降。但 Prompt Engineering 的局限也很明显它管的是怎么问管不了模型没见过什么。厨师厨艺再好你给他一道他从来没见过的食材他也不知道怎么处理。模型也一样你用 Prompt 告诉它认真回答、不要胡编它会努力表现好一点但遇到私有知识、遇到它训练数据里压根没有的东西它还是得编。如图平时在使用Ai时写提示词也可以遵循这个模版。面试官可能追问Prompt Engineering 能根治幻觉吗答不能。Prompt Engineering 是治标不治本。它能优化提问方式、约束输出格式、引导推理过程但它没办法凭空给模型注入它不知道的知识。幻觉的根本原因是模型在不知道的时候按概率生成答案Prompt 治不了这个病根只能缓解症状。二、微调让厨师回炉培训如果说 Prompt Engineering 是给厨师更详细的指令那微调Fine-tuning就是让厨师重新回炉培训把菜谱背进脑子里。微调是在已经预训练好的大模型基础上用特定领域的数据再做一轮训练。训练完之后模型的肌肉记忆就变了——它看到类似的 prompt反应就不一样了。举个例子。你想让模型回复客服消息时更温和专业你就拿大量用户投诉专业客服回复的数据对去微调它。训练完之后你再问它问题它回复的语气就会不自觉地更专业。但这里有个关键认知很多人搞错了咱得专门花点篇幅把这个坑踩清楚微调擅长改变行为、风格、输出格式但不擅长注入事实性知识。你可能会说不对啊微调不就是让模型学新知识吗说真还真不完全是。微调能让模型记住一些模式——比如什么场景该用什么语气、什么领域该用什么术语。但这种记忆跟人的肌肉记忆一样会遗忘、会混淆、更新成本极高。第一权重记忆会遗忘。大模型的知识不是存在一个叫知识库的地方而是分布式存在整个模型权重里的。你微调一批新知识进去原有的知识可能会被稀释或者干扰。就像你让厨师学做川菜结果他之前会的粤菜手艺变生疏了。再一个更新成本高。RAG 那边知识库要更新直接改文档就行微调要更新得重新跑一轮训练。训练一次大模型要多少 GPU 、多少时间、多少成本你搜一下就知道。这不是不能做是代价很大不能频繁做。还有个麻烦是说不清知识存在哪。RAG 检索到一段资料你知道答案是从哪篇文档里来的。微调之后模型记住了某个知识你问它这个知识从哪来的它说不清你也说不清。不可解释、不可溯源在需要严谨的场景里是个大麻烦。所以回到厨师那个比喻微调是让厨师把菜谱背进脑子里但背得不全、背完会忘、还说不清背了哪道菜。你让厨师记住遇到粤菜客人要多放盐他可能遇到川菜客人也下意识多放盐因为他只是背了规则没真正理解。为什么放这段代码让读者看到微调的数据格式理解它学的是模式不是事实。下面是微调训练数据的 JSON 格式示例[ { instruction: 你是一个客服助手语气要专业温和。, input: 用户投诉订单三天了还没送到。, output: 非常抱歉给您带来不便您的订单正在加急处理预计明天送达。请问还有什么可以帮您的吗 }, { instruction: 你是一个客服助手语气要专业温和。, input: 用户询问退款多久到账, output: 您好退款一般在1-3个工作日内原路返回请您耐心等待 } ]这段代码在干嘛每一条数据就是一次看到这种输入应该这样回答的训练样本。模型从大量这样的样本里学行为模式——什么场景该用什么语气、什么情况该怎么回复。它学的是说话方式不是背某条具体知识。为了代码清晰这里省略了常规的错误处理和相关逻辑实际生产代码中务必加if err ! nil判断。面试官可能追问微调能不能注入新知识答能但效果有限。微调能让模型学到一些领域特定的模式、风格、术语但注入事实性知识不是它的强项原因刚才说了三个记忆会遗忘、更新成本高、不可溯源。如果你的核心需求是让模型知道一批新事实比如产品手册、公司制度用 RAG 比微调合适得多。三、工具调用让厨师打电话问供应商第三种手段是工具调用Tool Use。你可能已经在 Agent 那篇见过这个词了——它让大模型能够在回答之前先去调用外部工具把实时信息拉进来。比喻一下Prompt Engineering 是给厨师更详细的指令微调是让厨师回炉培训那工具调用就是让厨师在做饭之前先打个电话问供应商——现在有没有这种食材、价格多少、最新的配料表是什么。工具调用解决的是模型的信息实时性问题。RAG 检索的文档库是静态的工具调用接的是实时接口——天气 API、股票行情、实时库存、数据库查询。模型可以自主判断这个问题需要实时数据我去查一下查完再回答。它和 RAG 的区别就在于RAG 查的是静态文档库工具调用查的是实时接口。你问今天北京多少度RAG 文档库里没有今天的天气它没法答工具调用可以让模型先去调一个天气 API把温度拿回来再组织语言回答。工具调用在降幻觉上的价值在于它把外部实时信息作为grounding——模型不是凭空生成而是基于实时事实来回答。实时的事实不会错模型基于事实生成答案幻觉自然就少了。但它也有局限工具调用依赖外部接口的质量。接口返回的数据格式不对、接口本身有 bug模型拿到的信息就是错的。而且工具调用只解决实时信息问题静态知识、领域知识还是得靠 RAG 或者微调。面试官可能追问工具调用和 RAG 有什么区别答两者都在给模型提供外部信息但数据源不同。RAG 查的是事先建好的文档向量库适合静态知识库工具调用查的是实时接口适合动态信息。打个比方RAG 是考试前把资料印好发给你工具调用是考试中让你查手机实时搜答案。一个是提前准备一个是实时查询。四、微调和 RAG 的本质区别这是本篇最核心的理论点咱把它单独拎出来讲。很多人做 AI 落地的时候最常纠结的一个问题就是我到底是上 RAG 还是上微调这个问题之所以难回答是因为没有搞清楚两者的本质。咱用四个厨师来对照让你一眼看明白——RAG 就像厨师参加考试时可以翻手册手册里有什么他就答什么手册更新了他答的也跟着更新。微调呢是厨师把菜谱背进了脑子里脑子记住了什么他就做什么换了厨师答的就不一样了。Prompt Engineering 更像是厨师做菜之前你告诉他少盐、多辣、用铁锅他按你的指令来执行。工具调用则是厨师遇到不知道的食材打电话给供应商问一下再处理。RAG 和微调的核心区别体现在三个维度——第一知识存在哪。RAG 的知识存在外部文档库里模型权重里没有这些知识。微调的知识存在模型权重里外部文档库里没有。你把公司员工手册上传到 RAG 系统模型权重里并没有这段手册你拿员工手册的数据微调模型模型权重里就有了这段知识但手册文档本身对模型回答没有任何作用。第二更新成本。RAG 更新知识改文档就行不需要重新训练模型。微调更新知识得重新跑一轮训练。公司制度改了RAG 那边直接更新文档文本几分钟生效微调那边得重新准备数据、跑训练、等模型收敛短则几小时长则几天。对于知识频繁更新的场景这个差异是致命的。第三可解释性与溯源。RAG 能告诉你这个答案是从哪篇文档里检索出来的答案可以溯源。微调说不清这个知识从哪条训练数据里来的答案无法溯源。在金融、医疗、法律这些对准确性要求极高的行业可溯源是硬需求。你告诉客户根据我们系统查询您的贷款审批结果是拒绝客户问为什么你得拿出依据不能说模型这么说的它也不清楚。总结一下怎么选知识频繁更新用 RAG行为模式需要深度定制用微调。需要模型按特定风格回答、用特定领域术语、遵循特定流程用微调。需要模型掌握一批随时会变的事实、文档、数据库用 RAG。面试官可能追问既要更新知识又要改风格怎么办答两个一起上。RAG 管知识库微调管行为风格。但两个一起上意味着两套系统的维护成本复杂度上来了。所以实际工作中建议 RAG 优先——先用 RAG 解决知识问题如果发现模型的行为风格始终不对比如总用太随意的语气回答客户再考虑加微调调一调风格。五、什么场景该用谁说完了理论咱把它落到实际场景上让你面试能讲、工作能避坑。企业内部知识库问答这种场景选 RAG。你们公司的 HR 手册、财务制度、合同模板这些内容随时可能更新选 RAG。知识更新直接改文档模型下一秒就能答上新内容。微调每次制度改了都得重新训练等你训完模型制度又改了。再比如客服机器人要统一风格这种选微调。用户问问题模型得用您好、请问有什么可以帮您这种语气开头选微调。这种风格一致性不是知识问题是行为模式问题微调能把它刻进肌肉记忆里Prompt 调也行但不够稳。实时数据查询的场景比如问我的订单到哪了、“现在这只股票多少钱”选工具调用。RAG 文档库里没有实时物流信息和股票行情只能靠 API 去查。垂直领域专家要术语统一比如医疗报告生成、法律文书撰写模型得用准确的医学术语和法律术语选微调。让模型学会这个领域的表达方式比让 RAG 每次都检索一堆术语文档来得稳。既要知识更新又要风格统一比如既要掌握最新的产品手册又要按统一风格回复客户两个一起上。RAG 管知识库微调管行为风格。这是大厂的常见做法不是因为高大上而是因为真的需要。一个实用的判断顺序——遇到新问题先问自己这个问题的答案是会频繁变动的吗是的话RAG。不是的话再看模型的风格和表达方式有问题吗有的话微调。还有实时数据需求吗有的话加工具调用。实际落地中RAG 是优先选项因为它的门槛最低、迭代最快、效果最直观。微调是补充手段是 RAG 搞不定的时候才上的大招。面试官可能追问实际项目中怎么组合这些手段答我的思路是 RAG 优先。知识库场景先上 RAG跑起来看效果。如果发现检索质量没问题但模型输出风格始终不对——比如老用太随意的语气对客户说话——再加微调调一调风格。如果还有实时数据需求再把工具调用接进来。不用一上来就全套都上维护成本高迭代也慢。为什么放这段代码让读者看到 RAG 和微调组合起来在流程上长什么样。// RAG 微调 组合流程funcanswerWithRAGAndFineTuned(questionstring)string{// 先用 RAG 检索相关知识docs:vectorStore.Search(question,topK3)context:strings.Join(docs,\n)// 拼进 Prompt给微调过的模型生成prompt:fmt.Sprintf(用正式专业的语气回答。\n参考知识\n%s\n\n问题%s,context,question)returnfineTunedLLM.Chat(prompt)}这段代码在干嘛用户提问后先去知识库检索把资料拼进 Prompt再交给微调过的模型生成回答。RAG 负责基于什么事实回答微调模型负责用什么风格回答各司其职。为了代码清晰这里省略了常规的错误处理和相关逻辑实际生产代码中务必加if err ! nil判断。六、落地常见坑先提一嘴趁这块地盘先给你们打几剂预防针后面第六篇会专门展开。最常见的坑是以为微调能注入新知识刚才花了大篇幅讲这个误区。微调擅长调行为、调风格不擅长记事实。上来就问能不能微调一批文档让模型学会然后发现效果不行——这不是你的数据质量差是路走错了。还有个坑是以为 RAG 能改模型风格。RAG 管的是基于什么资料生成管不了用什么语气生成。你想让模型用正式语气回答客户上 RAG 是没用的得靠 Prompt 或者微调。最后一个坑是两种手段硬凑不评估。RAG 和微调一起上结果发现效果不好不知道是哪边的问题。上了 RAG 之后要先单独评估 RAG 效果上了微调之后也要单独评估微调效果组合之后更要端到端评估。不要想当然觉得上了就比没上强。 本章面试要点降低幻觉有哪些方法各自原理是什么有四种主要手段。Prompt Engineering 通过优化提问方式、约束输出格式、引导推理来缓解幻觉微调通过在模型权重层面训练让模型记住特定行为模式和风格工具调用通过让模型查实时 API把外部事实接进来RAG 通过检索真实文档、约束生成空间来降幻觉。它们原理不同、适用场景不同通常组合使用。微调 和 RAG 的本质区别是什么三个维度。知识存在哪RAG 的知识在外部文档库微调的知识在模型权重里。更新成本RAG 改文档即可微调需要重新训练。溯源能力RAG 可溯源到具体文档微调不可溯源。简单说RAG 是现场查手册微调是把手册背进脑子。微调适合什么场景为什么它不擅长注入事实知识微调适合需要改变行为模式、输出风格、领域术语统一等场景。不擅长注入事实知识原因有三权重记忆会遗忘和干扰更新成本高每次都要重新训练不可溯源说不清知识存在哪。对于需要频繁更新或需要溯源的事实性知识RAG 远比微调合适。工具调用和 RAG 的区别是什么RAG 查的是静态文档库提前建好的知识库工具调用查的是实时接口API、数据库、传感器等。RAG 适合静态知识工具调用适合实时信息。两个不冲突经常一起用——RAG 提供领域知识工具调用提供实时数据。实际项目中怎么选型RAG 和微调谁优先实际工作建议 RAG 优先因为门槛低、迭代快、更新成本低。先用 RAG 解决知识问题跑起来看效果如果 RAG 检索质量没问题但模型风格始终不对再加微调调行为。如果有实时数据需求再接工具调用。不建议一上来就全套都上维护成本高迭代慢。下篇预告第三篇《RAG 的完整工作流程与文档切分数据怎么进系统切多大才合理》咱会把 RAG 的六步流程——加载、切分、向量化、存储、检索、生成——拆开来讲重点讲文档切分这个看似简单、实则坑最多的环节。切太大召回不准切太小上下文碎片化怎么拿捏这个度如果这篇文章帮你理清了 RAG 和微调的关系欢迎点赞、收藏、关注利威尔xu咱们下篇见。你项目里是 RAG 优先还是微调优先踩过哪些坑评论区聊聊。