第十一章习题 参考答案

[pikeduo]

1. 从 LLM 训练到 Agentic RL

1.1 为什么 Agentic RL 的状态包含历史观察，而 PBRFT 只包含初始提示？

PBRFT 的典型场景是“给定 prompt，生成一个回答，再根据回答质量打分”。因此它的状态基本就是初始提示 s0 = prompt，决策通常是单步的，环境不会随着模型动作持续变化。

Agentic RL 处理的是多步任务。智能体每一步可能会生成思考、调用工具、读取文件、执行代码、修改环境，并获得新的观察结果。因此第 t 步状态必须包含历史观察：

$$ [ s_t = (\text{prompt}, o_1, o_2, ..., o_t) ] $$

否则模型不知道自己已经查过什么、工具返回了什么、上一步是否失败，也无法规划下一步。文中也明确指出，PBRFT 主要关注单轮对话质量，而 Agentic RL 关注动态环境中的多步行动、外部交互和长期累积奖励。

这种差异带来的影响是：PBRFT 更容易训练、成本低，但只能优化“单个回答质量”；Agentic RL 训练更复杂，需要轨迹、环境反馈和奖励设计，但最终能学会任务完成策略，例如什么时候搜索、什么时候计算、什么时候停止、如何从错误中恢复。

1.2 “智能代码调试助手”的强化学习映射

可以定义如下：

状态空间 S

$$ [ s_t = (\text{bug描述}, \text{代码上下文}, \text{已读文件}, \text{文档片段}, \text{测试结果}, \text{修改历史}, \text{错误日志}) ] $$

例如：当前代码、报错栈、已尝试的 patch、单元测试输出、API 文档返回内容。

行动空间 A

包括：

analyze_code(file)：分析代码；
search_doc(api_name)：查阅文档；
edit_code(file, patch)：修改代码；
run_tests(test_cmd)：运行测试；
ask_clarification()：必要时请求更多信息；
final_answer()：输出修复说明。

状态转移函数 P

执行动作后环境更新：

$$ [ s_{t+1} \sim P(s_{t+1}|s_t, a_t) ] $$

例如调用 run_tests 后，状态新增测试结果；调用 search_doc 后，状态新增 API 用法；调用 edit_code 后，状态新增 diff。

奖励函数 R

可以使用混合奖励：

$$ [ R = 0.4R_{\text{test}} + 0.2R_{\text{bugfix}} + 0.15R_{\text{minimal}} + 0.15R_{\text{readability}} + 0.1R_{\text{process}} ] $$

其中：

R_test：测试全部通过 +1，部分通过按比例给分；
R_bugfix：原 bug 是否真正修复；
R_minimal：修改是否足够小，避免无关重构；
R_readability：代码风格、命名、可维护性；
R_process：是否合理查文档、定位问题、验证修复。

1.3 多步推理任务中，为什么监督学习难以优化长期目标？

例子：证明“对所有正整数 n，1 + 2 + ... + n = n(n+1)/2”。

监督学习通常学习的是完整参考答案：

第一步写归纳基础，第二步提出归纳假设，第三步证明 n+1 成立。

问题是，如果模型中间写错但最后答案格式看似正确，SFT 只能模仿样例文本，难以知道“哪一步导致后续失败”。反过来，有些中间路径和人工样例不同，但逻辑上完全正确，SFT 也可能把它当作偏离参考答案。

强化学习可以把整个证明看作轨迹：先选证明方法，再写基础情形，再写归纳假设，再完成推导。即使中间步骤没有人工标准答案，也可以用最终证明验证器、符号检查器或人工/模型评分器给延迟奖励。文中也指出，RL 可以让智能体根据正确性奖励学习更优推理路径，而不仅仅模仿训练数据。

---

2. SFT 与 GRPO

2.1 LoRA 的核心思想、效果与适用场景

LoRA 的核心思想是：冻结原模型权重，只训练少量低秩增量矩阵。假设原权重为 (W)，微调后为：

$$ [ W' = W + \Delta W ] $$

LoRA 假设：

$$ [ \Delta W = BA ] $$

其中 $(B \in \mathbb{R}^{d \times r})$， $(A \in \mathbb{R}^{r \times k})$，且 (r) 很小。这样训练参数从 $(d \times k)$变成 $(r(d+k))$，文中给出的例子是当 d=4096, k=4096, r=8 时，参数量可减少 256 倍。

它能用很少参数达到接近全参数微调效果，是因为很多下游任务并不需要改变模型全部知识，只需要在注意力层、MLP 层等关键模块上学习一个“任务方向”的低秩更新。适合选择 LoRA 的情况包括：显存有限、模型较大、多任务需要多个轻量 adapter、数据量不大、希望降低过拟合风险。全参数微调更适合数据规模很大、任务与原模型差异极大、资源充足且需要最大性能的场景。

2.2 GRPO 相比 PPO 的优势

PPO 需要估计优势函数 $(A(s,a))$，通常要训练 Value Model，因此工程上要维护 Policy Model、Reference Model、Value Model、Reward Model，显存和复杂度都较高。文中指出，GRPO 是面向 LLM 的 PPO 简化变体，不需要 Value Model，而是用组内相对奖励代替优势函数。

GRPO 的流程是：

1. 对同一个问题生成多个答案；
2. 分别计算奖励；
3. 计算组内平均奖励；
4. 用 $(r_i - \bar r)$得到相对奖励；
5. 用相对奖励更新策略，并加 KL 惩罚防止偏离参考模型。

它的优势是：显存更低、训练流程更简单、奖励方差更小、训练更稳定。如果应用到代码生成，需要把奖励从“数学答案是否正确”改成“测试是否通过、代码质量、复杂度、安全性”；如果应用到对话优化，需要使用“用户满意度、任务完成率、安全合规、简洁性、事实性”等奖励，并设计防止模型讨好用户或过度冗长的约束。

2.3 扩展 SFT 训练流程

可以按三个方向扩展。

第一，支持多轮对话数据。

将单轮样本：

{
  "prompt": "user question",
  "completion": "assistant answer"
}

扩展为：

{
 "messages": [
    {"role": "system", "content": "你是代码调试助手"},
   {"role": "user", "content": "这段代码报错..."},
    {"role": "assistant", "content": "我先分析错误栈..."},
   {"role": "user", "content": "测试结果如下..."},
    {"role": "assistant", "content": "问题在 API 参数..."}
 ]
}

训练时用模型 chat template 拼接，只对 assistant token 计算 loss，避免模型学习预测用户输入。

第二，添加数据增强。

可以做：

同义改写：把题目表述换一种说法，但保持答案不变；
难度调整：增加无关信息、增加中间步骤、改变数字规模；
格式扰动：不同输出模板，如 “Step 1 / Step 2 / Final Answer” 或自然语言推理；
错误样本修正：加入“错误推理—纠正”数据，提升鲁棒性。

第三，实现训练监控。

文中建议监控 loss、梯度范数、学习率；GRPO 阶段还需要看平均奖励、KL 散度、准确率和生成质量，并可用 wandb 或 TensorBoard 记录训练曲线。

---

3. 奖励函数设计

3.1 更精细的 GSM8K 奖励函数

文中介绍了准确率奖励、长度惩罚、步骤奖励，也指出二值准确率奖励简单但稀疏，不能区分“接近正确”和“完全错误”。

可以设计：

$$ [ R = 0.5R_{\text{answer}} + 0.25R_{\text{partial}} + 0.15R_{\text{reasoning}} + 0.1R_{\text{format}} - 0.1P_{\text{length}} ] $$

其中：

R_answer：最终答案完全正确得 1，否则 0；
R_partial：中间计算步骤正确比例，例如 3 个关键中间值对了 2 个，得 0.67；
R_reasoning：推理是否连贯、是否使用了题目条件、是否存在跳步；
R_format：是否包含清晰的步骤和最终答案；
P_length：超过目标 token 数后惩罚，避免刷步骤。

伪代码：

def reward_math(output, ground_truth, expected_steps):
    final = extract_final_answer(output)
       answer_score = 1.0 if numeric_equal(final, ground_truth) else 0.0

    predicted_steps = extract_intermediate_steps(output)
    partial_score = match_intermediate_values(predicted_steps, expected_steps)

    reasoning_score = judge_reasoning_consistency(output)  # 可用规则或评估模型
    format_score = has_step_format(output) and has_final_answer(output)

    length_penalty = max(0, len(output_tokens(output)) - 300) / 300

    return (
        0.5 * answer_score
        + 0.25 * partial_score
           + 0.15 * reasoning_score
           + 0.1 * float(format_score)
           - 0.1 * length_penalty
       )

3.2 三类智能体任务的奖励函数

代码生成助手

$$ [ R = 0.45R_{\text{tests}} + 0.2R_{\text{correctness}} + 0.15R_{\text{readability}} + 0.1R_{\text{efficiency}} + 0.1R_{\text{safety}} ] $$

测试通过率最重要，其次是是否满足需求、代码可读性、时间/空间复杂度、安全性。

客服对话智能体

$$ [ R = 0.4R_{\text{resolution}} + 0.25R_{\text{satisfaction}} + 0.15R_{\text{faithfulness}} + 0.1R_{\text{efficiency}} + 0.1R_{\text{policy}} ] $$

重点是是否解决问题、用户是否满意、是否忠实于知识库、响应是否及时、是否符合客服规范。

游戏 AI

$$ [ R = 0.35R_{\text{win}} + 0.2R_{\text{progress}} + 0.15R_{\text{survival}} + 0.15R_{\text{diversity}} + 0.15R_{\text{robustness}} ] $$

既看胜率，也看策略多样性和面对不同对手的鲁棒性，避免只学会一种容易被针对的套路。

3.3 奖励黑客与防御

例子：如果奖励函数只奖励“回答越长步骤越多越好”，模型可能生成大量无意义步骤来刷分；如果客服只奖励“用户点击已解决”，模型可能诱导用户点按钮，而不真正解决问题；如果代码助手只奖励测试通过，模型可能硬编码测试样例。

防御机制：

第一，使用多目标奖励，不只看一个指标；
第二，引入隐藏测试集或对抗测试；
第三，对异常高奖励样本做人工抽检；
第四，加入 KL 约束，防止策略偏离参考模型太远；
第五，奖励中加入惩罚项，例如冗长惩罚、重复惩罚、格式作弊惩罚；
第六，持续做错误模式分析。文中也提醒，糟糕奖励函数可能导致奖励欺骗、目标冲突和训练不收敛。

---

4. 数学推理智能体训练案例

4.1 GSM8K 的特点与扩展

GSM8K 是小学数学应用题数据集，包含 7,473 个训练样本和 1,319 个测试样本，通常需要 2 到 8 步推理。它适合训练算术应用题、条件提取、分步计算、最终答案抽取等能力。文中也强调数学推理适合评估 LLM，因为答案明确、可自动评估、需要多步推导。

如果要扩展到高等数学或数学证明，可以：

加入更高难度数据：MATH、AIME、Olympiad、Lean/Coq 形式化证明数据；
加入证明验证器：用符号系统、定理证明器或单元测试式验证；
奖励从“数值答案正确”扩展为“定理步骤合法、引用定理正确、推导无漏洞”；
训练方法上先 SFT 学格式，再用 GRPO/RL 根据验证结果优化证明策略。

4.2 泛化能力评估方案

为了判断模型是否真的学会推理，而不是记忆训练集，可以设计：

保留严格去重的测试集，去掉与训练题相似度过高的题；
使用数字替换测试，把题目结构不变但数字变化；
使用模板外测试，考察没见过的题型；
使用反事实测试，加入干扰条件，看模型是否误用；
评估中间步骤，不只看最终答案；
看 Accuracy@K、数值误差、平均长度、格式正确率、推理连贯性等多维指标。文中也建议评估不只看准确率，还要看效率指标和质量指标。

提升泛化的方法包括：数据增强、题型均衡采样、weight decay、early stopping、KL 正则、减少训练轮数、加入验证集监控、混合不同来源数据。

4.3 在线学习方案

在线学习流程可以是：

用户使用智能体解题；
系统记录问题、模型轨迹、用户反馈、自动验证结果；
数据过滤器去除低质量、敏感、重复样本；
把高置信反馈加入 replay buffer；
周期性用 SFT + GRPO 小步更新；
上线前通过离线评估、安全评估和灰度发布；
上线后监控准确率、投诉率、异常输出和奖励分布。

技术挑战主要包括：反馈噪声大、用户反馈可能不可靠；模型持续更新可能造成灾难性遗忘；在线数据可能引入安全风险和偏见；奖励函数可能被用户行为污染；模型更新需要可回滚、可审计。

---

5. 工具使用型 Agentic RL

5.1 工具学习训练方案

给定搜索引擎、计算器、代码执行器等工具，可以构造任务集：

简单问答：无需工具，训练“不乱用工具”；
数学计算：应调用计算器；
事实查询：应调用搜索；
代码问题：应调用代码执行器；
复合任务：先搜索，再计算，再总结。

状态：

$$ [ s_t = (\text{任务}, \text{历史动作}, \text{工具返回}, \text{中间结论}) ] $$

行动：

$$ [ a_t \in {\text{直接回答}, \text{调用搜索}, \text{调用计算器}, \text{执行代码}, \text{停止}} ] $$

奖励：

正确完成任务 +1；
选择正确工具 +0.2；
工具参数正确 +0.2；
无效工具调用 -0.1；
重复调用 -0.1；
错误答案 -1；
过早停止 -0.5。

文中提到 Agentic RL 的行动空间可以包含文本生成和工具调用，并通过多步反馈优化长期任务完成质量。

可以分成两层。

高层策略 planner

负责决定子目标：

1. 理解问题；
2. 需要查资料；
3. 需要计算；
4. 需要验证；
5. 输出最终答案。

高层动作是“选择下一阶段目标”。

低层策略 executor

负责具体工具调用：

search(query)、calculator(expression)、python(code)、read_doc(url)。

训练方式：

先用专家轨迹做 SFT，让高层学会合理规划，低层学会正确调用工具；
再用 RL 优化，低层根据工具调用是否成功获得即时奖励，高层根据最终任务是否完成获得延迟奖励；
用层级信用分配，把最终成功奖励分配给关键子目标。

协调方式是：高层给低层明确目标和约束，低层返回观察结果；高层不直接管工具参数，低层不擅自改变总体任务目标。

5.3 课程学习方案

课程顺序可以这样设计：

第一阶段：单工具、短任务。例如只用计算器解算术题。
第二阶段：单工具、复杂参数。例如搜索需要构造精确 query。
第三阶段：双工具顺序依赖。例如先搜索汇率，再计算金额。
第四阶段：多工具组合。例如搜索资料、写代码分析、生成报告。
第五阶段：开放任务，工具数量扩展到 50+，加入干扰工具和失败工具。

进入下一阶段的条件：

任务成功率 ≥ 80%；
工具选择准确率 ≥ 85%；
无效工具调用率 ≤ 10%；
平均步骤数不过度增长；
在 held-out 任务上表现稳定。

这样可以缓解探索效率低的问题：先让模型在小动作空间里学会“工具有用”，再逐步扩大工具集合和任务复杂度。