ms-swift框架下SAPO与GSPO算法在决策任务中的表现

在构建真正“聪明”的AI系统时，我们常常会遇到一个尴尬的局面：模型能写出语法完美的句子，也能在单轮问答中给出看似合理的回答，但一旦进入多轮交互、复杂推理或需要长期策略的任务——比如客服流程引导、医疗问诊辅助、金融理财规划——它就容易“走偏”，甚至越说越错。根本原因在于，传统训练方式如监督微调（SFT）和直接偏好优化（DPO）只关注最终输出的优劣，而忽略了过程的质量。

正是为了解决这一瓶颈，魔搭社区推出的ms-swift框架引入了 SAPO（Step-Aware Policy Optimization）与 GSPO（Generalized Stepwise Preference Optimization）两类前沿强化学习对齐算法。它们不再满足于“结果正确”，而是深入到每一步生成过程中，像一位经验丰富的导师那样，在关键时刻给予反馈、纠正方向、平衡风格，从而让模型学会如何“一步步把事情做对”。

从“看结果”到“看过程”：SAPO 的设计哲学

传统的DPO方法依赖成对的数据样本，例如两条完整回复A和B，标注出哪条更优，然后通过对比学习调整策略。这种方式简单有效，但在面对多步任务时显得力不从心。试想一个数学解题场景：模型前几步推导完全正确，最后一步计算失误导致答案错误——按照DPO逻辑，整条轨迹都会被判定为“差”，这种粗粒度惩罚极易误导模型放弃正确的中间路径。

SAPO 正是为此而来。它的核心思想是：行为的价值不仅取决于终点，更由过程决定。为此，SAPO 引入了“步级奖励分解”机制，将原本单一的整体评分拆解为多个时间步上的局部反馈信号。

具体来说，SAPO 的训练流程包含四个关键环节：

轨迹采样：让当前策略 $ \pi_\theta $ 在给定提示下生成完整的推理链或对话序列 $ \tau = (s_1, a_1), …, (s_T, a_T) $。
细粒度标注：人工或自动奖励模型对每个步骤 $ t $ 输出的动作 $ a_t $ 给出局部奖励 $ r_t $，形成逐层评价体系。
优势估计：采用GAE等时序差分技术计算每个动作的优势值 $ A_t $，衡量其相对于平均表现的超额贡献。
策略更新：使用类似PPO的目标函数进行梯度优化：
$$
\mathcal{L}{\text{SAPO}} = \mathbb{E}_t \left[ \min\left( \frac{\pi\theta(a_t|s_t)}{\pi_{\text{ref}}(a_t|s_t)} A_t, \text{clip}\left(\frac{\pi_\theta}{\pi_{\text{ref}}}, 1-\epsilon, 1+\epsilon\right) A_t \right) \right]
$$

这个公式看起来熟悉吗？没错，它继承了PPO的稳定性设计，但输入的是步级优势信号而非全局回报。这意味着模型不仅能学到“什么样的回答更好”，还能理解“在哪一步做了什么改进”。

举个实际例子：在一个故障排查机器人中，用户报告设备无法开机。理想流程应依次询问电源连接、指示灯状态、是否有异响等。若模型跳过第二步直接问“是否摔过机器”，虽然语言通顺，但逻辑跳跃会影响诊断效率。SAPO 可以在这一步给予负向奖励，促使模型逐步完善推理链条。

工程实现上的灵活性

在 ms-swift 中启用 SAPO 并不需要重写整个训练流程。只需通过配置即可激活其核心能力：

from swift.llm import SwiftModel from swift.trainers import SapoTrainer model = SwiftModel.from_pretrained("Qwen3-7B") training_args = TrainingArguments( per_device_train_batch_size=8, gradient_accumulation_steps=4, learning_rate=5e-6, num_train_epochs=3, output_dir="./output-sapo", preference_loss_type="step_aware", # 启用步感知损失 step_reward_weight=0.8, # 控制步级与终局奖励的权重比 use_reference_free=False ) trainer = SapoTrainer( model=model, args=training_args, train_dataset=train_data, tokenizer=tokenizer, reward_model=rm_model # 提供每步打分的奖励模型 ) trainer.train()

这里有几个值得注意的设计细节：

step_reward_weight是一个关键超参。设置过高可能导致模型过于关注短期收益而忽略整体目标；过低则退化为普通DPO。实践中建议从0.6~0.8开始尝试，并结合KL散度监控策略变化幅度。
奖励模型可以是轻量级小模型+规则引擎的组合，尤其适合初期数据稀缺阶段。例如用BERT分类器判断某步回复是否包含必要信息点，再辅以正则匹配检测关键词覆盖情况。

此外，SAPO 天然兼容 vLLM 和 SGLang 等现代推理引擎，支持在推理阶段动态调度多轮采样，实现在线持续优化。

当“正确”不再是唯一标准：GSPO 的多维进化

如果说 SAPO 解决了“过程可控”的问题，那么 GSPO 则进一步回答了一个更复杂的命题：当多个目标相互冲突时，AI该如何权衡？

现实中很多高质量服务并不存在唯一的“最优解”。以银行理财助手为例，“专业性强”往往意味着术语密集，而“易于理解”则要求语言通俗。这两个维度天然存在张力。如果仅用标量奖励统一打分，很容易陷入“要么太难懂，要么太浅薄”的两难境地。

GSPO 的突破在于，它将偏好建模从“一维胜负”升级为“多维演进”。其核心机制如下：

构建一个向量化奖励空间 $ \mathbf{r}_t \in \mathbb{R}^d $，每一维代表一个独立评价指标，如事实准确性、语气友好度、结构清晰性等。
基于这些多维评分构建偏序关系集合 $ \mathcal{P} = {(\tau_i \succ \tau_j)} $，表示轨迹i在综合评估上优于j。
使用带有KL约束的目标函数进行优化：
$$
\max_\theta \mathbb{E}{\tau \sim \pi\theta} \left[ \sum_{t=1}^T \phi(\mathbf{r}t) \right] - \beta \cdot \text{KL}[\pi\theta || \pi_{\text{ref}}]
$$
其中 $ \phi(\cdot) $ 是可学习的映射函数，用于融合不同维度的信号。

这种方法的优势非常明显：它允许开发者明确表达业务优先级。比如在医疗咨询场景中，我们可以设定：

诊断准确性权重为0.5
患者共情水平为0.3
指导操作清晰度为0.2

并通过 Web UI 实时调整这些参数，观察模型输出的变化趋势。

如何落地一个多维奖励系统？

下面是一个典型的 GSPO 实现示例，适用于医学对话场景：

from swift.trainers import GspoTrainer from swift.rewards import MultiDimensionalRewardModel class MedicalRM(MultiDimensionalRewardModel): def compute_rewards(self, texts): scores = [] for text in texts: score = { "diagnosis_accuracy": self._check_facts(text), "empathy_level": self._detect_emotion(text), "guidance_clarity": self._analyze_structure(text) } scores.append(score) return scores trainer = GspoTrainer( model=model, args=training_args, train_dataset=medical_dialogs, tokenizer=tokenizer, reward_model=MedicalRM(), reward_dims=["diagnosis_accuracy", "empathy_level", "guidance_clarity"], reward_weights=[0.5, 0.3, 0.2] ) trainer.train()

这段代码展示了 GSPO 的高度可扩展性。自定义MultiDimensionalRewardModel子类后，你可以自由接入外部知识库（如医学指南）、情感分析API、结构解析器等模块，形成一套完整的质量评估闭环。

更重要的是，由于各维度相互解耦，你在后续迭代中可以单独优化某一指标而不影响其他部分。例如发现“共情不足”后，只需增强情绪识别模块并重新加权，无需重新采集全部标注数据。

融入全链路工程体系：SAPO/GSPO 的真实战场

SAPO 与 GSPO 并非孤立存在的算法玩具，它们深深嵌入到 ms-swift 所构建的端到端大模型工程流水线之中。这套系统的典型架构如下：

[用户数据] ↓ [Dataset Manager] → [Tokenization & Packing] ↓ [Trainer: SAPO/GSPO] ← [Reference Model + Reward Model] ↓ [Checkpoint Export] → [Quantization: AWQ/GPTQ] ↓ [Inference Engine: vLLM/SGLang/LMDeploy] ↓ [Deployment: OpenAI API Compatible Service]

在这个闭环中，SAPO/GSPO 处于训练层的核心位置，上游对接高效的数据预处理模块，下游连接高性能推理引擎，实现了从标注到上线的无缝衔接。

以智能客服机器人为例，整个工作流程可能是这样的：

收集历史对话日志，按轮次标注每条回复在“问题解决度”、“响应速度”、“语气得体性”等方面的得分；
加载 Qwen3 或 InternLM3 等基础模型作为起点；
构建规则+小模型混合的步级奖励函数；
启动分布式训练任务，利用 DeepSpeed ZeRO3 + FlashAttention-2 加速计算；
在 EvalScope 上运行 MMLU、CMMLU、C-Eval 及自建测试集进行多维评测；
导出为 GPTQ 量化模型，部署至 vLLM 引擎提供低延迟服务。

这套流程之所以可行，离不开 ms-swift 对工程细节的深度打磨。例如针对长文本训练常见的显存溢出问题，框架原生支持 Ulysses 和 Ring-Attention 序列并行技术，配合 GaLore 梯度低秩压缩，使得 7B 级别模型在单卡 A10 上仅需约 9GB 显存即可完成训练——这对于中小企业而言意义重大。