使用 OpenGameEval 对 Roblox Studio 的代理人工智能助手进行基准测试

挑战 

创作者利用 Roblox Studio 的 AI 助手来加速 Roblox 体验的开发，但评估 AI 助手及其底层大型语言模型（LLMs）在交互式开发任务中的表现仍是一项挑战。 传统编程和智能体基准测试侧重于孤立的无状态任务，而 Roblox 开发工作流则需要专门设计的评估方法，以衡量其在跨 3D 层次结构推理、管理多人游戏客户端-服务器交互以及对有状态世界进行修改等任务中的表现。

为应对这一挑战，我们推出 OpenGameEval——一个开源评估框架及原生基准数据集，可在可复现的 Roblox Studio 环境中评估基于 LLM 的 AI 助手性能。我们希望 OpenGameEval 及其公开排行榜能为更广泛的 AI 研究社区提供一个独特的测试平台，用于评估模型在工具使用、代理推理及长时限任务解决方面的核心能力。

OpenGameEval 基准数据集

OpenGameEval 基准数据集是一套开源、人工精选的 47 个测试案例集合，基于该框架通过严格、迭代且完全由人工验证的过程构建而成。我们收集领域专家提供的提示词，构建定制化的 Roblox 体验环境以向 AI 模型提供必要上下文，手动创建评估方案和权威解法，并对所有场景进行全面的人工审查，以确保其全面性、泛化能力和稳定性。  

初始版本包含源自常见 Roblox 开发任务的场景，涵盖游戏机制、环境构建、角色动画、界面设计及音效设计。OpenGameEval 基准采用可执行的单元测试，其评分方法与 pass@k、cons@k 和 all@k 等行业标准指标保持一致，用于量化模型在该数据集上的表现。研究合作伙伴在收集 OpenGameEval 运行的评估结果后，可自行复现这些指标。

与典型的函数级编码挑战不同，OpenGameEval 支持对核心组件进行端到端测试。成功的模型必须掌握多项独特技能，例如导航实例层次结构、分析对象状态，以及从环境上下文中推断用户意图。

多步骤任务与情境变异 

Roblox 编程任务通常需要通过多步骤操作来处理体验中的现有上下文，并分析多个相互交织的脚本和实例，以实现预期结果。在下面的示例中，OpenGameEval 会在模拟真实游戏实例环境的沙盒中验证多个因素，以确保模型能够恰当地处理多个相关脚本、客户端/服务器交互以及提示词的原始意图。  

用户提示：  实现一个生命值恢复系统，该系统在受到伤害两秒后启动，并以每秒恢复 10 点生命值的速度进行恢复。 场景文件上下文： 一个激光标签体验，其中武器、队伍和核心玩法机制已预先设置。 预期推理步骤：  理解上下文：使用不同的搜索工具探索该体验，这通常需要通过调整搜索范围进行多次搜索：  识别现有关于受损和玩家生命值的脚本，并理解其逻辑。 推断添加生命值恢复脚本的最佳位置（例如：在服务器端还是客户端？作为核心游戏脚本的一部分，还是作为独立的玩家脚本？）。  实现：使用适当的API编写Luau代码来操作玩家生命值。该脚本需要：  准确捕捉需要恢复生命值的时间点，并确定恢复机制的实现方式。  具备通用性，适用于所有伤害类型，不局限于特定伤害脚本。 可验证的评估：  可执行测试（在沙盒游戏实例中运行）向测试玩家触发伤害事件，并验证： 生命值恢复在服务器端处理正确，并在客户端可见。 生命值恢复不会在两秒延迟结束前开始。  生命值以每秒 10 点的速度恢复。

为有效测试 AI 模型的鲁棒性和情境理解能力，任务将在多种环境条件下呈现。例如，“编写四向交通信号灯脚本”任务包含三种基于开发环境初始状态的情境变体。 

用户提示：  为我编写一个简单的四向交通信号灯脚本。 变体 1： 一个仅包含底板的空场景文件。有一个名为 TrafficLight 的交通信号灯模型，但没有脚本。  模型需要探索 TrafficLight 模型内的不同组件，并找到一种方法来切换其开启/关闭状态。  变体 2： 一个包含郊区场景设置的场景文件。有多个名为 Traffic Signal 的交通信号灯模型可用，且均未附带脚本。  模型需首先搜索场景，准确识别出其他实例中的交通信号灯。这些交通信号灯模型的结构逻辑与变体 1 不同，模型需要针对此场景实现独特的解决方案。  变体 3： 一个郊区场景的场所文件。其中包含多个交通信号灯和行人信号灯模型。虽然交通信号灯的脚本已被移除，但行人信号灯的脚本仍然保留。  模型需识别交通信号灯与行人信号灯的差异，并对正确的对象进行修改。行人信号灯的存在会让模型感到困惑，还是会对其有所帮助？

我们致力于研究模型在不同环境（背景信息和复杂度各异）中处理看似相似任务时的行为表现。

初步结果

OpenGameEval 基准测试提供了实证数据，用于诊断交互式开发中 AI 助手当前的状态。测试用例旨在区分模型在原子操作与需要多步骤上下文推理的操作中的能力差异。 

初步测试表明，模型通常在原子操作中表现优异，但在上下文推理方面却举步维艰。它们在需要单一、直接实例操作的任务中（如设置粒子发射器或修改玩家跳跃力）取得了最高的成功率。领先模型展现出近乎完美的成功率，证明了其在语法代码生成和基础API知识方面的娴熟程度。

与此形成鲜明对比的是，在需要协同操作、上下文过滤和深度API集成的任务中，仍存在显著差距。如上文提到的生命值恢复系统和四向交通信号灯等示例，在所有模型中仍持续呈现极低的pass@k分数。

快速演进

随着模型的持续进化，我们预计这些差距将逐渐缩小，但我们已经观察到了一些有趣的发展。在一项要求模型“将类似立方体的 Roblox 标志改为绿色”的评估任务中，我们最初发现所有模型均告失败，因为目标对象的名称中并未明确包含“标志”或“Roblox”一词。 

最新的评估显示，部分模型已成功解决这一问题。它们不再局限于简单的关键词匹配，而是通过结构推理、精细实例检查（不仅关注名称，还包括属性）以及协同推理，成功识别出最可能代表“Roblox 标志”的对象。 

下一步是什么？ 

我们致力于持续扩展和维护 OpenGameEval，以追踪 AI 领域的快速进步。当前的 OpenGameEval 框架和基准测试仅是基础。我们的战略路线图聚焦于三个核心目标，以确保该平台始终是 Roblox Studio 代理式 AI 助手评估的行业标准：

• 通过性能透明度赋能创作者：我们将定期更新排行榜和基准数据集，同时提供清晰透明的总结报告，帮助创作者比较模型，并了解其在代码生成、资源插入和工具协调方面的表现。

• 加速研发进程：我们将维护并扩展 API 适配器以实现评估标准化，使研究合作伙伴能够运行快速、顺畅且可复现的基准测试，从而开发下一代 AI 助手。

• 采取社区驱动的方法：我们将持续整合真实世界的创作者意图，并积极征集社区贡献，以确保该基准测试能持续代表 Roblox 开发领域的最前沿动态，并推动 AI 能力的进步。

框架、数据集和公开排行榜共同构成了 OpenGameEval，使其成为评估 Roblox 开发中 AI 驱动创作的透明、协作型基础，帮助整个创作者社区衡量进展、分享见解并构建更优秀的助手。