基准末日

关于 vulnpocalypse 有很多讨论，我没有太多要补充的，因为我不是安全人员，但我还没有看到太多关于密切相关的（公平地说，不太严重的问题）基准pocalypse 的讨论。虽然获得显着的性能提升变得比以往任何时候都容易，但奖励破解基准并获得虚假的性能提升也变得比以往更容易。前者可能在许多不同的公司悄然发生，但后者是我现在每周至少看到一次的事情。有人会声称他们优化了 X 并比现有软件获得了巨大的性能改进，但是，当你仔细观察时，你会发现他们所做的只是进行了一些优化，提高了基准性能，但实际上并没有提高实际性能。这通常是某种“我们用 Rust 重写了 X”项目，或者是一家寻求融资或出售某些东西的新初创公司，但这种情况也发生在其他类型的项目上。当然，人们总是宣扬不具代表性的微基准来表明他们喜欢的项目很棒。伪造一个不具代表性的微基准总是很容易，而且这一点永远不会改变。改变的是，过去需要花费大量的工作来测试大型基准套件，但 LLM 和循环就可以做到这一点。在困难时期，有很多著名的大型基准测试套件的例子。例如，早在人们关心 SPECint / SPECfp 作为工作站性能的代表时，CPU 供应商就会尝试寻找编译器“优化”来加速基准测试中的计算，例如 Sun 找到了一种将 SPECfp2000 中的 179.art 提高 12 倍的方法。熟练的工程师花了很多时间试图找到这样的基准黑客。法学硕士使这变得微不足道，使得以前值得信赖的基准变得毫无意义，除非你审核结果或信任审核结果的人。我不会指出某人的错误主张，而是指出 FRE，这个我有一个代理构建的正则表达式引擎，我可以声称它是世界上最快的正则表达式引擎，因为它在相当全面的 rebar 正则表达式基准套件中击败了 Rust 正则表达式板条箱。但这是通过将代理置于一个循环中一个月来创建的，指示不要过度拟合基准，但没有真正的监督。在大多数情况下，获得法学硕士并给你一个良好的基准分数是相当容易的，这个例子也不例外；我们花了几周时间才大致匹配 Rust 正则表达式板条箱的性能，然后又花了几周时间才在 rebar 上达到 1.4 倍的速度。但智能体习惯于奖励黑客攻击和过度拟合，除非你设置严格的护栏来避免这种情况，但我在本例中并没有这样做作为实验。为了检查过度拟合，我有点武断地使用了 ripgrep 基准语料库作为保留基准，在基准因算法崩溃而不会永远花费的情况下，速度慢了 10 倍，并且在某些情况下，花费的时间太长，甚至等待基准完成都是不合理的。速度提高了 40%，真是太棒了！ Andrew Gallant（又名 BurntSushi）的钢筋基准套件与基准套件一样相当全面，但即使使用相当全面的基准套件，代理也可以毫无问题地获得高分，同时过度拟合，但不一定能提供良好的总体性能。下一步是使用我们之前讨论过的一个技巧，不仅告诉法学硕士不要作弊，而且还设置了一个坚持不懈的基准来对其进行评判。之后，LLM 的总体性能适度一般化，在坚持的情况下整体速度慢了约 2.4 倍。考虑到我们将其与现有最快的通用正则表达式引擎进行比较，这听起来相当不错。但是，请记住，这些基准是由编码代理制定的。看看基准衡量的内容，其中一些确实没有意义，至少在同等权重下是这样。如果我们只看看起来很重要的基准测试，FRE 在 Holdout 0 上慢了 4 倍，这比应用好 ole“告诉他们你有一个 Holdout”技巧之前要好很多，但距离快 40% 还差得很远。我认为这方面有几件事很有趣： 即使您指示代理不要奖励黑客或过度拟合来赢得基准，以一种毫无意义的方式“赢得”一个非平凡的基准也是微不足道的。一般来说，在（1）上，编写专门的代码（过去需要人们对某些特定用例具有认真的工程经验）的成本已经大大降低，难怪我看到这么多虚假的声明。在过去，要构建像 FRE 这样的东西，假装性能足够好，能够虚假地声称加速了 40%，您需要相当多的专业知识。至少，你需要