知识讲堂

← 返回日报
算法理论 第一讲

过程奖励模型原理

就像老师批改数学作业时,不只看最终答案对不对,而是逐步检查每一行推导——即使最后答案碰巧写对了,中间某步用错公式也要扣分。
历史演进

强化学习用于语言模型对齐时,奖励信号的粒度决定了模型能否学到"正确的推理方式"而非仅仅"正确的答案"——这一根本矛盾驱动了过程奖励模型(PRM)的诞生。

2017–2019
结果奖励的原罪

OpenAI 与 DeepMind 将 RLHF 引入语言模型,最初的奖励模型(Outcome Reward Model, ORM)只对最终输出打分。这在短文本任务上尚可,但在数学推理、多步逻辑等任务中暴露出致命缺陷:模型可以通过"错误路径碰巧得到正确答案"获得高奖励,即所谓的 reward hacking。信用分配(credit assignment)问题在长链推理中被极度放大——一个 20 步推理链中第 3 步的错误,ORM 完全无法感知。

2021–2022
过程监督的早期探索

Uesato et al.(DeepMind,2022)在 GSM8K 数学数据集上首次系统对比了 ORM 与 PRM:PRM 对每个中间推理步骤单独打分,实验表明在相同数据量下 PRM 的 Best-of-N 采样精度显著高于 ORM。这项工作奠定了"步骤级监督优于结果级监督"的实证基础,但彼时标注成本极高——每道题的每个推理步骤都需要人工判断正误。

2023
Let's Verify Step by Step(OpenAI PRM800K)

Lightman et al.(OpenAI,2023,NeurIPS spotlight)发布了里程碑式工作:构建 PRM800K 数据集,包含 800K 个人工标注的步骤级正确性标签,训练出 PRM,在 MATH 数据集上将 GPT-4 的 Best-of-1860 精度从 ORM 的 72.4% 提升至 78.2%。更重要的是,他们证明了 PRM 能够检测"貌似合理但实际错误"的推理步骤,这是 ORM 的盲区。

2024
自动化标注与 PRM 的规模化

人工标注 PRM 数据的成本制约了其推广。Math-Shepherd(Wang et al., 2024)提出用蒙特卡洛树搜索(MCTS)自动估计每步的"完成正确率"作为软标签,无需人工标注。同年,DeepSeek-R1 和 Qwen-QwQ 等推理模型的成功,将 PRM 作为 RLHF 中的 verifier 推向工业实践,过程奖励信号开始与 GRPO、PPO 等策略优化算法深度结合。

2025
PRM 作为推理代理

今日论文([32])将 PRM 扩展为"过程奖励代理",用于知识密集型推理的引导——不仅评分,还主动决策何时检索外部知识、何时回溯。这标志着 PRM 从被动评估者演变为主动推理参与者。

核心思想
过程奖励模型在推理链的每个中间步骤上独立打分,而非只看最终答案,从而解决长链推理中的信用分配问题,让模型学会"每一步都正确"而非"蒙对答案"。
数学结构

设推理链为 $s = (s_1, s_2, \ldots, s_T)$,其中 $s_t$ 为第 $t$ 步推理步骤,$a$ 为最终答案。 ORM 定义奖励为:$R_{\text{ORM}}(s, a) = f(s_1, \ldots, s_T, a) \in \mathbb{R}$,只在序列末端给出单一标量,梯度信号稀疏。 PRM 定义步骤级奖励:$r_t = \text{PRM}(s_1, \ldots, s_t) \in [0, 1]$,表示"前 $t$ 步推理均正确"的概率。总奖励为: $$R_{\text{PRM}}(s) = \prod_{t=1}^{T} r_t \quad \text{或} \quad R_{\text{PRM}}(s) = \min_{t} r_t$$ 乘积形式要求每步都正确(任一步错误则整体奖励趋零),最小值形式更鲁棒。 Math-Shepherd 的软标签估计:对步骤 $s_t$,用 $N$ 次蒙特卡洛完成采样估计: $$\hat{r}_t = \frac{1}{N} \sum_{i=1}^{N} \mathbf{1}[\text{completion}_i \text{ reaches correct answer}]$$ 这等价于估计条件概率 $P(\text{correct} \mid s_1, \ldots, s_t)$,无需人工判断步骤正误,只需验证最终答案(数学题可自动验证)。 Best-of-N 推理时使用:生成 $N$ 条候选推理链,用 PRM 选出得分最高者:$s^* = \arg\max_{s^{(i)}} R_{\text{PRM}}(s^{(i)})$,这是 PRM 最直接的推理时应用,无需修改生成模型本身。

工作机制

PRM 的工作逻辑是:将语言模型的推理链视为马尔可夫决策过程,在每个状态(已生成步骤)上学习一个价值函数,从而为策略优化提供密集的步骤级信号。

Step 1推理链分段与步骤定义

将模型输出按自然边界(换行符、"Step N:"标记、句号等)切分为离散步骤 $s_1, \ldots, s_T$。为什么不用 token 级?因为单个 token 无法承载完整的推理语义,步骤是最小的"语义完整推理单元"。实现细节:OpenAI PRM800K 用换行符分割,Math-Shepherd 用特殊标记 `ки` 标识步骤边界,训练时在每个边界位置插入分类头。

Step 2步骤级标签获取

这是 PRM 最核心的工程挑战。人工标注路径:标注者逐步阅读推理链,判断每步是否逻辑正确(不要求计算正确,只要推理方向合理)。自动标注路径(Math-Shepherd):对每个前缀 $(s_1, \ldots, s_t)$,用策略模型续写 $N=8\sim16$ 条完成,统计到达正确答案的比例作为软标签 $\hat{r}_t$。关键设计:自动路径假设"能导向正确答案的步骤是好步骤",这在数学领域成立,但在开放域推理中需要更复杂的验证机制。

Step 3PRM 模型训练

PRM 通常以预训练语言模型为骨干,在每个步骤边界位置的最后一个 token 上接二分类头(或回归头):

python # 伪代码:PRM 前向传播 hidden_states = backbone(input_ids)  # [B, T_token, D] step_boundary_hidden = hidden_states[:, boundary_positions, :]  # [B, N_steps, D] step_scores = classification_head(step_boundary_hidden)  # [B, N_steps, 1] loss = BCE(step_scores, step_labels)  # 步骤级二元交叉熵

为什么用最后一个 token?因果注意力机制使该位置能看到该步骤的全部上下文。训练时通常冻结骨干前几层,只微调后几层和分类头,防止过拟合。

Step 4推理时集成(Best-of-N / Beam Search)

Best-of-N:并行生成 $N$ 条完整推理链,PRM 对每条打分,选最高分。Step-level Beam Search:每步生成 $K$ 个候选续写,PRM 实时剪枝,保留 top-$B$ 条,类似 MCTS 的树搜索。后者计算量更大但精度更高,是 o1/R1 类模型推理时计算扩展(test-time compute scaling)的核心机制。

Step 5与策略优化结合(RLHF 中的 PRM)

在 PPO/GRPO 训练中,PRM 替代 ORM 提供 token 级奖励信号:将步骤奖励 $r_t$ 广播到该步骤的所有 token 上,或只在边界 token 处注入奖励。这使策略梯度能够精确传播到导致错误的具体步骤,而非模糊地惩罚整条链。

长远价值

PRM 是当前推理型大模型(OpenAI o1/o3、DeepSeek-R1、Qwen-QwQ)的核心组件之一,直接支撑了"测试时计算扩展"范式——通过在推理时投入更多计算(而非更大模型)来提升精度。PRM800K 数据集已成为推理评估的标准基准。在代码生成、科学推理、医疗诊断等需要多步逻辑的高风险领域,PRM 提供的步骤级可信度评估具有不可替代的安全价值,预计未来5年将成为所有推理模型的标配组件。

前沿动向

当前核心开放问题:①泛化性:数学领域的 PRM 能否迁移到开放域推理(无法自动验证答案)?②步骤定义模糊性:步骤粒度如何自适应确定?③PRM 自身的幻觉:PRM 可能对错误步骤给出高分(对抗样本)。④计算效率:Step-level Beam Search 的推理成本是 Best-of-N 的数倍,如何在精度与效率间取得平衡?⑤多模态 PRM:图文混合推理链的步骤评估尚无成熟方案。

工程·思维 第二讲

超算API工程哲学

就像现代航空公司的订票系统——乘客只需声明"我要从北京到纽约",背后的航班调度、机型分配、备降方案全部由系统自动处理,而不需要乘客手动规划飞行路线和燃油计算。
历史演进

大规模分布式训练的工程复杂度已远超单机深度学习的认知框架——当一个训练任务横跨数千张 GPU、涉及数十种并行策略、在随时可能故障的硬件上运行数周时,"如何让工程师专注于算法而非基础设施"成为整个行业的核心工程命题。

2015–2018
HPC 与 ML 的文化冲突

传统高性能计算(HPC)集群使用 SLURM、PBS 等作业调度系统,工程师需要手写 bash 脚本、手动管理节点分配、通过 MPI 协调进程。这套体系在科学计算领域运行了数十年,但对 ML 工程师极不友好:调试一个 NCCL 通信错误可能需要 SSH 进入数十个节点逐一排查日志。Horovod(Uber,2018)是第一次系统性尝试——用 Python API 封装 MPI/NCCL,让 ML 工程师无需理解底层通信原语。但 Horovod 仍然是"单机思维的多机扩展",缺乏对集群级故障、动态资源调度的原生支持。

2019–2021
云厂商的基础设施抽象层

AWS SageMaker、Google Cloud AI Platform、Azure ML 相继推出托管训练服务,将集群管理完全隐藏在 API 后面。工程师提交一个 JSON 配置,云平台负责节点分配、网络拓扑、存储挂载。这解决了"能跑起来"的问题,但引入了新矛盾:不透明性。当训练在第 3 天突然崩溃,工程师无法判断是 NCCL 超时、节点硬件故障、还是梯度爆炸——黑盒 API 剥夺了调试能力。与此同时,PyTorch DDP、FSDP、Megatron-LM 等框架要求对网络拓扑(IB vs. RoCE)、内存层次(NVLink vs. PCIe)有精确控制,云平台的抽象层反而成为性能瓶颈。

2022–2023
大模型训练的基础设施危机

GPT-3(175B)、PaLM(540B)的训练暴露了工业级集群管理的极限:数千张 GPU 的训练任务平均每 2-3 小时遭遇一次节点故障,检查点策略、弹性训练(elastic training)、自动重启成为生死攸关的工程能力。Google 的 Pathways、Meta 的 RSC、微软的 Azure NDv4 集群各自发展出内部基础设施系统,但这些系统高度定制化、不可移植。Ray(Anyscale)和 Kubernetes-based 方案(Kubeflow)试图提供通用抽象,但在极致性能场景下仍有显著开销。

2024–2025
Monarch 范式:超算即 API

Monarch([8])代表了一种新的工程哲学:将超算集群暴露为声明式 API,工程师描述"我需要什么"(节点数、拓扑、并行策略、故障恢复策略),系统负责"如何实现"。关键洞见是:分布式强化学习(如 RLHF 中的 actor-critic 分离、PPO 的 rollout-update 异步)的调试复杂度已超过任何个人工程师的认知上限,必须将基础设施关注点从应用层彻底分离。这与 Kubernetes 对容器编排的贡献在哲学上同构,但面向的是更极端的性能约束场景。

核心思想
超算 API 工程的本质是"关注点分离"——将集群拓扑、故障恢复、通信调优等基础设施复杂度封装在 API 边界之下,让 ML 工程师只需声明意图,而非编写基础设施代码。
数学结构

N/A(本主题核心是系统设计哲学,无核心数学公式。但可量化的工程指标包括:集群利用率 $U = T_{\text{compute}} / T_{\text{total}}$,其中 $T_{\text{total}}$ 包含故障恢复、重调度、通信等待时间;以及 MFU(Model FLOP Utilization)$= \text{实际FLOP/s} / \text{理论峰值FLOP/s}$,顶级集群的 MFU 通常在 35%–55% 之间,基础设施层的每一个设计决策都直接影响这个数字。)

工作机制

超算 API 的工程设计围绕一个核心矛盾展开:性能需要对硬件的精确控制,而可用性需要对硬件的完全抽象——好的超算 API 必须在两者之间找到可逃逸的分层边界。

Step 1声明式作业描述与意图捕获

工程师通过高层 API 描述训练作业的"意图":节点数量、GPU 型号、并行策略(数据并行/张量并行/流水线并行的组合)、检查点频率、故障恢复策略。为什么用声明式而非命令式?命令式("在节点 A 启动进程,在节点 B 启动进程,用 NCCL 连接它们")将拓扑决策暴露给用户,而集群的实际拓扑(哪些节点在同一 IB 交换机下、哪些节点当前健康)只有调度系统才知道。声明式 API 让调度器能够根据实时集群状态做出最优拓扑决策。

yaml # 声明式作业描述示例(概念性) job:   nodes: 512   gpus_per_node: 8   parallelism:     data_parallel: 64     tensor_parallel: 8     pipeline_parallel: 8   fault_tolerance:     checkpoint_interval: 300s  # 每5分钟     max_node_failures: 4       # 容忍4节点故障     recovery_strategy: elastic_restart
Step 2拓扑感知调度与通信优化

调度器获得意图后,需要将逻辑进程映射到物理节点,核心约束是:通信密集的进程组应尽量在同一 NVLink 域或同一 IB 交换机下。张量并行(TP)组内通信量最大(all-reduce 频率极高),必须在 NVLink 相连的 GPU 间执行;流水线并行(PP)组间通信量较小,可以跨 IB;数据并行(DP)的 all-reduce 可以利用 NCCL 的层次化算法跨交换机执行。这个映射问题本质上是一个约束优化问题,好的超算 API 应将此决策内化,而非要求用户手动指定 `MASTER_ADDR`、`NCCL_SOCKET_IFNAME` 等底层参数。

Step 3弹性故障恢复与检查点管理

大规模训练中节点故障是常态而非异常。工程设计的关键决策:检查点粒度(太频繁浪费计算,太稀疏则故障后损失大量进度)和恢复策略(原地重启 vs. 替换故障节点 vs. 缩减规模继续训练)。Monarch 类系统的创新在于将故障检测、检查点触发、节点替换、训练恢复封装为自动化流水线,工程师只需在 API 层声明容忍度,无需编写故障处理逻辑。关键实现细节:异步检查点(训练继续,检查点写入在后台进行)可将检查点开销从 5-10% 降至 <1%。

Step 4分布式调试的可观测性设计

这是超算 API 最难的部分,也是最常被忽视的部分。当一个 512 节点的训练任务挂起时,工程师面对的是:哪个进程在等待?是 NCCL 死锁、梯度同步超时、还是某个节点的 GPU 显存 OOM?好的超算 API 必须提供结构化的可观测性接口:每个通信操作的延迟分布、每个节点的 GPU 利用率时序、NCCL 操作的调用栈。Monarch 的工程洞见是:调试分布式强化学习(actor 异步产生数据、learner 异步消费数据、critic 异步更新)的复杂度需要专门的追踪基础设施,而非通用的 Prometheus/Grafana 方案。

Step 5逃逸阀设计(Escape Hatch)

任何抽象层都必须提供逃逸机制,否则会在极端性能场景下成为瓶颈。好的超算 API 设计应遵循"80/20 原则":80% 的用户通过高层 API 完成工作,20% 的高级用户可以通过逃逸阀直接控制底层(如手动指定 NCCL 环境变量、自定义通信组、绕过调度器的节点亲和性设置)。这与 PyTorch 的设计哲学一致:`torch.compile` 提供自动优化,但 `torch.fx` 允许手动干预计算图。

长远价值

超算 API 的工程哲学直接影响了整个 AI 基础设施行业:Ray 的 actor 模型被 RLlib、Vllm 等广泛采用;Kubernetes 的声明式调度思想被 Kubeflow、Volcano 引入 ML 场景;AWS SageMaker HyperPod 将弹性训练商业化。对于音视频大模型工程师,这一哲学的实践意义在于:当你的多模态训练任务跨越 64+ 节点时,基础设施层的每一个设计决策(检查点策略、通信拓扑、故障恢复)都直接决定实际 MFU,进而决定模型迭代速度。

前沿动向

当前核心开放问题:①异构集群调度:H100/A100/CPU 混合集群的最优任务映射尚无通用解;②分布式 RL 的调试工具链:actor-learner 异步架构的死锁检测极其困难;③跨云/跨数据中心训练:WAN 延迟下的梯度同步策略;④能耗感知调度:在性能约束下最小化功耗,随着集群规模增大这一问题日益重要;⑤API 标准化:各厂商超算 API 互不兼容,作业可移植性极差。

往期讲解档案 53 个知识点

2026年04月13日离散令牌音源分离Discrete Token ModelingSource SeparationConditional Generation
2026年04月13日超算API工程哲学Distributed Training OrchestrationSupercomputer API DesignFault Tolerance
2026年04月12日信息瓶颈原理演进Information BottleneckVariational IBDisentanglement
2026年04月12日Safetensors格式工程哲学SafetensorsModel SerializationMemory-Mapped IO
2026年04月11日归一化层演进原理Layer NormalizationRMS NormalizationBatch Normalization
2026年04月11日GEMM自调优后端工程GEMM AutotuningTorchInductorCuteDSL
2026年04月10日多令牌预测原理Multi-Token PredictionSpeculative DecodingMedusa Heads
2026年04月10日ML从业者认知校准Calibration BiasCapability IllusionBenchmark Overfitting
2026年04月09日编码器-解码器LM原理Encoder-Decoder LMCross-Attention ConditioningSequence-to-Sequence
2026年04月09日torch.compile归一化优化torch.compileLayerNormRMSNorm
2026年04月08日KV缓存压缩原理KV Cache CompressionRoPE Position EncodingAttention Score Estimation
2026年04月08日音效基础模型工程Sound Effect GenerationFoundation ModelFoley Synthesis
2026年04月07日可验证奖励强化学习Verifiable RewardRLVRProcess Reward Model
2026年04月07日LLM技能退化认知机制Cognitive OffloadingSkill AtrophyDesirable Difficulty
2026年04月06日音素可解释说话人验证Phoneme-aware Speaker VerificationInterpretable BiometricsLocal Acoustic Evidence
2026年04月06日音频幻觉攻击评估Hallucination AttackAudio Language Model ReliabilityAdversarial Probing
2026年04月05日潜在空间推理原理Latent Space ReasoningContinuous RepresentationToken-Free Inference
2026年04月05日mRNA模型极低成本训练Biology Foundation ModelCross-Species TransferLow-Budget Training
2026年04月04日编码器-解码器TTS原理Encoder-Decoder TTSText ConditioningPositional Capacity
2026年04月04日大模型训练的MXFP8工程MXFP8MicroscalingMixed Precision Training
2026年04月03日在线知识蒸馏原理Online DistillationKnowledge TransferStudent-Teacher
2026年04月03日MoE专家并行调度工程Expert ParallelismMixture of ExpertsAll-to-All Communication
2026年04月02日波形潜空间扩散TTSwaveform latent diffusionnon-autoregressive TTSlatent space acoustic modeling
2026年04月02日波形隐空间扩散原理waveform latent spacediffusion TTSVAE audio codec
2026年04月02日LLM量化权重工程weight quantizationLLM compression4-bit quantization
2026年04月02日扩散语言模型离散生成Discrete DiffusionMasked Diffusion Language ModelNon-autoregressive TTS
2026年04月02日LLM后训练库工程演进RLHF engineeringPPO training stabilityreward hacking
2026年04月02日声学证据瓶颈原理Audio Evidence BottleneckAcoustic GroundingAudio Language Model
2026年04月02日状态空间模型音频建模State Space ModelMambaSelective Scan
2026年04月02日实时语音增强工程选型Real-time Speech EnhancementNoise SuppressionStreaming Inference
2026年04月02日对话上下文压缩原理Context CompressionAbstractive SummarizationCross-Attention Fusion
2026年04月02日说话人匿名化工程Speaker AnonymizationVoice ConversionStreaming Inference
2026年04月02日视听语音识别融合Audio-Visual Speech RecognitionLip ReadingViseme
2026年04月02日GPU训练吞吐加速工程MXFP8MoE TrainingExpert Parallelism
2026年04月01日熵驱动多样性生成diversity samplingtypicality biasrepulsion in latent space
2026年04月01日说话人分割工程选型speaker diarizationbenchmark methodologystreaming ASR pipeline
2026年03月31日转向检测联合建模turn-taking detectionvoice activity detectionjoint acoustic-linguistic modeling
2026年03月31日基准测试的系统性失效benchmark contaminationevaluation validityLLM judge reliability
2026年03月31日扩散模型声学生成diffusion modelscore matchingstochastic differential equation
2026年03月31日TTS开源生态竞争open-weight TTStime-to-first-audiomultilingual speech synthesis
2026年03月30日注意力机制变体演进Multi-Head AttentionGrouped Query AttentionMulti-head Latent Attention
2026年03月30日设备端语音推理架构on-device inferenceExecuTorchvoice agent pipeline
2026年03月29日混合自回归流匹配TTSautoregressive semantic tokensflow matching acoustic decoderhybrid TTS architecture
2026年03月29日NCCL超时诊断方法论NCCL watchdog timeoutdistributed training debuggingcollective communication
2026年03月29日混合架构音频表示Mambastate space modelaudio representation learning
2026年03月29日DeepSeek预训练加速工程MXFP8 trainingexpert parallelismMoE pretraining
2026年03月27日说话人验证度量学习speaker verificationmetric learningcurriculum learning
2026年03月27日MX浮点格式加速训练MXFP8microscalingmixed precision training
2026年03月26日TTS模型极限压缩model compressionknowledge distillationTTS on-device
2026年03月26日小模型极限压缩哲学model compressionknowledge distillationquantization
2026年03月25日流匹配生成原理flow matchingrectified flowODE
2026年03月25日神经音频编解码器neural audio codecresidual vector quantizationEnCodec
2026年03月25日推测解码加速推理speculative decodingdraft modeltoken verification