03-12 10:01 吉林农业大学算法工程师发布于河北

关注

AI-Agent 面试题汇总 - 大模型微调面

1. 如果想要在某个模型基础上做全参数微调，究竟需要多少显存？

这个问题不能只看模型参数量，还得把训练时真正占显存的几部分一起算进去。全参数微调时，显存通常会被下面这些东西吃掉：

模型参数本身
梯度
优化器状态
前向传播保存的激活值
CUDA 运行时和框架缓存

如果用的是 AdamW 这类优化器，除了参数之外，还要额外维护一阶矩和二阶矩，所以训练显存会明显高于推理显存。一个比较粗糙但实用的经验是：全参数微调的显存，往往是模型权重显存的 6 到 12 倍左右，具体还得看序列长度、batch size、是否开 gradient checkpointing、是否做 ZeRO/FSDP 分片。

拿 7B 模型举例，FP16 权重大概在 14GB 左右，但真正全参训练时，经常不是 14GB、20GB 这种量级，而是会奔着 40GB、60GB 甚至更高去。所以工业界真正落地时，除非资源很充足，否则一般不会优先上全参数微调，而是先用 LoRA、QLoRA 这类方案。

2. 为什么 SFT 之后感觉 LLM 傻了？

这其实是很典型的现象，本质上就是模型被“拉偏了”。预训练阶段，模型是在海量开放语料上学到通用知识和语言模式的；到了 SFT 阶段，如果你喂进去的数据很窄、风格很单一、模板味很重，它就会越来越往这套分布靠，最后通用能力就可能下降。

实际表现通常是这些：

回答变得死板
生成风格明显单一
爱套模板
原本会发散思考的题，变得只会机械回答
拒答变多，或者变得特别保守

还有一种常见情况是，SFT 数据量不算特别大，但监督信号很强。模型会被强行训练成“按这类答案说话”，久而久之就容易把原来的灵活性压掉。如果这时候学习率还偏大、训练轮数还偏多，那就更容易出现所谓“训傻了”的感觉。

想缓解这个问题，最有效的思路一般不是乱调参，而是回到数据和训练策略本身：

SFT 数据不要太窄
混入一部分高质量通用指令数据
学习率别太大
不要训太久
尽量用 PEFT，少动底座参数
训练时同步盯通用评测，不要只看领域指标

3. SFT 指令微调数据如何构建？

SFT 数据的核心不是“做成 json 就行”，而是要让模型学会：用户这样问时，我应该怎样稳定、自然、符合预期地回答。

最常见的数据格式无非两种，一种是 instruction/input/output，另一种是 chat messages。前者比较适合传统单轮任务，后者更适合多轮对话和助手型模型。

像这样就很常见：

{
  "instruction": "请解释什么是过拟合",
  "input": "",
  "output": "过拟合是指模型在训练集表现很好，但在测试集泛化能力较差。"
}

或者：

{
  "messages": [
    {"role": "system", "content": "你是一名AI助手"},
    {"role": "user", "content": "请解释什么是过拟合"},
    {"role": "assistant", "content": "过拟合是指模型在训练集表现很好，但在测试集泛化能力较差。"}
  ]
}

真正难的不是格式，而是样本质量。一份好的 SFT 数据集，通常要满足几个条件：任务覆盖够广、答案风格统一、事实正确、拒答逻辑清楚，而且不能全是那种“客服八股文”。

如果数据里全是特别短、特别模板化的答案，模型最后大概率就会学成“看起来很标准，但一点都不好用”的样子。如果数据里错误很多，那模型也会很老实地把错误学进去。

实际构建时，一般会先做数据采集，再做清洗、去重、统一模板，之后再人工审核，最后划分训练集和验证集。

def build_sft_sample(instruction, output, input_text=""):
    return {
        "instruction": instruction.strip(),
        "input": input_text.strip(),
        "output": output.strip()
    }

sample = build_sft_sample(
    "请将下面文本总结为一句话",
    "该文本主要介绍了大模型微调中的常见问题。",
    "大模型微调通常包括继续预训练、SFT、偏好优化等阶段。"
)
print(sample)

4. 领域模型 Continue PreTrain 数据选取？

继续预训练的目标，不是教模型“怎么回答”，而是给模型补领域知识。所以选数据的时候，最重要的不是格式多漂亮，而是这批数据能不能真正代表这个行业。

比如你做医疗模型，那就应该重点找：

医疗教材
临床指南
药品说明书
医学论文
标准化问诊文本
医保和诊疗规范

如果做金融，就应该尽量覆盖：

财报
公告
法规
风控规则
基金和证券材料
客服知识库

很多人容易踩的坑是，觉得“领域语料越多越好”，于是把一堆爬虫网页、低质量论坛、OCR 乱码也丢进去。这样看起来语料量很大，实际上有效知识密度非常低，甚至会把模型训坏。

所以 continue pretrain 的数据挑选标准，通常就围绕这几件事：

和业务强相关
质量高
覆盖面足够
重复少
不要全是碎片化短文本
最好混一点通用语料，防止模型只会说行业黑话

5. 领域数据训练后，通用能力往往会有所下降，如何缓解模型遗忘通用能力？

这是继续预训练很常见的副作用。因为你不断拿领域数据去更新参数，模型自然会越来越适应这个分布，原来在开放域上学到的一些能力就容易被覆盖掉。

最直接的办法其实就是别把门关死。也就是说，领域数据不要“独占训练集”，最好混入一部分通用语料。很多团队会用类似 7:3、8:2 这样的比例，把领域语料和通用语料混着训，效果通常比纯领域数据稳定很多。

另外，学习率也不能太大。继续预训练不是从零开始，模型已经有很强的能力底子了，这时候如果更新太猛，就容易把老能力冲掉。训练轮数同样不能贪多，很多时候不是“再训一点会更好”，而是“再训一点就开始坏”。

如果资源允许，也可以引入一些正则约束，比如约束新模型输出不要偏离原模型太多。但在大多数业务场景里，最实用的还是这几件事：

通用语料混训
学习率调小
控制训练轮数
训练中持续做通用评测
发现能力明显漂移时尽早停

6. 领域模型 Continue PreTrain，如何让模型在预训练过程中就学到更多的知识？

这个问题本质上不是“怎么把更多文本喂进去”，而是“怎么让模型更有效地吸收知识”。

真正有用的做法，通常都围绕“语料质量”和“知识组织方式”。

首先，语料一定得干净。如果一份文本里全是重复段落、乱码、无意义标点、错误抽取内容，那模型学到的不会是知识，而是噪声。所以去重、去脏、去模板污染，这些前处理工作非常重要。

其次，文本最好有完整结构。如果切分得太碎，章节被切断，定义、解释、结论分散在不同片段里，模型其实很难学到成体系的知识。所以在切 chunk 时，不要只盯着固定长度，也要考虑段落、标题、章节边界。

再一个是采样策略。知识密度高的文本，比如标准文档、教程、术语解释、FAQ 问答、操作规范，这些语料的价值往往远高于大量闲聊和低信息网页。如果能把结构化知识转成自然语言再混进去，效果通常也会更好。

7. 进行 SFT 操作的时候，基座模型选用 Chat 还是 Base？

这个问题没有绝对答案，关键看你要做什么。

如果你的目标是快速做出一个可用的助手，尤其是客服、问答机器人、多轮对话这种场景，那一般优先选 Chat 模型。因为它已经具备基本的指令跟随和对话风格，你只要拿业务数据去做进一步对齐，往往比较快就能出效果。

但如果你要做的是很深的行业定制，比如：

特定输出模板
很强的风格控制
特殊安全边界
特定任务链路

那 Base 模型 反而更有可塑性。它不像 Chat 模型那样已经被强烈对齐过，所以更容易被你重新塑造成你想要的样子。

缺点也很明显。Base 起步更难，需要更多高质量 SFT 数据去教它“怎么说话”；Chat 则起步快，但继续微调时可能会和它原有的对齐风格打架。

一句话说就是：想快，优先 Chat；想深度定制，Base 往往更合适。

8. 领域模型微调指令和数据输入格式有什么要求？

格式统一这件事，看起来像小事，实际上非常重要。因为模型学到的不只是内容本身，还会把“这个任务一般长什么样、角色怎么分、答案怎么收尾”一起学进去。

所以领域微调数据最好做到这些：

用户输入和模型输出边界清楚
system、user、assistant 角色定义明确
同一类任务的风格尽量统一
长文本任务有明确截断规则
标签表达保持一致，不要一会儿“是/否”，一会儿“正确/错误”，一会儿“1/0”

如果是企业内部助手，语言风格最好贴近真实业务场景，别全是互联网通用问答那种味道。因为你最后想训练出来的模型，不是会“标准回答”，而是会“像你们业务系统里的助手那样回答”。

{
  "messages": [
    {"role": "system", "content": "你是一名医疗问答助手，请基于已知资料回答，不知道就明确说明。"},
    {"role": "user", "content": "糖尿病患者能否长期空腹？"},
    {"role": "assistant", "content": "一般不建议长期空腹，具体需要根据血糖控制情况和医生建议决定。"}
  ]
}