一文搞懂提示工程、RAG、微调——LLM应用开发的三个层次

上个月，我参与了一个技术评审会。

某团队花了三个月，用大模型做了一个智能客服。演示效果不错，但上线第一周就翻车了。用户问“我的订单怎么还没到”，模型回答“建议您联系快递公司”。用户追问了两句，模型开始编造物流信息。

评审会上，leader问了一句：你们有没有做RAG？团队负责人愣了一下，说：我们做了提示工程，还微调了模型。

我听完就明白问题在哪了。

最近半年，我见过太多类似的案例。很多人已经开始感觉到：光会调用API不行了。提示词写了又写，模型还是瞎编。微调跑了好几轮，效果提升不明显。更麻烦的是，你根本不知道问题出在哪个环节。

这篇文章，我想把这三件事彻底讲清楚。不讲空话，直接给判断。

一、现象：为什么你的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的核心逻辑很简单：检索增强生成。

但在工程上，它解决了一个本质问题：让模型在不重新训练的情况下，获得外部知识。

怎么做？

1. 把文档切块，向量化，存入向量数据库
2. 用户提问时，把问题向量化，检索最相似的文档片段
3. 把检索结果拼接进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、微调学得再好，也跑不通。因为真正让系统变好的不是单次的技术选型，而是持续迭代的工程机制。

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

霍格沃兹测试开发学社，是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区