目录1.微调1.1.SFT监督微调1.2.RLHF强化学习1.3.DPO直接偏好优化1.4.RL1.5.Prompt、RAG、SFT、DPO、RL 怎么选1.6.微调评测1.7.面试官可能会问2.LoRA/QLoRA低秩微调2.1.LoRA 的核心思想2.2.rank 和 alpha2.3.QLoRA2.4.面试官可能会问3.RAG vs 微调3.1.缺 知识 还是 行为3.2.RAG 微调3.3.面试官可能会问4.面试官可能几会问4.1.总原则守住四条线Q1你这个项目为什么微调不能用 RAG 或 Prompt 吗选型Q2SFT、RLHF、DPO 有什么区别分别适合什么场景选型Q3你用 LoRA 训的那 rank 设的多少为什么是这个值参数Q4你怎么证明微调真的有收益评估Q5微调的数据是怎么来的怎么保证质量数据Q6基模越来越强了垂类微调还有必要吗成本 选型也有人反过来简历里写“对模型做了微调”但面试官追问一句“你们为什么要微调SFT、RLHF、DPO 分别解决什么问题为什么不用 RAG”然后就卡住了。这就很可惜。应用开发者不一定要亲手训一个百亿模型但必须知道微调到底在改变模型什么什么问题适合微调什么问题根本不该微调。这篇我们不推公式。也不把论文名词堆满。我们就把 SFT、RLHF、DPO 这三类方法讲清楚。1.微调先建立全局图微调不是 给模型塞知识很多人对微调的第一反应是模型不知道我们公司的业务那就微调一下让它记住。 这个理解太粗了。微调更常见的价值不是补知识而是控行为。知识会变。产品规则、价格、库存、组织架构、政策条款这些都可能更新。这类东西硬训进模型里后面规则一变模型参数里的旧知识还在很难清干净。之前讲 RAG 时说过RAG 更适合处理外部知识、私有知识、动态知识。微调更适合处理另外一类问题微调适合的问题说明模型知道规则但输出格式总是不稳行为稳定问题模型能回答但话术不符合业务口径表达偏好问题模型会做任务但步骤顺序经常乱流程稳定问题多个答案都没错但业务更偏好其中一种偏好选择问题小模型能力不够想学大模型在固定任务上的范式能力蒸馏问题 你看这些问题都不是 知道不知道而是 怎么做、怎么答、怎么选。先记住一句话RAG 解决外部知识进入上下文的问题微调解决模型行为模式被参数吸收的问题。从 Base Model 到可用助手能力是这样分层的预训练让模型会续写 → SFT监督微调 让模型学会按指令回答 → RLHF/DPO 让模型符合人类或业务偏好 → 最后用评测和线上反馈证明收益。1.1.SFT监督微调SFTSupervised Fine-Tuning监督微调一句话解释 给模型看 输入应该怎么对应输出 的高质量示范让模型模仿这种回答方式。比如客服退款场景。用户说我这个订单能退吗差的回答能退。更好的示范请先提供订单号我会查询订单状态、支付时间和商品类型再根据平台退款规则判断是否满足退款条件。SFT 数据就是大量这种 问题 标准回答。模型看多了会学到遇到退款问题不要直接下结论先收集订单号再查订单状态最后按规则判断。SFT 适合什么✅SFT 适合相对稳定、示范明确、可批量构造数据的任务适用场景例子固定 JSON 输出结构化字段工单分类类别映射信息抽取实体 / 关系固定客服话术业务口径工具调用格式Function Calling简历点评风格话术风格小模型学习大模型范式能力蒸馏共同点你能写出 好答案长什么样。只要能稳定写出好示范SFT 就有发挥空间。SFT 不适合什么❌SFT不适合把动态知识硬塞进模型商品价格、库存状态、最新政策、公司制度、合同条款、产品功能说明。这些信息变化频繁今天训进去明天就可能过期。这类场景更应该用 RAG、数据库查询、工具调用。SFT 教模型 怎么答RAG 给模型 答题资料。这个边界一定要分清。SFT 的风险⚠️SFT 最大的坑是数据质量。很多团队拿客服聊天记录直接训看起来数据很多其实里面全是坑脏数据类型后果老规则训练进过时流程错流程学会错误步骤坏话术输出不专业隐私信息泄露风险人工客服随口说的话不规范表达同一问题多种矛盾答案模型摇摆❗ 脏数据不是资产是污染源。所以 SFT 项目里最重要的不是 我训了多少条而是数据从哪里来、怎么清洗、怎么去重、怎么标注质量、怎么切训练 / 测试集、怎么做失败样本回流。1.2.RLHF强化学习Reinforcement Learning from Human Feedback基于人类反馈的强化学习是给模型一个标准答案而是告诉模型多个候选答案里人类更喜欢哪一个。比如同一个投诉问题两个回答A不符合规则不能退。B我理解你现在比较着急。退款需要先确认订单状态和商品类型如果不满足自动退款条件我可以帮你看是否需要转人工处理。这两个不一定是 一个绝对错、一个绝对对但业务可能明显更喜欢 B。这就是偏好问题。SFT 训练出能按指令回答的模型 → 对同一问题生成多个候选回答 → 人类标注哪个更好 → 用偏好数据训练 Reward Model → 用 PPO 强化学习优化模型 → 用评测集和线上指标检查有没有训歪两个容易混的词Reward Model奖励模型是 评分器学习人类偏好给模型输出打分。PPO是 优化算法根据 Reward Model 的分数更新模型同时限制模型不要偏离原模型太远。✅ PPOProximal Policy Optimization近端策略优化是一种强化学习算法策略优化算法OpenAI 2017 年提出论文Proximal Policy Optimization Algorithms。为什么要限制因为模型很容易钻 reward 的空子如果 Reward Model 偏爱长答案模型可能开始写一堆废话偏爱礼貌语气模型可能每句话都客气到离谱。所以 PPO 里通常会控制模型不要一下子偏离太远。 面试不用推公式讲清楚这层关系就够了RLHF 用人类偏好训练奖励模型再用强化学习算法让模型更偏向高奖励回答。RLHF 适合什么✅RLHF 适合 没有唯一标准答案但有明显偏好 的问题回答更礼貌还是更直接、拒答边界更保守还是更开放、客服先安抚还是先解释规则、Agent 失败时继续尝试还是停下来追问。RLHF 的关键词是偏好对齐。RLHF 的成本RLHF 很重重在三件事人类偏好标注贵Reward Model 自己也可能学偏PPO 训练和调参复杂、容易不稳定。所以除非数据量、团队能力和业务收益都足够不要一上来就喊 RLHF。更现实的路线是先 Prompt 和 RAG → 再 SFT → 有稳定偏好数据后再考虑 DPO → 只有任务足够大、反馈足够强、收益足够明确才考虑完整 RLHF 或更广义的 RL。1.3.DPO直接偏好优化DPODirect Preference Optimization一句话解释 直接用 好回答 vs 差回答 的偏好对训练模型让模型更倾向于好回答不再单独训练 Reward Model也不走复杂 PPO 流程。它仍然需要偏好数据同一个问题下chosen更符合业务偏好的回答rejected不符合偏好的回答。DPO 直接吃这种数据训练目标就是让模型以后更倾向 chosen而不是 rejected。DPO 为什么火因为它工程上更轻传统 RLHF 要训练 Reward Model还要跑 PPODPO 省掉了中间很多复杂环节训练流程更短、调参压力更小、稳定性通常更好、更容易基于已有偏好数据落地 如果你已有一批可靠的偏好对客服好坏回答、合规 / 不合规回答、正确 / 错误工具调用轨迹DPO 是更容易起步的选择。DPO 的边界⚠️DPO 不是万能替代 RLHF。它的前提是偏好数据质量足够高。如果标注标准混乱今天喜欢简洁、明天喜欢详细今天拒答、明天给建议模型就会左右摇摆。还有一种场景 DPO 不一定够Agent 多步执行。模型要在环境里连续行动理解任务→选工具→填参数→读结果→判断下一步→完成任务。要优化的是整个任务完成率、工具调用成功率、错误恢复能力只靠静态偏好对可能不够更需要真实环境反馈和轨迹级评估。1.4.RL很多人把 RLHF 和 RL 混在一起。其实RLHF 是 RL 的一种路线RL 更宽。一句话解释RL 是让模型在环境里做动作环境给奖励模型学会让长期奖励更高。它不一定要人类偏好只要 reward 能定义就可以有 RL。场景奖励信号代码任务编译通过→高、单测通过→高、报错→低数学任务答案正确→高、违反约束→低Agent 工具调用工具选对→高、参数合法→高、任务完成→高、越权→严重惩罚 这些任务更适合 RL因为reward 相对客观。但如果 reward 很模糊只是 我感觉这个回答更好直接上 RL 就很危险 —— 模型会为了拿高分钻规则漏洞这就是常说的reward hacking。RL 的核心不是 高级而是你有没有一个清晰、稳定、可验证的奖励信号。没有这个RL 只会把问题放大。1.5.Prompt、RAG、SFT、DPO、RL 怎么选具体怎么判断① 只是表达和格式问题先用 Prompt先给结论再解释、输出 JSON、不知道就说不知道、回答控制在 200 字以内、只根据给定材料回答。这些优先 Prompt。Prompt 能稳定解决就不要训练训练会引入数据、成本、版本、评测、回滚问题。② 是动态知识问题优先 RAG 或工具查商品价格、查订单状态、查公司制度、查文档条款。知识要可更新、可追溯、可替换微调不是知识库。③ 是稳定行为问题再考虑 SFT输出格式总是不稳、任务步骤经常乱、工具调用参数总不规范、固定场景话术不统一。这时让模型把固定行为模式学进参数里。④ 是偏好问题考虑 DPO 或 RLHF两个回答都能用但业务更喜欢其中一种、拒答尺度要更保守、客服先安抚再处理、安全场景更符合合规口径。有稳定偏好对先考虑 DPO。⑤ 有可验证 reward才考虑 RL单测是否通过、检索是否命中、工具调用是否成功、Agent 任务是否完成、风险动作是否被拦截。有明确反馈才有 RL 土壤否则别为了显得高级硬上。问题类型首选方案原因表达和格式问题Prompt先给结论 / 输出 JSON / 不知道就说不知道Prompt 能稳定解决就不要训练动态知识问题RAG 或工具知识要可更新、可追溯、可替换微调不是知识库稳定行为问题SFT输出格式不稳 / 步骤乱 / 参数不规范让模型把固定行为学进参数偏好问题DPO 或 RLHF有稳定偏好对→先 DPO规模大、反馈体系成熟→完整 RLHF可验证决策问题RL单测 / 命中 / 工具成功 / 任务完成有明确反馈才有 RL 土壤微调的价值正在从补能力转向控行为、控偏好、控成本、控风险。这个判断比简单说 微调有用 或 微调没用 更像工程答案。1.6.微调评测微调最怕一句话感觉效果好了。 这不是工程结论。微调前后至少要看四类指标。指标类具体指标 任务指标分类准确率、信息抽取 F1、JSON 合法率、工具调用成功率、任务完成率、用户问题解决率✅ 质量指标幻觉率、格式错误率、无证据回答率、错误拒答率、人工接管率、高风险问题处理正确率 成本指标单次调用成本、延迟、小模型承接流量、大模型调用量减少 风险指标越权动作率、错误放行率、错误拒答率、投诉率、回滚次数、审批触发率⚠️ 尤其是 RAG 和 Agent 项目不能只看用户满意度还要看证据链和执行轨迹。如果效果差不多但成本降了一半这也是非常实在的收益。回归测试每次换 Prompt、换 RAG、换工具、换模型、做微调都要跑回归。否则很容易出现这个场景好了另一个场景坏了训练集效果提高了线上真实问题变差了格式更稳了但拒答边界被破坏了❗ 所以要有固定回归集尤其要保留历史失败 case。失败样本不是垃圾是下一轮优化最值钱的数据。1.7.面试官可能会问“你怎么看 SFT、RLHF、DPO它们分别适合什么场景”“我会先把微调分成几类问题来看。SFT 本质是监督微调适合让模型学习高质量示范。它更适合固定输出格式、固定任务流程、工具调用范式、行业话术和小模型蒸馏不适合把频繁变化的业务知识硬塞进模型。动态知识我会优先用 RAG 或工具查询。RLHF 解决的是偏好对齐问题。它不是给模型唯一标准答案而是通过人类偏好让模型知道多个候选答案里哪个更符合人类或业务偏好。传统流程通常会训练Reward Model再用 PPO 这类强化学习算法优化模型。DPO 也是偏好优化但工程路径更轻。它直接用chosen/rejected这种偏好对训练模型省掉单独训练 Reward Model 和 PPO 的复杂流程。所以如果团队已经有高质量偏好数据我会优先考虑 DPO而不是一上来做完整 RLHF。更广义的RL 只有在 reward 清楚时才值得做比如代码单测、数学答案、Agent 工具调用成功率、任务完成率这类可验证目标。reward 模糊时强行上 RL很容易训歪。所以我不会把微调理解成‘给模型补知识’。基模越来越强后低质量垂类微调确实容易被抹平但控行为、控偏好、控成本、控风险仍然有价值。最后是否值得做要看评测集、线上指标、成本收益和风险指标而不是靠主观感觉。”这个回答能体现三件事。第一你知道概念。第二你知道边界。第三你知道工程落地要用指标说话。这比背 SFT、RLHF、DPO 的定义有用得多。2.LoRA/QLoRA低秩微调先搞清楚全参微调到底贵在哪很多人以为微调贵是因为 模型参数多这只说对了一半。真正吃显存的不只是模型权重本身。以 7B 模型、Adam 优化器、FP16 精度算一笔账显存项占用说明模型权重约 14 GB7B 参数 × 2 字节FP16梯度约 14 GB每个参数都要存一份梯度Adam 优化器状态约 28 GB动量 方差两份常用 FP32 存合计≈ 70 GB还没算前向激活值核心矛盾只要你要更新全部参数梯度和优化器状态就甩不掉显存就降不下来。所以问题变成能不能只更新一小部分参数让梯度和优化器状态只跟着这一小部分走—— 这就是 LoRA 的出发点。2.1.LoRA 的核心思想LoRA 的核心思想冻结原权重只学一个 增量LoRALow-Rank Adaptation低秩适配想法特别朴素拆成两句话原来的模型权重全部冻结一个都不动在旁边新加两个小矩阵只训练它们用它们表示 权重需要变化的部分。W_new W ΔW 全参微调直接改 WΔW 和 W 一样大 LoRA 不改 W用 ΔW B × A 近似 A 形状 r×dB 形状 d×rr ≪ d训练时 W 冻结只更新 A、B推理时把 W B×A 合并等价于微调过的权重。参数量差多少假设 d 4096方案可训练参数倍数全参微调一层4096×4096 ≈1678 万1×LoRAr84096×8 8×4096 ≈6.5 万少 250 多倍 可训练参数少 250 倍 → 梯度和优化器状态也跟着少 250 倍 → 显存自然下来。为什么 低秩 就够用直觉疑问这么小的矩阵近似大矩阵信息不会丢吗答案藏在一个观察里大模型适配下游任务时权重真正需要改变的方向其实没那么多。ΔW 虽然形状大但它 本质上 是个低秩矩阵 —— 有效信息维度很低。打个比方预训练模型已经会了 99% 的通用能力微调不是重新教一遍而是在原能力上 微调整。这点调整用不着满秩大矩阵。低秩不是偷工减料而是一个假设微调要学的东西本来就是低维的。实践证明这个假设在绝大多数下游任务上都成立。中间那个 r 像个瓶颈逼着模型只学最关键的变化方向而不是漫无目的地乱改。2.2.rank 和 alpharank秩怎么设rank 就是那个瓶颈的宽度越大表达越丰富但参数也越多。rank 取值效果太小1、2表达能力不够复杂任务学不到位8 / 16 / 32大多数场景够用简单任务数据少从 8 起步64任务复杂、数据多、与预训练分布差异大时128 以上往往说明该考虑全参微调了 面试回答模板rank 控制低秩矩阵的表达能力。我从 8 或 16 起步按任务复杂度和验证集表现往上调如果调到很大才有效果说明 LoRA 的低秩假设不成立会重新评估是否上全参微调。alpha 是干嘛的lora_alpha是缩放因子旁路输出实际会乘上alpha / r再加回主干W_new W (alpha / r) × B × A可以理解成旁路的音量旋钮控制 LoRA 学到的东西以多大强度叠加到原模型上。常见经验alpha 设成 rank 的 2 倍rank8 配 alpha16为什么除以 r这样调大 rank 时旁路整体幅度不会剧烈变化换 rank 不用重调学习率target_modules 挂在哪些层LoRA 不是无脑加所有层最早论文主要加注意力的q_proj、v_proj现在更常见q/k/v/o FFN 投影层加的层越多参数越多、效果可能更好但开销也更大 面试主动提一句 我把 LoRA 加在了注意力和 FFN 的投影层上会显得真调过而不是套默认配置。2.3.QLoRAQLoRA把 便宜 再往死里压一压LoRA 把可训练参数砍到很小了但还有一座大山被冻结的原始模型本身仍要完整加载进显存7B 权重 14GB70B 要 140GB。QLoRA Quantization量化 LoRA核心操作一句话把冻结的基座模型用 4bit 量化压缩后加载而 LoRA 旁路矩阵仍用较高精度训练。效果数值权重从 16bit → 4bit显存降到约1/47B 模型从 14GB →约 3.5GB最终结果单张 24GB 消费卡能微调 30B 模型面试加分词术语作用NF44-bit NormalFloat专为正态分布权重设计的 4bit 类型比普通 int4 更贴合权重分布精度损失更小双重量化Double Quantization连量化常数本身也再量化一次进一步省显存Paged Optimizer分页优化器借显存分页应对训练偶发峰值避免 OOM 崩掉 关键认知QLoRA 不是简单粗暴砍精度而是用 NF4 这种更聪明的量化尽量保住效果。QLoRA 的代价⚠️训练更慢前向要不断把 4bit 反量化回计算精度精度理论上略损NF4 做得好但 4bit 终究比 16bit 信息少 选型逻辑显存够用优先 LoRA卡不够大再上 QLoRA用时间换空间。LoRA 被低估的好处部署灵活LoRA 训出来的只是两个小矩阵几十到几百 MB基座一点没变。这意味着一个基座模型可以同时挂载多个不同 LoRA 适配器按业务需求随时切换。方案三个业务部署占用全参微调3 个独立 7B 模型≈ 42 GBLoRA1 个基座 3 个小适配器≈ 14 GB 多一点这种 一基座多适配器 模式在生产环境非常实用也是面试体现 懂工程落地 的好料。LoRA 不是万能的什么时候它不够下面这些情况LoRA 可能不够要考虑全参微调场景原因与预训练分布差异极大通用中文→全新小语种 / 领域语言低秩假设可能不成立要注入大量全新知识这种情况其实更该先想 RAG确要训进参数低秩容量可能不够追求极致效果且资源充足数据算力管够时全参效果天花板通常略高 但对绝大多数应用开发者90% 的微调需求LoRA 或 QLoRA 都能很好满足。需要全参的是少数别把 LoRA 当成 简化版 / 低配版—— 它在大多数实战里就是性价比最高的正解。2.4.面试官可能会问“你们微调用的什么方法LoRA 吗讲讲为什么用它参数怎么设的。”可以这样答1.“你们微调用的什么方法“我们用的是 LoRA资源紧张的时候用 QLoRA。用 LoRA 的核心原因是省显存。全参微调要更新所有参数梯度和优化器状态的开销比模型权重本身还大。LoRA 把原始权重冻结只在旁路训练两个低秩矩阵可训练参数能降到原来的几百分之一梯度和优化器开销跟着一起降。2.LoRA 吗讲讲为什么用它它的前提假设是微调要学的权重变化量本质上是低秩的——模型已经会了通用能力下游适配只需要在少数几个方向上做调整所以一个低秩矩阵就够表达。3.参数怎么设的参数上rank 我一般从 8 或 16 起步根据任务复杂度和验证集效果往上调如果要调到很大才有效说明 LoRA 不太适合这个任务会重新考虑全参微调。alpha 一般设成 rank 的两倍它是个缩放因子除以 r 是为了让 rank 变化时训练更稳定。LoRA 我会加在注意力的q/k/v/o 和 FFN 的投影层上。如果显存实在不够就上 QLoRA把冻结的基座用 NF4 做 4bit 量化适配器保持高精度代价是训练慢一点、精度略有损失。另外 LoRA 在部署上也有优势一个基座可以挂多个适配器按业务切换不用为每个业务存一整个大模型。”这个回答能体现四件事第一你懂它为什么省梯度和优化器状态。第二你懂它为什么能省低秩假设。第三你懂参数背后的权衡rank、alpha、target_modules。第四你懂工程落地QLoRA、多适配器部署。这比背一句“我们用 LoRA 微调了模型”强太多了。3.RAG vs 微调绝大多数人第一次纠结 微调还是 RAG都从一个错误前提出发模型不知道我们公司业务那我微调一下让它记住不就行了这个理解是错的。微调改的从来不是 模型知道什么而是 模型怎么做。你想让模型…属于谁来干输出固定 JSON 格式行为微调用客服语气说话行为微调医疗 / 法律专业判断风格行为微调知道 这周刚改的退款政策知识RAG知道 这个客户签了哪几条合同知识RAG把知识硬塞进参数里是灾难知识一变就得重训、答错无法追溯、还容易引发灾难性遗忘。RAG 解决的正是这四件事幻觉、私有知识、时效性、可追溯。主线记住缺知识找 RAG缺行为才考虑微调。3.1.缺 知识 还是 行为先问自己 —— 现在效果不好是因为模型不知道还是因为模型做不好模型 不知道知识问题模型 做不好行为问题答不出公司内部文档内容输出格式忽对忽错没法被代码解析说的是半年前旧产品信息语气太官方或太随意编造了不存在的条款专业领域判断风格不地道→ RAG→ 微调很多时候 Prompt 就够最容易混的例子—— 法律合同审查助手效果不好不知道最新法条 / 历史合同 →知识问题 → RAG知道法条但审查报告写得不像律师风格 →行为问题 → 微调 选型第一步永远是先定位问题而不是先选方案。同一个项目不同痛点答案完全相反。四个维度把选型量化下来维度倾向 RAG倾向微调数据量知识量大、文档海量塞不进上下文几百到几千条高质量带标注示范任务类型缺事实知识模型 不知道缺行为能力风格 / 格式 / 语气 / 专业度更新频率知识经常变改一次马上生效行为稳定不会三天两头改成本起步快改文档即可、无需训练数据 训练 评估一次性投入更高① 数据量你手里是 海量文档 还是 高质量示范几千份文档塞不进上下文 → RAG微调吃的不是文档是 输入→理想输出的成对示范关键词微调要的是示范不是资料10 万字产品手册是资料→RAG800 条 用户问 / 客服答 是示范→微调② 任务类型补事实还是改能力答案 对不对 取决于有没有查到正确资料 → RAG答案 好不好 取决于表达方式和专业度 → 微调③ 更新频率知识多久变一次高频更新的东西天然属于 RAG不属于参数想象用微调把价格表训进模型运营每天调价你每天重训一遍④ 成本一次性投入 vs 长期维护RAG 搭好检索链路后改知识≈改文档几乎零额外训练成本微调真正的成本在长期维护基座升级要不要重训数据漂移要不要补训 四个维度其实指向同一个判断 ——你缺的到底是知识还是行为其余维度都在帮你确认这件事。新手最典型的毛病一遇到效果不好第一反应 上微调—— 一上来就掏最重的武器。正确顺序是按成本从低到高试先定位缺什么缺知识、缺行为、还是两样都缺缺知识 → RAG可更新、可追溯不用动模型缺行为 → 先别急着微调再问一句Prompt /few-shot 能不能调好能 → 就用 Prompt很多 格式不稳 问题structured output 就治好了不能且手里有示范数据 → 才轮到微调两样都缺 → RAG 微调一起上成本线Prompt RAG 微调。能用 Prompt 解决的不上 RAG能用 RAG 解决的不上微调。微调是三者里最贵、最难维护、最容易翻车的该是试过前两步都不行之后的选择。3.2.RAG 微调不是单选题。真实复杂系统往往两个都要让它们各管各的线负责保证RAG 知识线去知识库检索最新最准资料拼进 context内容是新的、可追溯的微调行为线处理 context 的是已对齐过的模型懂领域格式 / 语气 / 专业判断输出是稳的、地道的具体场景—— 金融智能投顾助手行情、政策、产品信息每天在变 →RAG实时检索回答必须符合合规话术、专业风格、固定风险提示格式 →微调焊进模型行为 单用 RAG知识够新但话术不专业单用微调话术专业但知识停在训练那天。两条线各管各的才是成熟系统。3.3.面试官可能会问为什么用 RAG 不用微调 或 什么时候该微调什么时候该 RAG我判断的核心是先定位问题效果不好是因为 不知道 还是 做不好 。缺知识内部文档 / 实时数据 / 要追溯来源→ RAG这类知识量大、会变、要可追溯硬训进参数代价太高还可能灾难性遗忘RAG 改文档就能秒级更新。缺行为固定格式 / 特定语气 / 专业判断风格→ 我会先看 Prompt 和 few-shot 能不能解决因为最便宜Prompt 搞不定、又有高质量示范数据才上微调。具体我从四个维度权衡数据量海量文档 vs 少量高质量示范、任务类型补事实 vs 改行为、知识更新频率、一次性与长期维护成本。成本优先级Prompt RAG 微调。很多复杂项目其实是RAG 微调一起用RAG 管实时知识微调管稳定行为。4.面试官可能几会问很多录友一聊到微调面试都有一种拧巴的感觉。答浅了怕面试官觉得你没真做过——“哦就调了个 API 啊。”答深了又怕一脚踩进算法岗的深水区——面试官顺着你的话往下挖“那 PPO 的目标函数你推一下”“LoRA 的低秩矩阵初始化为什么一个高斯一个置零”然后你就卡死在那儿。这就是应用开发者的核心困境你不知道自己该答到哪一层。我先把结论给你面试官问应用岗微调考的从来不是你会不会训模型是你有没有工程判断力。什么叫工程判断力就是这几件事——这个需求该不该微调为什么微调的数据从哪来、靠不靠谱怎么证明微调真有收益而不是“感觉变好了”成本划不划算基模一升级会不会白训。这些问题没有一个需要你手撕训练代码。但每一个都能把“只会跑脚本”的人和“真懂工程”的人区分开。从最上面那句简历开始问题越往下越深先问你为什么微调、怎么选方法再问数据和指标——这些都在应用开发者的必答区里你答不上来就是真没做过。但过了那条红线再往下——loss 怎么推导、PPO 目标函数、分布式训练怎么搭——这就进了算法岗的深水区。应用岗答到“我知道有这回事、大概是干嘛的”就够了没必要硬装精通。装精通的下场是被一个追问当场拆穿。4.1.总原则守住四条线红线以上的所有问题其实都挂在四条线上选型、数据、评估、成本。这张图回答的是面试官五花八门的微调追问怎么归到四条主线上。你看「为什么微调」「SFT/RLHF/DPO 怎么选」归到选型「数据从哪来」归到数据「怎么证明有收益」归到评估「基模变强还要不要微调」归到成本。问法千变万化落点跑不出这四条。拿到任何一道微调题先在心里归个类话术就有了落脚点。把这四条线记牢任何微调题你都能找到落脚点选型为什么微调、为什么不用 RAG/Prompt、用哪种微调方法数据训练数据从哪来、怎么清洗、怎么切分评估怎么证明有收益离线指标、在线指标、对比实验、回归成本训练成本、维护成本、基模升级后会不会白训。面试官的问题再花哨你都先在心里归一下类这是在问选型还是数据还是评估还是成本。归好类话术就有了。Q1你这个项目为什么微调不能用 RAG 或 Prompt 吗选型“我判断的核心是先定位问题模型效果不好到底是因为它‘不知道’还是因为它‘做不好’。如果是缺知识——要回答内部文档、实时数据、还要能追溯来源——我用 RAG不会微调。因为这类知识量大、会变、还要可追溯硬训进参数代价太高改一次就得重训还可能引发灾难性遗忘。我们这个场景缺的是行为——要固定的输出格式 / 特定话术 / 专业判断风格。这种我会先看Prompt 和 few-shot能不能解决因为它最便宜。Prompt 搞不定、手里又有高质量示范数据才上微调。我的成本优先级是 Prompt RAG 微调。”记住一句话就够用缺知识找 RAG缺行为才微调能用 Prompt 绝不训模型。Q2SFT、RLHF、DPO 有什么区别分别适合什么场景选型“SFT 是监督微调给模型看‘输入对应什么输出’的高质量示范适合固定格式、固定话术、工具调用范式这类能写出标准答案的任务。RLHF 和 DPO 都是偏好对齐解决的是‘没有唯一正确答案、但业务明显更喜欢某一种’的问题。RLHF 要先训一个 Reward Model 再用 PPO 优化比较重DPO 直接用chosen/rejected偏好对训练省掉了 Reward Model 和 PPO工程上更轻。所以有了高质量偏好数据我会优先 DPO 而不是一上来做完整 RLHF。”Q3你用 LoRA 训的那 rank 设的多少为什么是这个值参数“我一般从 8 或 16 起步。rank 控制的是低秩矩阵的秩本质是给微调多大的‘改动容量’rank 越大能学的东西越多但参数和显存也越多还更容易过拟合。任务越简单、数据越少我用小 rank8就够任务复杂、数据量大才往上加到 16、32。具体哪个好我不是拍脑袋定的——是固定其他条件、跑几组对比实验看验证集指标选出来的。alphaα阿尔法 我一般设成 rank 的两倍左右控制 LoRA 这部分的更新强度。”Q4你怎么证明微调真的有收益评估首先是对比实验固定测试集拿微调前的基线模型和微调后的模型跑同一批 case对比指标。没有基线对比的‘提升’都是耍流氓。指标我会分几类看任务指标比如 JSON 合法率、分类准确率、信息抽取的 F1、工具调用成功率这是任务本身做没做对质量指标幻觉率、格式错误率、错误拒答率看回答质量成本指标如果微调目标是用小模型替代大模型降本那就看单次调用成本、延迟降了多少风险指标高风险业务还要看越权率、错误放行率有没有下降。然后是回归测试我会留一个固定回归集尤其保留历史失败 case防止‘这个场景好了、另一个场景坏了’。最后还要看线上指标因为离线测试集好不代表真实流量上好。”Q5微调的数据是怎么来的怎么保证质量数据“微调要的是‘示范’不是‘资料’——是‘输入该对应什么理想输出’的成对数据不是一堆文档。原始数据我不会直接用。客服聊天记录里全是坑老规则、错流程、坏话术、隐私信息还有同一个问题好几种互相矛盾的答案。这些不清洗就训模型会一起学进去。我的流程是先清洗去重、去掉过期规则和隐私信息、统一示范格式再人工抽检标注质量最后切训练集和测试集测试集绝不能和训练集重叠。对我来说数据质量比数据量重要得多——脏数据不是资产是污染源。”能讲到数据清洗、去重、切分、失败样本回流这一层面试官立刻知道你是真下场干过的。Q6基模越来越强了垂类微调还有必要吗成本 选型“我觉得要分开看低质量微调会被抹平高质量的行为/偏好/成本控制不会。容易被抹平的是那些补通用能力的微调——拿几千条普通 QA 补知识、没有评测集只靠主观感觉、把动态业务规则硬训进去。这些基模一升级收益就没了因为你补的正是基模迭代最快的部分。不会被抹平的是固定业务流程、品牌话术口径、安全拒答边界、用小模型降本、特定工具调用格式。这些不是‘基模更聪明’就能天然符合我业务的。所以我的判断是——微调的价值正在从‘补能力’转向‘控行为、控偏好、控成本、控风险’。”