Uzyskiwanie dużych modeli językowych (LLM) do lepszego rozumowania to jedno. Doprowadzenie ich bez spalania absurdalnych ilości obliczeń to kolejne. Nowy artykuł badawczy Tu Darmstadt, UCLA, Google Deepmind i Mila zagłębia się w ten kompromis-i może po prostu zmienić sposób, w jaki programiści AI myślą o skalowaniu rozumowania w czasie testu.
Podstawowe napięcie? Niezależnie od tego, czy LLM powinny wydać swoje obliczenia generując więcej odpowiedzi (tak zwane samozwańczo lub SC), czy weryfikując kilka obiecujących odpowiedzi przy użyciu generatywnych modeli nagrody (GenRMS). Okazuje się, że wybór złego może sprawić, że model marnuje swój model do 128 razy więcej obliczeni – dla ledwie zauważalnego uderzenia wydajności.
Nowa matematyka rozumowania na skalę
LLM, takie jak GPT-4, LAMA lub QWEN, stały się szokująco dobre w rozwiązywaniu problemów z matematyką i nauką, generując wiele łańcuchów myśli (COTS) i wybierając najczęstszy wynik. Taki jest pomysł SC – Brute Force Wisdom tłumu. Ale naukowcy byli również podekscytowani GenRMS, nowszym podejściem, które pozwala LLM działać jak ich własny sędzia, weryfikując odpowiedzi poprzez dalsze rozumowanie łańcucha.
Poprzednie porównania sprawiły, że GenRM wyglądał na bardzo wydajny: dopasowanie dokładności SC do 4 x mniej roztworów. Ale ten artykuł nazywa to kadrowanie – ciężko. Dlaczego? Ponieważ nikt nie liczył prawdziwego kosztu obliczeniowego wszystkich tych etapów weryfikacji.
Oblicz budżety zmieniają wszystko
Badanie to wprowadza czyste ramy do pomiaru rzeczywistych kosztów podejść SC i GenRM w ramach ustalonego budżetu obliczeniowego. Działa tak: możesz albo wydać obliczenie generując więcej odpowiedzi (SC) lub podzielić ten budżet na kilka odpowiedzi i wiele weryfikacji (GenRM). Ich model obliczania całkowitego obliczenia wnioskowania jest odświeżająco prosty: C (S, V) = S (1 + λv), gdzie S jest liczbą roztworów, v liczba weryfikacji, a λ odzwierciedla długość weryfikacji w stosunku do roztworów.
Brutalny wynik: SC jest nadal królem (chyba że jesteś bogaty)
Eksperymenty nie miało wątpliwości. W modelach LAMA i QWEN, od 7B do 70B parametrów oraz w zadaniach matematyki i rozumowania naukowego, historia powtórzyła się: SC przewyższało GenRM przy niższych budżetach obliczeniowych. Dopiero po skalowaniu obliczeń po 8 ×, czy Genrm nadrobiło zaległości. A uzyskanie niewielkiego wzrostu wydajności o 3,8% w stosunku do SC wymagało podatkowania o 128 × więcej obliczeń.
Wynik ten utrzymywał nawet zaawansowane „modele myślenia”, takie jak QWQ-32B, oraz na twardych zestawach danych matematycznych, takich jak AIME24. SC wygrywa, gdy obliczanie jest ciasne. GenRM ma sens tylko wtedy, gdy obliczanie jest praktycznie wolne – lub gdy problemy są tak trudne, że weryfikacja dramatycznie się opłaca.
IEA Ostrzega: AI może podwoić globalne zużycie energii w centrum danych do 2030
Inteligentny sposób korzystania z GenRM (jeśli musisz)
Mimo to badanie nie odrzucają GenRM. W rzeczywistości wywodzi się Przepisy dotyczące skalowania wnioskowania W przypadku GenRM-plan do rozwiązywania problemów komputerowych. Kluczowe odkrycie? Podczas skalowania GenRM przydzień oblicz w kierunku generowania roztworów szybciej niż weryfikacje – około 1,5 do 2 razy szybciej. W liczbach ich przepisy dotyczące skalowania wykazały optymalne skale liczby rozwiązań o budżecie obliczeniowym jako S ∝ C^0,57, podczas gdy optymalne weryfikacje skala jako V ∝ C^0,39.
To badanie pozostawia praktykującym bardzo praktycznym przewodnikiem: jeśli obliczanie jest ograniczone, Trust SC i wydają je na generowanie większej liczby rozwiązań. Jeśli obliczanie jest obfite, a zwłaszcza jeśli masz do czynienia z trudniejszymi zadaniami rozumowania, użycie GenRM z odpowiednią równowagą skalowania może być tego warte – ale tylko z poważną optymalizacją.
Dla programistów sztucznej inteligencji stojących przed ograniczeniami w świecie rzeczywistych, na wynos jest prawie komicznie prosty: więcej myślenia bije bardziej weryfikujące, chyba że masz zasoby bliskie. I nawet wtedy weryfikacja musi być inteligentna, wydajna i minimalna.
Pełny papier, „Kiedy rozwiązać, kiedy zweryfikować: Oblicz optymalne rozwiązywanie problemów i weryfikacja generatywna dla rozumowania LLM”Jest dostępny na arxiv. Ich baza kodu jest otwarta Github.
