LLM开发必读：提示工程、RAG与微调全面对比

上个月的一场技术评审会上，出现了这样的场景：

某团队耗时三个月，基于大模型搭建了一套智能客服系统。演示阶段表现尚可，上线第一周就暴雷。用户询问“我的订单为什么还没到”，模型回复“建议您联系快递公司”。用户追问两句，模型开始杜撰物流详情。

评审会上，负责人追问了一句：你们的方案是否集成了RAG？团队主管愣了一下，回答：我们做了提示工程，还微调了模型。

根因已经清晰。

近半年，类似案例并不罕见。越来越多的人开始意识到：仅仅会调用API远远不够。提示词反复修改，模型依旧胡编乱造；微调跑了多轮，效果提升微乎其微。更棘手的是，你完全不清楚问题卡在哪个环节。

本文打算把这三件事彻底拆透。不聊空泛概念，直接给出可执行的判断标准。

目录
现象：为什么你的LLM应用总差一口气
本质变化：从“规则匹配”到“概率生成”
核心机制拆解：三个层次的定位与边界
典型案例对比：同一需求，三种方案效果差距多大
工程落地启示：别一上来就微调，先诊断瓶颈在哪
用一个问题收尾

一、现象：为什么你的LLM应用总差一口气

先看三个真实场景。

场景A：你精心撰写了一段提示词，要求模型输出JSON格式。10次调用里，总有2次返回纯文本。你追加了一句“必须输出JSON”，效果好了两天，随后再次失效。

场景B：你构建了一个企业知识库问答系统。用户提问“我们公司的年假政策”，模型回答的内容与公司规定完全不符。你把政策文档塞进上下文，token消耗暴涨，响应时间也翻了一倍。

场景C：你投入预算微调模型，希望其掌握特定业务逻辑。结果训练集上表现不错，一遇到真实用户提问又开始信口开河。你怀疑是数据质量有问题，却不知从何处排查。

这些问题的本质是什么？

不是模型不够强，而是你选错了工具。

提示工程、RAG、微调，这三件事解决的是完全不同的问题。很多人把它们混为一谈，用提示工程去解决本该RAG承担的任务，用微调去处理提示工程就能搞定的问题。结果往往是事倍功半，还找不到根因。

核心判断一：提示工程解决的是“怎么问”，RAG解决的是“问什么”，微调解决的是“模型本身的认知边界”。

二、本质变化：为什么会这样

传统软件开发的思维是确定性的。你写if else，输入A必然输出B；你写SQL，查询条件确定，结果就确定。

但大模型不是。它是一个概率系统。同样的输入，每次输出都可能不同。它不知道“不知道”，当它不确定时，它会编造。

这带来一个根本变化：你无法再通过“写更详细的规则”来解决问题，需要换一套方法论。

这套方法论的核心是分层。LLM应用开发有三个层次：

• 交互层：如何与模型对话。这就是提示工程。
• 知识层：模型从哪里获取实时、准确的信息。这就是RAG。
• 能力层：模型本身的认知和输出风格如何改变。这就是微调。

每一层解决的问题不同，所需成本和数据量也不同。很多人一上来就冲微调，觉得“让模型学会我的业务”才是正解。但实际上，绝大多数问题用提示工程就能解决一半，再用RAG解决另一半。微调是最后那20%的提升手段，不是起手式。

三、核心机制拆解：三个层次的定位与边界

3.1 提示工程：被低估的“结构化对话能力”

很多人觉得提示工程就是写prompt。这句话说对了一半。

写prompt没错，但真正的提示工程是在做一件事：约束模型的输出空间。

模型本身是一个概率分布，你给它一个开头，它会预测下一个最可能的token。提示词的作用，就是改变这个概率分布的起点。本质是：通过示例、格式约束、思维链，让模型的生成路径收敛到你想要的区域。

具体怎么做？

• Few-shot：给2-3个示例，模型会模仿这个模式
• 格式约束：明确要求输出JSON、Markdown、XML
• 思维链：让模型先输出推理过程，再给答案

但提示工程有边界。它解决不了知识缺失的问题。模型不知道你公司的内部系统，你写再好的prompt它也不知道。

核心判断二：提示工程不是玄学，是把“概率分布”约束到“可接受区域”的工程手段。

3.2 RAG：解决“知识截止”和“幻觉”的唯一正解

RAG的核心逻辑很简单：检索增强生成。但在工程上，它解决了一个本质问题：让模型在不重新训练的情况下，获得外部知识。

流程是：

• 把文档切块，向量化，存入向量数据库
• 用户提问时，把问题向量化，检索最相似的文档片段
• 把检索结果拼接进prompt，让模型基于这些信息回答

RAG解决了两个痛点：

• 知识截止：模型训练后的新信息，通过检索实时获取
• 幻觉：让模型“基于给定材料回答”，大幅降低编造概率

但RAG也有坑。检索质量决定了回答质量。你切块策略不对，检索出来的内容不相关，模型还是会瞎编。需要一个反馈闭环来持续优化检索。

3.3 微调：最后的武器，别轻易用

微调的本质是改变模型的权重。提示工程和RAG都不改变模型本身，微调会。它让模型在特定任务上表现得更好。

什么时候用微调？

• 提示工程搞不定的输出格式或风格
• RAG检索结果对了，但模型理解错了
• 需要模型学会特定的“思维方式”

但微调的代价很大：需要高质量的标注数据（至少几百到上千条），训练成本高，迭代周期长，还可能导致模型在其他能力上退化（灾难性遗忘）。

微调解决的是模型“认知能力”的问题，不是知识的问题。如果你是想让模型知道你公司的新政策，应该用RAG，不是微调。

核心判断三：微调改变的是模型本身，RAG改变的是模型看到的信息。区分这一点，能避免80%的无效投入。

四、典型案例对比：同一个需求，三个方案效果差多少

假设一个需求：让模型识别用户投诉的紧急程度，并自动分发给对应部门。

方案一：纯提示工程
提示词写清楚分类规则和输出格式。效果很快，零成本。问题在于，当投诉描述很隐晦时，模型容易误判。比如“我等了三天了”，没有明确说“投诉”，但应该是高优先级。

方案二：提示工程 + RAG
检索历史投诉案例库。遇到新投诉时，找到相似的历史case和对应的处理方式。模型参考这些案例来分类。效果明显提升——模型不是凭空判断，而是有据可依。

方案三：微调
用上千条已标注的投诉数据微调模型。模型学会了这套分类逻辑，即使没有历史案例也能判断。但问题在于：业务规则变了怎么办？你得重新收集数据，重新微调，迭代成本很高。

实际工程中的最佳实践是：RAG兜底知识，提示词约束行为，微调只用在那些“RAG解决不了”的地方。比如模型总是把中等优先级误判为高优，这时候用少量badcase做微调。

五、工程落地启示：对测试和开发意味着什么

如果你是测试工程师，这套方法论直接影响了你怎么做质量保障。传统测试是输入输出校验，LLM应用的测试需要分层：

• 提示词层的测试：格式稳定性、边界case
• RAG层的测试：检索召回率、排序质量、切块策略有效性
• 微调层的测试：能力保持评估、退化检测

如果你是开发工程师，你需要回答一个问题：你的系统有没有反馈闭环？

很多团队只做了“生成”，没有做“评估”。用户反馈了badcase，没有回流到知识库或训练数据。这意味着同样的问题会反复出现。

最轻量的闭环是：把线上badcase人工审核后，写进提示词的few-shot示例。再进一步，更新到RAG的知识库。最后才考虑微调。

这套思路对在校生也有用。你不需要在实验室里跑大模型微调才能学到东西。理解分层思想、动手搭一个RAG系统、写几个高质量的few-shot prompt，比跑一个微调脚本有工程价值得多。

六、用一个问题收尾

几个月前问过一个团队：你们现在的LLM应用，从用户反馈到模型改进，走完一个闭环需要多久？

大部分人回答：不知道。因为我们没有这个流程。

换个方式问：你现在的系统，是否具备了从线上badcase到训练数据或知识库的反馈闭环？

如果没有，提示工程、RAG、微调学得再好，也跑不通。因为真正让系统变好的不是单次的技术选型，而是持续迭代的工程机制。

你可以把这个问题带回去，问问你的团队。