目录

1.微调

1.1.SFT（监督微调）

1.2.RLHF（强化学习）

1.3.DPO（直接偏好优化）

1.4.RL

1.5.Prompt、RAG、SFT、DPO、RL 怎么选

1.6.微调评测

1.7.面试官可能会问

2.LoRA/QLoRA（低秩微调）

2.1.LoRA 的核心思想

2.2.rank 和 alpha

2.3.QLoRA

2.4.面试官可能会问

3.RAG vs 微调

3.1.缺 "知识" 还是 "行为"

3.2.RAG + 微调

3.3.面试官可能会问

4.面试官可能几会问

4.1.总原则：守住四条线

Q1：你这个项目为什么微调？不能用 RAG 或 Prompt 吗？（选型）

Q2：SFT、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（监督微调）

SFT（Supervised Fine-Tuning，监督微调）一句话解释： 给模型看 "输入应该怎么对应输出" 的高质量示范，让模型模仿这种回答方式。

比如客服退款场景。用户说："我这个订单能退吗？"

• 差的回答："能退。"
• 更好的示范："请先提供订单号，我会查询订单状态、支付时间和商品类型，再根据平台退款规则判断是否满足退款条件。"

SFT 数据就是大量这种 "问题 + 标准回答"。

模型看多了会学到：遇到退款问题，不要直接下结论，先收集订单号，再查订单状态，最后按规则判断。

SFT 适合什么✅

SFT 适合相对稳定、示范明确、可批量构造数据的任务：

共同点：你能写出 "好答案长什么样"。只要能稳定写出好示范，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 的分数更新模型，同时限制模型不要偏离原模型太远。

✅ PPO（Proximal 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（直接偏好优化）

DPO（Direct Preference Optimization）一句话解释： 直接用 "好回答 vs 差回答" 的偏好对训练模型，让模型更倾向于好回答，不再单独训练 Reward Model，也不走复杂 PPO 流程。

它仍然需要偏好数据：同一个问题下，chosen（更符合业务偏好的回答）+rejected（不符合偏好的回答）。DPO 直接吃这种数据，训练目标就是让模型以后更倾向 chosen，而不是 rejected。

DPO 为什么火🔥

因为它工程上更轻：

• 传统 RLHF 要训练 Reward Model，还要跑 PPO
• DPO 省掉了中间很多复杂环节
• 训练流程更短、调参压力更小、稳定性通常更好、更容易基于已有偏好数据落地

💡 如果你已有一批可靠的偏好对（客服好坏回答、合规 / 不合规回答、正确 / 错误工具调用轨迹），DPO 是更容易起步的选择。

DPO 的边界⚠️

DPO 不是万能替代 RLHF。它的前提是偏好数据质量足够高。如果标注标准混乱（今天喜欢简洁、明天喜欢详细；今天拒答、明天给建议），模型就会左右摇摆。

还有一种场景 DPO 不一定够：Agent 多步执行。模型要在环境里连续行动（理解任务→选工具→填参数→读结果→判断下一步→完成任务）。要优化的是整个任务完成率、工具调用成功率、错误恢复能力，只靠静态偏好对可能不够，更需要真实环境反馈和轨迹级评估。

1.4.RL

很多人把 RLHF 和 RL 混在一起。其实RLHF 是 RL 的一种路线，RL 更宽。

一句话解释：RL 是让模型在环境里做动作，环境给奖励，模型学会让长期奖励更高。它不一定要人类偏好，只要 reward 能定义，就可以有 RL。

💡 这些任务更适合 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 土壤，否则别为了显得高级硬上。

💡微调的价值正在从补能力，转向控行为、控偏好、控成本、控风险。这个判断，比简单说 "微调有用" 或 "微调没用" 更像工程答案。

1.6.微调评测

微调最怕一句话："感觉效果好了。" 这不是工程结论。微调前后，至少要看四类指标。

⚠️ 尤其是 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 精度算一笔账：

💡核心矛盾：只要你要更新全部参数，梯度和优化器状态就甩不掉，显存就降不下来。

所以问题变成：能不能只更新一小部分参数，让梯度和优化器状态只跟着这一小部分走？—— 这就是 LoRA 的出发点。

2.1.LoRA 的核心思想

LoRA 的核心思想：冻结原权重，只学一个 "增量"🧊

LoRA（Low-Rank Adaptation，低秩适配）想法特别朴素，拆成两句话：

1. 原来的模型权重全部冻结，一个都不动；
2. 在旁边新加两个小矩阵，只训练它们，用它们表示 "权重需要变化的部分"。

W_new = W + ΔW 全参微调：直接改 W，ΔW 和 W 一样大 LoRA： 不改 W，用 ΔW = B × A 近似 A 形状 r×d，B 形状 d×r，r ≪ d

训练时 W 冻结，只更新 A、B；推理时把 W + B×A 合并，等价于微调过的权重。

参数量差多少🔍

假设 d = 4096：

💡 可训练参数少 250 倍 → 梯度和优化器状态也跟着少 250 倍 → 显存自然下来。

为什么 "低秩" 就够用🪜

直觉疑问："这么小的矩阵近似大矩阵，信息不会丢吗？"

答案藏在一个观察里：大模型适配下游任务时，权重真正需要改变的方向，其实没那么多。ΔW 虽然形状大，但它 "本质上" 是个低秩矩阵 —— 有效信息维度很低。

打个比方：预训练模型已经会了 99% 的通用能力，微调不是重新教一遍，而是在原能力上 "微调整"。这点调整，用不着满秩大矩阵。

💡低秩不是偷工减料，而是一个假设：微调要学的东西本来就是低维的。实践证明这个假设在绝大多数下游任务上都成立。中间那个 r 像个瓶颈，逼着模型只学最关键的变化方向，而不是漫无目的地乱改。

2.2.rank 和 alpha

rank（秩）怎么设

rank 就是那个瓶颈的宽度：越大，表达越丰富，但参数也越多。

🎤 面试回答模板："rank 控制低秩矩阵的表达能力。我从 8 或 16 起步，按任务复杂度和验证集表现往上调；如果调到很大才有效果，说明 LoRA 的低秩假设不成立，会重新评估是否上全参微调。"

alpha 是干嘛的

lora_alpha是缩放因子，旁路输出实际会乘上alpha / r再加回主干：

W_new = W + (alpha / r) × B × A

可以理解成旁路的"音量旋钮"，控制 LoRA 学到的东西以多大强度叠加到原模型上。

• 常见经验：alpha 设成 rank 的 2 倍（rank=8 配 alpha=16）
• 为什么除以 r？这样调大 rank 时，旁路整体幅度不会剧烈变化，换 rank 不用重调学习率

target_modules 挂在哪些层

LoRA 不是无脑加所有层：

• 最早论文主要加注意力的q_proj、v_proj
• 现在更常见：q/k/v/o + FFN 投影层
• 加的层越多，参数越多、效果可能更好，但开销也更大

🎤 面试主动提一句 "我把 LoRA 加在了注意力和 FFN 的投影层上"，会显得真调过，而不是套默认配置。

2.3.QLoRA

QLoRA：把 "便宜" 再往死里压一压📦

LoRA 把可训练参数砍到很小了，但还有一座大山：被冻结的原始模型本身仍要完整加载进显存（7B 权重 14GB，70B 要 140GB）。

QLoRA = Quantization（量化） + LoRA，核心操作一句话：

把冻结的基座模型用 4bit 量化压缩后加载，而 LoRA 旁路矩阵仍用较高精度训练。

面试加分词📚

💡 关键认知：QLoRA 不是简单粗暴砍精度，而是用 NF4 这种更聪明的量化尽量保住效果。

QLoRA 的代价⚠️

• 训练更慢：前向要不断把 4bit 反量化回计算精度
• 精度理论上略损：NF4 做得好，但 4bit 终究比 16bit 信息少

🧭 选型逻辑：显存够用优先 LoRA；卡不够大再上 QLoRA，用时间换空间。

LoRA 被低估的好处：部署灵活🚀

LoRA 训出来的只是两个小矩阵（几十到几百 MB），基座一点没变。这意味着：

一个基座模型，可以同时挂载多个不同 LoRA 适配器，按业务需求随时切换。

这种 "一基座多适配器" 模式在生产环境非常实用，也是面试体现 "懂工程落地" 的好料。

LoRA 不是万能的：什么时候它不够🚧

下面这些情况，LoRA 可能不够，要考虑全参微调：

💡 但对绝大多数应用开发者：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"，都从一个错误前提出发："模型不知道我们公司业务，那我微调一下让它记住，不就行了？"

这个理解是错的。微调改的从来不是 "模型知道什么"，而是 "模型怎么做"。

把知识硬塞进参数里是灾难：知识一变就得重训、答错无法追溯、还容易引发灾难性遗忘。RAG 解决的正是这四件事：幻觉、私有知识、时效性、可追溯。

💡主线记住：缺知识找 RAG，缺行为才考虑微调。

3.1.缺 "知识" 还是 "行为"

先问自己 —— 现在效果不好，是因为模型"不知道"，还是因为模型"做不好"？

最容易混的例子—— 法律合同审查助手效果不好：

• 不知道最新法条 / 历史合同 →知识问题 → RAG
• 知道法条，但审查报告写得不像律师风格 →行为问题 → 微调

💡 选型第一步永远是先定位问题，而不是先选方案。同一个项目不同痛点，答案完全相反。

四个维度，把选型量化下来📊

① 数据量：你手里是 "海量文档" 还是 "高质量示范"

• 几千份文档塞不进上下文 → RAG
• 微调吃的不是文档，是 "输入→理想输出"的成对示范
• 关键词：微调要的是示范，不是资料（10 万字产品手册是资料→RAG；800 条 "用户问 / 客服答" 是示范→微调）

② 任务类型：补事实，还是改能力

• 答案 "对不对" 取决于有没有查到正确资料 → RAG
• 答案 "好不好" 取决于表达方式和专业度 → 微调

③ 更新频率：知识多久变一次

• 高频更新的东西天然属于 RAG，不属于参数
• 想象：用微调把价格表训进模型，运营每天调价，你每天重训一遍？

④ 成本：一次性投入 vs 长期维护

• RAG 搭好检索链路后，改知识≈改文档，几乎零额外训练成本
• 微调真正的成本在长期维护：基座升级要不要重训？数据漂移要不要补训？

💡 四个维度其实指向同一个判断 ——你缺的到底是知识还是行为，其余维度都在帮你确认这件事。

新手最典型的毛病：一遇到效果不好第一反应 "上微调"—— 一上来就掏最重的武器。正确顺序是按成本从低到高试：

1. 先定位缺什么：缺知识、缺行为、还是两样都缺
2. 缺知识 → RAG：可更新、可追溯，不用动模型
3. 缺行为 → 先别急着微调，再问一句：Prompt /few-shot 能不能调好？
   • 能 → 就用 Prompt（很多 "格式不稳" 问题，structured output 就治好了）
   • 不能，且手里有示范数据 → 才轮到微调
4. 两样都缺 → RAG + 微调一起上

💡成本线：Prompt < RAG < 微调。能用 Prompt 解决的不上 RAG；能用 RAG 解决的不上微调。微调是三者里最贵、最难维护、最容易翻车的，该是试过前两步都不行之后的选择。

3.2.RAG + 微调

不是单选题。真实复杂系统往往两个都要，让它们各管各的：

具体场景—— 金融智能投顾助手：

• 行情、政策、产品信息每天在变 →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 绝不训模型。

Q2：SFT、RLHF、DPO 有什么区别？分别适合什么场景？（选型）

“SFT 是监督微调，给模型看‘输入对应什么输出’的高质量示范，适合固定格式、固定话术、工具调用范式这类能写出标准答案的任务。

RLHF 和 DPO 都是偏好对齐，解决的是‘没有唯一正确答案、但业务明显更喜欢某一种’的问题。RLHF 要先训一个 Reward Model 再用 PPO 优化，比较重；

DPO 直接用chosen/rejected偏好对训练，省掉了 Reward Model 和 PPO，工程上更轻。所以有了高质量偏好数据，我会优先 DPO 而不是一上来做完整 RLHF。”

Q3：你用 LoRA 训的？那 rank 设的多少，为什么是这个值？（参数）

“我一般从 8 或 16 起步。rank 控制的是低秩矩阵的秩，本质是给微调多大的‘改动容量’：rank 越大能学的东西越多，但参数和显存也越多，还更容易过拟合。

1. 任务越简单、数据越少，我用小 rank（8）就够；
2. 任务复杂、数据量大，才往上加到 16、32。

具体哪个好我不是拍脑袋定的——是固定其他条件、跑几组对比实验，看验证集指标选出来的。alpha（α，阿尔法） 我一般设成 rank 的两倍左右，控制 LoRA 这部分的更新强度。”

Q4：你怎么证明微调真的有收益？（评估）

首先是对比实验：固定测试集，拿微调前的基线模型和微调后的模型跑同一批 case，对比指标。没有基线对比的‘提升’都是耍流氓。

指标我会分几类看：

• 任务指标：比如 JSON 合法率、分类准确率、信息抽取的 F1、工具调用成功率，这是任务本身做没做对；
• 质量指标：幻觉率、格式错误率、错误拒答率，看回答质量；
• 成本指标：如果微调目标是用小模型替代大模型降本，那就看单次调用成本、延迟降了多少；
• 风险指标：高风险业务还要看越权率、错误放行率有没有下降。

然后是回归测试：我会留一个固定回归集，尤其保留历史失败 case，防止‘这个场景好了、另一个场景坏了’。最后还要看线上指标，因为离线测试集好不代表真实流量上好。”

Q5：微调的数据是怎么来的？怎么保证质量？（数据）

“微调要的是‘示范’不是‘资料’——是‘输入该对应什么理想输出’的成对数据，不是一堆文档。

原始数据我不会直接用。客服聊天记录里全是坑：老规则、错流程、坏话术、隐私信息，还有同一个问题好几种互相矛盾的答案。这些不清洗就训，模型会一起学进去。

我的流程是：

1. 先清洗去重、去掉过期规则和隐私信息、统一示范格式，
2. 再人工抽检标注质量，
3. 最后切训练集和测试集，测试集绝不能和训练集重叠。

对我来说数据质量比数据量重要得多——脏数据不是资产，是污染源。”能讲到数据清洗、去重、切分、失败样本回流这一层，面试官立刻知道你是真下场干过的。

Q6：基模越来越强了，垂类微调还有必要吗？（成本 + 选型）

“我觉得要分开看：低质量微调会被抹平，高质量的行为/偏好/成本控制不会。

容易被抹平的是那些补通用能力的微调——拿几千条普通 QA 补知识、没有评测集只靠主观感觉、把动态业务规则硬训进去。这些基模一升级收益就没了，因为你补的正是基模迭代最快的部分。

不会被抹平的是：固定业务流程、品牌话术口径、安全拒答边界、用小模型降本、特定工具调用格式。这些不是‘基模更聪明’就能天然符合我业务的。

所以我的判断是——微调的价值正在从‘补能力’转向‘控行为、控偏好、控成本、控风险’。”