大模型 prompt rag 微调

团队要做个问答或文案助手，第一反应往往是「是不是得微调一下」。真动手才发现：数据没多少、业务天天变、预算也不清楚该花在哪。这篇不讲原理堆概念，只给一套判断顺序——先看知识从哪来、再看任务要不要能力改变、最后算维护账，让读者知道自己该停在提示工程，还是加检索，还是真有必要动权重。

团队要做一个问答或者文案助手，第一反应常常是「是不是得微调一下」。真动手才发现：数据没多少、业务规则天天变、预算也不清楚到底该花在哪。这篇不讲原理堆概念，只给一套能照着走的判断顺序，让你清楚该停在提示工程、加上检索，还是真有必要动权重。

顺序的逻辑是：先看知识从哪来，再看任务要不要改变模型能力，最后算维护账。大部分团队停在前两步就够了，微调是压不住之后才考虑的手段，不是起点。

先分清你的问题出在「不知道」还是「不会」

模型答错，先别急着换技术。把错例分两类：一类是知识缺失，它从没见过这类资料；另一类是能力缺失，它见过但输出格式、口吻、判断口径不对。前者对应检索，后者对应提示或微调，路线完全不同。

• 验收标准都说不清的任务，先别选技术路线，先把标准写出来
• 错一次代价极低、人工顺手就改了的，直接人工兜底更划算
• 把三类问题各挑十条真实输入做成小测试集，后面每条路线的效果对比都靠它，别靠感觉
• 测试集要覆盖正常情况和边界情况，不然跑出来的通过率没参考价值

默认从提示工程起步，它是最便宜的验证手段

如果任务规则能写清楚、知识模型本来就有、容错率允许偶尔跑偏，那就先做提示工程。它的成本几乎只有人力，改一版试一版，一天能迭代好几轮，是验证需求到底成不成立最快的方式。

1. 写清规则把角色、输入输出格式、边界条件、几个正反例写进系统提示，别只在对话里试
2. 跑测试集用前面整理的小测试集跑通过率，记录哪些错例是知识缺失、哪些是格式问题
3. 判断要不要停规则超过几百行还压不住、每次都要手动补同一类资料、不同人写出来的提示效果差很多，说明该往下走了
4. 记下信号把提示里反复出现的外部知识列出来，这些就是后面要不要上检索的直接依据

知识要新、要能溯源、还经常变，就加检索这一层

检索管的是「知识从哪来」：把资料切片存进向量库，回答时按问题召回再塞进上下文，模型权重一个字不动。所以它天然适合资料每周都在更新、答案需要标出处、内容属于内部文档或私有数据的场景。

• 该上的信号：资料更新频繁、答案需要给出处、内容私有、错答代价高到必须可追溯
• 配套要一起定的：切分粒度、召回条数、要不要加重排、命中不了时怎么回复
• 命中不了直接说不知道，通常比让模型硬编一个答案好
• 不适用的情况：任务要的是模型学会一种表达风格或判断逻辑，检索塞再多示例也改不了模型的输出习惯

检索的效果一半靠切分和召回策略，别把它当成「接上向量库就完事」。同一批资料，切分方式变了，结果可能完全不同。相关服务的比对可以到 /sites 按当时的口径看。

微调是最后手段，它改的是行为不是知识

微调擅长的是固定输出格式与字段、统一口吻、把一套领域判断标准固化进模型，或者压缩提示词长度换推理成本。它不擅长处理时效性知识和需要引用来源的问答，你的样本本身就自相矛盾时，微调只会把矛盾学进去。

三关过不了就别推全量。可以先用低秩适应这类轻量方式在小样本上试一版，赢不了基线就停。数据准备、显存预算、合并部署这些活，站内已有专门文章：按 /stacks/fine-tuning 找服务商，按 /models/deploy 做部署测算。

一张对照表把三条路走完

判断顺序是固定的：任务规则能否写清、知识是否来自外部且会变、是否需要模型改变输出行为、三关全过才考虑微调。走完这四步，大部分团队会发现自己需要的其实是前两步的组合。

• 常见组合拳：检索负责给资料、提示负责给格式、微调只在格式和风格反复压不住时才上，三者不互斥
• 成本账要按当时的数字算，到 /tools/model-cost-calculator 和 /compute/finetune 核对
• 上线后留一条退路，哪条路线都要有回退方案和验收指标
• 模型换代时先按 /inference 比一次价，再决定要不要跟着换

先问问题出在知识还是能力，再问要不要动权重；顺序错了，钱和人都白花。