RAG 还是微调？

这个问题通常被摆成一道二选一：想让模型懂你的东西，无非这两种做法。问题恰恰出在这个提法上，因为这两件事根本不是一回事。

检索增强生成（RAG）在请求时提供知识。 微调则永久改变行为。

一旦把这两点分开，大多数情形立刻就有了答案。

分界线

先问：真正缺的是什么。

缺信息 → 检索。模型不知道你的退款政策、你的代码库、昨天的故障。把这些放进上下文。参见为什么需要 RAG。

缺行为 → 微调。模型知道得很多，但没法稳定按你要求的格式、行文风格或分类体系输出。它需要调整倾向，而倾向存在于参数里。

最常见的错误是用微调来灌事实。这么做效果很差，原因值得说清楚。

为什么微调不擅长装事实

事实落得不牢。 训练把参数往模式上推。风格本身就是模式，迁移得很好。而一个只见过几次的孤立事实只会留下一道浅浅的痕迹，重建出来的东西差不多对——轮廓对，细节错。这比不知道更糟，因为它和真的知道无法区分。

一更新就得重训。 文档每周都在变，重训不是。

没有出处。 微调后的回答没法引用来源，因为来源已经溶进权重里了。对大多数业务场景来说，「这是从哪儿来的」是硬性要求。

访问控制消失了。 内容一旦训进去，模型就照说不误，不管提问的是谁。用检索的话，权限是在查询时校验的。

微调真正擅长什么

格式与结构的稳定性。 每次调用都要固定的输出形状，靠 prompt 能做到 95%，微调能更高——而且更便宜，因为指令不再占用每次请求的 token。

语气与文风。 你所在组织的表达腔调，用文字几乎描述不清，拿几百个例子演示却很简单。

大批量下的窄分类任务。 在一个定义清晰的任务上，一个小的微调模型可以追平大得多的靠 prompt 驱动的模型，单次调用成本还只是零头。

规模化降本。 把长 prompt 挪进权重，就等于把它从每次请求里拿掉了。放到几百万次调用的量级上，这一条本身就足够成立。

领域惯例。 专业记号、医学简写、法律文书套路——这些是形式，不是事实。

规律是：微调教的是怎么回应，检索提供的是围绕什么回应。

先试这几招

这两个选项常常都上得太早。

把 prompt 写清楚。 大多数格式抱怨其实是需求没描述清楚。测试不要钱。

少样本示例。 三个示例往往就能达到人们期待微调带来的效果，代价只是多花点 token。示例管用的话，答案就有了，训练也不用跑。

换更强的模型。 有时候这才是老实的解法。动手搭任何东西之前，先用完全相同的 prompt 测一遍。

结构化输出约束。 如果问题是 JSON 不合法，schema 约束生成能保证合法。不需要训练。

等 prompt 加示例已经到瓶颈、而且差距可测量了，再去碰微调，不要提前。

两者结合

两者能干净地组合，最强的生产系统常常都上：检索负责最新的、带权限的、可引用的知识；轻量微调负责每次回答都要的格式和腔调。

顺序很重要。先把检索跑通——它解决的是更常见的问题，迭代起来也便宜得多。只有在知识问题解决之后行为差距仍然存在时，才加微调。

成本实况

RAG 花的是工程量：抽取、分块、embedding、向量存储、重排序。持续成本是每次查询为召回上下文付的 token。迭代很快——改索引，立刻看到结果。

微调花的是人工整理的数据集，这通常才是真正的开销，而且永远比预期的大。然后是一轮训练，再然后是一轮评测，每次基座模型更新还得再来一遍。持续推理更便宜，因为 prompt 变小了。

像 LoRA 这样的参数高效方法只训练少量新增参数，而不是整个模型，成本更低，也让多个任务专用变体变得可行。现在大家说微调，多半指的就是这个。

要点回顾

• RAG 提供知识，微调塑造行为。 先问缺的是哪一个，几乎所有情形都能定下来。
• 微调装事实不可靠，每次更新都要重训，还会毁掉出处和访问控制。
• 它擅长的是格式稳定性、语气、窄分类，以及在大批量下压低单次请求成本。
• 先试 prompt、少样本、更强的模型和输出约束。
• 两者能很好地配合——先搭检索，只有行为差距仍在时才加微调。

下一篇： 什么是 AI agent？