要不要做微调 / Post-Train 项目，轻量版怎么做

对多数转应用开发岗的人，微调不是必做项。面试更常考的是"你知不知道什么时候该微调、和 RAG / Prompt 怎么取舍"，而不是你手搓过多复杂的训练。真要做，做一个目标清晰、有评估、能说清收益的轻量 LoRA / SFT 就够了，不必一上来啃工业级 Post-Train。这一页帮你判断该不该碰微调，以及如果要做，轻量版的最小证据链长什么样。 作者：吴师兄 | 适合：纠结要不要做微调项目、把 LoRA / SFT 写进简历的转行者 | 前置：知道 RAG / Agent 是什么，看过技术栈全景 转应用开发岗，到底要不要做微调项目 看你投的岗位，多数应用开发岗"知道何时用微调"比"做过微调"更重要，不必硬凑一个微调项目进简历。 面试官问微调，大多数时候不是要验证你会不会写训练脚本，而是要验证你的判断力：遇到一个需求，你能不能分清它该用 Prompt、该用 RAG 还是该微调。这道判断题答错，比你没做过微调项目扣分更多。下面这张表按目标岗位给出优先级，先对号入座再决定投入。 | 你的目标岗位 | 微调优先级 | 该做到什么程度 | |---|---|---| | 大模型应用开发(RAG / Agent 工程) | 低 | 知道何时该微调、和 RAG / Prompt 怎么取舍；有余力做一个轻量 LoRA / SFT 加分，但别为它挤掉 RAG / Agent 主线 | | 应用算法 / 偏模型的算法岗 | 高 | 值得做深：自己构造数据、跑 SFT / LoRA、设计评估、能拿出实验证据说明收益和代价 | | 研究生算法向(想进模型团队) | 高 | 在应用算法基础上再往 Post-Train 深水区走一点：DPO/GRPO、对齐、训练数据设计，最好有一段相关实习或课题 | | 平台 / 推理工程岗 | 低 | 重点在服务化、推理优化，微调只需知道产物怎么部署，不必自己训 | 读这张表的关键：如果你是奔着 RAG / Agent 应用开发去的，微调是选修不是必修；真正非做不可的是应用算法和研究生算法向。别看别人简历上有微调就焦虑，先看你们投的是不是同一类岗。 何时该微调，何时该用 RAG 或 Prompt 这是面试高频判断题，记住一句话，知识更新问题用 RAG，风格/格式/固定行为问题用微调，简单约束用 Prompt。 很多人把这三件事混着用，面试一问就露怯。它们解决的是完全不同的问题: | 需求类型 | 该用什么 | 为什么 | |---|---|---| | 让模型基于最新/私有知识回答(文档、数据库、时效信息) | RAG | 知识会变，塞进检索库随时更新，微调进权重的知识改起来贵又慢 | | 让模型稳定输出某种风格、格式、固定行为模式(比如固定 JSON 结构、特定话术、领域语气) | 微调(SFT / LoRA) | 这类"行为习惯"靠 Prompt 反复叮嘱不稳定，写进权重才可靠 | | 一次性的简单约束、任务说明、少量示例 | Prompt / few-shot | 改一行提示词就能调，成本最低，能用 Prompt 解决就别上微调 | | 需要模型学会调用某类工具、走某种多步轨迹 | 微调(轨迹数据)或 Agent 编排 | 简单的用编排+Prompt，复杂稳定需求才上轨迹微调 | 一个实用的判断顺序：能用 Prompt 解决就别 RAG，能用 RAG 解决就别微调。微调是三者里最贵、最难维护的，只有当问题本质是"改模型的行为习惯"而不是"补知识"时才动它。面试里你能把这个取舍讲清楚，比你真训过一个模型更能打动人。这套判断该落在什么技术主线上，可以对照 技术栈全景怎么选主线。 轻量微调项目的最小证据链 如果你决定做，一个能过面试的轻量微调项目必须凑齐五个环节，缺了评估和收益说明的微调项目等于没做。 面试官盯着微调项目会追问"你怎么证明它有用"，所以项目的价值不在你跑通了训练，而在你能不能拿出一条完整的证据链。下面这张表是最小配置，每一环都要能讲。 | 环节 | 要做到 | 面试会追问 | |---|---|---| | 目标定义 | 明确"要改模型的什么行为"，一句话说清(比如让客服模型固定用某种话术+结构化输出) | 这个目标为什么不用 Prompt/RAG 解决 | | 数据构造 | 说清数据从哪来、多少条、怎么清洗和构造成训练格式、正负样本怎么定 | 数据质量怎么保证、有没有污染或泄漏 | | LoRA / SFT 训练 | 用 LoRA 等轻量方式跑通，记录关键超参(rank、学习率、轮数)和为什么这么设 | 为什么用 LoRA 不全参、显存怎么估 | | 评估(含通用能力有没有退化) | 有针对目标任务的评估集看收益，同时测一组通用能力题看有没有"练偏" | 你拿什么指标、通用能力退没退化怎么验证 | | 收益说明 | 用数据说清"微调后比 Prompt/RAG 基线好在哪、代价是什么" | 收益值不值这个成本、上线要不要维护 | 这五环里，新手最容易只做前三环(定义、数据、训练)就以为完事，恰恰是后两环(评估、收益)决定项目成色。尤其"通用能力有没有退化"这一项，微调很容易让模型在你的小任务上变好、在其他能力上变差，面试官几乎必问，你得提前测好。想看评估怎么系统设计，可以顺带刷 评估与监控题库。 工业级 Post-Train 长什么样(深水区参照) 工业级 Post-Train 和你自学的轻量 LoRA 完全是两个投入量级，知道它长什么样，是为了帮你判断"自学到哪算够"。 真实的工业级后训练是一整套闭环：SFT 打底 → 课程式(curriculum)数据分阶段喂 → RL 阶段用 DPO/GRPO 等做偏好对齐 → 工具调用轨迹数据训练 Agent 行为 → 再回到评估和数据迭代。它依赖大量高质量标注、稳定的训练基础设施、专门的评估体系，一个人在自己机器上基本复现不了全貌。 给你的定位建议：应用开发岗自学到"能做一个有评估的轻量 LoRA / SFT、能讲清 RAG / Prompt / 微调取舍"就够了，再往上是应用算法和研究生算法向的战场。想看这套训练闭环在一个真实 Agent 项目里怎么落地，可以读 Deep Research 的训练章；而完整的工业级 Post-Train 内容(SFT/RL 闭环、DPO/GRPO、轨迹数据)属于系统深挖的范畴，训练营 里有专门拆解，自学时先不必强求覆盖这一层。 两类人：研一 / 研二 vs 3 年 Java 后端 同样是"微调"，在校生和在职后端该做的事实质不同，一个可以做深攒实验证据，一个应该做透 RAG / Agent、微调只做轻量的。 | 人群 | 微调该投多少 | 起点与打法 | 别做什么 | |---|---|---|---| | 研一 / 研二在校生 | 可以做深 | 有算力和方向的，把微调当一条能出实验证据的线：自己设计数据、跑 SFT / LoRA、做消融、写清楚收益和退化，配合课题或实习最有说服力 | 别只跑通一个 demo 就停，没有实验对比等于没做深 | | 3 年 Java 后端 | 只做轻量，优先级靠后 | 先把 RAG / Agent 做透，让项目吃到你的服务化、数据管线、稳定性经验；微调只需知道何时用、能讲取舍，有余力再补一个轻量 LoRA | 别为了简历好看硬凑深度微调，你的杠杆在工程不在训练 | 为什么区别这么大：在校生有时间、有算力、有课题可以把微调做成有实验证据的深度项目，这正是算法岗看重的；在职后端的竞争力在工程落地，应该让 RAG / Agent 项目吃到你多年的后端经验，而不是去和应届生拼训练调参。想清楚自己这条线怎么走，分别可以看 研究生怎么转大模型 和 Java 后端转大模型的路径。 一个具体反例：为简历硬做的微调 最常见的翻车：为了简历好看，硬做一个微调项目，没有评估、说不清比 Prompt/RAG 好在哪，还顺手把模型的通用能力练退了。 这种项目在简历上看着唬人，"基于 LoRA 微调了 XX 模型"，但面试官一追问就崩："你怎么证明微调有收益？"答不上具体指标；"和直接用 Prompt/RAG 比好在哪？"没做过基线对比；"通用能力有没有下降？"根本没测过。三连问下来，面试官的判断是：这人不懂微调该什么时候用，也不懂怎么衡量效果，微调对他只是个简历装饰。 结果往往比不写这个项目还糟，因为它暴露了你缺少"判断和验证"的能力，而这恰恰是应用开发岗最看重的。与其硬凑一个说不清收益的微调，不如把一个 RAG / Agent 项目的评估闭环讲透。 选定之后的行动清单 还没想清微调在整张技术地图里该占多少权重：看 技术栈全景怎么选主线，先定主线再决定要不要分精力给微调。 决定不做微调项目、只需应对面试判断题：刷 模型微调题库 和 RLHF 与对齐题库，把概念和取舍题过一遍就够。 决定做一个轻量微调：按本页的"最小证据链"五环走，重点补上评估和收益说明两环。 想看训练在真实 Agent 项目里怎么用：读 Deep Research 的训练章，理解 Post-Train 在系统里的位置。 主线其实该放在 RAG / Agent：回去先把 怎么做一个 RAG 项目 或 怎么做一个 Agent 项目 做透。 常见问题 转大模型应用开发，必须做微调项目吗? 不必须。多数应用开发岗(RAG / Agent 工程)看重的是你知不知道何时该微调、和 RAG / Prompt 怎么取舍，而不是你训过模型。有余力做一个有评估的轻量 LoRA 加分，但别为它挤掉 RAG / Agent 主线。真正需要做深微调的是应用算法和研究生算法向。 什么时候该微调，什么时候用 RAG 或 Prompt? 一句话：知识更新问题用 RAG，风格/格式/固定行为问题用微调，简单约束用 Prompt。判断顺序是能用 Prompt 就别 RAG、能用 RAG 就别微调，因为微调最贵、最难维护。只有问题本质是"改模型的行为习惯"而不是"补知识"时才动微调。这是面试高频判断题。 LoRA / SFT 项目值不值得写进简历? 看你怎么做。如果只是跑通训练、没评估、说不清收益，反而暴露短板，不如不写。值得写的微调项目要有完整证据链：目标定义、数据构造、训练、评估(含通用能力有没有退化)、收益说明。缺了评估和收益说明的微调项目等于没做。 面试问微调，通常考什么? 大多考判断力而非动手细节：什么场景该微调、和 RAG / Prompt 怎么取舍、微调后怎么评估收益、通用能力会不会退化、为什么用 LoRA 不用全参。真做过项目的还会被追问数据怎么构造、超参怎么定。把取舍和评估讲清楚，比强调你训过多大模型更有用。 自学微调要不要学到 DPO/GRPO 这些? 应用开发岗不必强求。自学到"能做一个有评估的轻量 SFT / LoRA、能讲清取舍"就够了。DPO/GRPO、课程式训练、工具调用轨迹数据这些属于工业级 Post-Train 深水区，是应用算法和研究生算法向的战场，再往上是另一个投入量级，按目标岗位决定要不要碰。 相关阅读 大模型技术栈全景：RAG / Agent / 微调各是什么、怎么选主线 Deep Research 的训练章：Post-Train 在真实 Agent 项目里怎么用 模型微调题库：何时该微调、LoRA 与全参怎么选的高频考点 RLHF 与对齐题库：DPO/GRPO 与偏好对齐的面试题 研究生怎么转大模型：有算力和方向的人该怎么做深