模型头部之下藏着什么：四个训练旋钮、三组通过的种子，以及起到全部作用的 seq_len

两篇文章之前，我们重建了一个一直在误导我们的语料库。一篇文章之前，我们讲述了在任何东西起作用之前的十七次失败训练。这是我们公开承认错误的第三章，附带数字为证。

简而言之：我们的生产门控 supA-v3 在首次尝试中就通过了六项预先登记发布门控中的五项。第六项——按语言划分的漏报率——之所以失败，完全是因为俄语攻击漏了过去。我们本可以照常发布；发布合同中并没有任何条款要求各语言之间做到完美平衡。但一个悄悄偏向英语的门控，对于在英语论坛之外部署智能体的人来说是一种风险，因此我们开展了一项有针对性的训练活动，以弄清楚这种情况为何发生。

答案结果是尴尬地机械。下面是我们学到的全部内容、看到的每一个数字，以及一个略带不适的观察：这个特定的修复原本很容易被忽略。

摘要

• v3 通过了 FPR（0.64%，上限为 ≤1%），但漏掉了 9.11% 的俄语攻击，使我们的分语言 FNR 预算超出了 1.1 个百分点。
• 我们的第一反应——在损失中将俄语攻击样本的有效权重提高到 x5——反而让情况更糟。RU FNR 从 9.11% 跃升至 31.72%。加大权重只是移动了分数，并没有改善排序。
• 在全部十次运行中，AUROC 都稳定在 0.99957 至 0.99989 之间，这表明我们并没有修复排序能力，只是在重新分配工作点。
• 真正的赢家是 seq_len=96，而不是任何加权旋钮或学习率。它是唯一一项能让编码器看到足够长的上下文、从而注意到多语言注入模式比编码窗口更长的改动。
• 三次独立的种子重跑确认了稳定性：阈值有所波动（这正是校准应有的表现），但门控结论完全复现。
• 本次活动共运行十次训练。这个成本最低的实验，教给我们的比本季度做过的其他任何事情都多。
• 已在 POST /v30/analyze 上线；认证方式、请求结构和调用示例请参阅开发者文档。

上次的进展

语料库已在 Hugging Face 上公开，采用 CC-BY-4.0 许可，每一行都附有来源信息。训练流水线和发布门控在任何模型接触数据之前，就已以机器可读的 JSON 形式预先登记。每次训练运行都会自动记录其配置、产物哈希和评估结果，因此这次活动读起来是一条可审计的记录，而不是一部精彩片段集。

在 v3 活动中，我们使用了 10,554 行数据进行训练：其中 9,754 行沿用自 v3，另外 800 条是全新的良性俄语问题，涵盖没有任何保留集条目涉及的爱好话题。污染检查结果干净。校准阈值给出的误报几乎为零。但一个问题立即浮现：按语言划分的漏报率讲述了一个难看的故事。

五种语言几乎是白得的，第六种则不然。

第一次尝试：更用力

当某个特定切片在召回率上失败时，最直观的想法是在训练中对该切片加大力度：提高损失中你希望更频繁捕获的那部分的权重。如果基础配方中已经包含 x3 的边界样本加权，或许俄语攻击需要总计 x15。

这次运行在机械层面是成功的：训练完成，产物生成，污染检查干净。然后评估结果出来了，让我们沉默了一秒钟：

RU FNR 从 9.11% 升至 31.72%。

AUROC 几乎没有变化（0.99957 → 0.99969）。这一差异很关键。一个排序能力没有提升的模型，无法通过改变损失权重来修复——你只是沿着一条固定曲线移动了截断点。这正是发生的事：校准阈值被推到了 0.99，意味着几乎每个决策都变得更加保守，而召回率的崩塌也就机械地随之而来。

阈值扫描显示了真实的情况。在网格中每一个 FPR 降到我们 1% 上限以下的点上，RU FNR 都高于 8% 的门控线；反之亦然。在该配置下，这两个约束无法相交。无论怎样寻找阈值，都找不到一个并不存在的值。

第二次尝试：放下权重

如果加大损失权重行不通，下一个合理的假设是架构层面的问题。值得注意的是，在 MiniLM 的分词器下，俄语的分词结果比其他五种语言都要长——对于语义相当的内容，平均多出大约 30% 至 40% 的 token。如果序列在 64 个 token 处被截断，攻击的尾部就可能完全不可见。

我们测试了两个变体：

• seq_len = 96，其余保持默认
• seq_len = 128，并将 lr_head 提高到 2e-3

两者都通过了。干净利落。每一道门控，依次通过。

这种模式——两次序列长度实验无论学习率如何调整都能通过，而所有不改变序列长度的变体则一直失败——正是分词窗口问题在你的数据中显现时的典型特征。

四个独立的配置达到了所有门控全部通过：

另有三个候选配置未能通过一项或多项门控，主要是较短序列的变体，其中较高的学习率仍然不足。

这张图的右半部分被刻意设计得很乏味。两个通过的配置处于同一区域，无论我们是否将学习率翻倍。序列长度才是承担主要工作的因素。

确认这不是运气

在一次扫描中取得四次通过，并不能证明因果关系。为了验证我们面对的是一个稳健的配方，而不是超参数的幸运组合，我们用不同的随机种子又对获胜配置重新训练了两次。其他条件完全相同。

校准阈值如预期般移动（0.50 → 0.91 → 0.80）——每个种子下的概率分布都会略有变化。门控结果却纹丝不动。当不同的随机初始化产生独立的阈值位置，却得出相同的硬门控结论时，你得到的是一项发现，而不只是一则轶事。

结合上面类似交叉验证的扫描，我们现在有七个不同的配置通过了完整的预先登记套件，且它们都可以追溯到同一个底层结构性选择。

获胜运行的真实面貌

在冻结的回归保留集上，使用我们所部署运行的校准阈值：

• 误报率： 测得 0.64%——156 条干净的负样本提示中有 1 条触发
• 分语言漏报： RU 0.56% · IT 0.00% · PT 0.00% · ES 0.00% · DE 0.12% · EN 0.00%
• bench-core 上的 AUROC： 0.99986
• 对 PromptGuard 漏报样本的捕获率： 98.8%
• CPU 推理延迟（int8 ONNX，batch=1）： p50 ≈ 27 毫秒，p95 ≈ 45 毫秒

这并未解决的问题

坦诚地说明局限，正是我们公开发布这些数字的全部意义。

我们测试了每个模型捕获规则引擎已知内容的改写，以及针对该语料库家族生成的、真正新颖的合成攻击的能力。真实对手的行为变化速度，比任何离线数据集所能跟踪的都要快。最终总会有某种东西以我们的保留集从未预料到的方式，同时绕过正则表达式和分类器。严格测量的意义在于知道自己在与什么打交道，而不是假装已经永久解决了检测问题。

第二点：获胜配置使用的是 96 个 token 的序列，而非 64 个。CPU 推理成本会适度上升（在我们的硬件上比 seq64 慢约 45%）。而且也没有理由认为，更长的序列会无限期地继续带来帮助；所要解决的失效模式，正是较长俄语短语被截断的问题，超出该窗口之后，你就是在为边际收益支付算力。

第三点：金丝雀划分和 bench-private-holdout 划分的排除，是通过 ID 断言来维持的。这种污染防控纪律能经受审计，但面对我们尚未摄入的新语料来源时仍然脆弱。

第四点：在本次活动中，有九个配置在任何一个成功之前，就至少未能通过一项门控。只发布通过的故事，无法说明如何构建能够捕获这些失败的流水线。每一次失败——包括像 x5 权重导致 31.72% 崩塌那样的灾难性失败——都按原样保留在提交日志中。

下一步

在 POST /v30/analyze 上与确定性规则引擎以 OR 组合模式进行影子部署：正则命中或模型分数超过阈值即产生拦截；仅其中之一不一定产生放行。规则引擎处理头部遗漏的内容；神经网络捕获正则无法看到的其他一切。延迟叠加是有意为之的：正则路径开销很小，并且在 ONNX 运行时出现异常时可充当备用方案。

想亲自试试吗？请前往开发者文档：完整的 /v30/analyze 合约、认证设置和请求结构都记录在那里，影子指标稳定后 /openapi.json 也会提供。客户端集成说明将在预发布环境的试运行期结束后发布到更新日志中。

2026 年 10 月 14 日更新：措辞已修改，改为陈述实测结果。