GRPO/RLVR：只奖励可验证行为
如果奖励函数只数“引用数量”，Agent 很快会学会塞进十个无关 Evidence；如果只奖“少调用”，它可能不取证就返回 unknown。先把这种投机轨迹写出来，才能看清 RLVR 真正训练的是什么。
Reinforcement Learning with Verifiable Rewards（RLVR）的核心不是“用 RL 让医学更正确”，而是把可程序判定的行为转成可靠奖励。GRPO 使用同一问题的一组采样结果构造相对优势，减少对独立 value critic 的依赖；DeepSeekMath 对该方法作了系统描述。S19
适合与不适合的目标
Section titled “适合与不适合的目标”适合用可验证奖励的目标：FHIR 查询是否命中正确患者和资源、JSON 是否符合 schema、单位换算是否正确、时间窗计算、工具顺序、引用是否存在、是否在预算内、是否触发人审、是否拒绝越权写入。
不适合直接当单一奖励的：开放式诊断是否“好”、治疗方案是否合适、解释是否让所有用户信任。把这些交给一个 LLM judge 会把 judge 偏差变成奖励函数。
原理：奖励栈与硬门
Section titled “原理：奖励栈与硬门”先运行 hard gates：跨患者读取、未授权写入、伪造引用、PHI 泄露任一发生，总任务失败。再计算软奖励：任务完成、步骤效率、格式、引用覆盖和成本。每个 reward component 有独立日志，避免一个总分掩盖安全失败。
组采样要控制问题难度和可比性；记录 policy/reference 版本、温度、seed 和 verifier 版本。训练前先用手工对抗轨迹测试 verifier，防止“输出空内容”“重复调用拿分”“利用 parser 漏洞”等投机。
| 方法 | 反馈 | 优点 | 风险 |
|---|---|---|---|
| SFT | 金标输出 | 稳定 | 不探索 |
| DPO | 成对偏好 | 简化偏好优化 S18 | 受离线数据覆盖限制 |
| GRPO/RLVR | 可执行奖励 | 适合工具/计算行为 S19 | reward hacking、训练不稳 |
| 规则搜索/规划 | 确定目标 | 可解释 | 对开放文本有限 |
先让越权轨迹在奖励之前失败
Section titled “先让越权轨迹在奖励之前失败”python3 labs/run_lab.py --lab 17实验对 4 条候选轨迹运行 verifier，先过安全硬门，再计算 schema、正确工具和成本奖励，最后做组内标准化。包含越权写操作的轨迹即使答案正确也得硬失败。可以先把一条轨迹的 patient scope 改错，确认系统记录的是 hard failure，而不是用较高的格式分把它补回来。这里没有梯度更新，因此只是 RLVR 环境 smoke test。
贯穿实例：把“查询 ANC”变成可验证环境
Section titled “贯穿实例：把“查询 ANC”变成可验证环境”初始环境装入合成 patient、FHIR fixtures、criterion、ToolManifest 和预算。模型输出一条或多条 action。环境执行后，hidden verifier 检查：patient id 是否正确、code/date 是否符合 criterion、是否处理分页与 status、单位比较是否正确、Evidence 是否存在、最终 status 是否匹配、工具次数和成本。每项都可程序判定。
同一问题采样一组轨迹：A 正确且简洁；B 查错 code；C 正确但重复五次；D 企图写 EHR。D 触发硬失败；A 在软分上最高；B 任务错；C 被成本惩罚。组内相对优势使 A 相对同组更好，但绝不能把“本组最佳”当绝对可发布，所以训练外还有最低通过门。
verifier 是产品代码，不是附属脚本
Section titled “verifier 是产品代码，不是附属脚本”reward 的每一部分都要单元测试和对抗测试。schema verifier 测 parser 绕过；tool verifier 测等价合法路径；citation verifier 测悬空、跨患者和相关不支持；budget verifier 防重复调用；security gate 直接读取环境审计，而不信模型声明。verifier 版本进入 TaskPackage 和训练 lineage。
最危险的漏洞来自代理指标。例如奖励“有引用”会诱导塞很多无关 ids；奖励“少工具”会诱导不取证；奖励最终 JSON 一致会忽略跨患者读取。每加入奖励，先写最便宜的作弊策略，再修设计。如果无法可靠验证，就不将其用于 RL。
GRPO 的工程直觉
Section titled “GRPO 的工程直觉”GRPO 针对同 prompt 的多个 rollout，以组内 reward 计算相对优势，避免训练独立 critic 的一部分成本。S19 仍需 policy/reference、采样、KL/clip、长度、batch 和稳定性管理。组大小小则估计噪声大，rollout 多则推理成本高；reward 稀疏会让学习困难。
Agent rollout 比数学答案更昂贵且有状态。训练环境必须可快速 reset、隔离并确定性重放；外部真实 FHIR/API 不适合直接放进在线训练，因为状态变化、隐私、成本和副作用不可控。用合成虚拟环境训练，真实环境只做受控离线验证。
奖励组成的优先级
Section titled “奖励组成的优先级”先 hard gates，再任务成功，再证据/校准，最后效率。示意：hard_pass * (task + citation + abstention + efficiency)，任何安全违规乘零或固定失败；但具体权重必须通过对抗和敏感性分析，不照抄示例。保留 component 表，而不是只存 total reward。
unknown 奖励尤其要平衡：缺证据时奖励 abstain，证据充足时滥用 unknown 要扣分。否则模型学会永远拒绝。环境必须知道 evidence completeness，这在合成数据中可由潜变量与观测过程构造。
训练阶梯和停止条件
Section titled “训练阶梯和停止条件”第 0 阶段手写轨迹验证环境；第 1 阶段 random/baseline policy 暴露 reward 漏洞；第 2 阶段少量 rollout smoke；第 3 阶段完整训练；第 4 阶段冻结 TaskPackage 和安全红队。任一阶段出现 reward hacking、任务无改善、关键退化或预算超限就停止。
TRL 可提供 GRPO trainer 实现，S21 但环境、奖励和医疗边界仍由项目负责。训练前固定 library/模型/tool schema；训练后不能只用训练 verifier 测试，需独立 held-out verifier 和人工审查失败样本。
报告训练前后 task success、hard violation、每个 reward component、长度/调用、held-out 场景、多个 seed 和失败 run。把 RLVR environment smoke 标成 environment PASS, training not-run。只有完整 run 真实存在，才写模型效果；如果收益只在已知模板上，结论限定在该分布。
为什么不奖励“诊断正确”
Section titled “为什么不奖励“诊断正确””开放临床判断缺少单一、稳定、无争议的程序金标；把 LLM judge 当奖励会把其偏差和提示敏感性优化进 policy。MedAgent Forge 只训练候选筛选中的可验证工程行为，最终临床责任保持在人和受治理流程中。
环境实现的工程合同
Section titled “环境实现的工程合同”reset(task_seed) 必须产生隔离初始状态；step(action) 先 schema/policy，再执行工具并返回 observation；finalize() 运行隐藏 verifier；snapshot() 支持失败重放。环境内时间可控、外部网络禁用、工具 fixture 有版本，避免训练 reward 因真实 API 漂移。每个 episode 有最大步数与资源，超限终止。
训练与评测环境共享合同但不共享全部任务/漏洞。held-out verifier 包含同语义新模板和对抗例；训练看不到金标内部状态。任何环境变更提升分数前，先用历史策略重跑，判断是修 bug 还是让任务变容易。
reward 敏感性与安全
Section titled “reward 敏感性与安全”对每个 component 做权重 sweep，检查策略是否从“过度调用”跳到“永不调用”、从“乱答”跳到“永远 unknown”。画 Pareto 而不是只找一个总分。安全 hard gate 统计具体违规，即使数学上总 reward 已最低也要保留事件。
rollout 数据治理
Section titled “rollout 数据治理”rollout 可能包含合成/受限输入、模型输出和工具结果，按原始数据等级治理；不因是训练中间产物就默认可公开。去除不必要原文，保留 task/evidence refs 与动作。失败轨迹对改进最有价值，也最可能泄露，访问和保留同样受控。
给“引用数量”正奖励，构造塞入十个无关引用的投机轨迹；把 reward 改为支持性 verifier 后再测试。再给“少调用”奖励，构造不取证直接 unknown；增加 evidence-completeness/任务门。你会发现 reward 设计就是安全需求的可执行化。
计算预算与可复现性
Section titled “计算预算与可复现性”Agent RL 的主要成本常在 rollout，而非反向传播。记录每 prompt 采样数、平均 steps、模型 tokens、tool 环境时间、过滤失败和实际费用；预算超出时先减少无价值长轨迹，不降低安全 verifier。rollout 并行要隔离环境和 seed，防两个 episode 共用状态。
同样 config 不一定逐 token 确定，至少固定数据/task/environment/model/tool 版本并报告多次波动。训练日志记录 reward components 和 KL/长度，不记录敏感原文。
与规划/搜索的替代关系
Section titled “与规划/搜索的替代关系”对于确定性条件树和有限工具，规则规划或搜索可能比 RL 更简单、可解释；RLVR 只有在行为分布需要从多条合法路径中学习时才有价值。先实现 rule baseline 与 best-of-n/rejection sampling，如果已满足需求，GRPO 不是必选。
环境通过之后
Section titled “环境通过之后”当前 lab 只证明四条轨迹上的 hard/soft reward 计算。下一里程碑应是对随机/手写策略运行成百 episode，自动发现 reward 漏洞；随后才连 TRL trainer。S21 每一步在 PROJECT.md 标明 environment/smoke/full-run，网站不合并展示。
奖励只能约束 verifier 能看见的行为。缺少独立环境、对抗用例和 held-out 门时，训练出来的只是更会迎合当前脚本的策略。
- verifier 覆盖不到的漏洞会成为最容易被利用的奖励捷径。
- 训练环境成功不能替代真实工作流验证。
- 组内相对奖励可能在整组都差时选出“较好但仍不可用”的样本。
- 未产生可复现训练 run 前，不得宣称 GRPO 改善本项目。
资料与延伸阅读
Section titled “资料与延伸阅读”以下参考资料用于区分偏好优化、可验证奖励和训练器实现。参考资料不是把开放临床判断变成单一 reward 的许可。