Potrzebowałem jednej odpowiedzi na pytanie „jak dobry jest ten model?”
Tycoon może to udawać ukrytą tabelą ocen. Nie chciałem tego. Jeśli liczba parametrów, dane i moc obliczeniowa są centralnymi decyzjami, muszą spotykać się w jednej spójnej funkcji jakości, inaczej kreator staje się teatrem.
Dlatego Scaling Laws używa parametrycznej zależności straty w stylu Chinchilli jako jedynego wyliczenia jakości modelu. Liczy się i liczba parametrów, i tokeny treningowe. Źle wydana ta sama moc potrafi dać gorszy wynik.
Około dwudziestu tokenów na parametr
Obecne dopasowanie umieszcza region optymalny obliczeniowo w okolicach dwudziestu tokenów treningowych na parametr. To jest przydatne jako projekt gry, bo tworzy widoczną równowagę. Podbij liczbę parametrów za wysoko bez wystarczających danych, a przebieg będzie niedotrenowany. Przesadź z danymi jak na rozmiar modelu, a gracz płaci za malejącą wartość.
Kreator potrafi pokazać ten kompromis na żywo, zamiast wymagać od gracza wykucia pracy naukowej.
Wynik zdolności celowo nie jest MMLU
Gra przelicza stratę na względną skalę zdolności. Dziesięciokrotność efektywnej mocy mapuje się na mniej więcej dziesięć punktów zdolności. To sprawia, że granica możliwości jest czytelna przez wieloletnią kampanię, ale nie jest twierdzeniem, że „72 zdolności” równa się konkretnemu wynikowi benchmarku w prawdziwym świecie.
To rozdzielenie ma znaczenie. Symulacja pożycza z badań zależność; nie pożycza naukowego autorytetu dla każdej liczby, którą wrzucam na HUD.
Najpierw prognoza, wynik później
Ekran nowego modelu pokazuje prognozę. Dopiero zakończenie przebiegu tworzy rzeczywisty wynik modelu w okolicach tego szacunku. Trzymam te stany osobno w kodzie, bo inaczej przewidywanie po cichu staje się pomiarem w chwili, gdy gracz kliknie Trenuj.
Ta sama zasada dotyczy przyszłych wpisów sprzętowych i premier rywali. Znane dane referencyjne i dane prognozowane mogą żyć w tej samej kampanii, ale interfejs nie powinien udawać, że pochodzą z tego samego źródła.
Badania są odniesieniem, nie klatką
Oryginalna praca o Chinchilli jest punktem wyjścia, a projekt śledzi też późniejszą pracę, która ponownie zbadała jedną z jej procedur dopasowania. Celem nie jest odtworzenie pracy linijka po linijce. Celem jest utrzymanie decyzji treningowej na tyle spójnej, żeby „skala” coś znaczyła za każdym razem, gdy pojawia się w grze.
Kiedy kreator modelu się zmienia, symulacja dalej powinna umieć wyjaśnić, dlaczego liczba się ruszyła. Jeśli nie potrafię tego wyjaśnić, nie chcę tego chować za ładniejszym paskiem postępu.
Źródła, z których korzystam
Odniesieniem naukowym jest praca Hoffmanna i współautorów, Training Compute-Optimal Large Language Models. Obok trzymam też próbę replikacji skalowania Chinchilli z 2024 roku bo bada ona ponownie trzecią procedurę dopasowania, zamiast traktować każdą wydrukowaną stałą jako nietykalną.
Dłuższy rozbiór implementacji leży na stronie Jak działa / Skalowanie.
Ta notatka opisuje pracę widoczną w obecnym projekcie albo w fundamencie symulacji. Elementy planowane zostają oznaczone na publicznej roadmapie, zamiast być tutaj opisane tak, jakby już wyszły.