「这个需求要不要微调」是我们被问得最多的问题之一。多数情况下答案是「先别」，但少数情况下微调确实不可替代。这篇把提示工程、RAG、微调三条路线的边界讲清楚，再深入 SFT 与 LoRA 的选型与实操。
先分清三条路线
提示工程解决「怎么问」，RAG 解决「知识从哪来」，微调解决「模型的行为方式」。判断方法很直接：如果问题是模型不知道某条信息——用 RAG；如果问题是模型知道但答不按你要的格式、风格、流程——才轮到微调。把 RAG 能解决的问题拿去微调，是预算最昂贵的错误之一。
什么时候真的需要微调
三类场景让微调物有所值：一是固定格式与风格的高频任务（如按企业规范生成报告），期望值要通过大量样例固化；二是垂直领域语感（如医疗问诊话术），通用模型怎么提示都「不像」；三是蒸馏降本——把大模型的能力压进小模型，换取推理成本数量级的下降。反过来说，知识更新频繁、样例不足一百条的需求，都不该优先微调。
SFT 与 LoRA：怎么选
SFT（监督微调）指用标注问答对让模型模仿目标行为，是微调的基础形态。全量 SFT 调整全部参数，效果好但显存与成本高，适合资源充足、追求极限效果的团队。LoRA 冻结原模型、只训练少量低秩旁路参数，训练成本通常低一个数量级，效果在多数任务上接近全量微调，还支持按需切换多个任务适配器——预算有限时的默认答案。经验值：单任务样例在几百到几千条、目标是格式与风格对齐的场景，LoRA 基本够用。
数据集质量决定上限
微调圈有句老话：垃圾数据进，垃圾模型出。我们内部的门槛是四条：样例来自真实业务而非编造；答案有唯一顾问审核（多人标注必须对齐口径）；正例反例配比明确（很多团队只喂正例，结果模型学不会「不该说什么」）；留出 10% 从未参与训练的测试集。数据准备占到整个项目工期的六成并不夸张。
三个常见的坑
第一是灾难性遗忘：学新任务把通用能力练废了，解法是混入一定比例的通用数据、控制学习率与轮数。第二是过拟合：训练集表现完美、测试集拉胯，看到 loss 降到 0 就要警惕。第三是评测缺失：只凭感觉「好像变好了」，正确做法是固定一套离线评测集，每轮训练后对比打分。微调不是一锤子买卖，而是「数据-训练-评测」的循环，前两个圈的产出往往只是下一轮的基线。
私有化部署是微调的前置环境，见《大模型私有化部署实录》；知识类需求优先用 RAG，见《RAG 落地避坑指南》；基座模型能力参见《蓝芯 BlueCore 3.2 发布》；需要微调可行性评估，欢迎通过联系合作交流。