你可能听过「微调能让模型更懂你的业务」，但打开文档一看全是数据集、显存、LoRA 这些词，不知道从哪下手。这篇不教你跑通某一条命令，而是先把概念和地图铺清楚：微调改的是模型的什么、一次微调从准备到上线要经过哪几个环节、市面上几种主流做法各自适合什么情况，最后告诉你哪些需求其实用提示词或检索就能解决，不必动微调。看完你能判断自己该不该走这条路、大概要走哪条。
你可能听过「微调能让模型更懂你的业务」，但一打开文档，全是数据集、显存、LoRA 这些词，根本不知道从哪下手。这篇不教你跑通某条命令，而是先把地图铺清楚：微调到底改的是模型的什么、一次微调从准备到上线要经过哪几个环节、市面上几种主流做法各自适合什么情况。看完你至少能判断自己该不该走这条路、大概要走哪一档。
先给个结论垫底：微调不是万能钥匙，它更像「上岗前针对岗位再练一遍」。很多需求用提示词或检索就能解决，硬上微调只会把时间烧在整理数据上。下面按「是什么—怎么做—怎么选—什么时候别做」四步走，每步都给判断标准和可执行动作。
微调到底改了什么
打个比方：预训练像让模型读完一屋子书，什么都知道一点，但不知道你要它干什么；微调就是上岗前针对岗位再练一遍，让它习惯你的说话方式和任务格式。技术上，训练过程会调整模型内部的大量数值参数，让它在你的样本上表现更好。注意，它改的是「倾向」而不是「知识库」，这点后面会反复用到。
判断要不要微调，先把你手上的需求归归类。下面三类是最常见的，微调只擅长其中一部分，别搞混。
| 需求类型 | 典型表现 | 微调是否擅长 |
|---|---|---|
| 改变输出风格 | 希望回答更简短、更正式、更像客服话术 | 比较擅长，样本几十到几百条就可能见效 |
| 固定任务格式 | 每次都要输出固定字段的 JSON 或固定结构的报告 | 比较擅长，格式类任务样本容易造 |
| 补充领域知识 | 想让模型知道公司内部制度、最新产品参数 | 不擅长，实时和长尾知识应该交给检索 |
| 提升事实正确性 | 希望回答不再胡说、数字不再编 | 不擅长，微调不会保证事实准确 |
更实用的判断法是问自己一句：这个要求，我能不能用一段指令说清楚？能说清就别微调。如果不能，再问：是不是只要把资料查出来喂给模型就行？能查就别微调。这两关都过不了的，才轮到微调上场。想看各家模型在指令跟随上的差异，可以到 /models 对照当时的资料再决定基座。
一次微调要经过哪几个环节
微调是个流水线，不是一条命令。把它拆成六步，每一步都有明确的产出物，出问题才知道回退到哪。
- 明确目标与验收标准先写清楚「做成什么样算成功」，比如格式错误率降到多少、某类问题的回答通过人工抽查。没有验收标准的微调，最后只能凭感觉说「好像好了一点」。
- 准备与清洗样本把真实场景的输入输出整理成一条条样本，去重、去矛盾、去错误标注。这一步通常占整个项目最多时间，样本质量比数量更决定结果。
- 选基座与训练方式根据任务复杂度、预算和算力选一个基座，再决定用全参还是轻量方式。基座能力不够时，微调也救不回来。
- 训练与调参先用小批量样本跑通流程，确认识别、保存、加载都没问题，再逐步加数据。每次只改一个变量，方便定位问题。
- 评测拿一份没参与训练的样本做盲测，最好是同一批问题对比微调前后的输出，而不是只看训练时的指标。
- 部署与持续迭代上线后收集真实 bad case，定期回流成新样本。微调不是一次性动作，而是循环。
这里最容易踩的坑是：每一步都改了东西，最后效果变差，却说不清是数据、参数还是基座的问题。所以每个环节都留好版本，模型文件、数据集、配置分开存放，能一键回到上一版。数据准备做得好不好，比用什么高级训练技巧重要得多。
常用方法体系怎么分
方法名字很多，但按三个维度切就好记：动多少参数、用什么数据、谁来干。先看第一个维度，它决定了你要多少显存。
- 改动全部参数：效果上限高，但对显存和算力要求最高，小团队要慎重
- 只训练一小部分附加参数：基座冻结，额外加一小块可训练的部分，显存门槛低很多，是入门主流
- 不动权重只做对齐类调整：用偏好类样本引导输出倾向，通常作为第二步使用
- 只调推理侧参数：连训练都不做，靠解码参数和提示模板微调输出，成本最低但能力提升有限
第二个维度看数据形态。指令样本适合教格式和风格，偏好对比样本适合教「哪个回答更好」，领域问答样本适合让模型熟悉某类问题的表达方式。目标是格式就攒指令样本，目标是语气和取舍就攒偏好样本，别什么都往一个数据集里塞。
第三个维度看谁来干。自己租卡跑最灵活也最费人；用托管微调服务省运维，但要注意数据留存和迁移成本；只调推理侧参数门槛最低，适合验证需求是否真实存在。托管服务的可信度和计费方式，可以到 /sites 看当时的检测结论和用户反馈。
| 你的目标 | 数据量级参考 | 算力要求 | 上手难度 |
|---|---|---|---|
| 只想改语气和格式 | 几百条以内 | 低 | 容易，优先考虑轻量方式 |
| 让模型熟悉一类任务 | 几千条量级 | 中等 | 需要调参经验 |
| 显著提升某领域能力 | 上万条且质量高 | 高 | 建议有专人负责数据和训练 |
| 只是验证需求 | 几十条即可 | 极低 | 先做小规模对照实验 |
具体到价格和算力开销，站内的数字会随时间和活动变化，到 /price-watch 核对当时的行情，别拿几个月前的印象做预算。
什么情况下先别碰微调
有三类情况，建议先去做提示词和检索，别一上来就开训练。
- 样本凑不齐：手上只有几十条真实对话，还都是同一类问题，强行微调只会过拟合
- 目标隔两周就变：业务还在快速调整，今天要的格式下个月就变，微调的成本追不上变化
- 只是想让模型答得更准：先检查是不是提示词太模糊、是不是该把资料检索出来喂进去
还要说清微调不解决什么：它不带来实时知识，模型不会知道你昨天刚改的价格；它不保证事实正确，样本里有的错误它照样学；它也挡不住提示词注入这类攻击，安全策略要在调用层和检索层做。把这些边界记住，能省下很多无效训练。
如果你判断确实需要微调，先跑一个小规模对照实验：同样一批问题，一组用提示词加检索，一组用微调，让不知道分组的人盲评。哪边赢、赢多少，心里有数了再决定要不要扩大投入。这个实验通常几天就能出结论，比直接上大规模训练划算得多。
下一步先去站内工具目录挑一个能做小规模对照实验的方案，看看当前可用的托管和自建路径，再回来决定要不要动微调。→常见问题
微调和提示词、检索到底怎么选？
先用最简单的办法试：如果只是要求输出格式和语气，写清楚指令通常就够；如果是模型不知道你公司的内部资料，先上检索；只有当风格、格式或判断口径怎么改指令都稳定不下来、而且你手上有成百上千条像样的样本时，再考虑微调。可以到 /ai-dict 先把几个相关术语的意思对齐，再决定。
微调需要多少数据才够？
没有统一数字，取决于任务难度和目标。改动越接近「换个说法」「固定格式」，需要的样本越少；要让模型掌握一套新的判断标准，样本就要多得多，而且每条都得是你认可的正确答案。起步阶段建议先做几十条高质量样本跑一轮对照，看趋势再决定加量，别一上来就攒几千条。
自己微调还是找托管服务？
看两件事：你有没有稳定的数据和长期维护的人，以及你能不能接受数据离开自己的环境。只是想验证效果，托管服务上手快；数据敏感或要长期跑，就得把算力和部署一起算进来。具体有哪些服务商和算力口径，可以到 /stacks/fine-tuning 和 /compute 两页对照着看。
