当“祝福 AI”开始被提更多需求时

几乎所有祝福类应用，在跑通第一个版本之后，都会遇到一个非常现实的问题：

“既然能写拜年祝福，
那能不能顺便写感谢信？
再顺便加个道歉模板？”

从产品角度看，这个需求非常合理。
从工程角度看，这却是一个危险的拐点。

因为你正在从：

• 单一表达目标
• 走向
• 多种情绪、不同语气、不同风险等级的表达任务

而你要做出的第一个技术选择是：

是继续微调一个模型，
还是为每一种表达拆模型？

这篇文章，就是围绕这个问题展开的。

一、先别急着谈“多任务”，先谈这三件事到底差在哪

表面上看，拜年、感谢、道歉都属于“情绪表达类文本”，
但在工程视角下，它们的差异非常大。

拜年

• 正向情绪
• 风险低
• 可适度夸张
• 用户对“具体性”要求高，对“准确性”要求相对低

感谢

• 中性偏正
• 需要具体，但不能过度
• 容易显得公式化
• 语气失衡会让人感觉敷衍

道歉

• 负向情绪
• 风险最高
• 极其依赖分寸
• 一个措辞不当，可能引发反感或法律风险

这三类任务，并不是“换几个关键词”那么简单。

二、为什么“一个模型搞定所有人情话”这么诱人

尽管风险明显，但多任务微调的诱惑非常大：

• 少维护一个模型
• 统一部署
• 数据和工程流程复用
• 用户体验看起来更“智能”

从技术上看，多任务微调也并非新鲜事：

• 共享 backbone
• 不同任务混合训练
• 用任务标识或指令区分

问题在于：

表达类任务的“冲突”，
往往不是在语义层面，
而是在“表达偏好”层面。

这也是多任务微调最容易被低估的风险来源。

三、多任务微调在表达任务里，真正学到的是什么

在像这样的系统里，微调学到的并不是：

• “如何写一句拜年祝福”
• “如何表达感谢”

而是更底层的东西：

在什么情况下，
哪些表达是“更安全、更合适、更优先”的。

当你把多种任务混在一起训练时，模型学到的是：

• 各类表达在同一空间里的相对位置
• 哪些语气是“高频安全区”
• 哪些极端表达应该被压制

这听起来很好，但问题也正出在这里。

四、一个真实的风险：表达任务会互相“污染”

在多任务微调中，最常见、也最隐蔽的问题是：

低风险任务，会拉高高风险任务的表达概率。

举个非常具体的例子：

• 拜年任务中，夸张、热情、轻松是加分项
• 但这些特质一旦“泄漏”到道歉任务中，就会变成灾难

你会看到类似输出：

“真的非常非常抱歉这次给您添麻烦了，希望您新的一年也一切顺利～”

从语言角度看没错，
从情绪逻辑上看，却非常不合适。

五、那是不是多任务微调就不可行？

不是。

关键不在于“能不能多任务”，而在于：

这些任务在“表达偏好空间”里，
是否能共存。

在工程上，一个可行的判断标准是：

• 是否都属于同一情绪方向
• 是否对风险容忍度相近
• 是否允许相似的语气策略

例如：

• 拜年 + 节日问候
• 感谢 + 表扬
  通常是可以共存的。

但：

• 拜年 + 严肃道歉
• 感谢 + 投诉回复
  就需要非常谨慎。

多任务可共存性判断矩阵

六、如果扩展多任务，合理的做法是什么

如果从这个系统继续扩展，比较理性的路径是：

• 第一阶段：单任务（拜年）跑稳风格
• 第二阶段：引入表达相近的子任务（如感谢）
• 第三阶段：对高风险任务（道歉）保持隔离

这可以通过几种工程手段实现：

• 明确的任务标签
• 严格控制任务比例
• 对高风险任务单独评估

关键不是“一个模型全干”，而是：

哪些东西值得共享，
哪些东西必须隔离。

七、多任务微调中，任务比例比你想象得更重要

一个常被忽略的事实是：

模型并不知道哪个任务“更重要”，
它只知道哪个任务“出现得更多”。

如果拜年数据占 70%，感谢占 20%，道歉占 10%，
模型学到的整体表达偏好，一定会偏向：

• 更积极
• 更热情
• 更安全

这在拜年任务里是好事，
但在道歉任务里，可能就是问题。

所以在多任务微调中：

• 数据比例
• 采样策略
• loss 权重

本质上都是在调：

模型的“表达倾向分布”。

八、评估层面：多任务最容易“看起来都还行”

多任务微调还有一个非常危险的错觉：

每个任务单独看，好像都能用。

但一旦你把它们放在一起对比，就会发现：

• 风格边界开始模糊
• 某些语气变得“似曾相识”
• 极端场景下更容易翻车

这也是为什么多任务模型的评估，必须按任务拆开看，而不能只看总体感觉。

单任务评估 vs 多任务拆分评估

九、什么时候该果断拆模型

如果在多任务微调过程中，你开始看到以下信号，就该考虑拆模型了：

• 某个高风险任务开始频繁出现“不合适但不算错”的输出
• 调一个任务，另一个任务明显变差
• 你开始靠 prompt 修补微调带来的副作用

这些信号说明的不是“你调得不够”，而是：

这些任务，本来就不该共享同一套表达偏好。

在多任务表达类微调中，最大的挑战往往不是训练，而是判断哪些任务可以共存、哪些必须拆开。借助LLaMA-Factory Online做小规模、多版本的对照微调，更容易提前发现任务间的风格冲突，而不是等到上线后才被用户反馈“怪怪的”。

总结：多任务微调，调的不是能力，是边界

用一句话收尾这篇文章：

多任务微调不是“让模型会更多”，
而是让你更早面对一个问题：
哪些东西，本来就不该混在一起。

在拜年、感谢、道歉这样的表达任务中：

• 技术难点不在模型
• 而在“人情世故的边界”

一个成熟的工程选择，往往不是“一个模型全搞定”，
而是知道什么时候该停下，什么时候该拆开。