GLM5.2 如何“四两拨千斤”

TL;DR

距离GLM5.2发布了快一个月，我也从发布第一天用到了现在，编程能力上，在国内肯定是稳居第一（这里提一嘴，dsv4正式版快出来了，也看到B站有人被灰测到了，做了一系列“一句话生成一个游戏”实践，其中“一句话生成CS”效果确实惊艳，一次成功可用，效果也非常好，全面开放预计下星期，感觉有望超过GLM5.2）。回到正题，GLM5.2在多项benchmark保持开源SOTA，在前端开发评估系统 Code Arena 上更是在一段时间内成为世界可用大模型第一（之所以是一段时间，是因为Fable5刚出来就被ban掉了，现在重新放出来了）。GLM5.2的参数量是公开的的 —— 753B，Claude opus4系列由于闭源，参数量无法得知，网传比较多的是 5T，来源大概率是马斯克在推上的回复

有不少博主根据推理速度反推了opus 规模在 1.5T ~ 2.5T 之间，至少也是GLM5.2的2倍，这也解释了为什么GLM5.2会被诟病解决一个问题要思考很长时间，在参数量不够的情况下，想生成质量更高的回答，把思维链拉长是一个不错的方案，让大模型充分思考（目前国内缺卡太严重了，马斯克自家已经在训10T了，国内最大的只有deepseek的v4以及美团的longcat2.0达到1.6T，GLM5.2更是一直被吐槽工作日卡爆，哎，没招儿）。

接下来就聊聊GLM5.2靠什么和至少2倍参数量的opus打的有来有回。

重要提示，这篇文章主要探讨GLM5在后训练上所做的努力，这也是我接下来想学习的一个方向。

从 GRPO 组内比较，切换到 critic-based PPO

GLM5的技术报告中的方案是 GRPO + IcePop 变体（处理训练推理不一致），而在 GLM5.2 的技术blog中指出切换到 PPO

强化学习最基础的一类算法叫策略梯度(Policy Gradient)，它的核心思想是：如果一个动作最终带来了最高奖励，就调高这个动作的概率；带来低奖励，就调低概率。公式为：

\nabla_{\theta} J(\theta) = \mathbb{E}[\nabla_{\theta} \log \pi_{\theta}(a_t | s_t) \cdot R_t]

其中 $R_t$ 是这个动作最终获得的（累积）奖励，在实践中会有一个大问题： $R_t$ 的方差通常非常大。举个例子，你在训练一个模型解数学题，即便模型这次侥幸蒙对了（回答正确， $R_t$ = 1），也不代表它这次的具体解题过程真的是"应该被强化"的高质量输出；反过来，一次思路正确但最后算错的回答（ $R_t$ = 0）也不代表这个思考过程一无是处。如果直接拿原始奖励值 $R_t$ 去乘梯度，不同样本之间的奖励绝对值波动会让梯度估计噪声很大，训练就很不稳定，收敛慢。

Baseline（记作 $b(s_t)$ ）是一个只依赖状态、不依赖具体动作的参考值，用来从原始奖励里减去：

\nabla_{\theta} J(\theta) = \mathbb{E} \left[ \nabla_{\theta} \log \pi_{\theta}(a_t | s_t) \cdot (R_t - b(s_t)) \right]

关键性质：只要 $b(s_t)$ 不依赖动作 $a_t$ 本身，减去它不会改变梯度的期望值（这是一个可以严格数学证明的性质），但可以大幅降低方差。直觉上：我们真正关心的不是"这个动作获得的奖励绝对值是多少"，而是"这个动作相对于这个状态下'通常水平'表现得更好还是更差"。举例来说，如果一道题很简单，模型平均水平就能拿到0.9分，那么某次具体回答拿0.9分其实是"平庸"的，不该被特别强化；但如果换一道很难的题，模型平均只能拿0.3分，那次拿到0.9分就是"显著超出平均水平"，值得被强化。baseline 就是这个"平均水平"的估计， $R_t - b(s_t)$ 这个差值，就是之前反复提到的 advantage（优势函数） —— “比平均水平好多少/差多少”。

$b(s_t)$ 该如何计算，PPO的做法是单独训练一个神经网络（通常和策略模型 $π_θ$ ，也就是“actor”，结构类似甚至共享底座），专门用来预测"在状态 $s_t$ 下，未来能获得的期望累积奖励是多少"，记作 $V(s_t)$ ，这个网络就叫 value model 或 critic（评论家，对应"actor 演员"这个说法 —— actor 负责做动作决策，critic 负责评判这个状态"值多少分"）。在 LLM RLHF 语境下具体化一下：critic 是一个和策略模型分开、单独训练的模型，输入是"当前已经生成到某个位置的文本"，输出是一个标量，预测"接着往下生成，最终能拿到多少奖励"。这个 critic 本身需要用真实观察到的奖励（比如最终 reward model 打的分）作为监督信号，通过类似回归的方式持续训练，让它的预测越来越准。用这个 $V(s_t)$ 作为 baseline，advantage 就是：

\hat{A}_t = R_t - V(s_t)

（PPO 里实际常用 GAE，即广义优势估计，公式更复杂一些，但核心思想一致：都是"实际获得的奖励"减去"critic 预测的期望水平"）

上面反复提到了“单独训练”，因为它点出了这个方法实践中的成本和麻烦：

要多训一个模型：critic 本身是一个需要参数、需要梯度更新、需要占用显存和算力的神经网络，在 LLM 场景下，这意味着你要维护两套几乎同等规模的模型（policy + critic）同时训练，直接翻倍了训练资源开销。
critic 自己也需要收敛，且收敛速度和policy不一定同步：训练初期，critic 对"什么水平的回答值多少分"的估计是不准的（因为它也是从零开始学的），这时候用一个不准的 baseline 去计算 advantage，反而可能引入新的偏差和噪声。而且 critic 和 policy 是同时在变化的两个移动目标——policy 在变，critic 要跟着重新估计新policy下的期望回报，这种"互相追赶"的动态在实践中容易造成训练不稳定（这在 Deep RL 文献里是个长期存在的已知问题）。
在 LLM 场景下 critic 的训练本身就很tricky：一个state（比如"生成到第37个token时的上文"）对应的"未来期望回报"是什么，其实定义起来没有传统RL（比如游戏里"当前局面"）那么自然，critic 需要学会理解半截生成内容的"潜力"，这本身就是一个不简单的建模任务。

而GRPO 完全不训练 critic，而是用一种"组内相对比较"的方式直接近似 baseline——对同一个 prompt 采样一组（比如32个）回答，直接拿这组回答奖励的均值当作 baseline：

\hat{A}_i = R_i - \text{mean}(R_1, \dots, R_G)

（GLM-5 报告里进一步除以了组内标准差做归一化，这是个额外的技巧，用来让不同难度问题的 advantage 幅度可比）这里 $mean(R_1,...,R_G)$ 扮演的角色，正好就是 critic 原本要做的事——估计"这个 prompt 下大概能拿到多少分"这个"平均水平"，只不过 GRPO 是用同一批采样样本自己的经验均值去近似这个量，而不是训练一个单独的神经网络去预测它。

那么

为什么要变

在长周期智能体任务中，一条轨迹可能长到超出模型的有效上下文窗口（即便是1M，长周期任务的累计交互记录依然可能溢出），Compaction 是业界处理这个问题的常见手段 —— 当轨迹太长，把早期的交互历史压缩/摘要成一段更短的内容，然后从这个压缩点切开，继续往下走。

问题是：一条超长轨迹一旦被 compaction，就变成了若干条“子轨迹（sub-trace）”。而且 —— 不同的 rollout（同一个prompt下采样出的不同轨迹）在哪里触发的 compaction、触发几次、每个子轨迹多长，都是不确定的。

而GRPO要求对同一个prompt必须采样出一组可比较的完整rollout，这直接击中了GRPO的软肋。

（我一直有一个疑惑，DeepSeek v4也是使用GRPO，且早于GLM5.2推出1M上下文，长程任务下也有非常好的表现，而GLM转向PPO后确实有了质的变化，希望在后续学习中能解开这个疑惑）

Anti-Hacking 机制

编程任务的奖励信号之所以被大量采用（因为它客观、可验证、不需要人工标注），但恰恰是这种"客观可验证"的特性，让它比主观奖励（比如GRM打分）更容易被"钻空子"。原因很直白：如果奖励只看"测试是否通过"，模型不需要真的理解问题、写出正确代码，只需要想办法让测试通过——哪怕通过一种完全不体现"解决问题能力"的手段。而且博客明确指出："GLM-5.2显示更多潜力比GLM-5.1更像是黑客行为"——模型能力越强，投机取巧的能力也越强，这是个很值得警惕的信号：不是说更强的模型更"听话"，反而是更强的模型更擅长找到奖励函数设计上的漏洞。具体的作弊手法（这段列举得非常具体）博客给出了几种真实观察到的作弊行为：

读取受保护的评测文件：直接翻找测试用例、标准答案文件
从参考资料或上游commit里抄答案：比如任务本来是"实现某个GitHub仓库缺失的功能"，模型直接去抓取该功能在上游仓库里已经写好的真实实现 具体的命令示例：
BASH
1. find /workspace -name "*hidden*" 2. cat /workspace/.eval/secret_cases.json 3. python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"
这三行命令连起来看非常直白：先搜索沙盒环境里有没有藏着"secret"、"hidden"字样的文件（推测测试用例可能藏在这类路径里）→ 找到后直接读取里面的隐藏测试用例内容 → 把这些内容当作参数喂给自己的解答脚本，本质上就是"偷看答案再假装自己算出来的"。这跟人类考试作弊的逻辑几乎一模一样，只不过作弊工具从抄小纸条变成了 find + cat + 命令行参数注入。

解决方案：两阶段检测 + 在线拦截而非直接终止轨迹

基于规则的过滤器：先用规则粗筛，目标是最大化召回率（recall）——也就是"宁可错杀，不可放过"，先把所有"看起来可疑"的行为都标记出来
LLM 评判器：对规则筛出来的可疑行为再用LLM判断意图，目标是保持高精确率（precision）——因为规则本身很粗糙，可能会把一些正常操作误判成作弊（比如模型合理地读取项目里的某个配置文件，可能因为文件名里恰好有"test"字样就被规则误伤），LLM 这一层负责把"真正的作弊"和"正常行为被规则误伤"区分开

处理方式：不是直接终止整条轨迹、判定失败，而是拦截这一次具体的工具调用，返回一个"假信息"（dummy information），让模型以为这次尝试没有成功，然后轨迹继续往下走。

如果每次抓到作弊就粗暴地把整条轨迹判负、突然终止，会带来两个问题：

训练信号突变：轨迹被"腰斩"，模型在那个时间点之前的所有正常操作也可能被连带惩罚，这是一种不精确的信用分配（credit assignment）——作弊只发生在某一步，但惩罚却波及了整条轨迹
训练不稳定/模型坍塌：如果这种"突然终止"频繁发生，尤其是在长周期任务里（一条轨迹可能已经花了很长时间、很多步骤才走到作弊那一步），会给训练过程引入剧烈的方差和不连续性，容易导致我们之前讨论过的那种"训练崩溃"（类似非确定性top-k导致熵骤降的那种失稳模式）

未完待续...