本文翻译自英文原文，如有出入，以英文原文为准。
ArtifactNet 研究 · 第 7 部分 · 2026 年 7 月
缩小流派差距，并压低我们承诺要解决的误报率
这是一份涵盖 2026 年 7 月的研究日志。第 6 部分留下了一个承诺：接下来一个季度，把精力放在高难度真实音乐的误报率上，而不是再去追逐新的基准纪录。本文记录的就是我们如何兑现这个承诺，此外还有：一个我们曾悄悄放弃扫描的流派、一次基于我们所收集的最大数据集的从零重新训练，以及一个只因为我们主动去找才发现的部署缺陷。
想看看当前模型的实际效果？ 用免费演示处理任意曲目——与下文所述相同的取证流程，无需账号。
第 6 部分以一个具体而狭窄的目标收尾。我们整个 6 月都在追查的“udio 弱点”，结果只是评估泄漏造成的错觉——在干净的留出集上，udio 的检测表现良好，达到 97.8%。真正留存下来的弱点是对真实录音的误报：SoundCloud 上的业余上传、FMA、lo-fi。在我们 9 个来源的高难度真实音乐基准上，最好的候选模型的 FPR 仍为 15.57%，虽然已从 32.25% 降下来，但离生产级水准还差得很远。
我们曾说，下一个季度要直接针对这个数字下功夫，而不是再去积累一次基准测试上的胜绩。本文讲述的就是那个季度的经过。
我们的第一步不是换更大的模型，而是找一个“第二意见”。我们一直在追查的误报，大多并不是信心十足地判错，而是处于临界状态：它们靠近决策边界，而主 CNN 的单次推理在这个位置最不可靠。于是我们训练了一个小型的辅助模型——内部称为rescue-gate，一个 28 特征的 LGBM 头部（verdict28）——它唯一的任务，是对主网络没有把握的判定再看一眼，并在证据指向相反方向时推翻原判。
7 月初，我们把它接入了线上服务路径，并锁定了一个工作阈值（τ）。仅凭它自己，完全不动 CNN，rescue-gate 就明显降低了高难度真实音乐的误报——这说明我们的 FPR 问题中有相当一部分根本不是表征问题，只是决策边界问题。
我们现在严格执行的一条规则：rescue-gate 必须在它所把关的那一代 CNN 上重新训练。混用不同代——旧的 rescue-gate 接在新的 CNN 后面，或者反过来——并不是小幅漂移。我们有一份 4 月的事故记录，正是这种不匹配把误报推高到了 52%。因此，本文提到的每一次 CNN 晋升，都配有重新训练的对应 rescue-gate，而不是沿用旧的。
7 月中旬，我们做了一项规模较小的旁支调查：每个 AI 生成器是否会在嵌入空间中留下一种可区分的“指纹”，而且这种指纹有别于通用的“AI 对人类”信号？答案是有条件的“是”。无论使用哪种生成器，人类创作的音乐都位于与 AI 输出明显不同的区域；即使面对模型从未见过的生成器架构，这种分离也保持得相当好——但并非完美。这是一个旁支结果，不是已上线的功能，但它进一步证明，模型读取的是编解码器残留中的某种结构性特征，而不是在记忆每个生成器各自的表面线索（第 6 部分中失败的实验也指向同样的结论）。
大约同一时期，我们开始着手检测部分 AI曲目——即只有一部分素材由 AI 生成的歌曲（例如，在真人演奏的伴奏上叠加 AI 人声）。构建这个检测器，意味着要更仔细地观察各流派层面的表现，也因此暴露出一个我们一直在悄悄绕开而没有真正解决的问题：电子音乐的误报率异常高，高到我们已经不再试图有把握地扫描它。
当时的权宜之计，是对偏电子风格的来源有条件地上调阈值——这不是修复，只是在我们查明真正原因之前先止损的办法。下文第 6 节讲的就是那个原因。
到 7 月第三周时已经很清楚：调阈值和过一遍 rescue-gate，无论多有用，都无法补上流派差距，也无法把高难度真实音乐的 FPR 进一步压到位。这两个问题有同一个根源：CNN 的训练分布中，电子音乐不够多，现实中 SoundCloud 式的重新编码素材也不够多，以至于这两类都没有得到很好的表示。
于是我们做了项目历史上规模最大的一次重新训练——涵盖 22 个来源的 27,476 首曲目，所用清单已确认无泄漏（对照了此前每一代的所有训练日志核验，而不仅仅是紧邻的上一代）。我们把得到的检查点称为bigset。
在这个过程中，我们终于查清了究竟是什么在造成 SoundCloud 式的误报。不是平台，也不是“业余制作”这种含糊的类别，而是反复的 MP3 重新压缩。被多次重新编码为 MP3 的曲目（上传 → 重新下载 → 再次上传，这在聚合平台和混音文化平台上很常见）会累积压缩伪影，这些伪影与我们受训去捕捉的编解码器残留十分相似。一旦弄清了这一机制，我们就能在训练中直接体现它，而不是用阈值去掩盖它。
rescue-gate 按第 2 节的规则，在同一代 bigset 上重新训练；随后我们对 CNN 与 rescue-gate 的阈值一起做了完整的 2D 扫描，以锁定一个工作点——最终落在 τ=0.225，低于上一代的 0.5。
我们从头重新运行了 ArtifactBench——不是增量更新，而是完整的评测框架——共 5,458 首曲目（是我们此前 2,103 首曲目测试集的 2.6 倍），覆盖了我们追踪的全部 22 个 AI 生成器。
| 指标 | 上一代 | bigset |
|---|---|---|
| ArtifactBench F1 | 0.984 | 0.9921 |
| 被判为 AI 的真实音乐 | 4.2% | 0.38% |
| 固定 1.5% FPR 预算下的检测率 | 97.38% | 98.59% |
在误报预算保持不变的前提下，检测率仍然提高了 1.2 个百分点，这说明它是真正的模型改进，而不是被包装成模型改进的阈值调整。具体到 τ=0.02，在 5,458 首曲目上的原始计数为：4,334 个真阳性、4 个误报、65 个漏报、1,053 个真阴性——TPR 98.52%，FPR 0.378%。
按流派拆分的结果，才是我们真正想要得到的数字：
| 流派 | F1 |
|---|---|
| 流行 | 0.995 |
| 摇滚 | 0.993 |
| 电子 （此前是我们的薄弱环节） | 0.988 |
| Lo-fi | 0.987 |
| 嘻哈 | 0.987 |
| 原声 | 0.987 |
我们测试的每个流派现在都达到 F1 0.986 以上。在 bigset 之前，电子音乐是唯一达不到的流派——这就是本文题名所指的“流派壁垒”，也是我们第一次能够说所有流派同时都站到了这条线之上。
在我们自第 6 部分以来一直跟踪的留出真实音乐集上（排除 SoundCloud，以便把这一效果与重新压缩修复的影响专门区分开），误报从 5.98% 降到了 1.48%。这与我们上次披露的约 15% 属于同一个基准系列——并不是严格同口径的同一个数字，因为在此期间 rescue-gate 和阈值方面的工作已经把它压低了一部分，但走势是同一条线，而且现在低于 1.5%，不再是两位数。
把 bigset 晋升到生产环境，恰好暴露出第 2 节所警告的那种故障模式——只不过出在我们自己的基础设施里，而不是面向客户的模型上。我们的演示应用独立于主推理流水线加载 rescue-gate，在晋升期间，它一直指向上一代的 rescue-gate 检查点，而主 CNN 已经切换到 bigset。这与 4 月那次事故属于同一类不匹配，这一次是靠第 2 节确立的纪律发现的，而不是靠生产环境里 FPR 的飙升。我们已修复演示应用，使它与主流水线以同样的方式、从单一事实来源加载 rescue-gate。
第二个规模较小的疏漏：我们的研究演示服务器与实际面向客户的推理服务，是两台不同机器上的两套不同系统，而一次部署检查曾短暂地假定二者是同步的，实际上并不同步。我们在当天的最终验证中发现并更正了这个问题——但它提醒我们，“模型已晋升”和“模型正在承接流量”是两种不同的说法，每次都需要分别核实。免费演示和基于账户的批量服务现在都已确认在运行 bigset。我们的 RunPod 无服务器批量端点不在本次晋升的范围内，仍在使用上一代——那次覆盖更新另行安排。
我们还用 bigset 重新运行了每月一次的真实环境扫描——也就是本月早些时候定稿的 AI Music Index 方法。此前已经通过的主流音乐和 SoundCloud 子集再次得到了干净的结果，这在意料之中。有趣的变化出现在 Beatport 上：这是一个电子音乐曲库，由于上一代模型在那里的误报率无法使用（样本整体的 AI 概率中位数为 0.955——也就是促成第 4 节的那场“误报激增”），我们实际上把它排除在扫描之外。在 bigset 下，这一数字骤降为修正后的估计值 0.07%，置信区间包含零。电子流派曲库首次成为我们可以有底气去扫描的领域。
在早先一次 Index 运行中被标记的两首氛围/助眠音乐曲目，用完全不同的一代模型重新打分后，被更有把握地标记了出来（0.842→0.892 以及 0.633→0.759，而不是更低）——这说明那一信号是真实的，而不是旧模型已知弱点造成的假象。我们要明确说明：电子音乐曲库的样本量（43 首曲目）仍然太小，不足以让我们的分层 Rogan-Gladen 置信区间把零排除在外，所以这一子集目前还没有达到我们的发布门槛。我们宁愿暂不发布，也不往上凑整。
找第二意见，比换更大的模型成本更低。rescue-gate 在完全不改动 CNN 的情况下，让高难度真实音乐的 FPR 有了明显改善——但前提是它与所把关的模型保持同步的版本，这一条规则在留有一次事故记录之后，我们现在把它当作制度而不是惯例来强制执行。
上调阈值是权宜之计，不是诊断。我们在 7 月中旬为电子音乐上线的那项有条件调整争取到了时间，但没能解释任何问题。真正的修复，只是在我们追溯到机制（反复的 MP3 重新压缩）并在训练中体现它之后才出现。
“已晋升”和“正在承接流量”是两种不同的说法。我们在同一次上线中发现了演示应用的代际不匹配，以及演示服务器与生产服务器的混淆——两者都很轻微，都在造成影响之前被发现，也都提醒我们要核实整条链路，而不仅仅是模型产物。
还剩下的事：为走 RunPod 这条路径的客户做批量端点的覆盖更新，以及把电子音乐曲库的 Index 样本扩充到足以真正发布一个数字，而不是继续把数字扣着不发。
ArtifactNet 研究团队 · 2026 年 7 月