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