关于漏洞启示录的讨论很多，我对此并没有太多可以补充的，因为我不是安全专家，但我注意到关于与之密切相关的（而且可以说是较轻微的）问题——基准启示录的讨论并不多。尽管现在获取显著的性能提升变得前所未有的容易，但同时，操纵基准测试并制造虚假的性能提升也变得前所未有的简单。前者可能在许多公司之间悄然发生，但后者我现在几乎每周都会看到。某人会声称他们优化了某个项目 X，从而比现有软件有了巨大的性能提升，但实际上，他们所做的只是对基准性能的一些优化，而没有真正提高现实世界的性能。这通常是某种“我们用 Rust 重写了 X” 这样的项目，或者是一个新创业公司，试图融资或出售某个东西，但其他类型的项目也会发生这种情况。当然，人们一直都在利用不具代表性的微基准来展示他们的宠儿项目是多么出色。伪造不具代表性的微基准一直是件容易的事，而这永远不会改变。变化的是，以前操纵大型基准套件需要大量的工作，而现在一个语言模型和循环可以轻松完成。回想起来，有不少著名的操纵大型基准套件的例子，那时做这件事是困难的。例如，在人们曾经关心 SPECint / SPECfp 作为工作站性能代理的时代，CPU 供应商会试图寻找能够加速基准计算的编译器“优化”，例如 Sun 找到了提升 SPECfp2000 中 179.art 计算速度 12倍的方法。技术高超的工程师花费大量时间寻找类似的基准破解。如今，语言模型使这变得简单。与其指出某人的错误主张，不如说说 FRE，这个我让一个代理构建的正则表达式引擎，我可以声称它是世界上最快的正则表达式引擎，因为它在相当全面的 rebar 正则基准套件中击败了 Rust 正则库。但这是通过将一个代理置于循环中一个月来完成的，指示其不要过拟合基准，但没有真实的监督。大部分情况下，让一个语言模型给你一个良好的基准分数相对简单，这个案例也不例外；大约花了几周时间大致匹配 Rust 正则库的性能，然后又花了几周时间在 rebar 的性能上提升到 1.4 倍。但是，代理容易奖励破解和过拟合，除非你设置严格的保护措施来避免这一点，而我在这个实验中并未这样做。为了检查过拟合，我稍微任意地使用 ripgrep 基准语料库作为保留基准，在基准没有由于算法爆炸而需要很长时间的情况下，它在这些案例中慢了 10 倍，还有一些情况长到连等待基准完成都不合理。关于“快 40%”这句话听起来真是太乐观了！Andrew Gallant（又名 BurntSushi）的 rebar 基准套件在众多基准套件中算较全面的，但即使有较全面的基准套件，代理们仍然能在过拟合的情况下得到高分，这并不一定能提供良好的通用性能。下一步是使用我们之前谈过的一个技巧，不仅告诉语言模型不要作弊，还告诉它有一个保留基准集供其评判。在那之后，语言模型的表现适度地泛化到保留集上大约慢 2.4 倍。与现存最快的通用正则引擎比较，结果听起来还是不错的。但请记住，这些基准是由一个编码代理制作的。仔细看看这些基准所测量的内容，有些内容在平等权重下包含起来实在不合理。如果只看似乎有意义的基准，FRE 在保留集上慢了 4 倍，这当然比应用“告诉他们你有一个保留集”的好方法前要好，但距离所谓“快 40%”仍然相差甚远。我觉得有几件事有趣：即使在指示代理不要奖励破解或过拟合以“获胜”基准测试的情况下，仍然轻而易举地“赢得”一个非平凡的基准测试。再次强调，告诉语言模型有一个保留集的效果比仅仅告诉语言模型要进行泛化工作或不要过拟合或作弊要更好。尽管 FRE 的整体性能并不太好，但实际上在某些用例上表现较好；一般而言，以前需要人们有一定工程经验才能处理的专用代码写作成本已经大幅降低。关于（1），难怪我会看到这么多虚假的声明。在过去，要构建一个像 FRE 这样的能够虚假声称 40% 加速的东西，需要相当多的专业知识。至少，你需要对字符串匹配算法、正则引擎以及...