面经策

为什么需要微调？直接用 Prompt Engineering 或 RAG 不行吗？ ​

  • 标签：

🏛 业务架构师 ​

这是微调立项的第一问。我的判断框架——三种手段各有擅长，按"要什么"分层：

要知识/事实 → RAG：产品参数、政策条款、库存价格，这些要随业务更新、要溯源、要权限控制。微调灌知识有三个死穴：更新一次训一次（周级 vs 分钟级）、无法引用出处（合规风险）、容易学成"记忆碎片"答非所问。

要行为/风格 → 微调：固定输出格式、品牌话术、领域推理范式（医疗问诊的问询套路）。这些写进提示词要么不稳定、要么每次烧大量示例 token；微调一次内化，小模型也能稳定输出，长期更便宜。

要单点效果 → 提示工程：探索期需求、临时任务、低频场景，改提示五分钟见效，零沉没成本。

决策的三个业务变量：

  1. 变更频率：知识月月变 → RAG；行为范式半年稳定 → 可微调；
  2. 调用量：日调用十万次的高频任务，微调小模型省下的 API 费几个月就覆盖训练成本；日几百次 → 提示工程+API 更划算；
  3. 数据家底：有没有几千条高质量"指令-理想输出"沉淀？没有就先攒数据（这本身要几个月），别空谈微调。

真实世界的答案通常是组合：RAG 管事实 + 微调管格式与风格 + 提示词管临场调度。我反对的是跳过前两级直接上微调的"炫技式立项"——那是在没有需求验证的情况下做最贵的投入。

🏗 系统架构师 ​

先给结论：RAG 和 Prompt Engineering 能解决"知识"和"轻量适配"，解决不了"行为内化"——微调的不可替代场景就三类：

Prompt/RAG 的能力边界：

  • Prompt 遵循不稳定：长指令、复杂格式约束下模型会漂移（尤其小模型），few-shot 占窗口且每次请求都付 token；
  • RAG 只改"模型能看到什么"，不改"模型怎么反应"——输出风格、术语体系、拒绝策略、隐式判断标准，这些写不进 Prompt 的东西 RAG 无能为力。

必须微调的三类场景：

  • 格式与风格刚性：结构化抽取、固定话术客服、品牌语气——微调把契约内化进权重，合规率 99%+，且省掉每请求几千 token 的示例；
  • 经济账：高 QPS 任务用微调小模型（7B）替代大模型 API，单条成本降一个数量级——QPS 1000、日均千万次调用，月成本差距是十万级人民币；
  • 领域行为深度：医疗法律场景的判断模式、代码风格修复模式——几千条专家标注里隐含的标准，Prompt 表达不出来。

决策顺序（我的标准流程）：Prompt 优化（零成本）→ few-shot + RAG（低成本）→ 效果/成本仍不达标 → 微调。三者不互斥：微调塑行为 + RAG 供事实 + Prompt 做任务适配是生产最优组合。

反向判断：知识频繁更新 → RAG；样本凑不到几千条 → 微调收益不稳；低频长尾任务 → 别折腾微调。

💻 全栈开发专家 ​

先摆决策矩阵再解释：知识/事实型需求用 RAG，行为/风格/格式型需求用微调，很多系统两者都要。

为什么不微调优先：

  1. 更新成本：RAG 改文档分钟级生效；微调重新训练+评测+发布以天计。价格表每周变，你不可能每周微调；
  2. 可溯源性：RAG 能给引用来源（企业合规刚需）；微调把知识熔进权重，出错了无法解释「它为什么这么说」；
  3. 长尾幻觉：微调灌的知识模型会「半记半编」——记得模糊时照样幻觉，且更自信；RAG 检索不到可以明确拒答；
  4. 数据量门槛：RAG 有文档就能跑；高质量微调数据的构建/清洗成本常被低估。

Prompt Engineering 的边界：它解决「怎么问」，不解决「知识从哪来」和「稳定输出行为」。能 prompt 解决的当然优先 prompt（零成本）。

什么时候微调不可替代：

  • 输出格式/协议必须 100% 稳定（结构化抽取、API 话术）；
  • 领域话术/风格深度定制；
  • 小模型替代大模型降本（微调后 7B 干 72B 的活）；
  • 延迟敏感（不再需要长 prompt 和多轮检索）。

组合拳（真实项目形态）：客服系统 = RAG（知识库问答+引用）+ 微调（话术风格和拒答行为）+ Embedding 微调（领域检索）。三者各管一段，边界清晰才好归因优化。