Ngày tàn của các bài kiểm tra năng lực AI: Khi LLM dễ dàng 'gian lận' điểm số

Đã có rất nhiều cuộc thảo luận về "vulnpocalypse" (thảm họa lỗ hổng bảo mật), vấn đề mà tôi không có nhiều ý kiến đóng góp vì tôi không phải là chuyên gia bảo mật, nhưng tôi chưa thấy nhiều thảo luận về một vấn đề liên quan chặt chẽ (và công bằng mà nói, ít nghiêm trọng hơn), đó là "benchmarkpocalypse" (thảm họa điểm chuẩn).

Mặc dù việc đạt được những bước tiến lớn về hiệu năng trở nên dễ dàng hơn bao giờ hết, nhưng việc "hack" điểm chuẩn để tạo ra những bước tiến hiệu năng giả tạo cũng trở nên dễ dàng hơn. Điều thứ nhất có lẽ đang diễn ra âm thầm tại nhiều công ty khác nhau, nhưng điều thứ hai là thứ mà ngày nay tôi thấy ít nhất mỗi tuần một lần. Ai đó sẽ tuyên bố họ đã tối ưu hóa X và đạt được sự cải thiện hiệu năng khổng lồ so với phần mềm hiện có, nhưng khi nhìn kỹ vào đó, những gì họ làm chỉ là thực hiện một vài tối ưu hóa giúp cải thiện điểm số benchmark mà không thực sự cải thiện hiệu năng trong thực tế. Đây thường là kiểu dự án "chúng tôi viết lại X bằng Rust" hoặc một startup mới đang tìm cách gọi vốn hoặc bán thứ gì đó, nhưng nó cũng xảy ra với các loại dự án khác.

Tất nhiên, mọi người vẫn luôn rêu rao về các microbenchmark không mang tính đại diện để chứng minh rằng dự án tâm huyết của họ là tuyệt vời. Việc làm giả một microbenchmark không mang tính đại diện luôn dễ dàng và điều đó sẽ không bao giờ thay đổi. Điều đã thay đổi là trước đây cần rất nhiều công sức để "chơi khăm" (game) một bộ benchmark lớn, nhưng giờ đây một LLM và một vòng lặp có thể làm điều đó dễ dàng. Có khá nhiều ví dụ nổi tiếng về việc thao túng các bộ benchmark lớn từ thời điểm mà việc này còn khó khăn. Ví dụ, từ rất lâu trước đây khi mọi người quan tâm đến SPECint / SPECfp như là thước đo cho hiệu năng máy trạm, các nhà cung cấp CPU thường cố gắng tìm các "tối ưu hóa" trình biên dịch giúp tăng tốc tính toán trong benchmark, chẳng hạn như Sun đã tìm ra cách cải thiện 179.art lên 12 lần trong SPECfp2000. Các kỹ sư lành nghề đã dành rất nhiều thời gian để tìm ra những thủ thuật benchmark như vậy. LLM khiến việc này trở nên tầm thường, làm cho các benchmark vốn đáng tin cậy trước đây trở nên vô nghĩa trừ khi bạn kiểm định kết quả hoặc tin tưởng vào người đã làm điều đó.

Thay vì chỉ trích tuyên bố tồi của ai đó, tôi sẽ chỉ ra FRE, công cụ regex mà tôi đã yêu cầu một tác nhân (agent) xây dựng. Tôi có thể tuyên bố đây là công cụ regex nhanh nhất thế giới vì nó đánh bại crate regex của Rust trong bộ benchmark regex khá toàn diện là rebar. Nhưng công cụ này được tạo ra bằng cách đặt một tác nhân vào vòng lặp trong một tháng với chỉ dẫn là không được overfitting (quá khớp) với benchmark, nhưng không có sự giám sát thực sự nào. Phần lớn, việc khiến một LLM đưa ra điểm số benchmark tốt là khá dễ dàng, và trường hợp này cũng không ngoại lệ; mất vài tuần để đạt được hiệu năng xấp xỉ crate regex của Rust và sau đó mất thêm vài tuần nữa để nhanh hơn 1,4 lần trên rebar. Nhưng các tác nhân thường có xu hướng "reward hack" (hack phần thưởng) và overfitting trừ khi bạn đặt ra các rào cản nghiêm ngặt để tránh điều đó, điều mà tôi đã không làm trong trường hợp này như một thử nghiệm.

Để kiểm tra tình trạng overfitting, tôi đã sử dụng bộ benchmark ripgrep một cách khá tùy tiện làm benchmark kiểm chứng (holdout). Kết quả là nó chậm hơn 10 lần trong các trường hợp mà benchmark không kéo dài vô tận do sự bùng nổ thuật toán, và có những trường hợp nó chạy lâu đến mức không thể chờ đợi benchmark hoàn thành. Thế là xong chuyện nhanh hơn 40%!

Bộ benchmark rebar của Andrew Gallant (còn gọi là BurntSushi) khá toàn diện so với các bộ benchmark khác, nhưng ngay cả với một bộ benchmark toàn diện, các tác nhân vẫn không gặp khó khăn gì trong việc đạt điểm cao trong khi vẫn bị overfitting theo cách không nhất thiết mang lại hiệu năng tổng quát tốt.

Bước tiếp theo là sử dụng một thủ thuật mà chúng ta đã thảo luận trước đó: không chỉ bảo LLM không được gian lận, mà còn thông báo rằng có một bộ benchmark kiểm chứng (holdout) dùng để đánh giá nó. Sau đó, LLM đã khái quát hóa hiệu năng ở mức độ vừa phải, đến mức nó chậm hơn khoảng 2,4 lần so với bộ kiểm chứng. Điều đó nghe có vẻ khá tốt khi xét đến việc chúng ta đang so sánh nó với công cụ regex đa năng nhanh nhất hiện có. Nhưng hãy nhớ rằng những benchmark này được tạo ra bởi một tác nhân lập trình. Khi xem xét những gì các benchmark đo lường, một số trong đó thực sự không hợp lý để đưa vào, ít nhất là với trọng số ngang bằng. Nếu chúng ta chỉ nhìn vào những benchmark có vẻ quan trọng, FRE chậm hơn 4 lần trên bộ kiểm chứng, tốt hơn nhiều so với trước khi áp dụng thủ thuật "nói với chúng rằng bạn có bộ kiểm chứng", nhưng vẫn còn khá xa so với việc nhanh hơn 40%.

Có một vài điều tôi thấy thú vị về việc này:

Về (1), không có gì ngạc nhiên khi tôi thấy quá nhiều tuyên bố giả mạo. Trong quá khứ, để xây dựng một thứ như FRE có thể làm giả hiệu năng đủ tốt để tuyên bố gian lận mức tăng tốc 40%, bạn cần một lượng chuyên môn đáng kể. Tối thiểu, bạn cần hiểu khá rõ về các thuật toán khớp chuỗi, công cụ regex, cũng như kỹ năng tối ưu hóa mã nguồn chung và tối ưu hóa SIMD khá tốt. FRE cũng có chế độ biên dịch regex thành mã máy, vì vậy bạn cũng cần một số chuyên môn về trình biên dịch. Giờ đây, bạn có thể đạt được kiểu gian lận benchmark đó (dù bạn có muốn gian lận hay không) chỉ với vài phút gõ phím.

Về (2), tôi tò mò liệu điều này có mang tính khái quát hay không nhưng chưa thử đủ ví dụ để có thể khẳng định.

Về (3), không có lý do gì để sử dụng một thư viện regex được viết theo kiểu "vibe coding" (viết mã dựa trên cảm tính) mà gần như không tốn công sức con người, lại chậm hơn một thư viện mạnh mẽ, hiện có và đã được kiểm thử kỹ lưỡng, vì vậy tôi thấy sản phẩm FRE này không thú vị. Điều tôi thấy thú vị ở đây là LLM có thể thay thế cho những kiến thức vốn từng rất hiếm, chuyên biệt và đắt đỏ đến mức nào.

Trong quá khứ, ngay cả khi bạn có kiến thức, bạn có lẽ cũng sẽ không viết một công cụ regex tùy chỉnh được tối ưu hóa cho khối lượng công việc cụ thể của mình. Có một số trường hợp sử dụng quy mô lớn mà mọi người sẽ thực hiện mức độ tùy chỉnh đó, ví dụ, khi tôi làm việc trên chỉ mục Bing, mã nguồn chứa nhiều trình biên dịch khác nhau vì ai đó làm việc trên đó muốn đạt được hiệu năng tối đa; vì bạn quan tâm đến cả thời gian biên dịch và hiệu năng sau biên dịch trong một công cụ tìm kiếm và sự đánh đổi ở các nơi khác nhau là khác nhau, bạn có được hiệu năng tốt hơn bằng cách viết một trình biên dịch tùy chỉnh cho từng nơi mà một dự án bình thường có thể chỉ sử dụng trình thông dịch hoặc trực tiếp duyệt qua cấu trúc dữ liệu bằng "mã bình thường". Người viết các trình biên dịch đó, khi làm việc với mã giống regex, cũng có thể viết nhiều công cụ regex tùy chỉnh, nhưng rất ít người có cả chuyên môn và thiên hướng để làm điều đó, chưa nói đến sự tự do để dành thời gian cho loại mã chuyên biệt như vậy cho công việc. Nếu bạn định giá kỹ sư Bing đó (lúc đó là kỹ sư cấp Partner, được thăng chức lên Distinguished Engineer vì công việc của họ trên chỉ mục tìm kiếm) so với chi phí chạy một LLM trong vòng lặp, chi phí viết loại mã chuyên biệt này đã giảm đi nhiều bậc độ lớn.

Mặc dù công cụ regex FRE tổng thể có hiệu năng kém hơn crate regex của Rust, nhưng những lợi ích bạn có thể đạt được khi chuyên biệt hóa cho khối lượng công việc hoặc trường hợp sử dụng của mình có nghĩa là, trong một số trường hợp, việc chèn công cụ regex chuyên biệt của riêng bạn vào đâu đó có thể là hợp lý, và điều tương tự cũng áp dụng cho nhiều loại phần mềm cấp thấp khác. Bạn không cần phải là một người theo chủ nghĩa tối đa hóa AI mới nghĩ rằng có khả năng trong vòng vài năm tới, chúng ta có thể thấy điều này xảy ra với những thứ lớn hơn, như cơ sở dữ liệu.

Cảm ơn Yossi Kreinin, Jamie Brandon, Peter Geoghegan, Luke Burton, John Spurling, Dennis Snell và Max Bittker vì những bình luận/chỉnh sửa/thảo luận.

Tái bút: Theo thảo luận ở đây, với LLM, thời gian để mày mò một chút và thỏa mãn sự tò mò của tôi đã giảm đi rất nhiều, trong khi thời gian để viết ra một thứ gì đó và làm cho nó đủ chặt chẽ để xuất bản trên blog của tôi thì không thực sự thay đổi (vì nhiều lý do, tôi nghĩ nó thực sự đã tăng lên). Kết quả của việc này là tôi đang thực hiện nhiều phân tích hơn bao giờ hết và chia sẻ kết quả với một vài người bạn nhưng không xuất bản chúng. Như một thử nghiệm, tôi đang cố gắng viết ra một số thứ rất nhanh, với tiêu chuẩn thấp hơn nhiều về độ sạch sẽ và chặt chẽ so với những gì tôi thường có cho một bài đăng trên blog; giống như những gì tôi sẽ nói với một người bạn trong một cuộc trò chuyện bình thường hơn là những gì tôi thường đưa vào một bài đăng trên blog. Mục tiêu của bài đăng này là thực hiện việc viết trong khoảng nửa giờ, vì vậy đó là thứ tôi có thể làm trong giờ ăn trưa mà không thực sự tốn thời gian. Nếu bạn có ý kiến về điều này, hãy cho tôi biết bạn nghĩ gì!

Tất nhiên, một lưu ý ở đây là tất cả các con số đều có nguy cơ sai cao hơn bình thường. Tôi đã xem xét một benchmark trong khoảng một hoặc hai phút và tìm thấy một vấn đề, sau đó tôi xem xét một benchmark khác trong một phút và tìm thấy một vấn đề khác. Cả hai đều đã được sửa, nhưng điều này ngụ ý rằng có những vấn đề khác mà tôi chưa dành thời gian để truy tìm. Nhưng, liên quan đến các con số benchmark tồi, điều đó rất thực tế! Hầu như bất cứ khi nào tôi xem xét các con số benchmark, chẳng hạn như ở đây, hoặc ở đây, các con số đều sai. Một khía cạnh khác của "benchmarkpocalypse" là, ít nhất là hiện tại, LLM rất giỏi trong việc thực hiện benchmark tồi, vì vậy ngay cả khi bạn có thứ gì đó thực sự cải thiện hiệu năng, bạn thường không thể biết được từ một số thiết lập benchmark do LLM tạo ra trừ khi đã dành một lượng đáng kể sự cẩn thận để đảm bảo rằng thiết lập benchmark là hợp lý.

Phụ lục: chi tiết hơn về benchmark FRE

Một điều tôi phát hiện ra sau khi viết những dòng trên nhưng trước khi xuất bản bài đăng, là tuyên bố của LLM rằng FRE nhanh hơn 40% so với crate regex của Rust trên rebar cũng sai. Hoặc, nếu không sai, thì ít nhất cũng gây hiểu lầm. Nó không thực sự chạy các benchmark theo cùng cách mà các benchmark rebar được chạy. Tôi đã kiểm tra điều này sau khi dành một phút kiểm tra kết quả benchmark và tìm thấy hai vấn đề. Hóa ra, mặc dù có chỉ dẫn chạy các benchmark rebar như cách chúng được chạy trong https://github.com/BurntSushi/rebar, LLM đã thay đổi giao diện để cho phép FRE thực hiện một số tối ưu hóa giúp cải thiện hiệu năng. Sau khi sửa lỗi đó, thay vì FRE nhanh hơn 1,4 lần so với Rust trên rebar, nó lại chậm hơn 1,5 lần (và "chỉ" nhanh gấp đôi re2), vì vậy kết quả ban đầu là giả mạo gấp đôi. FRE không chỉ bị overfitting nặng nề với các benchmark rebar, mà kết quả còn liên quan đến gian lận.

Nhưng ở khía cạnh tích cực, điều này có nghĩa là sự khác biệt về hiệu năng giữa FRE trên rebar (chậm hơn 1,5 lần so với Rust) và trên các benchmark kiểm chứng (chậm hơn 2,4 lần) không lớn như vẻ ngoài trước đó, vì vậy thủ thuật "nói với LLM rằng bạn có bộ kiểm chứng" đã hoạt động hiệu quả hơn vẻ ngoài của nó trước đây.

Sau đó, tôi để một LLM thực hiện leo đồi (hill climb) trong vài giờ và nó tuyên bố rằng FRE nhanh hơn 1,28 lần, nghe có vẻ là một sự cải thiện tuyệt vời chỉ với vài giờ chạy LLM, nhưng sau đó tôi quyết định dành thêm một phút để tìm kiếm gian lận và tìm thấy nhiều vấn đề, bao gồm một trường hợp tìm kiếm số lượng kết quả khớp của (?s)^(.*)$ trả về số lượng mà không cần nhìn vào haystack (dữ liệu). Một trường hợp gian lận khác là thực hiện grep nhiều dòng trong khi benchmark được cho là phải thực hiện từng dòng một. Việc tìm thấy những điều này không đáng ngạc nhiên vì đây là kiểu chuyện xảy ra khi bạn để một tác nhân trong vòng lặp trong một tháng mà không xác định các rào cản nghiêm ngặt. Việc này làm cho lập luận của tôi ở đây mạnh mẽ hơn hay làm suy yếu nó thì không rõ, nhưng sau khi sửa một loạt các vấn đề này, FRE lại trở về mức chậm hơn 1,4 lần. Sau khi để một tác nhân chạy qua đêm, FRE được cho là đã nhanh hơn 1,5 lần.

Vì mục tiêu ban đầu của tôi ở đây là xem điều gì sẽ xảy ra khi bạn chạy một tác nhân SOTA (hiện đại nhất) công khai hiện tại trong một vòng lặp (GPT-5.6 Sol) mà không cần nhiều sự giám sát trên một vấn đề tối ưu hóa mã không tầm thường, thay vì dành nhiều thời gian sửa chữa mọi thứ để làm cho các benchmark công bằng hơn, tôi sẽ dừng lại ở đây và đưa ra một vài biểu đồ kết quả.

Nhìn chung, chúng ta có thể thấy rằng so với Rust và RE2, FRE có xu hướng vượt trội trên các benchmark rebar (và như đã lưu ý ở trên, phần lớn điều này là do overfitting), nhưng không phải trên diện rộng (các biểu đồ bên dưới không nhất thiết khớp với các con số được đề cập trong bài đăng vì một tác nhân liên tục thực hiện các thay đổi, vì vậy bất kỳ ảnh chụp nhanh nào cũng là ước tính tại một thời điểm trở nên lỗi thời ngay lập tức):

Nếu bạn tò mò về hiệu năng trên các benchmark cụ thể hoặc các lớp benchmark rebar cụ thể, chúng ta có bảng sau (tỷ lệ trên một có nghĩa là FRE nhanh hơn; dưới một có nghĩa là FRE chậm hơn):

Ngoài ra còn có chế độ trình biên dịch AOT mất nhiều thời gian để biên dịch regex thành mã gốc trước khi chạy. Không có hỗ trợ AOT cho mọi thứ, nhưng đây là kết quả từ các trường hợp được hỗ trợ. Như chúng ta có thể thấy, trình biên dịch AOT rất chậm (nó thua rất nặng trong các benchmark về thời gian biên dịch) và, mặc dù dành khá nhiều thời gian để biên dịch, kết quả thường chậm hơn so với công cụ regex FRE tiêu chuẩn (mặc dù nó cũng nhanh hơn trong nhiều trường hợp).

Và sau đó là các benchmark kiểm chứng. Như đã lưu ý ở trên, đối với mã FRE không phải AOT, hiệu năng trên bộ kiểm chứng không tốt bằng trên rebar. Và như cũng đã lưu ý ở trên, xét đến việc đây là khối lượng công việc như ripgrep, bộ benchmark "tìm kiếm nóng" có lẽ quan trọng hơn những bộ khác, vì vậy kết quả FRE tệ hơn so với điểm số tổng thể.

Một điều cần lưu ý ở đây là, đối với các trường hợp benchmark kiểm chứng mà chúng ta không bao gồm thời gian biên dịch như một phần của benchmark và chúng ta chạy tìm kiếm nhiều lần, AOT FRE vượt trội hơn trong benchmark. Đối với nhiều trường hợp sử dụng, bạn không muốn một regex mất vài giây để biên dịch, nhưng có rất nhiều trường hợp điều này là ổn, ví dụ, đối với thứ gì đó như ripgrep hoặc Silver Searcher, nó có thể bắt đầu chạy với một regex có thể bắt đầu khớp ngay lập tức và sau đó biên dịch trong một luồng khác và chuyển sang trình khớp nhanh hơn khi nó biên dịch xong. Với việc bao nhiêu CPU của tôi dành cho các tìm kiếm ripgrep dài, có vẻ như một chiến lược như vậy có thể cải thiện hiệu năng cho công việc tôi thực hiện cá nhân. Trước LLM, có lẽ sẽ không hợp lý khi dành công sức để viết một trình biên dịch regex tối ưu hóa, nhưng điều này hiện có thể thực hiện được với vài token.

Một điều khác cần lưu ý là sự so sánh này có thể không công bằng vì nó được chạy trên máy ARM Graviton với SVE/SVE2 và FRE có các tối ưu hóa SVE/SVE2. Trước LLM, có thể không đáng để có các regex được tối ưu hóa cho mọi sự kết hợp của các tập lệnh SIMD ngoài kia, nhưng với LLM, việc tạo ra các tối ưu hóa SIMD ở mức tạm ổn là khá dễ dàng. Tôi biết các chuyên gia con người thấy rằng họ thường có thể vượt qua LLM ở đây, ví dụ, Jay Stelly nói rằng lần cuối cùng anh ấy cố gắng khiến LLM tạo mã SIMD, phải mất hơn 20 lần lặp để có được mã tốt như anh ấy muốn. Nhưng, ở mặt khác, LLM có khả năng thử nhiều tối ưu hóa hơn mức một con người có thể thử trong bất kỳ khoảng thời gian nào, vì vậy chúng vẫn có thể hoạt động khá tốt tổng thể ngay cả khi bất kỳ tối ưu hóa cụ thể nào không tốt bằng những gì một chuyên gia con người tạo ra.

Ngoài ra còn có vấn đề được thảo luận trong bài đăng này về overfitting. Tùy thuộc vào ngữ cảnh, vấn đề đó nằm ở mức từ rất dễ giải quyết đến hơi khó giải quyết. Tôi cố tình không cố gắng quá nhiều để giải quyết vấn đề ở đây để xem điều gì sẽ xảy ra, nhưng tôi đã quản lý để giải quyết vấn đề mà không tốn quá nhiều công sức khi làm việc trên Azul AI này (chỉ là ví dụ), nhưng rất nhiều tuyên bố benchmark lớn này xuất hiện khi mọi người dành ít hoặc không dành công sức để cố gắng tránh overfitting, hoặc thậm chí là công sức tiêu cực. Trong kỷ nguyên trước LLM, mọi người thường chọn các microbenchmark không mang tính đại diện cao để khoe khoang dự án tâm huyết của họ tuyệt vời như thế nào, điều mà ít nhất ở mức độ không ý thức, liên quan đến công sức tiêu cực để tránh overfitting với một benchmark. Do bản chất con người, tôi không nghĩ mọi người sẽ ngừng đưa ra các tuyên bố gây hiểu lầm và việc đưa ra các tuyên bố gây hiểu lầm đã trở nên dễ dàng hơn bao giờ hết, vì vậy tất nhiên chúng ta thấy nhiều hơn.

Lưu ý rằng mặc dù bài đăng này đã thảo luận về phần mềm không phải AI, mọi thứ được nói ở đây đều áp dụng gấp đôi cho phần mềm AI. Ví dụ, tôi đã thấy rất nhiều người để lại bình luận nói rằng Kimi K3 ở mức Fable (5). Nhưng mọi người tôi biết đã sử dụng nó đều thấy nó tệ hơn đáng kể so với GPT-5.6 Sol và Fable. Tôi không nói đó không phải là một thành tựu kỹ thuật ấn tượng, nhưng hiệu năng trên nhiều tác vụ thực tế không đạt đến mức như trong các benchmark. Điều này thậm chí áp dụng cho các vấn đề đánh giá khác nhau, chẳng hạn như khi một người bạn thử các tác nhân lập trình khác nhau trên các bài toán cuộc thi ICFP 2026. Nó cũng áp dụng cho các vấn đề bảo mật, điều mà tôi không nghi ngờ gì các phòng thí nghiệm AI đang đưa vào các đánh giá của họ, ví dụ, một đồng nghiệp của tôi đã thử sử dụng Kimi K3 để quét các lỗ hổng trong phần mềm của chúng tôi và thấy rằng nó tìm thấy khoảng một phần tư số lỗ hổng mà GPT-5.6 Sol tìm thấy, không tìm thấy lỗ hổng nào mà GPT-5.6 Sol không tìm thấy, và không có bất kỳ lợi thế nào ở bất kỳ khía cạnh nào ngoài chi phí. Những người tôi biết đang sử dụng các mô hình rẻ hơn để tìm các vấn đề bảo mật thực sự đang sử dụng các mô hình khác, chẳng hạn như GLM-5.2, hoạt động kém hơn trên các benchmark nhưng tốt hơn trong thực tế.

Quay lại chủ đề FRE, một lưu ý nữa là benchmark kiểm chứng là một tập hợp con tùy ý của thiết lập benchmark ripgrep được chọn bởi một tác nhân vì những lý do không xác định. Tôi đã yêu cầu một tác nhân lấy toàn bộ bộ benchmark, nhưng việc đó không hoàn thành kịp cho bài đăng này, vì vậy tôi không biết kết quả sẽ như thế nào khi nó hoàn thành.

Thật buồn cười, tôi có chút niềm tin vào một số dự án mà mọi người hoài nghi nhất, ví dụ, mỗi khi tôi thấy pgrust ở đâu đó, có rất nhiều bình luận hoài nghi. Nhưng, nếu không xem xét chi tiết những gì anh ấy đang tối ưu hóa, tôi sẽ tin rằng họ không làm điều gì mờ ám với các benchmark của họ vì Michael Malis đã bắt đầu dự án (và vẫn tham gia). Tôi từng xem xét hầu hết các tuyên bố benchmark lọt vào tầm ngắm của mình một cách chi tiết, nhưng hiện nay có quá nhiều thứ như vậy đến mức tôi thực sự không có thời gian để làm điều đó và thường cho rằng các tuyên bố là sai về mặt tinh thần (ngay cả khi đúng về mặt kỹ thuật) trừ khi có lý do để tin ngược lại. Tất nhiên điều này đôi khi sẽ sai (ví dụ, nếu tôi không biết Michael Malis, tôi sẽ đoán rằng pgrust chỉ là một dự án "có LLM viết lại thứ này" chất lượng thấp khác), nhưng LLM là một cỗ máy đáng kinh ngạc để DoS sự chú ý của con người đến mức tôi không biết mình sẽ làm gì khác về nó (tôi đã thử để LLM phân tích các tuyên bố hiệu năng và, mặc dù kết quả có tương quan với những gì tôi nghĩ nếu tôi tự xem xét thứ gì đó, kết quả thường khá sai).

Ai đó có thể dành vài giây (hoặc, nếu sử dụng đúng khung làm việc, thực sự không tốn thời gian của họ) để tạo ra thứ gì đó mà mọi người mất vài phút đến vài giờ để hiểu. Đây là chủ đề cho một bài đăng khác, nhưng từ việc nói chuyện với mọi người về trải nghiệm của họ với điều này tại nơi làm việc, các công ty có chuẩn mực kém cho loại việc này thực sự đang phải vật lộn với năng suất ngày nay.

Một vài benchmark regex đầu tiên tôi xem xét đã được tích hợp vào rebar, vì vậy chúng sẽ không hoạt động như một bộ kiểm chứng. Và, như đã thảo luận trước đó, các LLM SOTA hiện tại không giỏi về benchmark, vì vậy tôi sẽ không thể tin tưởng LLM đưa ra một benchmark kiểm chứng trừ khi tôi biết đủ về hiệu năng regex để đánh giá chất lượng của bộ benchmark. Vì tôi biết gần như bằng không về các thuật toán khớp chuỗi hoặc hiệu năng regex, điều đó cũng không khả thi.

Hóa ra BurntSushi cũng duy trì ripgrep và các benchmark cho ripgrep, đây là những benchmark đủ lớn để không bị gộp vào rebar, vì vậy tôi đã thử sử dụng các benchmark đó làm bộ kiểm chứng.