微调、RAG 与提示词：
三种方案怎么选

01先分清三类问题

选方案之前，先判断问题属于哪一类：

• 不知道最新事实——模型缺少知识，优先考虑检索。
• 知道事实但格式、风格不稳定——先用提示词，必要时微调。
• 输出总带着不想要的习惯（语气、术语、结构）——才轮到微调。

归类错了，后面做什么都是白费。我见过最常见的情况，是把“提示词没写清楚”误判成“模型能力不够”。

02提示词永远先做

提示词成本最低、迭代最快，也最容易回退。把任务、约束和示例写清楚，很多问题在这一层就解决了。

而且提示词是后面所有方案的基础：如果连提示词都说不清任务，微调的数据也很难标对，检索也不知道该找什么。

03RAG 解决“知道什么”

RAG 适合私有知识、频繁更新的内容和需要出处的回答。它不改模型参数，知识更新只需更新索引，这是它最大的优势。

代价是系统复杂度：切分、召回、重排、上下文组装都要维护。检索质量上不去，模型再强也答不准。

04微调解决“怎么做”

微调适合固定输出格式、稳定风格和领域表达习惯。它更像是在教模型一种行为方式，而不是往模型里塞事实。

因此我不建议用微调来可靠地注入新知识：知识会过期，而重新训练的成本很高。事实类的内容交给检索，行为类的偏好交给微调。另外，微调需要标注数据、训练成本和回归评估，不要把它当成第一个选项。

05通常是组合，而不是三选一

真实系统里，三者经常一起出现：提示词定义任务，RAG 提供事实，微调稳定风格。关键是先上线最小组合，再用评测数据决定下一步加什么。

每加一层复杂度，都要能说清它解决了哪个具体问题。说不清的时候，通常说明还不该加。

方案的选择不取决于哪个更先进，而取决于问题到底出在哪一层。 A NOTE TO MYSELF