## `mask_history` 参数详解

### 1. 基本定义

```54:57:src/llamafactory/hparams/data_args.py
    mask_history: bool = field(
        default=False,
        metadata={"help": "Whether or not to mask the history and train on the last turn only."},
    )
```



- 默认值：`False`
- 作用：在多轮对话中，只对最后一轮计算损失，历史轮次不参与损失计算

### 2. 核心机制

#### 2.1 反转编码顺序（优先保留最后一轮）

```49:50:src/llamafactory/data/processor/supervised.py
        if self.data_args.mask_history:
            encoded_pairs = encoded_pairs[::-1]  # high priority for last turns
```

- 将对话对反转，确保最后一轮优先处理，避免被截断

#### 2.2 屏蔽历史轮次的损失

```70:73:src/llamafactory/data/processor/supervised.py
            if self.data_args.mask_history and turn_idx != 0:  # train on the last turn only
                target_label = [IGNORE_INDEX] * target_len
            else:
                target_label = target_ids
```

- `turn_idx == 0`：最后一轮，正常计算损失
- `turn_idx != 0`：历史轮次，`target_label` 设为 `IGNORE_INDEX`，不计算损失

#### 2.3 反转序列拼接顺序

```75:80:src/llamafactory/data/processor/supervised.py
            if self.data_args.mask_history:  # reversed sequences
                input_ids = source_ids + target_ids + input_ids
                labels = source_label + target_label + labels
            else:
                input_ids += source_ids + target_ids
                labels += source_label + target_label
```

- `mask_history=True`：新内容前置（`source_ids + target_ids + input_ids`）
- `mask_history=False`：按时间顺序拼接（`input_ids += source_ids + target_ids`）

### 3. 实际效果对比

假设有一个3轮对话：

```
轮次1: User: "你好" → Assistant: "你好！"
轮次2: User: "今天天气怎么样？" → Assistant: "今天天气很好。"
轮次3: User: "适合出门吗？" → Assistant: "适合出门。"
```

#### 当 `mask_history=False`（默认）：

```
input_ids: [轮次1的user+assistant] + [轮次2的user+assistant] + [轮次3的user+assistant]
labels:    [IGNORE...IGNORE, 轮次1的assistant] + [IGNORE...IGNORE, 轮次2的assistant] + [IGNORE...IGNORE, 轮次3的assistant]
```
- 所有轮次都计算损失

#### 当 `mask_history=True`：

```
input_ids: [轮次3的user+assistant] + [轮次2的user+assistant] + [轮次1的user+assistant]  (反转)
labels:    [IGNORE...IGNORE, 轮次3的assistant] + [IGNORE...IGNORE, IGNORE...IGNORE] + [IGNORE...IGNORE, IGNORE...IGNORE]
```
- 只有最后一轮（轮次3）计算损失
- 历史轮次仍作为上下文，但不参与梯度更新

### 4. 使用场景

- 长对话训练：只优化最新回复，避免历史干扰
- 上下文学习：保留历史作为上下文，但不训练历史回复
- 节省计算：减少需要计算损失的 token 数

### 5. 限制条件

```176:177:src/llamafactory/hparams/data_args.py
        if self.mask_history and self.train_on_prompt:
            raise ValueError("`mask_history` is incompatible with `train_on_prompt`.")
```

- 不能与 `train_on_prompt=True` 同时使用（两者冲突）

### 6. 与您例子中的 `loss_mask` 的关系

- `mask_history`：在数据预处理阶段统一屏蔽历史轮次
- `loss_mask`：在消息级别精细控制每个消息是否计算损失

目前 LLaMA-Factory 不支持消息级别的 `loss_mask`，但 `mask_history` 可以实现“只训练最后一轮”的效果。

### 7. 总结

- `mask_history=True`：只对最后一轮计算损失，历史轮次作为上下文但不参与训练
- 适用于长对话场景，可节省计算并聚焦最新回复
- 与 `train_on_prompt` 互斥

LLaMA-Factory  mask_history 

https://arxiv.org/pdf/2509.02544



## 1. 他们到底想解决什么问题?

想象一下,你想让 AI 帮你:
- 在京东上搜"三体",找到刘慈欣写的、50 块钱以内的书,加入购物车
- 玩一局 2048,尽量拿高分
- 在 Ubuntu 上用终端命令处理文件、跑代码

这些任务有个共同特点:**需要多步操作、需要看屏幕、需要根据反馈调整策略**。这就是 GUI Agent 要干的事儿。

但现有方案有几个大坑:
1. **数据太少**: 不像文本和代码有海量训练数据,GUI 操作的轨迹数据贵得要死
2. **多轮 RL 难训**: 游戏可能要几百步才结束,奖励稀疏,模型不知道哪步做对了
3. **纯 GUI 不够用**: 很多任务用命令行、文件系统更高效,纯点鼠标太慢
4. **环境不稳定**: 要跑几百万次交互,虚拟机动不动就崩溃

UI-TARS-2 就是奔着这四个问题去的。

---

## 2. 核心方法论:四大支柱

### 2.1 数据飞轮 (Data Flywheel)

**核心思想**: 模型和数据互相喂养,越滚越大。


#### 怎么冷启动?

一开始得有种子数据:
- **CT (Continual Pre-training) 数据**: UI-TARS 1.0/1.5 的数据 + 网上爬的教程视频 + 人工标注的轨迹
- **SFT (Supervised Fine-Tuning) 数据**: 合成数据 + 高质量人工标注

注意:**Agent 数据只占一小部分,大头还是通用数据**(聊天、推理等),目的是保留模型的通用能力。

#### 怎么迭代?

训练完第一轮 RL 模型后,用它来生成新数据:

```
新数据 = rejection sampling (RFT) + interactive annotation
```

然后用一个验证模型 `V(s)` 给每条数据打分:
- **高质量** (`V(s)=1`): 扔进下一轮 SFT
- **低质量** (`V(s)=0`): 扔进下一轮 CT (让模型见见世面)

这样形成正反馈循环:
```
更好的模型 → 更多高质量数据 → 更更好的模型
```

而且**没有数据浪费**,低质量数据也能用来做 CT。

---

### 2.2 沙盒环境:All-in-One GUI Sandbox

训练 Agent 需要一个能跑得动、跑得稳的环境。UI-TARS-2 搞了两套:

#### (1) GUI 环境:云虚拟机集群

- 支持 Windows、Ubuntu、Android 三大系统
- 几千台虚拟机,支持每秒几千次查询 (QPS)
- 每个 session 有独立 ID,支持 VNC 实时监控
- **关键创新**: 共享文件系统,浏览器下载的文件可以直接用命令行处理

技术细节:
```python
# 伪代码示意
vm = VMManager.allocate(os="ubuntu")
vm.execute_gui_action("click", x=100, y=200)
vm.execute_shell("cat downloaded_file.txt | grep keyword")
```

#### (2) 游戏环境:硬件加速的浏览器沙盒

![](browser_sandbox.png)

为什么要单独搞游戏环境? 因为:
- 游戏都是 HTML5/WebGL,必须跑在浏览器里
- 需要高并发 (一个容器跑多个浏览器实例)
- 需要控制时间流速 (加速训练)

**黑科技**: 重新实现了浏览器的 `Window.setTimeout` 等 API,可以暂停/加速游戏时间,同时不改变游戏逻辑。

---

### 2.3 数据标注:怎么搞到高质量轨迹?

#### CT 数据:In-Situ Annotation (原地标注)

**问题**: 之前的数据只有 action,没有 reasoning (思考过程),导致模型只会模仿,不理解为什么这么做。

**解决方案**: Think-Aloud Protocol (边想边说)

1. 标注员**边操作边说出想法**,录音
2. 用 ASR 转文字,LLM 润色成高质量 reasoning
3. 自动对齐到每一步操作

举个例子:
```
[标注员操作] 点击搜索框
[录音转文字] "我现在要搜三体,先得点这个搜索框"
[LLM 润色] "为了完成任务,首先需要在搜索框中输入关键词'三体'"
```

还有个妙招:**让新手标注员做不会的任务**。新手会搜索、试错、查资料,这些过程都是宝贵的训练数据。

#### SFT 数据:Interactive Annotation (交互式标注)

**问题**: 传统标注是 off-policy 的,标注员的操作和模型的操作分布不一样,训练效果差。

**解决方案**: Human-in-the-Loop (人在回路里)

![](interactive_annotation.png)

流程:
1. 给标注员一个任务 (比如"在京东搜三体")
2. 模型生成 3 个候选 (每个都有 thought + action)
3. 标注员选一个,或者自己手动输入
4. 环境执行这个 action,模型看到反馈后继续预测
5. 重复直到任务完成

**关键优势**: 标注数据和模型实际 rollout 的分布一致 (on-policy),而且标注员能实时纠错。

---

### 2.4 多轮强化学习:怎么训一个能玩 1000 步游戏的模型?

#### 2.4.1 任务设计:怎么自动生成可验证的训练任务?

RL 需要大量任务 + 可靠的奖励信号。他们设计了三类任务:

##### (1) GUI-Browsing: 信息检索任务

**目标**: 让模型学会通过网页搜索、推理来回答复杂问题。

**任务生成方法 1: 多条件模糊化**

从维基百科抽取实体 (比如一个乐队),然后故意"脱敏":
```
原始信息:
- 乐队: AC/DC
- 成员来自: Dreghorn 和 Irvine
- 签约唱片公司: Atlantic Records

生成问题:
"被某人才机构发现,最初阵容包括来自 Dreghorn 和 Irvine 的成员,
主唱是创始成员推荐的。这个乐队签的是哪家唱片公司?"

答案: Atlantic Records
```

关键:**无法直接搜索,必须多步推理**。

**任务生成方法 2: 多跳链式条件**

递归构造推理链:
```
问题: "完成某 20 世纪航天计划的指令舱驾驶员毕业的大学,
      校园里以他命名的工程楼叫什么?"

推理链:
1. 某航天计划 → 阿波罗 11 号
2. 指令舱驾驶员 → Michael Collins
3. 毕业大学 → 西点军校
4. 以他命名的工程楼 → (搜索答案)
```

##### (2) GUI-General: 通用网页操作任务

直接从真实网站抽取功能,合成任务:
```
"访问京东,搜索'三体',找到刘慈欣著、价格<50元的纸质书,加入购物车"
```

过滤掉:
- 需要登录的
- 太简单的 (一步完成)
- 太难验证的

##### (3) Gameplay: 游戏任务

收集/生成小游戏,写 JS 验证脚本:
```javascript
// 验证脚本示例
function verify_game_state() {
  return {
    score: game.score,
    level: game.level,
    success: game.score > 1000
  };
}
```

**为什么要训游戏?** 游戏是最好的长周期决策训练场,而且能自动生成无限任务。

---

#### 2.4.2 奖励设计:怎么判断任务做得好不好?

两种情况:

##### (1) 有标准答案

- **Gameplay**: 直接看游戏分数
- **GUI-Browsing**: 用 LLM-as-Judge 比对答案

```python
# LLM-as-Judge 伪代码
def evaluate(model_answer, ground_truth):
    prompt = f"模型答案:{model_answer}\n标准答案:{ground_truth}\n是否正确?(是/否)"
    return llm(prompt) == "是"
```

##### (2) 没有标准答案 (GUI-General)

**问题**: 网页操作任务往往没有唯一答案,怎么判断对错?

**解决方案**: 训练一个专门的 **Outcome Reward Model (ORM)**

- **输入**: 完整文本历史 + 最后 5 张截图
- **输出**: 0~1 的分数
- **训练方法**: 
  1. 人工标注一批 (成功/失败)
  2. 用 single-turn RL 训练到 F1=83.8

有意思的发现:**即使 ORM 有 16% 的错误率,RL 照样能训好**。为啥? 因为就算最终任务失败,中间步骤可能是对的,模型还是能学到东西。

---

#### 2.4.3 训练基础设施:怎么跑几百万次 rollout 不崩溃?

![](rl_infra.png)

三个关键设计:

##### (1) 异步推理 + 服务器化 Rollout

传统方式:
```python
for task in tasks:
    trajectory = model.rollout(task)  # 阻塞等待
    train(trajectory)  # 训练
```

问题:**长尾任务** (比如 1000 步的游戏) 会卡住整个训练流程。

新方式:
```python
# 伪代码
rollout_pool = []
for task in tasks:
    async_start(model.rollout, task)  # 异步启动

while True:
    if len(rollout_pool) >= min_batch_size:
        train(rollout_pool)  # 够一个 batch 就训练
        rollout_pool = [未完成的轨迹]  # 未完成的留着
```

**效果**: 不用等所有任务都跑完,够一个 batch 就可以开始训练。

##### (2) 有状态环境 (Stateful Environment)

传统 RL 环境每次 reset 都重新开始,UI-TARS-2 的环境**保持状态**:

```python
# 传统方式
env.reset()
for step in range(max_steps):
    action = model(obs)
    obs = env.step(action)

# UI-TARS-2 方式
session = env.create_session()  # 创建持久 session
for step in range(max_steps):
    action = model(obs)
    obs = session.step(action)  # session 保持状态
# session 自动清理
```

**好处**: 支持需要多轮工具调用、文件读写的复杂任务。

##### (3) 流式训练 (Streaming Training)

不用等整个 batch 跑完:
```
Rollout Pool: [完成的轨迹1, 完成的轨迹2, ..., 未完成的轨迹N]
              ↓
              只要够 min_batch_size 就开始训练
              ↓
              未完成的轨迹继续跑,下次再训练
```

---

#### 2.4.4 RL 算法:PPO 魔改大法

基础算法是 **PPO (Proximal Policy Optimization)**,目标函数:

$$
\mathcal{J}_{\text{PPO}}(\theta) = \mathbb{E} \left[ \min \left( r_t(\theta) \hat{A}_t, \text{clip}(r_t(\theta), 1-\varepsilon_{\text{low}}, 1+\varepsilon_{\text{high}}) \hat{A}_t \right) \right]
$$

其中:
- $r_t(\theta) = \frac{\pi_\theta(a_t|s_t)}{\pi_{\theta_{\text{old}}}(a_t|s_t)}$ (新旧策略的概率比)
- $\hat{A}_t$ (Advantage,表示这个动作比平均好多少)
- $\text{clip}(x, a, b)$ (把 $x$ 限制在 $[a, b]$ 之间)

但直接用 PPO 训长周期任务会炸,他们加了 5 个关键技巧:

##### 技巧 1: Reward Shaping (奖励塑形)

**问题**: 游戏可能 1000 步才结束,前 999 步奖励都是 0,模型不知道哪步做对了。

**解决方案**:
- **主要奖励**: 只看最终成功/失败
- **辅助奖励**: 
  - Format Reward (输出格式对了就给点分)
  - Length Penalty (太长或太短都扣分)

```python
reward = final_success * 100  # 主奖励
if valid_format:
    reward += 1  # 格式奖励
reward -= 0.01 * num_steps  # 长度惩罚
```

##### 技巧 2: Decoupled GAE (解耦广义优势估计)

**背景知识**: Advantage $\hat{A}_t$ 衡量"这个动作比平均好多少",计算公式:

$$
\hat{A}_t = \sum_{l=0}^{\infty} (\gamma \lambda)^l \delta_{t+l}
$$

其中 $\delta_t = r_t + \gamma V(s_{t+1}) - V(s_t)$ (TD error)

**问题**: 长序列 (比如 1000 步) 时,$\lambda$ 太大会放大噪声,$\lambda$ 太小会丢失长期信息。

**解决方案**: 策略网络和价值网络用**不同的 $\lambda$**:

$$
\begin{align}
\text{策略网络}: & \quad \lambda_{\text{policy}} = 0.98 \quad \text{(保留长期信息)} \\
\text{价值网络}: & \quad \lambda_{\text{critic}} = 0.90 \quad \text{(快速衰减噪声)}
\end{align}
$$

**直觉**: 策略网络需要看到远期回报来学习规划,价值网络需要稳定估计来指导训练。

##### 技巧 3: Length-Adaptive GAE (长度自适应)

**问题**: 10 步的简单任务和 1000 步的复杂任务,用同一个 $\lambda$ 不合理。

**解决方案**: 根据序列长度 $l$ 动态调整:

$$
\lambda_{\text{policy}} = 1 - \frac{1}{\alpha \cdot l}
$$

其中 $\alpha=0.05$ (超参数)

**效果**:
- 短序列 ($l=10$): $\lambda \approx 0.8$ (只看近期)
- 长序列 ($l=1000$): $\lambda \approx 0.98$ (看长期)

##### 技巧 4: Value Pretraining (价值预训练)

**问题**: PPO 开始时,价值网络是随机初始化的,给出的 $V(s)$ 乱七八糟,导致 Advantage 估计很差。

**解决方案**: 先用固定策略 (比如 SFT 模型) 跑一堆轨迹,用 **Monte Carlo 真实回报** ($\lambda=1.0$) 训练价值网络:

$$
\text{Loss} = \mathbb{E} \left[ \left( V_\theta(s_t) - \sum_{k=0}^{T-t} \gamma^k r_{t+k} \right)^2 \right]
$$

训练到 Explained Variance > 0.9 (价值网络能解释 90% 的回报方差) 再开始 PPO。

**效果**: 避免训练初期因为价值估计太烂导致策略崩溃。

##### 技巧 5: Clip Higher (非对称裁剪)

**标准 PPO**: 把概率比裁剪到 $[0.8, 1.2]$ (对称)

**UI-TARS-2**: 裁剪到 $[0.9, 1.3]$ (非对称)

$$
\text{clip}(r_t, 1-\varepsilon_{\text{low}}, 1+\varepsilon_{\text{high}}) \quad \text{where } \varepsilon_{\text{low}}=0.1, \varepsilon_{\text{high}}=0.3
$$

**直觉**:
- $\varepsilon_{\text{low}}=0.1$ (保守): 不轻易抛弃旧策略 (防止遗忘)
- $\varepsilon_{\text{high}}=0.3$ (激进): 鼓励尝试低概率但可能高回报的新动作 (扩大探索)

---

### 2.5 参数插值:怎么把多个专家 Agent 合成一个通才?

**问题**: GUI-Browsing、GUI-General、Game 三个领域差异很大,联合训练不稳定。

**解决方案**: 分别训练,然后**参数加权平均**:

$$
\theta^{(\text{merge})} = \alpha_1 \theta^{(\text{GUI-Browsing})} + \alpha_2 \theta^{(\text{GUI-General})} + \alpha_3 \theta^{(\text{Game})} + \cdots
$$

其中 $\sum \alpha_i = 1, \alpha_i \geq 0$

**理论依据**: 从同一个预训练模型微调出来的模型,在参数空间里是**线性模式连接**的 (linearly mode-connected),即参数插值后的模型性能不会太差。

**实验发现**: 合并后的模型在每个领域的表现都接近该领域的专家模型,而且能处理需要跨领域技能的复合任务。

---

## 3. 实验结果:到底有多强?

### 3.1 GUI 任务:全面吊打

| 模型 | OSWorld | WindowsAgentArena | AndroidWorld | Online-Mind2Web |
|------|---------|-------------------|--------------|-----------------|
| Claude-4 | 43.9 | - | - | - |
| OpenAI CUA-o3 | 42.9 | - | 52.5 | 71.0 |
| UI-TARS-1.5 | 42.5 | 42.1 | 64.2 | 75.8 |
| **UI-TARS-2** | **47.5** | **50.6** | **73.3** | **88.2** |

**关键发现**:
- 在 Online-Mind2Web 上达到 88.2%,接近人类水平
- RL 训练后,OOD 泛化能力暴增 (OSWorld +10.5%, AndroidWorld +8.7%)

### 3.2 游戏任务:接近人类 60%

15 款游戏的平均归一化分数 (人类=100):

| 模型 | 平均分 |
|------|--------|
| 人类 | 100.0 |
| **UI-TARS-2** | **59.8** |
| OpenAI CUA | 24.7 |
| Claude Computer Use | 21.6 |

**亮点**:
- 在 2048、Infinity-Loop 等游戏上达到人类 90%+ 水平
- 在 Shapes 上**超过人类** (108.9 vs 100)
- 比 OpenAI CUA 高 2.4 倍,比 Claude 高 2.8 倍

### 3.3 推理时扩展 (Inference-Time Scaling)

![](inference_scaling.png)

**发现**: 随着允许的最大步数增加,UI-TARS-2 的表现持续上升,其他模型很快就饱和了。

**为什么?** UI-TARS-2 学会了**解锁新子目标**,而不是瞎转悠。

---

## 4. 训练过程的有趣发现

### 4.1 熵的变化:探索 vs 利用

传统 reasoning RL (比如 OpenAI o1) 训练时,熵单调下降 (模型越来越确定)。

UI-TARS-2 的熵**先升后降**:

![](entropy.png)

**解释**: GUI 和游戏环境需要持续探索,模型在学习过程中发现了更多有效策略,而不是过早收敛到单一解法。

### 4.2 Think Length 的变化:从长到短

![](think_length.png)

**GUI 任务**: Think length 持续下降

**解释**: 一旦知道该点哪个按钮,就不需要长篇大论的推理了,直接行动更高效。

**游戏任务**: Think length 呈周期性

**解释**: 每次游戏升级难度,Think length 就上升 (需要思考新策略),熟悉后又下降。

### 4.3 VLM-as-Verifier 靠谱吗?

用 UI-TARS-2 自己当 ORM (奖励模型),F1=83.8,错误率 16%。

**惊人发现**: 即使错误率这么高,RL 照样训得好!

**原因**: 即使任务最终失败,中间很多步骤可能是对的,模型还是能从正确的中间步骤学到东西。这些正确步骤的奖励 > 错误奖励的负面影响。

### 4.4 PPO vs GRPO

GRPO 在推理任务上很强,但在 GUI Agent 上 PPO 碾压 GRPO:

![](ppo_vs_grpo.png)

**推测**: GRPO 更适合单轮推理,PPO 更适合多轮交互。

### 4.5 混合 RL:GUI + GUI-SDK

实验设置:
- **Baseline**: 分别训练 GUI-only 和 GUI-SDK-only
- **Hybrid**: 同时训练两种接口 (每种接口的数据量减半)

结果:
- Hybrid 模型在 GUI-only 任务上**超过** GUI-only baseline
- 原因:**GUI-SDK 学到的知识迁移到了 GUI**

**启示**: 更强大的接口能帮助模型学习更好的表征,即使最终只用弱接口。

---

## 5. 对我们的启发

### 5.1 数据层面

1. **在线 Interactive Annotation 是王道**
   - 模型生成多个候选,人工选择/修正
   - 保证数据是 on-policy 的

2. **Think-Aloud 标注法**
   - 让标注员边操作边说想法
   - ASR + LLM 润色,得到高质量 reasoning

3. **数据飞轮**
   - 高质量数据进 SFT,低质量数据进 CT
   - 没有数据浪费,持续迭代

### 5.2 训练层面

1. **必须上 RL**
   - SFT 只能到 80% 左右,RL 能冲到 90%+
   - RL 带来的泛化能力提升巨大 (OOD +10%)

2. **长周期 RL 的关键技巧**
   - Value Pretraining (价值预训练)
   - Decoupled GAE (解耦 $\lambda$)
   - Length-Adaptive GAE (自适应 $\lambda$)
   - Clip Higher (非对称裁剪)

3. **流式训练 + 异步 Rollout**
   - 不要等长尾任务,够一个 batch 就训练
   - 大幅提升训练效率

### 5.3 环境层面

1. **Stateful Environment**
   - 支持多轮工具调用,保持状态

2. **GUI + SDK 混合**
   - 纯 GUI 不够用,命令行、文件系统必不可少

3. **硬件加速 + 时间操控**
   - 游戏环境需要 GPU 加速截图
   - 能暂停/加速游戏时间,提升采样效率

---

## 6. 还有哪些坑?

1. **奖励模型的假阳率**
   - 当前 ORM 的 F1=83.8,还有 16% 的错误
   - 虽然不影响训练,但理论上还有提升空间

2. **长周期任务的信用分配**
   - 1000 步的游戏,怎么知道第 37 步做对了?
   - 当前主要靠稀疏奖励 + Value Pretraining,还可以引入更多先验 (比如 Hindsight Experience Replay)

3. **参数插值的权重**
   - 论文没说 $\alpha_i$ 怎么定的
   - 可能需要网格搜索或者用验证集调

4. **量化带来的精度损失**
   - W4A8 量化后,OSWorld 从 47.5 降到 44.4
   - 对延迟敏感的应用可以接受,但还有优化空间

---

## 7. 总结

UI-TARS-2 最牛的地方不是某个单点技术,而是**系统性的方法论**:

1. **数据飞轮**: 模型和数据互相喂养,持续迭代
2. **Interactive Annotation**: On-policy 数据采集,人在回路
3. **Sandbox 环境**: GUI + SDK 混合,有状态,高并发
4. **魔改 PPO**: 5 个关键技巧,专治长周期 RL
5. **参数插值**: 分别训练专家,合并成通才

如果你想做 GUI Agent,这篇论文是必读的。不仅技术细节清晰,而且很多坑都帮你踩过了。

最后提一句:**开源万岁!** 字节愿意把这么多细节公开,对整个社区都是巨大贡献。

---

**参考文献**:
- UI-TARS-2

UI-TARS 2.0 论文精读

要让Cursor（VSCode）在Windows任务栏显示工程名称而不是文件名，需要修改VSCode的窗口标题配置。具体步骤如下：
方法一：通过设置界面修改
1. 打开Cursor/VSCode，按 `Ctrl+,` 打开设置
2. 在搜索框中输入 window.title
3. 将默认值修改为：


```bash
${dirty}${rootName}${separator}${activeEditorMedium}${separator}${appName}
```


也就是填写到这里ctrl+S就行了：
![image.png](/static/img/724d12d2ea1f7b6f77a141dc81c5f9a9.image.webp)



Cursor（VSCode）在Windows任务栏显示工程名称而不是文件名

https://mp.weixin.qq.com/s/dU428dZEB9HoNtxnBRFISQ

论文标题：

EvoLM: In Search of Lost Language Model Training Dynamics

论文链接：

https://arxiv.org/pdf/2506.16029

项目主页：

https://zhentingqi.github.io/internal/projects/EvoLM/

代码链接：

https://github.com/zhentingqi/evolm


EvoLM训练流程：

![image.png](/static/img/f2942526520ed4d02022e8b4ddc9548d.image.webp)



根据EvoLM论文的研究结果，以下是针对"8张4090"算力条件下的LLM炼丹最优配方总结：

📋 核心配方要点

1. 基础模型选择

• 优先小模型：选择1B-3B参数的充分训练基座（如TinyLlama）

• 避坑：不要使用大模型的中间checkpoint，性能会显著下降

2. 持续预训练(CPT) - 最关键步骤

• 必须执行：领域适配的CPT不能跳过

• 黄金比例：通用数据:领域数据 = 1:5（约16%通用数据回放）

• 算力分配：30-40B Tokens即可饱和，约需几天时间


![image.png](/static/img/12b07368346a3df38cbb92a693bb1455.image.webp)

3. 监督微调(SFT)策略

• epoch控制：严格限制在2-4个epoch（3个为最佳）

• 防过拟合：超过4个epoch会损害泛化能力

• 留有余地：不要用SFT填满模型，为RL预留空间

4. 强化学习(RL)取舍

• 饱和点：4-8个epoch或50-100K样本即达收益饱和

• 作用本质：RL主要提升置信度而非根本推理能力

• 算力警告：PPO需要4个模型副本，显存消耗巨大

⚖️ 算力分配决策树

场景一：追求领域专家（数学/医疗/法律）

• 配方：重SFT + 轻RL（70-90%预算给SFT）

• 理由：SFT对域内任务提升最直接稳定

场景二：追求通用推理能力

• 配方：轻SFT + 重RL（10% SFT + 90% RL）

• 风险：RL容易导致输出冗长，需要精细调优

🎯 监控指标革新

• 弃用：Validation Loss和PPL（后训练阶段零相关）

• 采用：ORM分数（与下游性能强相关0.62-0.84）

• 工具：使用现成Reward Model（如Skywork）进行验证

💡 终极建议

对于大多数资源受限场景，最稳妥路径是：
1. 选择质量基座
2. 执行带Replay的CPT  
3. 进行3个epoch的SFT
4. 跳过RL（除非算力充裕）

EvoLM证明：精心调教的SFT模型往往优于配置错误的RL模型，在算力有限时尤为明显。

EvoLM LLM炼丹师最优配方

qwen3vl的tools设计验证

stepfun-ai/GELab-Zero-4B-preview

win：
```js
C:\Users\Administrator\.wslconfig
```
win写这个文件为：
```js
[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=false
autoProxy=true
```
win重启，然后ps关闭防火墙：

```js
# 允许 ICMPv4 入站流量（针对 ping）
New-NetFirewallRule -DisplayName "WSL Ping Allow" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow -Protocol ICMPv4
```


wsl:

```js
cc@DESKTOP-564RG57:~$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.21.160.1

```
wsl ping 这个nameserver。




wsl和win无法互相ping

Open-AutoGLM

https://github.com/wgzhao/dbeaver-agent/issues/18

https://dbeaver.com/download/ultimate/


![image.png](/static/img/78d336235fd6e3ef139748fcc7ad7ad5.image.webp)


```bash
java -cp "plugins\*;.\dbeaver-agent-25.3-SNAPSHOT-jar-with-dependencies.jar" com.dbeaver.agent.License
```



1、降级版本到25.0

2、下载jdk25

2.1、复制dbeaver-agent-25.0-SNAPSHOT-jar-with-dependencies.jar，也可自行下源码打包

3、

4、

java -cp "D:\dbeaver-ue-25.0.0-win32.win32.x86_64\dbeaver\plugins\*;D:\dbeaver-ue-25.0.0-win32.win32.x86_64\dbeaver\dbeaver-agent-25.0-SNAPSHOT-jar-with-dependencies.jar" com.dbeaver.agent.License


5、dbeaver.ini 按照在结尾新增

+ -javaagent:dbeaver-agent-25.0-SNAPSHOT-jar-with-dependencies.jar
+ -Xbootclasspath/a:dbeaver-agent-25.0-SNAPSHOT-jar-with-dependencies.jar

6、运行dbeaver.exe




DBeaver Ultimate Edition 

# 深入理解 GRPO 强化学习:从 PPO 到 Group Relative Policy Optimization

当 DeepSeek-R1 横空出世,以开源姿态挑战 OpenAI 的 o1 模型时,整个 AI 社区都在关注一个问题:他们是如何做到的?答案的关键之一就是 **GRPO (Group Relative Policy Optimization)** —— 一种更高效的强化学习算法。

本文将带你从零开始理解 GRPO,看看它如何在保持性能的同时,将训练成本降低了近 50%。



## 一、从一个类比开始:小学生考试的故事

在深入技术细节之前,让我们用一个简单的类比来理解强化学习的核心思想。

### 1.1 最简单的情况:只看绝对分数

想象你是一个小学生,每次考试后:
- 考了 90 分 → 很开心,下次继续这样做
- 考了 60 分 → 不太好,下次要改进

这就像最基础的强化学习:**根据奖励(分数)调整行为**。

但这有个问题:假如这次考试特别难,全班平均分只有 50 分,你考了 60 分其实已经很不错了。但如果你只看绝对分数,可能会错误地认为自己表现不好。

### 1.2 引入"基准线":父母的期望

聪明的父母会这样做:
- 如果你通常考 80 分,这次考了 85 分 → 超出预期,奖励!
- 如果你通常考 80 分,这次考了 75 分 → 低于预期,需要改进

这个"通常考多少分"就是**基准线(Baseline)**。我们不再看绝对分数,而是看**相对于基准线的表现**。

在强化学习中,这个差值叫做 **Advantage(优势)**:

```
Advantage = 实际得分 - 基准线
```

- Advantage > 0:表现好于预期,增强这个行为
- Advantage < 0:表现差于预期,减弱这个行为

**这就是 PPO 和 GRPO 的核心思想!**

## 二、理解 PPO:传统的强化学习方法

在介绍 GRPO 之前,我们需要理解它的前身 —— PPO (Proximal Policy Optimization),这是 ChatGPT 使用的强化学习算法。

### 2.1 PPO 的完整流程

假设我们要训练一个数学推理模型,PPO 的流程是这样的:

**步骤 1:生成回答**
给模型一个问题:"计算 25 × 4 = ?"
模型生成回答:"25 × 4 = 100"

**步骤 2:奖励模型评分**
用一个专门训练的**奖励模型(Reward Model)**给这个回答打分:
- 答案正确 → +10 分
- 格式规范 → +2 分
- 总分:**12 分**

**步骤 3:价值模型估计基准**
这是 PPO 的关键组件 —— **价值模型(Value Model / Critic)**:

价值模型会预测:"对于这个问题,平均来说应该能得多少分?"
假设价值模型估计:基准线 = 8 分

**步骤 4:计算 Advantage**
```
Advantage = 实际奖励 - 价值模型估计
         = 12 - 8 
         = +4
```

这个 +4 表示这次表现比预期好 4 分。

**步骤 5:更新模型**
基于这个 Advantage,我们会:
- 增加生成这个回答的概率(因为 Advantage > 0)
- 同时更新价值模型,让它的估计更准确

### 2.2 PPO 需要哪些"模型"?

PPO 训练需要 **4 个大型模型**同时工作:

1. **策略模型(Policy Model)** - 要训练的 LLM 本身
2. **奖励模型(Reward Model)** - 给回答打分
3. **价值模型(Value Model / Critic)** - 估计基准线
4. **参考模型(Reference Model)** - 原始模型的冻结副本,防止模型改变太大

这 4 个模型都是大型神经网络,通常都有几十亿参数,对内存和计算资源的要求非常高!

### 2.3 PPO 的目标函数

PPO 的数学目标是:

$$J_{PPO}(\theta) = \mathbb{E}\left[\min\left(\frac{\pi_\theta(a|s)}{\pi_{\theta_{old}}(a|s)} A^t, \text{clip}\left(\frac{\pi_\theta(a|s)}{\pi_{\theta_{old}}(a|s)}, 1-\epsilon, 1+\epsilon\right) A^t\right)\right]$$

看起来复杂,但本质是:
- $A^t$ 是 Advantage
- $\frac{\pi_\theta(a|s)}{\pi_{\theta_{old}}(a|s)}$ 是概率比(新模型生成这个回答的概率 / 旧模型生成的概率)
- $\text{clip}(...)$ 限制更新幅度,防止模型变化太大
- $\min(...)$ 选择更保守的更新方向

## 三、GRPO 的核心创新:不需要价值模型!

GRPO 的关键创新在于:**用一组回答的平均奖励替代价值模型**。

### 3.1 GRPO 的基本思路

回到考试的类比:

**PPO 的做法:**
- 父母(价值模型)根据你平时的表现预测:"这次考试你大概能考 80 分"
- 你考了 85 分 → Advantage = +5

**GRPO 的做法:**
- 不需要父母预测,让你做同一份试卷 **8 次**
- 你 8 次分别考了:82, 78, 90, 75, 88, 80, 85, 92
- 平均分 = 83.75
- 某一次考了 90 分 → Advantage = 90 - 83.75 = +6.25
- 某一次考了 75 分 → Advantage = 75 - 83.75 = -8.75

**核心思想:用同一组问题的多次尝试的平均值作为基准线,而不是训练一个单独的模型来预测基准线。**

### 3.2 GRPO 的详细流程

让我们看一个具体例子:

**输入问题:**
```
"What is 13 × 17?"
```

**步骤 1:生成一组回答(Group)**

对同一个问题,让模型生成 G=4 个不同的回答:

```python
回答 1: "13 × 17 = 221"         # 正确
回答 2: "13 × 17 = 230"         # 错误
回答 3: "13 × 17 = 221"         # 正确
回答 4: "Let me think... 221"  # 正确但格式不好
```

**步骤 2:奖励模型评分**

每个回答通过奖励模型获得分数:

```python
回答 1: r₁ = 10.0  (完全正确)
回答 2: r₂ = 0.0   (答案错误)
回答 3: r₃ = 10.0  (完全正确)
回答 4: r₄ = 7.0   (答案对但格式差)
```

**步骤 3:计算这一组的平均奖励和标准差**

```python
平均奖励 = (10.0 + 0.0 + 10.0 + 7.0) / 4 = 6.75
标准差 = 4.27
```

**步骤 4:计算每个回答的归一化 Advantage**

GRPO 使用标准化的 Advantage(类似 Z-score):

$$\hat{A}_i = \frac{r_i - \text{mean}(r)}{\text{std}(r)}$$

```python
Advantage₁ = (10.0 - 6.75) / 4.27 = +0.76  (好于平均)
Advantage₂ = (0.0 - 6.75) / 4.27  = -1.58  (远差于平均)
Advantage₃ = (10.0 - 6.75) / 4.27 = +0.76  (好于平均)
Advantage₄ = (7.0 - 6.75) / 4.27  = +0.06  (略好于平均)
```

**步骤 5:更新模型**

- 回答 1 和 3:Advantage 为正,增加生成类似回答的概率
- 回答 2:Advantage 为负且很大,大幅降低生成类似回答的概率
- 回答 4:Advantage 略为正,稍微增加概率

### 3.3 为什么要标准化?

标准化(除以标准差)有重要作用:

**情况 A:回答质量差异大**
```
回答奖励:[10, 9, 2, 1]
平均:5.5,标准差:4.2
Advantage₁ = (10-5.5)/4.2 = 1.07
```

**情况 B:回答质量都差不多**
```
回答奖励:[6, 6, 5, 5]
平均:5.5,标准差:0.58
Advantage₁ = (6-5.5)/0.58 = 0.86
```

虽然都是 +0.5 的差值,但情况 A 中的差异更显著,所以得到更大的 Advantage。这让训练更稳定。

## 四、GRPO 的数学公式

理解了核心思想后,让我们看看完整的数学形式。

### 4.1 Advantage 计算

对于问题 $q$,生成 $G$ 个回答 $\{o_1, o_2, ..., o_G\}$,每个获得奖励 $r_i$:

$$\hat{A}_i = \frac{r_i - \frac{1}{G}\sum_{j=1}^G r_j}{\sqrt{\frac{1}{G}\sum_{j=1}^G (r_j - \bar{r})^2}}$$

简化写法:

$$\hat{A}_i = \frac{r_i - \text{mean}(r)}{\text{std}(r)}$$

### 4.2 GRPO 目标函数

完整的 GRPO 目标是:

$$J_{GRPO}(\theta) = \mathbb{E}\left[\frac{1}{G}\sum_{i=1}^G \frac{1}{|o_i|}\sum_{t=1}^{|o_i|} \min\left(\rho_t \hat{A}_i, \text{clip}(\rho_t, 1-\epsilon, 1+\epsilon) \hat{A}_i\right) - \beta D_{KL}\right]$$

其中:
- $\rho_t = \frac{\pi_\theta(o_{i,t}|q, o_{i,<t})}{\pi_{\theta_{old}}(o_{i,t}|q, o_{i,<t})}$ 是概率比
- $\hat{A}_i$ 是归一化的 Advantage
- $\text{clip}(\rho_t, 1-\epsilon, 1+\epsilon)$ 限制概率比在 $[1-\epsilon, 1+\epsilon]$ 范围内(通常 $\epsilon=0.2$)
- $\beta D_{KL}$ 是 KL 散度惩罚项(可选,现代实现通常设为 0)

### 4.3 公式拆解

让我们逐部分理解:

**1. 概率比 $\rho_t$**

$$\rho_t = \frac{\pi_\theta(o_{i,t}|q, o_{i,<t})}{\pi_{\theta_{old}}(o_{i,t}|q, o_{i,<t})}$$

这是"新模型生成这个 token 的概率"除以"旧模型生成这个 token 的概率":

- $\rho_t > 1$:新模型更倾向于生成这个 token
- $\rho_t < 1$:新模型更不倾向于生成这个 token
- $\rho_t = 1$:概率没变

**2. 为什么需要 clip?**

想象一个极端情况:
- 旧模型生成某个 token 的概率:0.001
- 新模型生成的概率:0.5
- 概率比 = 500!

如果不限制,这会导致梯度爆炸。clip 函数将其限制在合理范围:

$$\text{clip}(\rho_t, 1-\epsilon, 1+\epsilon) = \text{clip}(\rho_t, 0.8, 1.2)$$

**3. min 操作**

$$\min(\rho_t \hat{A}_i, \text{clip}(\rho_t, 1-\epsilon, 1+\epsilon) \hat{A}_i)$$

这个 min 的作用是:**选择更保守的更新**。

- 如果 Advantage > 0(好的行为):我们想增大概率,但 clip 防止增大太多
- 如果 Advantage < 0(坏的行为):我们想减小概率,但 clip 防止减小太多

**4. 对所有 token 平均**

$$\frac{1}{|o_i|}\sum_{t=1}^{|o_i|}$$

虽然 Advantage 是对整个回答计算的,但更新是对每个 token 进行的。我们把整个序列的 Advantage 分配给每个 token。

## 五、PPO vs GRPO:直观对比

让我们用一张对比表总结区别:

| 特性 | PPO | GRPO |
|------|-----|------|
| **所需模型数量** | 4 个(策略、奖励、价值、参考) | 2-3 个(策略、奖励,可选参考) |
| **基准线来源** | 价值模型预测 | 同组回答平均值 |
| **内存占用** | 高(需要额外的价值模型) | 低(省去价值模型) |
| **计算开销** | 需要训练价值模型 | 只需多次采样 |
| **训练稳定性** | 依赖价值模型质量 | 依赖采样数量 |
| **最适合场景** | 状态空间复杂的任务 | 可验证正确性的任务(数学、代码) |

### 5.1 为什么 GRPO 在 LLM 中有效?

GRPO 特别适合大语言模型的原因:

**1. 奖励可以客观验证**
- 数学题:答案对就是对,错就是错
- 代码生成:运行测试用例即可验证
- 不需要复杂的"价值估计"

**2. 现代 GPU 可以高效并行采样**
- 生成 64 个回答并不比生成 1 个慢太多(批处理)
- 价值模型也是个大模型,内存占用和策略模型一样大

**3. 群组比较更自然**
- 奖励模型通常本身就是通过"比较"训练的(哪个回答更好)
- GRPO 的群组相对比较正好匹配这种训练方式

mask_history 参数详解

1. 基本定义

1. 他们到底想解决什

tools工作流说明

深入理解 GRPO 强化学习:从 PPO 到 Group Relative Policy Optimization

`mask_history` 参数详解