上个月，在一次AI大模型应用技术评审会上，出现了令人印象深刻的场景：
某团队耗时三个月，基于大模型搭建了一套智能客服系统。演示环节效果尚可，但上线第一周就彻底翻车。用户问“我的订单怎么还没到”，模型回答“建议您联系快递公司”。当用户继续追问时，模型开始编造虚假物流信息。
评审会上，负责人问了一句：你们有没有使用RAG？团队负责人愣了一下，回答道：我们做了提示工程，还微调了模型。
根因已经非常明显了。
最近半年，这样的案例屡见不鲜。越来越多的人意识到：仅仅会调用API远远不够。反复优化提示词，模型照旧胡编乱造；多轮微调跑下来，效果提升微乎其微。更棘手的是，你根本不知道问题到底卡在了哪个环节。
本文打算把提示工程、RAG、微调这三件事彻底讲清楚。不讲空泛理论，直接给可落地的判断依据。
目录
现象：为什么你的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、微调学得再好，也跑不通。因为真正让系统变好的不是单次的技术选型，而是持续迭代的工程机制。
你可以把这个问题带回去，问问你的团队。
