打造 OsuGAI：由 AI 生成的 osu! standard beatmap

OsuGAI 是 DanceGAI 第一个面向 osu! standard 的模型。osu! standard 是 osu! 最初的模式：圆圈、滑条和转盘分布在整个游戏区域里。它今天以测试版上线，与面向 osu! mania 的 ManiaGAI 并列。这份报告会说明它如何表示一张谱面、从什么数据中学习、如何训练、我们测量了什么——以及同样坦白地说明，它还有哪些地方做得不对。

为什么 osu! standard 比 osu! mania 更难

osu! mania 谱面是一列列的音符：生成器要决定一个音符什么时候出现，以及落在 4 到 9 条轨道中的哪一条。而在 osu! standard 里，每个物件还要在 512 × 384 的游戏区域上有一个位置，玩家必须移动过去。这就多出了三个 mania 没有的问题：

• 二维移动。物件之间的间距、跳跃角度和流畅度，基本决定了一张 standard 谱面玩起来是好是坏——而且它们是连续的，不是在几条轨道里挑一条。
• 滑条几何。滑条是一条有长度、有速度、有时还会往返的曲线；它必须契合音乐，也要契合周围的物件。
• 可读性。物件会在你击打之前出现，还会互相重叠、堆叠。一张谱面可以 timing 完美，却依然根本读不懂。

表示方式：先是玩法，再是编辑器物件

教模型学 osu! standard，最直接的办法是给它编辑器里的物件——“圆圈位于 (x, y)”“滑条带有这些控制点”。我们最先尝试的就是这一类方法。OsuGAI v1 则改为按谱面被玩的方式来描述它，之后再把描述还原成物件。每一拍由五个 token 组成：

• 一个交互 token：这一拍内的按键状态，以每拍 48 格采样——只有按下或松开，没有别的。点击是一次短按；滑条或转盘是一次长按。这个 token 是训练谱面中最常见的 4,096 种 48 格模式之一，覆盖了 99.87% 的训练拍和 99.69% 的留出拍。
• 四个空间 token：这一拍内最多四个时刻的光标位置——每一次按下、每一次松开，然后把最长的按住平均切分。位置落在 4 像素的网格上（128 × 96 格），所以最大取整误差是 2.83 像素；未使用的槽位留空。

也就是每拍五个槽位，共用一套 16,385 个 token 的词表（4,096 种按键模式加 12,289 个位置）。空间 token 所描述的时刻只由按键模式推出，所以模型根本不需要学习物件类型。

为什么要把预期的玩法和编辑器的表示分开？有两个原因，都是在训练任何模型之前，用真人回放测出来的。第一，编辑器里的选择在游玩中大多是看不出来的：只看光标，短滑条与圆圈能被区分开的比例只有 43–45%——所以物件层面的细节可以交给解码器决定，而不是要模型去猜。第二，玩法描述几乎不会丢失任何重要信息：用理想化的按键状态加真人光标路径重建的谱面，被其他玩家的回放击中的比例，和用感知物件的描述重建的谱面一样高（97.9% 对 98.0%）。如果改用玩家实际的按键状态，这个比例会降到 78.5%——真实的按键噪声太大，没法拿来学习，这就是按键 token 采用理想化状态的原因。

训练数据

语料库由 ranked、approved 和 loved 的 osu! standard 谱面组成——117,920 张谱面中有 117,918 张转换成功。验证集和留出集与训练集按歌曲隔离：其中的歌曲都没有出现在训练集里。和 ManiaGAI 一样，每张谱面的 timing 都先被移到我们自己 timing 检测器的网格上，这样模型训练时用的网格，和它生成时拿到的网格是同一种。没有任何谱面因为太难而被剔除。

光标位置从哪里来：osu!lazer 的 Auto 回放

谱面文件只说明物件在哪里，不说明光标在物件之间怎么移动。我们从 osu!lazer 的 Auto 回放——游戏内置的完美玩家——推出空间 token。我们把它的光标逻辑移植到 Python，并在 20 张谱面上与真正的游戏对照：264,716 帧，帧数完全相同，按键和堆叠零差异，平均偏差 0.014 像素。在一个 91 张谱面的基准测试中，由 Auto 光标路径解码回来的谱面，被其他玩家的真人回放击中的比例为 99.7%。

有一点要坦白：Auto 不是人。它会精确沿着每条滑条的路径走，所以它的光标很接近“把原始滑条几何写成位置”——72% 的原始滑条路径可以在 4 像素以内从 Auto 中读回，而从单个真人回放中只能读回 1%。因此，OsuGAI v1 学到的是 mapper 把东西放在哪里，而不是人实际上怎么移动。

架构

1. 音乐
2. Timing 网格
3. Planner
4. Noter
5. 解码器
6. .osu / .osz

OsuGAI 和 ManiaGAI 运行在同一个引擎上（详见Planner 与 Noter），只替换了与模式相关的部分：

• Planner（沿用）。一个小型扩散模型，与我们早先 osu! standard 工作中的版本完全相同。它在任何物件出现之前，就规划好歌曲的每一部分：星级，以及一份风格描述——滑条占比、角度特征、间距不规则度、stream 间距和节奏。
• Noter（全新）。一个约 6,410 万参数的 MaskGIT 式 transformer，按照规划、音频和难度设置（圆圈大小、缩圈速度、整体难度和滑条速度）填入每一拍的五个 token。除了精确位置的准确率之外，训练时如果位置落在目标 16 像素以内，也会给予部分分数。
• 解码器（基于规则，能识别往返）。把玩法还原成物件：一次按下变成圆圈；一次长按，如果光标绕着中心转了至少 1.5 拍就变成转盘，否则变成滑条——选用能让滑球紧贴预测路径的最简单的直线、圆弧或曲线。清晰且时间均匀的折返会变成往返滑条。新 combo 按固定规则划分。

训练：四轮

Noter 以我们之前的 osu! standard 模型为起点热启动，训练了四轮，每轮四个限时 epoch（每个约 46 分钟）——在单张 RTX 4070 Ti SUPER（16 GB）上总共约 14 小时，GPU 显存峰值约 6 GB。每轮结束后，我们都会生成一套评估集：8 首留出歌曲 × 22 种设置 = 176 张谱面。

• 验证损失在四轮中从 3.1389 降到了 2.9570。
• 结构有效性：每一轮中，全部 176 张评估谱面都是有效的 osu! standard 谱面——物件合法，没有槽位违规。
• 难度和风格有响应：8 首歌中有 8 首的实测星级随目标升高，四个风格维度中的每一个也都在 8 首歌中的 8 首上把谱面往正确的方向推——不过逐段遵循规划的能力仍然很弱。
• 确定性：同一首歌、同一个随机种子，得到逐字节相同的 .osu 文件。

速度。在那张开发用 GPU 上，Flower Dance（4:22）的八个难度走完计时的各个阶段约需 16–18 秒——音频准备、timing、音频特征、规划，以及约 11–12 秒的音符生成；解码和写文件在 CPU 上平均每张谱面再多约 0.6 秒。这是一个本地基准测试：线上运行在另一种云端 GPU 上，我们还没有测量 OsuGAI 的线上延迟。

局限性

有效的谱面不等于好玩的谱面，上面的任何数字都不能说明 OsuGAI 的谱面适合竞技游玩。我们已知的问题有：

• 难度超出目标。谱面会比目标更难，在高星级时还会难得多：在 Flower Dance 上，7.43、8.71 和 10 的目标实测分别为 9.28、13.49 和 13.99 星。因此网站只提供 ★1–★6 的目标，并始终显示实测星级。
• 与自身交叉的滑条。最后一轮生成的滑条中有 3.3% 会自相交（第一轮后为 2.4%），而原始谱面中只有 0.1%。
• 滑条几何瑕疵。有些滑条触到了速度上限（最后一轮为 2.8%），往返滑条也比人工谱面少（占滑条的 6.1%，人工谱面为 21%）。
• Auto 监督。光标路径来自 Auto，而不是真人：模型学到的是物件摆放，而不是人的移动。
• 溢出与词表回退。0.58% 的训练拍需要四个以上的位置；只保留前四个。0.13% 的拍落在 4,096 种按键模式之外，会改用最接近的那一种。非常密集的谱面受影响最大。
• 还没有大范围的真人试玩。目前所有检查都是自动的，或基于录制好的回放。测试版就是真人试玩的开始。

接下来

• 更好的难度校准——让目标值得信赖，并恢复完整的星级范围。
• 更干净的滑条几何——更少的自相交和被限速的滑条，更自然的往返。
• 真人游玩数据——学习人怎么移动，而不只是物件在哪里。
• 更强的风格控制——让谱面逐段遵循风格滑块，而不只是在平均上遵循。
• 更多 osu! 模式——osu! taiko 和 osu! catch 是路线图上的下一步。

刚接触这个模式？osu! standard 是什么？介绍了游戏本身；技术页面介绍了 OsuGAI 与 ManiaGAI 共用的引擎。