从真实工作出发构建 benchmark：饱和、mock 与污染
一、公开 benchmark 为什么在饱和
一个评测基准的价值，在于它能区分能力不同的模型。当主流模型在某个基准上的得分彼此接近、并逼近上限时，它就很难再提供新的信息。这就是通常说的饱和。
我们认为饱和至少有三个来源。第一，题目分布与真实工作脱节：许多基准由研究者编写或从公开竞赛中收集，任务边界清晰、输入输出规整，而真实工作往往充满不完整的需求、遗留代码与跨系统依赖。第二，公开即被吸收：题目一旦公开，就可能直接或间接进入模型语料，分数提升未必代表能力提升。第三，结果评分过于粗粒度：只看最终是否通过，分不清方向对了但没做完，和一开始就走偏。
因此，与其再做一个更难的题库，我们更关心的是：能否让评测任务直接来源于真实存在的工作，并在发布方式上控制它被吸收的速度。
二、把企业旧系统变成 RL 环境
审批流、报表工具、老旧的业务后台，这些企业内部的遗留系统，恰恰是 Agent 在真实落地中最常面对的对象。但它们无法直接拿来做评测：连接着生产环境、依赖内网服务、状态不可重置。我们的做法是为它们做 mock：
- 边界识别：梳理系统对外依赖（库表、外部接口、身份认证、文件存储），确定哪些需要替换、哪些可以保留。
- 内容替换：用结构一致、语义合理的模拟内容替换真实内容，确保不含个人信息与商业秘密，同时保留足以构成任务难度的业务约束。
- 依赖桩化：为外部接口编写行为一致的桩服务，使系统可以在隔离容器中完整运行。
- 状态可重置：每个任务回合从同一快照开始，保证不同模型、不同次运行之间结果可比。
- 可执行验证：为每个任务定义可以程序化检查的完成条件，必要时由领域专家补充 Rubric，用于过程评分。
经过这些步骤，一个旧系统就成为一个接口统一（重置、执行动作、观察结果）的交互环境，既可用于评测，也可作为强化学习环境。
三、如何控制污染
污染无法被彻底消除，但可以被管理。我们计划采用以下做法：
- 公开子集与私有测试集分离：只公开少量样题用于说明格式与难度，主要评测在私有集上进行。
- 版本化与轮换：评测集按版本发布，定期替换任务，报告结果时注明版本。
- 来源可追溯：每个任务记录来源类型与构建时间，便于事后分析某一结果是否可能受到污染影响。
- 过程而非仅结果：结合步骤级的过程评分，减少靠记住答案得来的虚高。
四、尚未解决的问题
mock 化在多大程度上保留了真实系统的难度？过程评分如何在专家主观判断与可复现性之间取得平衡？私有测试集如何在保持可信的同时接受外部审查？这些是我们接下来要回答的问题，也欢迎同行交流。
— 八分之七实验室