微软与 Hugging Face 用 ThinkingBox 数据库校验结果作为 RL 奖励训练智能体

这是我们第一篇博客文章《Agent 说它完成了。数据库不同意。》的后续。ThinkingBox-Training 现已在 GitHub 上发布。

我们构建 ThinkingBox，通过将最终数据库状态与预期结果进行比较来评估 Agent 的工作。随后，我们在 ThinkingBox-Bench 之外的训练任务上，将同类的可执行信号用作奖励。对于 Qwen3.8-27B，平均成功率从 51.70% 提升至 60.78%，而在全部二十次尝试中均正确完成的任务数从 38 个增加到 107 个（经过 50 步 GRPO）。

图 1。ThinkingBox 将终端数据库状态的可执行检查转化为 ThinkingBox-Bench 之外任务上后训练 Agent 的奖励。

这是 Microsoft 与 Hugging Face 的联合博客，特别感谢 Microsoft 的 Mirco Milletari 和 Xiang Jiang、Hugging Face 的 Sergio Paniego，以及我们的前实习生 Zhuochun Li（匹兹堡大学）在共同撰写/审阅方面所做的努力。

我们构建 ThinkingBox，是为了抓住那些声称自己完成了、但实际上并没有完成的 Agent。

ThinkingBox-Bench（我们的基准数据集）中的 507 个任务，每一个都会交给 Agent 一个真实的后端和一组工具，让它工作，然后检查数据库中真正发生了什么变化。在第一篇文章中，我们抓到了一个模型将客户的工单关闭为已解决，而背后的承运商异常仍然处于未解决状态。九次看起来称职的工具调用，一行错误的数据库记录。

然后我们注意到了我们所构建的东西。对于大多数任务，可执行检查可以直接根据最终数据库状态返回 1 或 0。这不仅仅是一个评分器。这可以是一个奖励函数。⁺

因此，我们从基准之外以 ThinkingBox 格式构建了一个训练池，并将其可执行结果用作奖励。关键在于选择哪些任务适合 Agent 训练：大多数任务要么已经被解决，要么对眼前的模型来说毫无希望，而这两种情况都教不会它任何东西。

难度是相对于策略而言的：一个任务只有在当前模型尚未学会它之前，对该模型来说才是困难的。

我们称之为离线策略相对难度。我们在训练前使用基础策略对每个任务的成功概率进行一次估计，并在整个运行过程中保持所选训练池固定不变。

训练之后发生了什么

我们使用离线策略相对难度构建训练池，然后用 GRPO 对 Qwen3.8-27B 微调了 50 步。回顾一下，我们对 507 个基准任务中的每一个都评估 20 次。pass@1 衡量全部 10,140 次尝试的平均成功率。pass@20 衡量至少被解决一次的任务占比。Observed 20/20 衡量在每次记录尝试中均通过的任务占比。

表 1。Qwen3.8-27B 在离线选择的训练池上经过 50 步 GRPO 前后的结果。

训练大幅提升了可重复成功率，而至少一次覆盖率略有下降。本文的其余部分将解释我们如何选择练习任务、构建奖励循环，以及衡量这一权衡。

这项改进在单个任务上表现如何？一位旅客申请降级房间，但公司政策要求必须先获得经理批准。训练前，智能体在 20 次尝试中有 15 次未经批准就更改了预订并发放了退款。经过 RL 微调后，它在全部 20 次尝试中都保留了预订和支付状态。

图 2. 一个企业酒店预订任务，每个模型尝试 20 次。基础 Qwen3.8-27B 模型在 15 次尝试中未经所需经理批准就更改了预订。经 RL 微调的模型在全部 20 次尝试中都保留了预订和支付状态；在 19 次中所有预期记录均匹配。

目录

1. 基准测试在六十秒内的发现
2. 结果：可靠性一列发生了变化
3. 收益落在何处
4. 可靠性付出的代价
5. 训练循环
6. 离线策略相对难度
7. 什么能获得奖励
8. 运行训练栈
9. 下一步走向何方

赶时间？核心结果见上文。实现见运行训练栈。

基准测试在六十秒内的发现

ThinkingBox-Bench 根据智能体留下的数据库记录对其进行评分。它的 507 个任务中的每一个都会启动一个真实后端，向智能体提供一组 MCP 工具和一个带有私有上下文的模拟 LLM 用户，并在最后针对终端数据库状态运行可执行检查。检查针对的是需要正确的后端记录，而不是具体的工具调用。这会激励模型去发现可能的新解决路径，而不是“重新发现”人类支持的解决方案——后者虽然正确，但可能并非最优。

在我们的第一篇文章中，我们让十八个模型各运行该基准测试二十次，并报告了总体准确率所掩盖的差距。Kimi-K3 至少一次解决了 93.89% 的任务，但在全部二十次记录尝试中仅完成了 507 个任务中的 68 个（13.41%）。Claude Opus 5 则相反：覆盖范围更窄，一致性高得多。

而更大或更好的模型并没有缩小这一差距。Claude Opus 5.5 在 pass@1 上比 Claude Opus 5 高 0.66 个百分点，但在全部二十次尝试中通过的任务数完全相同，均为 241 个。总体准确率的提升没有带来任何额外的可靠性。

如果你要为涉及生产数据库记录的工作选择模型，不应只看 pass@1。观测到的 20/20 显示了哪些任务在每次尝试中都能成功，这更接近生产可靠性所需。

可执行的终端状态判定同时也是训练奖励。在展开训练循环之前，以下是密封基准测试上发生的变化。

结果：可靠性一列发生了变化

在训练 Qwen3.8-27B 后，我们在其从未训练过的 507 任务基准测试上评估了选定的第 50 步检查点。这 507 个任务代表一个分布外测试集：它们的领域、数据库和大多数 MCP 工具在 RL 训练期间均未遇到。

表 2. 按领域划分的 ThinkingBox-Bench pass@1（%），包括我们第一篇博客表 2中的选定模型以及我们针对不同领域和整体的微调模型。观测到的 20/20 数字基于整个 507 任务基准测试。每个模型在全部 507 个任务上评估 20 次重复试验。粗体标记该列领先者；下划线标记第二名。

最引人注目的结果是表 1 中 observed-20/20 那一行。一个27B 模型最初每次尝试只能完成 ThinkingBox-Bench 的 38 项（7.5%），现在每次尝试能完成 107 项（21.1%），几乎是原来的三倍。作为对比，Kimi-K3 的 observed 20/20 为 68，GPT-5.4 为 128，GPT-6 Astra 为 231，Claude Opus 5.5 以 241 领先。

平均成功率与可重复性会得出不同的排序。在表 2 中，我们注意到 GPT-5.6 Sol 的 pass@1 略高于经 RL 微调的 Qwen3.8-27B（61.91% 对 60.78%），但在全部 20 次记录尝试中通过的任务更少：82 对 107。Claude Sonnet 4.6 的 pass@1 更低，为 59.19%，但每次通过的任务数几乎相同，为 102。单看任一指标都无法反映全貌。

观察到的模式与“锐化”一致：可重复的成功率上升，而至少成功一次的覆盖率略有下降。这与先前的工作相符。一种解释是，概率分布向能够反复成功的轨迹移动，而一些低概率路径消失了。

总体而言，模型并没有变得更广。它变得更可重复。下一个问题是这些增益落在了哪里。

增益落在了哪里

图 3。各领域的基线得分、RLFT 得分及百分点变化。绿色变化单元格表示提升，红色单元格表示下降；蓝色阴影表示各指标内的得分水平。

Pass@1 和 observed 20/20 在全部五个领域均上升。Pass@20 则好坏参半：在 neobank 和 consulting 中上升，但在 retail、travel 和 auto insurance 中下降。Auto insurance 的广度损失最大（−7.0 个百分点），而 retail 的 observed-20/20 提升最大（+24.5 个百分点）。

可靠性的代价

第一篇博文用简单的数学为一致性定价：将完整 20 次运行活动的估算成本除以模型每次都通过的任务数。

每个可靠任务的成本 = 507 × 20 活动的估算成本 ÷ 通过 20/20 的任务数

将同样的成本计算应用于微调检查点实测的 token 用量：

表 3。基线与 RL 微调 Qwen3.8-27B 的估算评估成本与可靠性。每次成功尝试的成本等于总估算活动成本（507 x 20）除以通过的尝试次数。

在每次可靠任务 8.00 美元的水平上，微调模型已接近配套对比中的 GPT-5.4（6.80 美元）、GPT-6 Astra（7.45 美元）和 Claude Opus 5.5（7.80 美元）。

单次尝试视角

图 4 将每次成功尝试的成本与 pass@1 对照定价。

图 4。金色箭头追踪 Qwen3.8-27B 基线在帕累托成本位置上的变化至 RLFT（菱形）：pass@1 从 51.70% 升至 60.78%，而每次成功尝试的估算成本从 0.177 美元降至 0.139 美元。带圈圆点标记帕累托成本前沿。

这一变化使微调检查点接近 GPT-5.6 Sol，尽管 GPT-5.6 Sol 仍然更便宜且 pass@1 略高。在我们的论文中定价的四个模型落在绘图范围之外。

这些美元数值是比较用的服务指数，而非发票或云账单。服务微调后的检查点与基础模型相同。该计算包含模型推理成本，不包含训练运行成本以及为整理训练数据集而进行策略探测的成本。

这些结果告诉我们哪些方面发生了变化。接下来的章节将解释训练循环，以及为什么选择正确的任务最为重要。

训练循环

图 5. 六个阶段，现置于上下文中：候选任务输入，前三个阶段离线运行一次，后三个阶段在训练运行中为每个组重复。训练后的检查点针对 ThinkingBox-Bench 进行评估。

选择阶段离线运行一次，针对基础策略模型，即本例中的 Qwen3.8 27B；随后训练使用该已整理好的固定任务池。图 5 中的琥珀色虚线箭头标示了我们未采取的路径：在训练运行期间重新探测难度。

每次 rollout 都是一个完整回合，而非文本补全。它会获得全新的后端、隔离的 MCP 会话，以及作为模拟用户的 GPT-5 Chat。大多数奖励来自确定性的终态检查；少数狭窄的评分标准要求可以调用配置的评判器（GPT-5 Chat）。

训练和评估必须以相同方式解释 Qwen 输出。这包括推理提取、工具调用、参数类型、渲染以及隔离的任务状态。否则，奖励衡量的将是一个与评估时不同的智能体。共享的解释代码位于 trainer/core/tb_interpret.py。

对于参考运行，我们使用 token-mean GRPO 在 187 个任务上对 Qwen3.8-27B 进行了全参数 RL 微调。每次更新在 24 块 H100 上生成 18 组、每组 8 次 rollout，即 144 个回合。训练同步运行，并采用参数和优化器卸载；AdamW 使用 1e-6 学习率和零权重衰减。我们训练了 50 步。

训练期间，零方差组按 DAPO 风格被替换。系统错误单独处理：后端超时不是智能体的错误结果，因此受影响的组会被重新填充，而不是计为失败。

这解释了保留任务是如何训练的。剩下的问题是哪些任务进入了训练池。

离线策略相对难度

在深入探讨训练任务的选择之前，先做一个免责声明：

RL 训练池中未包含任何 ThinkingBox-Bench 任务。该基准被保留用于评估。

ThinkingBox-Bench 相对于 RL 训练池是分布外的：其领域、数据库、策略和大多数工具在 RL 训练期间均未遇到。两个集合仍共享 ThinkingBox 框架、模拟用户机制、可执行的终态评分、少数常用工具以及相似的任务风格。这些共享元素限制了迁移结论的范围。

选择为何重要归结为关于 GRPO 的一个算术事实。如果全部八次 rollout 都失败，奖励向量为 [0, 0, 0, 0, 0, 0, 0, 0]。如果全部八次都成功，则为 [1, 1, 1, 1, 1, 1, 1, 1]。无论哪种情况，组内中心化都不会产生任务奖励优势，因为没有轨迹比其他轨迹表现更好。⁺⁺

像 [0, 0, 0, 1, 1, 1, 1, 1] 这样的混合组提供了 GRPO 可以学习的对比。对于有状态智能体而言，这种区分代价高昂：每次 rollout 都要配置隔离后端、运行真实工具会话，并调用单独的模型来扮演用户。

因此，塑造这项工作的核心问题不只是用哪个模型或优化器？而是：哪些候选任务应当进入固定的训练池？

我们在后验上使用离线通过率过滤器来选择训练池。它估计哪些任务在基础策略下可能产生对比性的终端奖励。

于是我们进行探测。每个候选任务都会针对基础策略模型反复运行。用通俗的话说，规则很简单：模型总是失败的任务，目前不太可能教会它什么；模型总是通过的任务，它已经学会了；模型有时能解出的任务，才是结果能提供对比的地方。

从有限探测中估计难度

每个候选任务运行 n 次，产生 k 次成功。我们用 Jeffreys 后验概率对其潜在成功概率建模：

成功概率 | n 次探测中 k 次成功 ~ Beta(k + ½, n − k + ½)

图 6. 离线策略相对难度由重复的基础策略探测估计得出，并用于保留可能产生对比性奖励的任务。

我们将单位区间划分为五个桶，边界为 0.08、0.40、0.60 和 0.90，作为这些运行的超参数。每个任务被分配到后验质量最大的桶：

• 极少解出 [0, 0.08)：丢弃
• 困难 [0.08, 0.40)：保留
• 中等 [0.40, 0.60)：保留
• 经常解出 [0.60, 0.90)：保留用于全参数 RLFT
• 几乎总能解出 [0.90, 1]：丢弃

更多细节见我们的 ThinkingBox 论文附录 C.4。

一个任务的端到端流程

图 7. 放大来看，一个任务经过全部六个阶段：GPT-5.4 筛选、基础模型探测、难度分类、一个 rollout 组、终端状态评分和一次 GRPO 更新。

图 7 跟踪了一个可能进入训练池的候选任务。对于 Qwen3.8 27B 全参数池，GPT-5.4 首先充当可解性筛选器。随后基础策略在探测中仅成功少数几次，例如 8 次中成功 3 次，产生 Beta(3.5, 5.5) 后验。其最大质量 54.0% 落在困难区间。

当被采样用于训练时，该任务产生了混合奖励组 [0, 0, 0, 0, 1, 1, 1, 1]。因此成功的轨迹获得高于均值的任务优势，失败的轨迹获得低于均值的优势，从而为 GRPO 提供可学习的对比。不同的策略模型可能将同一任务归入不同的难度区间。

最终 Qwen3.8-27B 精选训练池包含 187 个任务。

什么能获得奖励

与轨迹无关。奖励是任务自身的可执行判定。

当一个回合结束时，沙箱会提取后端实际发生的变化，并针对终端状态运行任务的确定性检查。任何产生正确最终状态的轨迹都会通过。错误、缺失或多余的副作用都会失败。奖励为 1 或 0。

在基准测试中，数据库评分器可以看作“考官”：它抓住了那些报告成功却留下错误记录的智能体。在训练中，同样的检查可以看作另一组不相交任务上的“老师”。

两条奖励路径，一个二元判定

• 可执行检查（占绝大多数）。当所需结果体现在终端状态或副作用中时，由确定性测试接受或拒绝；无需调用 LLM 评判器。
• 评判器辅助检查（占少数）。当某项狭窄要求无法从数据库状态中清晰判定时，由配置的 LLM 评判器回答一个二元评分问题，供可执行测试使用。

运行训练栈

我们发布了用于训练 Qwen3.8-27B 的数据选择、rollout、奖励和 Verl 集成，位于 microsoft/thinkingbox-training。仓库 README 是入口。详细指南包括：

• docs/data-preparation.md 用于任务水合、策略探测、基准排除和训练/验证划分；
• docs/reference-q38-run.md 用于经过验证的 24-H100 Qwen3.8 配置；
• docs/evaluation.md 用于合并检查点并运行 ThinkingBox-Bench 507 x 20。

开始之前

已在 Linux 和 WSL 上使用 Python 3.12 和 uv 测试。你需要具备兼容 CUDA/NCCL 栈的 NVIDIA GPU、本地 Qwen3.8-27B 检查点，以及用于模拟用户和评判器的 OpenAI 兼容端点。经过验证的参考配置使用 3 个节点 x 8 块 H100 GPU；较小的自定义配置取决于模型大小、上下文长度和 rollout 并发度。

公开示例任务列表用于演练接口。它不是报告运行所用的私有 187 任务训练池。请提供与公开基准保持不相交的授权训练源。

安装

将三个仓库并排放置：

mkdir -p ~/thinkingbox-workspace
cd ~/thinkingbox-workspace

git clone https://github.com/microsoft/thinkingbox.git
git clone https://github.com/microsoft/thinkingbox-data.git
git clone --branch main https://github.com/microsoft/thinkingbox-training

git -C thinkingbox checkout 892964e7226044e5463ad188da119df838f4bec1
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

创建经过验证的环境

发布的栈面向 Linux、Python 3.12、Verl 0.9.0 和固定的包锁文件：

cd ~/thinkingbox-workspace/thinkingbox-training

uv venv --python 3.12
source .venv/bin/activate

uv sync --frozen --extra fast --extra tracking --extra eval-proxy
uv pip install -e ../thinkingbox
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/thinkingbox_tools
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/tb_business_ops_servers_202606

python scripts/prepare_verl.py --dest .deps/verl --install
python scripts/verify_verl_install.py
uv pip check

最后两条命令应报告已验证的已打补丁 Verl 检出，且没有损坏的依赖项。之后不要运行另一次自动包同步：它可能会用原版 Verl wheel 替换已打补丁的源码安装。

准备训练数据

从公开提供的样本开始，或以 ThinkingBox 格式添加你自己的授权数据集。然后运行仓库的准备脚本：

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
python data/prepare_data.py --help

该脚本汇总策略探测结果，应用离线策略相对难度过滤和基准排除，并写出选定的 train.yaml 和 test.yaml 文件。docs/data-preparation.md 记录了输入字段、加载器契约和完整命令。

配置并检查启动

按照 docs/reference-q38-run.md 启动 Typesense 和 MCP 服务器，配置模拟用户和评判器，设置模型、任务列表、检查点和拓扑变量，并准备 Ray 集群。将凭据保存在运行时密钥注入中，而不是提交到文件或 shell 历史记录中。

在分配训练作业之前，使用指南中的试运行命令：

DRY_RUN=true ./scripts/run_train.sh \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

它必须以零退出，且不启动 Ray 或分配 GPU。在启动运行之前，阅读输出的 python -m verl.trainer.main_ppo 命令和每个已解析的覆盖项。

训练

启动器负责配置训练；它不负责供应主机。在参考三节点拓扑上，在每个节点上导出相同的环境，将 CHECKPOINT_DIR 挂载到相同的绝对路径，然后启动 Ray：

# head node
ROLE=head NODE_IP="$HEAD_IP" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

# each worker node
ROLE=worker NODE_IP="$WORKER_IP" \
  HEAD_ADDRESS="$HEAD_IP:6379" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

在 ray status 报告全部 24 块 GPU 后，从头节点启动一次：

export RAY_ADDRESS=auto
export GPUS=0,1,2,3,4,5,6,7

./scripts/run_train.sh \
  trainer.project_name=thinkingbox-training \
  trainer.experiment_name=q38-full-rlft \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

通过 OpenEnv 评估检查点

第一篇 ThinkingBox 文章涵盖了 Typesense、MCP Session Proxy 和 OpenEnv 的搭建。按照 docs/evaluation.md 合并训练好的检查点，然后用 vLLM 提供服务。

在 OpenEnv 仓库根目录下，将 MERGED_MODEL 设为合并后的模型目录，将 THINKINGBOX_DATA 设为固定版本的基准测试检出目录。历史检查点评估使用了这套八卡 A100 服务配置：

vllm serve "$MERGED_MODEL" \
  --served-model-name q38-rlft \
  --host 127.0.0.1 \
  --port 8001 \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.85 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 8192 \
  --language-model-only \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml

在另一个终端中，从 ThinkingBox Training 检出目录启动针对 Qwen 聊天模板的 OpenEnv 兼容代理。它监听 8014 端口，并转发到 8001 端口上的 vLLM：

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
bash scripts/launch_sysmerge.sh

在评估期间保持其运行。从另一个终端检查就绪状态：

curl --fail http://127.0.0.1:8014/readyz

更新现有 thinkingbox.yaml 中的 agent 条目；保留其 MCP、模拟用户和评判器配置：

orchestrator:
  agent_model:
    type: aoai
    endpoint_url: http://127.0.0.1:8014/v1/chat/completions
    deployment: q38-rlft
    credential:
      type: api-key
      api_key: <your_api_key>
    is_reasoning: true
    temperature: 1.0
    top_k: 20
    top_p: 0.95
    max_completion_tokens: 8192
    timeout: 1800

如第一篇文章所述启动 OpenEnv，将 OPENENV_TB_CONFIG 指向此 thinkingbox.yaml，将 OPENENV_TB_DATASET 指向 $THINKINGBOX_DATA。一旦 /ready 成功，运行包含 507 个任务 × 20 次尝试的完整协议：

uv run --project envs/thinkingbox_env --frozen \
  thinkingbox-eval \
  --config "$PWD/thinkingbox.yaml" \
  --base-url http://127.0.0.1:8000 \
  --dataset "$THINKINGBOX_DATA" \
  --output q38-rlft-full.jsonl \
  --errors-output q38-rlft-full-errors.jsonl \
  --repeat 20 \
  --coverage-profile full \
  --aggregate-output q38-rlft-full-aggregate.json \
  --message-timeout 1800

full 配置文件会在聚合前校验全部 10,140 个预期任务/重复键。

后续方向

这项工作有价值的部分不是一个 Qwen3.8-27B 检查点，而是将可执行结果转化为奖励的训练循环和训练数据整理流程。

如果你正在训练或评估一个会接触真实数据库记录的 agent：

1. 先探测，再训练。 拿你自己的 agent 任务集，让基础策略对其运行 n 次，然后查看分带直方图。根据我们的经验，团队往往没有检查过这个分布，而它通常比预期更不均衡。
2. 检查一致性。 将同一份记录的模型输出分别通过训练解析器和评估解析器重放，验证两者提取出相同的工具名称和参数。否则，训练可能会奖励评估以不同方式解读的行为。
3. 同时报告覆盖率和可重复性。 说明有多少任务在 k 次尝试中至少通过一次，以及有多少任务在全部 k 次尝试中都通过。一个偶尔能找到解决方案的模型，未必能稳定地重复该解决方案。

更多细节可在以下链接中找到：

• 环境： envs/thinkingbox_env
• OpenEnv： ThinkingBox 环境文档
• 框架： microsoft/thinkingbox · 教程
• 基准测试： microsoft/thinkingbox-data · v1.0 版本
• 数据集查看器： microsoft/ThinkingBox-Bench
• 论文： arXiv:2608.19741 或 HF
• RL 训练： microsoft/thinkingbox-training
• 博客： The Agent Said It Was Done. The Database Disagreed.

引用论文

@article{li2026thinkingbox,
  title   = {One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows},
  author  = {Li, Zhuochun and Ko, Youngmin and Keramati, Ali and Kundu, Tuhin and
             Tsai, Liang-Chun and Ferri, Nicola and Milletari, Mirco and Liu, Jiaxiang and
             Lopez Pelaez, Susana Palmaz and Wang, Yuepeng and Smolyakov, Vadim and
             Jiang, Xiang and Olafsson, Kjartan and Guy, Tommy},
  journal = {arXiv preprint arXiv:2608.19741},
  year    = {2026},
  url     = {https://arxiv.org/abs/2608.19741}
}

ThinkingBox 代码采用 MIT 许可证；基准测试数据采用 CDLA-Permissive-2.0。

免责声明：公开基准测试中的每个任务都是合成重建的。工作流和策略以真实企业 agent 模式为蓝本；客户并非真实存在。

ThinkingBox、ThinkingBox-Bench 和 ThinkingBox-Training 由 Microsoft Copilot Studio 团队与 Toloka 合作构建，合作者包括曾在 Microsoft 实习的匹兹堡大学、西北大学、哥伦比亚大学和 UC Irvine 的研究人员。欢迎在下方评论区、github 或通过电子邮件 firstnamelastname@microsoft.com 提问。

⁺ 少数任务还包含针对数据库无法清晰捕获的结果的狭窄二元评分标准要求；这些检查可以调用已配置的 LLM 评判器。

⁺⁺ 这个零梯度问题有一个标准的批处理时修复方法：过采样、丢弃退化组、重新填充。全参数运行正是这样做的，类似于DAPO 对零方差组的替换。但重新填充仍然要为每个被丢弃的 rollout 支付全额代价。