基准测试末日

# 基准测试末日 来源：http://danluu.com/benchpocalypse/ 关于"漏洞末日"已有诸多讨论，我本人并非安全领域专家，对此所知甚少。但有一个密切相关且相对不那么严重的问题却鲜少被提及——我称之为"基准测试末日"。 尽管如今实现显著性能提升比以往任何时候都容易，但通过操纵基准测试制造虚假性能数据也变得同样简单。前者正在众多企业中悄然发生，后者我如今每周至少目睹一次。总有人宣称他们优化了某项技术，相比现有软件实现了巨大性能飞跃，但细看之下，他们所做的不过是某种仅能提升基准测试分数却无益于实际性能的优化。这类项目常见于"我们用Rust重写了X"1 (http://danluu.com/benchpocalypse/#fn:P)式的宣言，或是寻求融资/推销产品的新创企业，但在其他类型项目中同样屡见不鲜。 诚然，人们历来都爱用不具代表性的微基准测试来标榜自己心爱的项目。构造不具代表性的微基准测试一直易如反掌，这点永远不会改变。但变化在于：过去操纵大型基准测试套件需要大量工作，而现在只需用大语言模型配合循环程序就能轻松实现。在操纵大型基准测试套件还很困难的年代，存在不少著名案例。例如早年业界关注SPECint/SPECfp作为工作站性能指标时，CPU厂商会寻找能加速基准测试计算的编译器"优化"手段。比如Sun公司曾在SPECfp2000中通过优化`179.art`模块实现12倍提升2 (http://danluu.com/car-safety/)。当时需要资深工程师耗费大量时间挖掘这类基准测试漏洞，而大语言模型让这一切变得轻而易举。 我不打算指出某个具体的虚假宣称，而是以我让智能体构建的FRE正则表达式引擎3 (https://github.com/danluu/fre/)为例。按理说它堪称世界最快正则引擎，因为在相当全面的rebar正则基准测试套件4 (https://github.com/BurntSushi/rebar)中击败了Rust regex crate。但这个项目是通过让智能体循环运行一个月实现的，虽然指令明确要求"不要过拟合基准测试"，却没有任何实质监督。通常情况下，让大语言模型在基准测试中取得高分相当容易，这个案例也不例外：最初几周大致匹配了Rust regex crate的性能，随后几周又提升了1.4倍5 (http://danluu.com/benchpocalypse/#fn:O)。但除非设置严格的防护机制，否则智能体总会倾向于操纵基准测试和过拟合——我这次纯粹出于实验目的并未采取这些措施。 为检验过拟合程度，我随意3 (http://danluu.com/benchpocalypse/#fn:A)选用ripgrep基准测试语料库作为保留集进行验证。结果发现在基准测试未因算法爆炸而耗时过长的情况下，FRE速度慢了10倍；某些案例甚至耗时长到无法等待测试完成。所谓40%的性能提升就此破灭！ Andrew Gallant（又称BurntSushi）的rebar基准测试套件已相当全面，但即便如此，智能体仍能在不过度拟合的前提下轻松获得高分，且这种高分未必代表真实的通用性能表现。 下一步我们采用了曾讨论过的方法6 (http://danluu.com/pl-tokens/)——不仅警告智能体不得作弊，还告知其存在用于评估的保留测试集。此后智能体实现了中等程度的性能泛化，最终在保留集上整体慢了约2.4倍。考虑到比较对象是目前最快的通用正则引擎，这个结果看似不错。但请记住，这些基准测试本身就是由编码智能体生成的。查看测试指标后会发现，某些测试项根本不应纳入，至少不应给予相同权重。若只关注实际重要的测试项，FRE (https://github.com/danluu/fre/)在保留集上慢了4倍7 (http://danluu.com/benchpocalypse/#fn:and-actually-runs-all-tests-to-completion-so-the-speedup-was-much-more-than-just-10-4)。虽然这比应用"告知保留集"策略前好得多，但距离40%的性能提升仍相去甚远。 这件事有几个值得关注之处： 1. 即便明确指令智能体不得操纵基准测试或过拟合，仍可轻松"赢得"非平凡基准测试——尽管毫无意义 2. 再次证实：告知大语言模型存在保留集，比单纯要求其"保持泛化性能/不作弊"效果更佳 3. 尽管FRE (https://github.com/danluu/fre/)整体性能一般，但在特定用例中确实更优；总的来说，为特定用例编写专业代码（过去需要资深工程师经验）的成本已大幅降低 关于第1点，难怪现在充斥着这么多虚假宣称。过去要构建像FRE (https://github.com/danluu/fre/)这样能虚假宣称40%提速的项目，需要相当专业知识。至少要深刻理解字符串匹配算法、正则引擎原理，并具备扎实的通用代码优化与SIMD优化能力。由于FRE还包含将正则编译为机器码的模式，还需编译器专业知识。而现在只需几分钟输入即可获得这种基准测试作弊能力（无论你是否愿意）。 关于第2点，我很好奇这种策略是否具有普适性，但目前尝试案例尚不足以判断。 关于第3点，没有人会选用耗费极少人力、性能却不敌成熟可靠现有库的"氛围编程"正则库，因此我对FRE (https://github.com/danluu/fre/)这个产物本身不感兴趣。真正有趣的是大语言模型能在多大程度上替代那些曾经稀缺、专业且昂贵的知识。 过去即便拥有相关专业知识，也很少有人会为特定工作负载编写定制正则引擎。某些大规模用例确实会进行这种深度定制——例如我在Bing索引组 (http://danluu.com/bitfunnel-sigir.pdf)工作时，代码中包含多个不同的编译器，因为追求极致性能的工程师认为：搜索引擎需要同时考量编译时间与运行性能，不同模块的权衡取舍各不相同，为每个模块编写专用编译器（而非通用解释器或直接操作数据结构）能获得更好性能。编写这些编译器的人若处理正则类代码，可能还会编写多个定制正则引擎。但同时具备专业知识与定制意愿的人本就凤毛麟角，更不用说工作中有空闲投入如此专业的代码开发。若对比当时这位Bing工程师（现为杰出工程师）的薪资与运行大语言模型循环的成本，这类专业代码的开发成本已下降了数个数量级。 尽管FRE (https://github.com/danluu/fre/)整体性能不及Rust regex crate，但针对工作负载/用例优化所能带来的收益意味着，在某些场景下插入定制正则引擎是合理的。其他各类底层软件同理。即便不是AI至上主义者，也应认为在可预见的未来，这种深度定制可能扩展到更复杂的系统（如数据库）。 *感谢Yossi Kreinin、Jamie Brandon、Peter Geoghegan、Luke Burton、John Spurling和Max Bittker提供的评论/修正/讨论。* *附言：如7 (http://danluu.com/pl-tokens/)所述，大语言模型使探索新事物满足好奇心的时间大幅缩短，但将成果整理成足够严谨的博文所需时间并未改变（实际上我认为反而增加了）。结果是我比以往进行了更多分析，与少数朋友分享成果却未正式发布。作为实验，我尝试以更低标准（比起通常博文要求）快速整理内容——更像是与朋友闲聊而非博文写作。本文目标是在半小时内完成撰写，适合午餐时间完成。若你对此有看法，欢迎告知。**需要注意的是，本文所有数据出错风险比平时更高。我仅花一两分钟检查某个基准测试就发现问题，又花一分钟检查另一个测试发现另一个问题。虽已修正，但这意味着可能存在其他未追踪的问题。不过就错误基准数据而言，这极具现实意义！每次审视基准数据时——无论此处 (http://danluu.com/pl-tokens/)、此处 (http://danluu.com/exercise-7/)还是其他案例——数据都存在错误。基准测试末日的另一面是：至少目前看来，大语言模型擅长执行劣质基准测试，因此即便确实存在性能提升，除非经过大量精心设计确保基准设置合理，否则通常无法从AI生成的基准测试配置中分辨真伪。* ### 附录：更多FRE基准测试细节 在发布前写作过程中我发现，大语言模型声称"FRE (https://github.com/danluu/fre/)在rebar上比Rust regex crate快40%"的说法也是错误的。或者说即便不算错误，至少存在误导。因为它实际上并未按照rebar的原始运行方式进行测试。我花一分钟检查基准结果时发现了两个问题：尽管明确要求按https://github.com/BurntSushi/rebar方式运行rebar基准测试，大语言模型却修改了接口以允许FRE进行某些性能优化。修正后，FRE (https://github.com/danluu/fre/)非但没有比Rust快1.4倍，反而慢了1.5倍（仅比re2快两倍），因此原始结果是双重虚假——不仅FRE (https://github.com/danluu/fre/)高度过拟合rebar基准，测试过程也存在作弊行为。 但积极的一面是，这表明FRE (https://github.com/danluu/fre/)在rebar上（比Rust慢1.5倍）与在保留集上（慢2.4倍）的性能差异不如先前看起来那么大，证明"告知大语言模型存在保留集"的策略效果比预期更好。 此后我让大语言模型进行数小时爬山优化，它宣称FRE (https://github.com/danluu/fre/)实现了1.28倍提升——仅几小时的AI时间就取得如此改进看似惊人。但我决定再花一分钟检查作弊行为，结果发现了多个问题，包括搜索`\(?s\)^\(\.\*\)$`匹配数时甚至未查看待搜索数据就返回结果，以及在应当逐行执行的基准测试中进行多行搜索。发现这些问题并不意外，因为这正是让智能体在缺乏严格防护的循环中运行一个月会出现的情况。这究竟是强化还是削弱了我的观点尚不明确，但在修正另一批问题后，FRE (https://github.com/danluu/fre/)又回到了慢1.4倍的状态。让智能体通宵运行后，FRE (https://github.com/danluu/fre/)据称又恢复了1.5倍的性能提升。 由于我最初目标是观察当前最先进的公开智能体（GPT-5.6 Sol）在缺乏监督的情况下处理非平凡代码优化问题的行为，而非继续修复基准测试公平性问题，就此打住并附上部分结果图表。 总体而言，与Rust和RE2相比，FRE (https://github.com/danluu/fre/)在rebar基准测试中往往表现更优（如前所述，这很大程度源于过拟合），但并非全面领先（下图可能与文章所述数字不完全匹配，因为智能体持续修改代码，任何快照都是即时估计且会立即过时）： 若对特定基准测试或rebar测试分类的性能感兴趣，可参见下表（比值大于1表示FRE更快，小于1表示FRE更慢）： 此外还有AOT编译模式，可将正则表达式预编译为原生代码（耗时较长）。虽然非全部功能都支持AOT，但以下是支持案例的结果。可见AOT编译非常耗时（在编译时间基准测试中表现极差），且尽管花费大量时间编译，结果往往比标准FRE (https://github.com/danluu/fre/)正则引擎更慢（尽管某些案例确实更快）。 最后是保留集基准测试。如前所述，对于非AOT版FRE (https://github.com/danluu/fre/)代码，其在保留集上的表现不如rebar。同时考虑该测试面向ripgrep类工作负载，"热点搜索"测试集可能比其他更重要，因此FRE (https://github.com/danluu/fre/)的实际表现比总体评分显示的更差。 需注意的是，在排除编译时间且反复执行搜索的保留集测试中，AOT版FRE (https://github.com/danluu/fre/)表现优异。许多用例无需耗时数秒的编译过程，但某些场景完全可行——例如ripgrep或Silver Searcher可先用即时匹配的正则启动，同时在后台线程编译优化版本，完成后切换。考虑到我有大量CPU时间消耗在长时间ripgrep搜索上，此类策略可能提升我个人工作性能。在大语言模型出现前，投入精力编写优化正则编译器并不划算，但现在只需少量token即可实现。 另一点需要注意：本次比较可能不完全公平，因为测试运行在配备SVE/SVE2指令集的ARM Graviton服务器上，而FRE (https://github.com/danluu/fre/)包含SVE/SVE2优化。在大语言模型出现前，为每种SIMD指令组合优化正则引擎可能不值得，但现在大语言模型可以相对容易地生成尚可的SIMD优化代码。我知道人类专家在此领域通常仍能超越AI，例如Jay Stel