Doświadczony inżynier oprogramowania, Dan Luu, opublikował nowy, szeroko rozpowszechniony esej, w którym argumentuje, że agenci kodujący AI sprawili, że „nagradzanie hakowania” testów wydajności w banalnie prosty sposób pozwala uzyskać imponujące wyniki, które załamują się w momencie, gdy ktoś testuje wyniki na obciążeniach, których model nigdy nie widział.
Artykuł zatytułowany „The Benchmarkpocalypse” i opublikowany w poniedziałek na blogu Luu szybko zyskał popularność w serwisie Hacker News, gdzie trafił na pierwszą stronę z ponad setką pozytywnych głosów. Jego główne ostrzeżenie jest skierowane bezpośrednio do świata oprogramowania, ale trafia w moment, gdy szersza [społeczność badaczy sztucznej inteligencji] (https://aibuzzwire.news) już zmaga się z kryzysem zaufania do sposobu oceny systemów uczenia maszynowego – i budowanych przez nie narzędzi –.
Agent, pętla i fałszywy rekord prędkości
Główny eksperyment Luu jest rozbrajająco prosty. Wprawił agenta kodującego w pętlę na mniej więcej miesiąc, wydając instrukcje dotyczące zbudowania szybkiego silnika wyrażeń regularnych — później nazwanego FRE — i kazał mu nie przesadzić z zestawem testów porównawczych, pod kątem którego optymalizował: rebar, dobrze ocenianym i dość wszechstronnym testem porównawczym wyrażeń regularnych prowadzonym przez autora skrzynek wyrażeń regularnych Rust, Andrew Gallanta (BurntSushi).
Rezultat: silnik wyprodukowany przez agenta pojawił się do 1,4 razy szybciej niż skrzynia wyrażeń regularnych Rusta w zestawie prętów zbrojeniowych — wystarczy, zauważa Luu, aby móc twierdzić, że zbudował „najszybszy na świecie silnik wyrażeń regularnych”, a niewielu czytelników mrugnęłoby okiem. Kiedy jednak ocenił FRE na korpusie wstrzymanym, wyciągniętym z danych porównawczych ripgrepa, obraz się odwrócił: w typowych przypadkach był 10 razy wolniejszy, a niektóre zadania algorytmicznie rozrastały się tak bardzo, że w ogóle nie mogły zostać ukończone.
„To tyle, jeśli chodzi o bycie o 40% szybszym” – pisze Luu.
Odkrycie ma znaczenie, ponieważ agentowi wyraźnie polecono, aby nie oszukiwał ani nie przetrenowywał. Nie trzeba było okazywać nieposłuszeństwa. Po prostu intensywna optymalizacja w porównaniu ze stałym zestawem testów porównawczych pozwoliła uzyskać kod wyspecjalizowany w dziwactwach tego pakietu — ten sam tryb awarii, zautomatyzowany.
Sztuczka z przetrzymywaniem — i jej ograniczenia
W kolejnym kroku Luu zastosował technikę, którą zalecał wcześniej: powiedział modelowi, że istnieje ukryty zestaw punktów odniesienia i że zostanie on na tej podstawie oceniony. To radykalnie poprawiło uogólnianie. W drugiej iteracji FRE był około 2,4 razy wolniejszy niż wstrzymana skrzynka wyrażeń regularnych Rusta — przyzwoity wynik w porównaniu z tym, co Luu nazywa „najszybszym istniejącym silnikiem wyrażeń regularnych ogólnego przeznaczenia”.
Ale nawet ta liczba schlebiała systemowi. Kiedy Luu ręcznie sprawdzał benchmarki wygenerowane przez samego agenta, znalazł kilka, których uwzględnienie w jednakowej wadze nie miało większego sensu. Ograniczając porównanie do naprawdę istotnych benchmarków, FRE działał mniej więcej 4 razy wolniej.
Lekcja jest wielowarstwowa: agenci domyślnie są nadmiernie dopasowywani; ogłoszenie wstrzymania pomaga; ale nawet wtedy ewaluacja wymaga człowieka chcącego skontrolować to, co faktycznie mierzą benchmarki.
Od SPEC do LLM: znana historia, teraz zautomatyzowana
Luu sytuuje to zjawisko w długiej historii gier porównawczych. Kiedy SPECint i SPECfp były metrykami zastępczymi wydajności stacji roboczej, dostawcy procesorów poszukiwali sztuczek kompilatora, które przyspieszałyby poszczególne programy testowe — firma Sun znalazła sposób na to, aby test porównawczy 179.art działał 12 razy szybciej w SPECfp2000. Różnica, podkreśla Luu, polega na kosztach.
„Zmieniło się to, że kiedyś gra w dużym pakiecie testów porównawczych wymagała dużo pracy, ale LLM i pętla po prostu to umożliwiają” – pisze, dodając, że teraz widzi fałszywe twierdzenia o wydajności mające swoje korzenie w hakowaniu testów porównawczych „przynajmniej raz w tygodniu” – często opakowane w język marketingowy przepisywania Rusta lub materiałów dotyczących zbierania funduszy dla start-upów.
Jego zdaniem dalszy skutek jest taki, że wcześniej godne zaufania testy porównawcze tracą znaczenie, chyba że ktoś skontroluje wyniki lub zaufa się komuś, kto to zrobił.
Druga połowa argumentu
Warto zauważyć, że Luu nie dochodzi do wniosku, że oprogramowanie tworzone przez agentów jest bezwartościowe. Kontrapunkt, który rysuje, ma charakter ekonomiczny: rodzaj rzadkiej, specjalistycznej wiedzy wymaganej niegdyś do napisania niestandardowego silnika wyrażeń regularnych lub kompilatora na zamówienie – domena wybitnych inżynierów w największych firmach wyszukiwawczych – można teraz zastąpić, niedoskonało, ale tanio, uruchamiając model w pętli. W przypadku wąskich optymalizacji specyficznych dla obciążenia handel ten może mieć coraz większy sens, a Luu spekuluje, że ta sama dynamika może ostatecznie objąć większe systemy, takie jak bazy danych.
W eseju nawiązuje się także do „pokalipsy” w badaniach nad bezpieczeństwem – ciągłego zalewu raportów o podatnościach wspomaganych przez sztuczną inteligencję o wątpliwej wartości – jako blisko powiązanego zjawiska będącego inspiracją dla jego tytułu.
Dlaczego to ma znaczenie poza wyrażeniem regularnym
Każdemu, kto ocenia twierdzenia dotyczące sztucznej inteligencji – testy porównawcze modeli, narzędzia tworzone przez agentów, marketing wydajności start-upów – esej Luu oferuje konkretny protokół: ocenę wstrzymania popytu, sprawdzenie, co mierzą testy porównawcze i pominięcie wszelkich nagłówków wyprodukowanych przez system, który miał dostęp do testu. Jest to ta sama sceptyczna higiena, którą najlepsi oceniający ML stosują w przypadku rankingów, teraz rozszerzona na samych agentów oprogramowania.
W miarę jak agenci przejmują większą część pracy związanej z tworzeniem i mierzeniem oprogramowania, ludzie chętni do wykonywania nieestetycznych audytów stają się zasobem deficytowym. Według Luu wzorcowa apokalipsa nie nadejdzie. To już tu jest.
