RLVR 训练小模型调用 Jira/Confluence API 的初步验证

arXiv 新发布的一篇工作论文探讨了一个具体问题：能否在不接入真实企业 API 的前提下，用「可验证奖励强化学习（RLVR）」在小模型上训练出能稳定调用 Jira 和 Confluence 接口的智能体。研究团队将该方法定位为「概念验证（proof of concept）」，并明确指出当前版本尚不适合直接落地生产。

研究动机：next-token 目标与企业 API 不匹配

作者指出，大语言模型通常以「预测下一个 token」为目标训练，但在企业 SaaS 工作流中，成功意味着按正确顺序、以正确的嵌套参数命中正确的接口端点。这种目标错配在实际部署中表现为：必填字段被遗漏、工具名被幻觉生成、一次只读调用后就提前停止。为弥合这一差距，作者选择在目标环境中原生应用 RLVR，让奖励信号直接来自工具调用轨迹本身。

方法：五个合成环境 + 纯轨迹奖励

• 团队按照 Jira REST v3 与 Confluence v2 的 schema 构建了一组高保真的合成环境，共五种场景。
• 奖励完全由工具调用轨迹计算，不依赖真实在线 API、没有学得的评判模型，也无人工标注参与。
• 训练采用 GRPO 算法，使用与训练阶段相同的检查器对同一批模型进行评分。

实验结果：从 0.35–0.92 提升到 0.95–1.00

被测模型为 Qwen3-1.7B 与 Qwen3-4B。

• 在五种场景中，四种奖励信号非退化的场景上，RL 训练后的策略把平均奖励从基线 4B 模型的 0.35–0.92 提升到 0.95–1.00。
• 单一场景最大提升出现在 Confluence 页面创建：从 $0.35 \rightarrow 1.00$。
• 第五个场景「工单状态流转（ticket-transition）」奖励曲线饱和，未经训练的 4B 模型已能拿满分。

局限与定位

作者在文中坦率列出两点需要斟酌的限制：

• 手写可验证奖励难以扩展到本文涉及的少量端点之外的场景，目前不具备规模化条件。
• 五种场景之一存在奖励饱和问题，意味着并非所有企业接口都需要 RLVR 才能解决。

文章将该工作定位为「面向企业内部 API 的、小模型结果优化」的初步一步，距离真正可用于复杂企业工作流的智能体仍有距离，但对有意探索 RLVR 在工具调用场景落地路径的研究者与工程团队而言，是一份方法与边界都比较清晰的参考。