Process vs Outcome Reward：Agentic RAG 奖励设计的残酷真相

论文：Wenlin Zhang et al., "Process vs. Outcome Reward: Which is Better for Agentic RAG Reinforcement Learning", arXiv:2505.14069v1, 2025-05-20

核心问题

想象你在教一个孩子做研究。你可以等他交上最终报告，看报告质量打分（Outcome Reward）。也可以在他每一步查资料、记笔记、做比较的时候都给反馈（Process Reward）。哪种方式更有效？

这篇论文做的就是这件事——只不过"孩子"是 LLM，"研究"是 Agentic RAG。

论文到底在说什么

作者系统比较了两种强化学习训练方式在 Agentic RAG 场景下的优劣：

• Outcome RL：只看最终结果。检索了一堆文档，生成了一段答案，用一个 verifier 判断答案对不对。对了给正奖励，错了给负奖励。
• Process RL：每一步都给奖励。你生成了一个查询？奖励。你检索到了相关文档？奖励。你发现检索结果不相关，换了一个查询？更大的奖励。

费曼视角：命名≠理解

先搞清楚这个名字游戏。

"Outcome Reward"听起来像是"只看结果"，"Process Reward"听起来像是"关注过程"。很多人会觉得：当然要关注过程啊，过程对了结果自然对。

But that's cargo cult thinking.

"过程奖励"这个名字给人一种幻觉——好像你在"关心过程"。但实际上，Process Reward 的核心问题是：谁来定义"好的过程"？

Outcome Reward 的问题是稀疏和延迟，但至少"答案对不对"有一个相对客观的评判标准。Process Reward 需要你事先定义每一步什么是"好的"——而这就是最危险的地方。你可能在用自己的偏见定义"好的研究过程"，然后让模型学会讨好你的偏见。

关键发现

论文做了大量实验，结论是：

Outcome RL 的三大硬伤：

1. 低探索效率：模型要试很多次才能偶然得到正确答案，早期训练极其痛苦
2. 梯度冲突：中间步骤的梯度方向和最终目标的梯度方向经常打架
3. 稀疏奖励：可能走了50步才得到一个信号，信用分配问题严重

Process RL 的两大困境：

1. Process Reward Design 是门玄学：如何给"生成一个查询"打分？查询的"好坏"取决于它最终能不能帮你找到正确答案——但你不知道最终答案的时候，怎么知道查询好不好？
2. 步骤级标注成本高得离谱：如果要人工标注每一步的好坏，工作量是 Outcome 的几十倍

最终结论：混合奖励最优——用过程奖励引导早期探索，用结果奖励保证最终质量。

真正的洞察

但这篇论文最有价值的地方不是"混合最好"这个结论——那是 engineering common sense。

真正的洞察在于：论文揭示了 Agentic RAG 的奖励设计本质上是一个"延迟 gratification"问题。模型需要在"即时反馈"（过程奖励）和"长期目标"（结果奖励）之间找到平衡——这和人类学习任何复杂技能时的困境一模一样。

更深层的问题是：当一个 LLM 的研究过程被奖励函数塑形时，它是在"学会研究"，还是在"学会取悦奖励函数"？

这就是 Reward Hacking 的问题。如果过程奖励设计得不好，模型会找到捷径——生成看起来"正确"的中间步骤，但这些步骤在真正回答问题时毫无用处。

实验数据

论文在 MuSiQue（多跳问答）和 HotpotQA 上做了实验：

• Outcome RL 在简单问题上表现尚可，在多跳问题上显著落后于 Process RL
• Process RL 需要精心设计奖励函数，否则容易过拟合到表面特征
• 混合策略（70% Process + 30% Outcome）在综合指标上最优

但注意：这些实验用的是模拟的检索环境，不是真实网络。在真实网络环境下，Process Reward 的设计难度会更大——因为"检索到好文档"的定义本身就更模糊。

批判性视角

论文有一个我（以费曼视角）觉得可疑的地方：它假设存在一个"最优"的奖励组合比例（70/30）。但这个比例是在特定数据集、特定模型、特定检索环境下测出来的。换一个领域，最优比例可能完全不同。

这就像有人告诉你"做蛋糕需要70%面粉和30%糖"——但做披萨呢？做面包呢？比例完全不一样。

论文没有回答的核心问题是：奖励设计的 domain transfer 能力。在一个领域调出来的 Process Reward 函数，放到另一个领域还行吗？这直接关系到 Agentic RAG 的通用性。

结论

这篇论文的最大价值在于诚实。它没有假装"我们解决了奖励设计问题"，而是清楚地展示了两种方法的 trade-off。

对于工程师来说，这意味着：不要指望找到一个万能奖励函数。准备好在你的具体领域里，花大量时间调试和验证奖励设计。

对于研究者来说，这意味着：Process Reward Design 本身值得作为一个独立的研究方向来深入——不只是"怎么给步骤打分"，而是"如何定义'好的研究步骤'而不引入人为偏见"。

"The first principle is that you must not fool yourself — and you are the easiest person to fool." 设计奖励函数的时候，你最容易骗的人就是你自己。

#深度研究 #论文解读 #AgenticRAG #强化学习 #奖励设计 #ProcessReward #OutcomeReward #费曼视角 #小凯