三个旋钮，不是台阶
读到这里你已经知道：大语言模型是一堆冻结的参数，在推理时把你的文字变成更多文字。问题在于，基础模型懂很多关于世界的通识，却对你的世界一无所知——你的文档、你的语气、上周二的价目表。要补上这一课，你能下手的地方恰好只有三个，而把它们看成三个各自独立的旋钮、而不是一条越爬越高的质量阶梯，会让你受益无穷。
第一是提示（prompting）：改变你送进去的文字。第二是检索（RAG）：在运行时取出相关事实，贴进同一段提示里。第三是微调（fine-tuning）：真的用更多训练去挪动权重。前两条不碰模型本身，全都在上下文窗口里发生；只有第三条改变了模型自己。这一条区分——模型的记忆变没变，还是只是它当下看到的东西变了？——是下文一切的脊梁。
提示：最便宜、最快的旋钮
提示利用的是你早先见过的一个特性——上下文学习。一个有能力的模型，能仅凭提示里写的指令和几个示例就接住一项新任务，完全不改权重。好的提示工程——一段清晰的系统提示、一两个做好的示例、对多步推理再加一点思维链的引导——能把「模型的默认表现」和「你想要的表现」之间的差距，关掉得出乎意料地多。
为什么从这里开始？因为迭代一圈以秒计，成本只是你发出去的 token，而且你可以随时改主意。没有训练任务要等，没有数据要标注，没有单独的模型要托管。等下个季度更强的基础模型一发布，一个纯提示的系统通常直接白捡这次升级。这份灵活性，值真金白银。
但提示有它实打实的局限，而且不只是文风层面。它没法教会模型在预训练里从没见过的事实——问它你们的内部 API，它会信誓旦旦地幻觉出一个错误答案。长提示每次调用都要多花 token，最终把上下文窗口挤爆。而且单靠提示，很难在成千上万个边角情形里产出深度一致的口吻或格式。撞上这些墙时，你就该去够另外两个旋钮了。
RAG：在运行时把事实喂给它
当问题出在知识上——模型缺事实，或者事实变得太快没法烤进权重——对的旋钮几乎总是检索增强生成。它的形状很简单：把你的文档以嵌入形式存进向量数据库，查询时取出与用户问题最相关的那几段，贴进提示里，让模型依据这些段落来回答。推理和行文仍由模型完成；你只是递给了它一本翻开的书。
user question
|-> embed -> search vector DB -> top-k relevant chunks
| |
+----------------> PROMPT <----------------+
|
LLM answer (grounded in the chunks, with citations)RAG 受欢迎是有硬道理的。事实留在模型之外，所以更新知识只需改一份文档，而不必重新训练任何东西。答案能附上出处，因此可被审计。又因为模型被要求倚靠检索到的文本，构建良好的 RAG 在「能找到依据的问题」上可量化地压低了幻觉。对大多数「和我们的文档对话／从知识库里回答」的产品来说，RAG 加上扎实的提示就是全部答案——根本不需要微调。
微调：当你非动权重不可时
微调是指：在一个现成模型上，用你自己的带标注样本继续训练，挪动权重，把新行为烤进去。它是迁移学习的一种：你保留模型来之不易的通用能力，再让它专精化。判断你是否需要它，有一条犀利的检验——当你必须改变模型行为的方式、而非它所知道的内容时，才微调。知识问题交给 RAG；行为问题交给微调。
微调的正当理由：把精确的输出格式或品牌口吻锁进每一次调用；教会一项狭窄技能——你有大量示例、却很难用语言描述清楚；或者为了缩短提示——一旦指令住进了权重，你就不必每次请求都为它们付费。这些大多在精神上属于指令微调：给模型看许许多多「(输入, 期望输出)」的配对，直到模式粘住。你很少需要动全部权重；轻量方法只调一小片，就能廉价地拿到大部分收益。
它的代价，正是你把它留到最后的原因。你需要一份干净的、带标注的数据集——而打磨这份数据才是真正的工作，训练本身倒不是。一次训练要花时间和算力，你从此拥有并且必须托管一个单独的模型，还冒着对自己样本过拟合、或侵蚀模型通用能力的风险。最糟的是，微调后模型的知识冻结在训练那一刻；事实一变，你要重新训练，而不是改一份文档。这最后一点，恰恰说明了为什么用微调去修 RAG 本能干净解决的知识问题，是个糟糕选择。
蒸馏，与成本／质量的权衡
有个近亲值得认识：蒸馏。做法是让一个又大又贵的「教师」模型产出高质量输出，你再微调一个又小又便宜的「学生」去模仿它（在大模型语境里叫模型蒸馏）。卖点很诱人——一个在你那项狭窄任务上跑得又快又省的小模型，在那一小片范围内往往接近教师的质量。代价是：学生只在你训练过的地方保住教师的水准；一旦推到那范围之外，质量就掉下去。
退一步看，整个决策就是一场跨越两种截然不同预算的成本／质量权衡。一是前期成本：提示几乎为零，RAG 需要搭建并维护一条检索流水线，微调和蒸馏则要标注数据和一次训练。二是推理时的单次调用成本——也就是你持续的推理成本。长提示和大段 RAG 上下文每次调用都更费 token；而一个微调或蒸馏出来的小模型，一旦存在，单次调用可能便宜得多。怎么选取决于你的流量：一个一次性工具，和一个每天回答百万次调用的服务，指向截然不同的答案。
- 从提示开始。写一段清晰的系统提示，加上一两个示例，对着一个小评测集量化质量。很多任务到这一步就够了。
- 如果失败的原因是缺事实或事实过时，就加上 RAG。把功夫下在检索质量上——切块、搜索、排序——再去怪模型。
- 如果失败的原因是顽固的行为问题——格式不对、风格不对、提示钉不住的某项技能——而你又有示例，那就微调。如果你同时还需要新鲜事实，就把它和 RAG 叠在一起用；这些旋钮是可以叠加的。
- 如果一个微调过的大模型有效、但在规模上单次调用太贵，就为那项狭窄任务把它蒸馏成一个更小的学生模型。
这一切都不是一锤定音的决定，也没有哪一项能取代「测量」。不管你最终上线什么，都在它旁边放一个小评测集，盯着数字看——下一级讲的正是如何评估和守护你部署的东西。三个旋钮不是对手；最强的系统会把提示写好、把对的事实检索出来，只去微调那些怎么换法都死活不肯动的行为。