一文搞懂提示工程、RAG、微调——LLM应用开发的三个层次
上个月，我参与了一个技术评审会。
某团队花了三个月，用大模型做了一个智能客服。演示效果不错，但上线第一周就翻车了。用户问“我的订单怎么还没到”，模型回答“建议您联系快递公司”。用户追问了两句，模型开始编造物流信息。
评审会上，leader问了一句：你们有没有做RAG？团队负责人愣了一下，说：我们做了提示工程，还微调了模型。
我听完就明白问题在哪了。
最近半年，我见过太多类似的案例。很多人已经开始感觉到：光会调用API不行了。提示词写了又写，模型还是瞎编。微调跑了好几轮，效果提升不明显。更麻烦的是，你根本不知道问题出在哪个环节。
这篇文章，我想把这三件事彻底讲清楚。不讲空话，直接给判断。
目录
现象：为什么你的LLM应用总是差点意思
本质变化：从“规则匹配”到“概率生成”
核心机制拆解：三个层次的定位与边界
典型案例对比：同一个需求，三个方案效果差多少
工程落地启示：别上来就微调，先诊断瓶颈在哪
用一个问题收尾
一、现象：为什么你的LLM应用总是差点意思
先看三个真实场景。
场景A：你写了一段精心设计的提示词，要求模型输出JSON格式。10次调用里，有2次返回了纯文本。你加上了“一定要输出JSON”，效果好了两天，后来又崩了。
场景B：你做了一个企业知识库问答系统。用户问“我们公司的年假政策”，模型回答的内容跟公司规定完全对不上。你把政策文档塞进上下文，token消耗暴涨，响应时间也慢了一倍。
场景C：你花了钱微调了模型，想让模型学会特定的业务逻辑。结果发现在训练集上表现不错，一遇到真实用户提问又开始乱说。你怀疑是数据质量的问题，但不知道该从哪里查起。
这些问题的本质是什么？
不是模型不够强，是你选错了工具。
提示工程、RAG、微调，这三件事解决的是完全不同的问题。很多人把它们混在一起，用提示工程去解决本该RAG做的事，用微调去解决提示工程能解决的问题。结果是事倍功半，还找不到根因。
观点句1：提示工程解决的是“怎么问”，RAG解决的是“问什么”，微调解决的是“模型本身的认知边界”。
二、本质变化：为什么会这样
传统软件开发的思维是确定性的。
你写if else，输入A必然输出B。你写SQL，查询条件确定，结果就确定。
但大模型不是。它是一个概率系统。同样的输入，每次输出可能不一样。它不知道“不知道”，当它不确定的时候，它会编。
这带来了一个根本变化：
你不再能通过“写更详细的规则”来解决问题。你需要换一套方法论。
这套方法论的核心是分层。
LLM应用开发有三个层次：
交互层：怎么跟模型对话。这是提示工程。
知识层：模型从哪里获取实时、准确的信息。这是RAG。
能力层：模型本身的认知和输出风格怎么改变。这是微调。
每一层解决的问题不同，需要的成本和数据量也不同。
很多人一上来就冲微调，觉得“让模型学会我的业务”才是正解。但实际上，绝大多数问题用提示工程就能解决一半，再用RAG解决另一半。微调是最后20%的提升手段，不是起手式。
三、核心机制拆解：三个层次的定位与边界
3.1 提示工程：被低估的“结构化对话能力”
很多人觉得提示工程就是写prompt。这句话对了一半。
写prompt没错，但真正的提示工程是在做一件事：约束模型的输出空间。
模型本身是一个概率分布。你给它一个开头，它会预测下一个最可能的token。提示词的作用就是改变这个概率分布的起点。
本质是：通过示例、格式约束、思维链，让模型的生成路径收敛到你想要的区域。
怎么做？
Few-shot：给2-3个示例，模型会模仿这个模式
格式约束：明确要求输出JSON、Markdown、XML
思维链：让模型先输出推理过程，再给答案
但提示工程有边界。它解决不了知识缺失的问题。模型不知道你公司的内部系统，你写再好的prompt它也不知道。
观点句2：提示工程不是玄学，是把“概率分布”约束到“可接受区域”的工程手段。
3.2 RAG：解决“知识截止”和“幻觉”的唯一正解
RAG的核心逻辑很简单：检索增强生成。
但在工程上，它解决了一个本质问题：让模型在不重新训练的情况下，获得外部知识。
怎么做？
把文档切块，向量化，存入向量数据库
用户提问时，把问题向量化，检索最相似的文档片段
把检索结果拼接进prompt，让模型基于这些信息回答
RAG解决了两个痛点：
知识截止：模型训练后的新信息，通过检索实时获取
幻觉：让模型“基于给定材料回答”，大幅降低编造概率
但RAG也有坑。检索质量决定了回答质量。你切块策略不对，检索出来的内容不相关，模型还是会瞎编。你需要一个反馈闭环来持续优化检索。
mermaid流程图可以看得更清楚：
3.3 微调：最后的武器，别轻易用
微调的本质是改变模型的权重。
提示工程和RAG都不改变模型本身。微调会。它让模型在特定任务上表现得更好。
什么时候用微调？
提示工程搞不定的输出格式或风格
RAG检索结果对了，但模型理解错了
需要模型学会特定的“思维方式”
但微调的代价很大：
需要高质量的标注数据，至少几百到上千条
训练成本高，迭代周期长
可能导致模型在其他能力上退化（灾难性遗忘）
微调解决的是模型“认知能力”的问题，不是知识的问题。如果你是想让模型知道你公司的新政策，应该用RAG，不是微调。
观点句3：微调改变的是模型本身，RAG改变的是模型看到的信息。区分这一点，能避免80%的无效投入。
四、典型案例对比：同一个需求，三个方案效果差多少
假设一个需求：让模型识别用户投诉的紧急程度，并自动分发给对应部门。
方案一：纯提示工程
提示词写清楚分类规则和输出格式。效果很快，零成本。
问题：当投诉描述很隐晦时，模型容易误判。比如“我等了三天了”，没有明确说“投诉”，但应该是高优。
方案二：提示工程 + RAG
检索历史投诉案例库。遇到新投诉时，找到相似的历史case和对应的处理方式。模型参考这些案例来分类。
效果明显提升。因为模型不是凭空判断，而是有据可依。
方案三：微调
用上千条已标注的投诉数据微调模型。模型学会了这套分类逻辑，即使没有历史案例也能判断。
但问题是：业务规则变了怎么办？你得重新收集数据，重新微调。迭代成本很高。
实际工程中的最佳实践是：RAG兜底知识，提示词约束行为，微调只用在那些“RAG解决不了”的地方。比如模型总是把中等优先级误判为高优，这时候用少量badcase做微调。
五、工程落地启示：对测试和开发意味着什么
如果你是测试工程师，这套方法论直接影响了你怎么做质量保障。
传统测试是输入输出校验。LLM应用的测试需要分层：
提示词层的测试：格式稳定性、边界case
RAG层的测试：检索召回率、排序质量、切块策略有效性
微调层的测试：能力保持评估、退化检测
如果你是开发工程师，你需要回答一个问题：你的系统有没有反馈闭环？
很多团队只做了“生成”，没有做“评估”。用户反馈了badcase，没有回流到知识库或训练数据。这意味着同样的问题会反复出现。
最轻量的闭环是：把线上badcase人工审核后，写进提示词的few-shot示例。再进一步，更新到RAG的知识库。最后才考虑微调。
这套思路对在校生也有用。你不需要在实验室里跑大模型微调才能学到东西。理解分层思想、动手搭一个RAG系统、写几个高质量的few-shot prompt，比跑一个微调脚本有工程价值得多。
六、用一个问题收尾
几个月前我问过一个团队：你们现在的LLM应用，从用户反馈到模型改进，走完一个闭环需要多久？
大部分人回答：不知道。因为我们没有这个流程。
那我换个方式问：
你现在的系统，是否具备了从线上badcase到训练数据或知识库的反馈闭环？
如果没有，提示工程、RAG、微调学得再好，也跑不通。因为真正让系统变好的不是单次的技术选型，而是持续迭代的工程机制。
你可以把这个问题带回去，问你的团队。