基準測試末日：當 LLM 讓偽造效能提升變得輕而易舉

最近關於「漏洞末日」（vulnpocalypse）的討論很多，我對此沒有太多可以補充的，因為我不是安全領域的專家。但我注意到一個密切相關（雖然較不嚴重）的問題，那就是「基準測試末日」（benchmarkpocalypse）。

雖然現在比以往任何時候都更容易實現真正的效能提升，但同樣地，現在也比以往任何時候都更容易操縱基準測試，以獲得虛假的效能提升。前者可能正在許多不同的公司悄悄地進行，但後者是我現在每週至少會看到一次的情況。有人會聲稱他們優化了 X，並在現有軟體上取得了巨大的效能提升，但當你仔細查看時，他們所做的優化只是改善了基準測試的表現，而實際上並未提升真實世界的效能。這通常是某種「我們用 Rust 重寫了 X」的專案，或是尋求籌資或銷售產品的新創公司，但這種情況也發生在其他類型的專案上。

當然，人們一直以來都會利用有代表性的微基準測試來證明他們的寵兒專案很棒。偽造一個沒有代表性的微基準測試一直都很容易，而且這點永遠不會改變。改變的是，過去要操縱一個大型基準測試套件需要付出很多努力，但現在 LLM 和迴圈就可以做到。過去，當這件事很困難時，有很多著名的操縱大型基準測試套件的例子。例如，很久以前，當人們將 SPECint / SPECfp 作為工作站效能的指標時，CPU 製造商會試圖尋找編譯器「優化」，以加速基準測試中的計算，例如 Sun 在 SPECfp2000 中找到一種方法將 179.art 的效能提高了 12 倍。技術精湛的工程師花了很多時間試圖找到這樣的基準測試漏洞。LLM 讓這件事變得微不足道，使得過去值得信賴的基準測試變得毫無意義，除非你審查結果或信任做過審查的人。

我不會指出某人的錯誤聲明，而是會提到 FRE，這是一個由代理程式建構的正規表達式引擎，我可以聲稱它是世界上最快的正規表達式引擎，因為它在相當全面的 rebar 正規表達式基準測試套件中擊敗了 Rust 的正規表達式 crate。但這是透過讓代理程式在迴圈中運行一個月，並指示它不要過度擬合基準測試，但沒有真正的監督。總的來說，讓 LLM 獲得良好的基準測試分數相當容易，這個案例也不例外；花了幾週時間大致匹配 Rust 正規表達式 crate 的效能，然後又花了幾週時間在 rebar 上達到 1.4 倍的速度。但除非你設置了嚴格的防護措施來避免，否則代理程式傾向於獎勵漏洞和過度擬合，而我在這個案例中沒有這樣做，這是一個實驗。

為了檢查過度擬合，我有點隨意地使用了 ripgrep 的基準測試語料庫作為保留基準測試，在基準測試不會因為演算法爆炸而耗費過長時間的情況下，它慢了 10 倍，而且有些情況下，它耗時太長以至於無法合理地等待基準測試完成。所以，聲稱快 40% 就這樣了！

Andrew Gallant（又名 BurntSushi）的 rebar 基準測試套件，就基準測試套件而言相當全面，但即使是相當全面的基準測試套件，代理程式也能輕鬆獲得高分，同時過度擬合，而這並不一定能帶來良好的通用效能。

下一步是使用我們之前討論過的技巧，不僅告訴 LLM 不要作弊，還告訴它有一個保留基準測試集，它將根據該基準測試進行評估。之後，LLM 適度地泛化了效能，使其在保留基準測試上整體慢了約 2.4 倍。考慮到我們將其與現存最快的通用正規表達式引擎進行比較，這聽起來相當不錯。但是，請記住，這些基準測試是由編碼代理程式製作的。查看基準測試的衡量標準，其中一些在同等權重下似乎沒有意義。如果我們只看那些看起來很重要的基準測試，FRE 在保留基準測試上慢了 4 倍，這比應用「告訴它們你有保留基準測試」技巧後要好得多，但仍然離快 40% 相當遙遠。

有幾點我認為很有趣：

關於 (1)，難怪我看到這麼多虛假的聲明。過去，要建構像 FRE 這樣能夠很好地偽造效能，以便能夠虛假地聲稱加速 40% 的東西，你需要相當多的專業知識。至少，你需要對字串匹配演算法、正規表達式引擎，以及相當不錯的通用程式碼優化和 SIMD 優化技能有深入的了解。FRE 還有一個模式，它可以將正規表達式編譯成機器碼，所以你還需要一些編譯器專業知識。現在，你可以透過幾分鐘的打字來獲得這種基準測試作弊（無論你是否想要作弊）。

關於 (2)，我很好奇這是否會泛化，但還沒有嘗試足夠的範例來判斷。

關於 (3)，沒有理由使用一個幾乎沒有人類努力的、效能比健壯、現有、經過充分測試的程式庫還差的「氛圍編碼」正規表達式程式庫，所以我發現 FRE 的產物並不有趣。這裡有趣的是，LLM 在多大程度上可以取代過去稀有、專業且昂貴的知識。

過去，即使你擁有知識，你可能也不會編寫一個針對你特定工作負載進行優化的自訂正規表達式引擎。有一些大規模的使用案例，人們會進行這種程度的客製化，例如，當我處理 Bing 索引時，程式碼中包含多個不同的編譯器，因為在那裡工作的人想要榨取最大的效能；由於你在搜尋引擎中同時關心編譯時間和編譯後的效能，並且在不同地方的權衡不同，因此透過為正常專案可能只使用解釋器或直接使用「正常程式碼」遍歷某些資料結構的地方編寫自訂編譯器，可以獲得更好的效能。編寫這些編譯器的人，在處理類似正規表達式的程式碼時，也可能會編寫多個自訂正規表達式引擎，但很少有人同時擁有專業知識和意願這樣做，更不用說有自由在工作中花費這麼多時間在如此專業的程式碼上。如果你將那位 Bing 工程師（當時是合夥人級工程師，因其在搜尋索引上的工作被晉升為傑出工程師）的成本與運行 LLM 的成本進行比較，編寫這種專業程式碼的成本已經下降了好幾個數量級。

儘管整體 FRE 正規表達式引擎的效能比 Rust 正規表達式 crate 差，但為你的工作負載或使用案例進行專門化所能獲得的收益意味著，在某些情況下，插入你自己的專門正規表達式引擎可能是合理的，對於各種其他類型的低階軟體也是如此。你不必成為 AI 極端主義者，就可以認為在幾年內，我們可能會看到這種情況發生在更大的事物上，例如資料庫。

感謝 Yossi Kreinin、Jamie Brandon、Peter Geoghegan、Luke Burton、John Spurling、Dennis Snell 和 Max Bittker 的評論/更正/討論。

P.S. 根據這裡的討論，透過 LLM，花點時間探索事物以滿足我的好奇心的時間大大縮短了，而撰寫內容並使其嚴謹到足以發布到我的部落格上的時間實際上沒有改變（由於各種原因，我認為它實際上有所增加）。結果是，我現在進行的分析比以往任何時候都多，並與一些朋友分享結果，但沒有發布。作為一個實驗，我正試圖非常快速地寫下一些東西，對清理和嚴謹性的標準比我通常對發布到部落格上的內容的要求要低得多；更像是與朋友隨意交談，而不是我通常會寫在部落格文章中的內容。這篇文章的目標是在大約半小時內完成撰寫，這樣我就可以在午餐時間完成，而無需真正花費時間。如果你對此有任何意見，請告訴我！

當然，這裡有一個警告，所有數字出錯的風險都比平常高。我花了一兩分鐘看了一個基準測試，發現了一個問題，然後又花了一分鐘看另一個基準測試，又發現了一個問題。這兩者都已修復，但這意味著還有其他我沒有花時間去追查的問題。但是，就糟糕的基準測試數字而言，這是非常現實的！幾乎每次我深入研究基準測試數字時，例如在這裡或在這裡，數字都是錯誤的。基準測試末日的另一個方面是，至少目前來說，LLM 擅長進行糟糕的基準測試，所以即使你擁有一個真正的效能提升，除非花費大量精力確保基準測試設置合理，否則你通常無法從一些 LLM 生成的基準測試設置中得知。

在我寫完以上內容但在發布文章之前，我發現 LLM 聲稱 FRE 在 rebar 上比 Rust 正規表達式 crate 快 40% 的說法也是錯誤的。或者，如果不是錯誤，至少是誤導性的。它實際上並沒有以 rebar 基準測試運行的方式運行基準測試。在花了一分鐘檢查基準測試結果後，我發現了兩個問題。結果是，儘管指示按照 https://github.com/BurntSushi/rebar 的方式運行 rebar 基準測試，但 LLM 更改了介面，允許 FRE 進行一些優化以提高效能。修復後，FRE 在 rebar 上不再比 Rust 快 1.4 倍，而是慢了 1.5 倍（並且「僅」比 re2 快兩倍），所以最初的結果是雙重虛假的。FRE 不僅嚴重過度擬合了 rebar 基準測試，而且結果還涉及作弊。

但從好的方面來看，這意味著 FRE 在 rebar 上的效能（比 Rust 慢 1.5 倍）與在保留基準測試上的效能（慢 2.4 倍）之間的差異不像之前看起來那麼大，所以「告訴 LLM 你有保留基準測試」的技巧比之前看起來效果更好。

之後，我讓 LLM 進行了幾個小時的爬坡，它聲稱 FRE 快了 1.28 倍，這聽起來像是僅僅幾個小時的 LLM 時間就取得了巨大的進步，但隨後我決定花另一分鐘尋找作弊行為，並發現了多個問題，包括一個案例，其中搜尋 (?s)^(.*)$ 的匹配計數在甚至沒有查看字串（資料）的情況下就返回了計數。另一個作弊案例是進行多行 grep，而基準測試應該逐行進行。發現這些並不令人意外，因為當你讓代理程式在沒有定義嚴格防護措施的情況下運行一個月時，就會發生這種情況。這是否會加強我的觀點，還是削弱它，尚不清楚，但在修復了另一組這些問題後，FRE 又回到了慢 1.4 倍。讓代理程式運行一夜後，FRE 據稱又回到了快 1.5 倍。

由於我最初的目標是觀察當你在沒有太多監督的情況下，讓一個當前的（公開的）SOTA 代理程式（GPT-5.6 Sol）在一個非平凡的程式碼優化問題上運行時會發生什麼，而不是花更多時間修復以使基準測試更公平，我將在這裡停止，並展示一些結果圖表。

總體而言，我們可以發現，與 Rust 和 RE2 相比，FRE 在 rebar 基準測試上傾向於表現更好（如上所述，這很大程度上歸因於過度擬合），但並非全面領先（下面的圖表不一定與文章中提到的數字相符，因為代理程式不斷進行更改，因此任何快照都是即時估計，會立即過時）：

如果你對特定基準測試或特定類別的 rebar 基準測試的效能感興趣，我們有以下表格（大於一的比率表示 FRE 更快；小於一表示 FRE 更慢）：

還有一個 AOT 編譯器模式，它需要很長時間才能將正規表達式編譯成原生程式碼，然後再運行它。並非所有情況都支援 AOT，但這裡是在支援情況下的結果。正如我們所見，AOT 編譯器非常慢（在編譯時間基準測試中表現非常差），儘管花費了大量時間編譯，結果通常比標準 FRE 正規表達式引擎慢（儘管在許多情況下也更快）。

然後是保留基準測試。如上所述，對於非 AOT FRE 程式碼，在保留基準測試上的效能不如在 rebar 上。正如上面所指出的，考慮到這是一個類似 ripgrep 的工作負載，對於其他基準測試，「熱搜尋」基準測試集可能比其他基準測試更重要，因此 FRE 的結果比整體分數看起來要差。

需要注意的一點是，對於我們不將編譯時間計入基準測試的保留基準測試案例，並且我們重複運行搜尋，AOT FRE 在基準測試上表現更好。對於許多使用案例，你可能不想要一個需要數秒才能編譯的正規表達式，但也有很多情況下這是可以接受的，例如，對於像 ripgrep 或 Silver Searcher 這樣的東西，它可以開始運行一個可以立即開始匹配的正規表達式，然後在另一個執行緒中編譯，並在編譯完成後切換到更快的匹配器。考慮到我的 CPU 有多少時間花在長時間的 ripgrep 搜尋上，這樣的策略似乎可以提高我個人工作的效能。在 LLM 出現之前，花費精力編寫一個優化的正規表達式編譯器可能沒有意義，但現在只需幾個 token 就可以做到。

還需要注意的另一點是，這個比較可能不公平，因為它是在配備 SVE/SVE2 的 ARM Graviton 機器上運行的，而 FRE 具有 SVE/SVE2 優化。在 LLM 出現之前，為各種 SIMD 指令組合優化正規表達式可能不值得，但有了 LLM，生成還可以的 SIMD 優化相當容易。我知道一些人類專家發現他們通常可以勝過 LLM，例如，Jay Stelly 說他上次嘗試讓 LLM 生成 SIMD 程式碼時，花了 20 多次迭代才讓程式碼達到他想要的程度。但是，另一方面，LLM 能夠嘗試比人類在任何給定時間內可能嘗試的更多的優化，所以即使任何特定的優化不如人類專家生產的，它們總體上仍然可以表現得相當好。

還有這篇文章討論的過度擬合問題。根據上下文，這個問題的難易程度從非常容易到有點困難不等。我故意在這裡沒有非常努力地解決這個問題，看看會發生什麼，但在處理 Azul AI 時（僅舉例），我確實設法在沒有過度努力的情況下解決了這個問題，但許多這些大型基準測試聲明都發生在人們花費很少或根本不花精力試圖避免過度擬合，甚至負面努力的情況下。在 LLM 出現之前，人們經常選擇高度無代表性的微基準測試來展示他們的寵兒專案有多棒，這至少在非意識層面上，涉及避免過度擬合基準測試的負面努力。由於人類的本性，我認為人們不會停止做出誤導性的聲明，而且現在做出誤導性聲明的機會比以往任何時候都多，所以當然我們看到更多這樣的聲明。

請注意，雖然這篇文章討論的是非 AI 軟體，但這裡所說的一切對於 AI 軟體都加倍適用。例如，我看到很多人評論說 Kimi K3 達到了 Fable (5) 的水平。但我認識的每一個使用過它的人都發現它比 GPT-5.6 Sol 和 Fable 差很多。我並不是說它不是一個令人印象深刻的工程成就，但它在各種真實世界任務上的表現並未達到基準測試的水平。這甚至適用於各種評估問題，例如當一位朋友在 ICFP 2026 比賽問題上測試不同的編碼代理程式時。這也適用於安全問題，我毫不懷疑 AI 實驗室正在將其納入他們的評估中，例如，我的一位同事嘗試使用 Kimi K3 掃描我們的軟體漏洞，發現它找到的漏洞大約是 GPT-5.6 Sol 找到的四分之一，沒有找到 GPT-5.6 Sol 沒有找到的漏洞，並且除了成本之外，在任何方面都沒有優勢。我認識的那些使用更便宜的模型來尋找真實安全問題的人，正在使用其他模型，例如 GLM-5.2，它們在基準測試上的表現較差，但在實際應用中表現更好。

回到 FRE 的話題，還有一個要點是，保留基準測試是 ripgrep 基準測試設置的一個任意子集，由代理程式出於未知原因選擇。我要求代理程式拉取整個基準測試套件，但這篇文章的時間不夠完成，所以我不知道一旦完成結果會如何。

有趣的是，我對一些人們最懷疑的專案抱有一些信心，例如，每次我看到 pgrust 時，都會有很多懷疑的評論。但是，在沒有深入研究他正在優化什麼細節的情況下，我會相信他們沒有在基準測試上做什麼可疑的事情，因為 Michael Malis 發起了這個專案（並且仍然參與其中）。我過去會詳細查看我雷達上的大多數基準測試聲明，但現在這些聲明太多了，我真的沒有時間這樣做，並且通常假設聲明在精神上是錯誤的（即使在技術上是正確的），除非有某些理由相信相反。當然，這有時會是錯誤的（例如，如果我不知道 Michael Malis，我會猜測 pgrust 只是另一個低品質的「讓 LLM 重寫這個東西」專案），但 LLM 是人類注意力的一個令人難以置信的 DoS 機器，我不知道還能做什麼（我曾嘗試讓 LLM 分析效能聲明，雖然結果與我自行查看時的看法相關，但結果通常相當錯誤）。

有人可以花幾秒鐘（或者，如果使用正確的框架，實際上不花任何時間）生成一些需要人們花費幾分鐘到幾小時才能理解的東西。這是另一篇文章的主題，但從與人們談論他們在工作場所的經驗來看，那些在這種事情上有不良規範的公司今天在生產力方面確實面臨困難。

我查看的前幾個正規表達式基準測試已經被納入了 rebar，所以它們無法作為保留基準測試。而且，如前所述，目前的 SOTA LLM 在基準測試方面並不擅長，所以我無法信任 LLM 來提出保留基準測試，除非我對正規表達式效能有足夠的了解來判斷基準測試套件的品質。由於我對字串匹配演算法或正規表達式效能幾乎一無所知，所以這也無法實現。

結果發現，BurntSushi 也維護著 ripgrep 和 ripgrep 的基準測試，這些基準測試足夠大，沒有被打包到 rebar 中，所以我試圖使用這些基準測試作為保留基準測試。