上个月我参与了一个技术评审会。某团队花了三个月用大模型做了一个智能客服。演示效果不错但上线第一周就翻车了。用户问“我的订单怎么还没到”模型回答“建议您联系快递公司”。用户追问了两句模型开始编造物流信息。评审会上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应用的测试需要分层提示词层的测试格式稳定性、边界caseRAG层的测试检索召回率、排序质量、切块策略有效性微调层的测试能力保持评估、退化检测如果你是开发工程师你需要回答一个问题你的系统有没有反馈闭环很多团队只做了“生成”没有做“评估”。用户反馈了badcase没有回流到知识库或训练数据。这意味着同样的问题会反复出现。最轻量的闭环是把线上badcase人工审核后写进提示词的few-shot示例。再进一步更新到RAG的知识库。最后才考虑微调。这套思路对在校生也有用。你不需要在实验室里跑大模型微调才能学到东西。理解分层思想、动手搭一个RAG系统、写几个高质量的few-shot prompt比跑一个微调脚本有工程价值得多。六、用一个问题收尾几个月前我问过一个团队你们现在的LLM应用从用户反馈到模型改进走完一个闭环需要多久大部分人回答不知道。因为我们没有这个流程。那我换个方式问你现在的系统是否具备了从线上badcase到训练数据或知识库的反馈闭环如果没有提示工程、RAG、微调学得再好也跑不通。因为真正让系统变好的不是单次的技术选型而是持续迭代的工程机制。你可以把这个问题带回去问你的团队。