Wczoraj wieczorem nauczyłem nanochat d32, jak liczyć 'r' w truskawce (lub podobnych wariantach). Pomyślałem, że to będzie dobry/zabawny przykład, jak dodać możliwości do nanochat, więc napisałem pełny przewodnik tutaj: To jest realizowane za pomocą nowego syntetycznego zadania `SpellingBee`, które generuje przykłady użytkownika proszącego o tego rodzaju problem oraz idealne rozwiązanie od asystenta. Następnie przeprowadzamy midtrain/SFT finetuning na tych przykładach, aby wyposażyć LLM w tę zdolność, lub dalej trenujemy z RL, aby uczynić go bardziej odpornym. Jest wiele szczegółów, które trzeba dopracować, szczególnie w przypadku mniejszych modeli, a przewodnik przechodzi przez nie. Krótkie podsumowanie: - Musisz zapewnić różnorodność w podpowiedziach/zapytaniach użytkowników - W przypadku małych modeli, takich jak nanochat, musisz być naprawdę ostrożny z detalami tokenizacji, aby ułatwić zadanie LLM. W szczególności musisz uważać na białe znaki, a następnie musisz rozłożyć obliczenia rozumowania na wiele tokenów częściowego rozwiązania: najpierw standaryzujemy słowo w cudzysłowach, potem je literujemy (aby rozbić tokeny), następnie iterujemy i utrzymujemy wyraźny licznik itd. - Zachęcam model do rozwiązania zadania na dwa różne sposoby: manualnie (obliczenia w myślach) oraz za pomocą narzędzia, jakim jest interpreter Pythona, do którego ma dostęp nanochat. To jest trochę "sztuczki i iluzje", ponieważ każde rozwiązanie w tej chwili jest "czyste", bez błędów. Można by dostosować zadanie, aby symulować błędy i pokazywać poprawki na przykładach, lub przeprowadzić RL. Najprawdopodobniej najlepsze będzie połączenie obu, gdzie pierwsze działa jako priorytet dla RL i daje mu rzeczy do pracy. Gdyby nanochat był znacznie większym modelem, można by się spodziewać, że ta zdolność łatwiej "wyjdzie na jaw" w pewnym momencie. Ale ponieważ "mózg" nanochat d32 ma rozmiar ~pszczółki miodnej, jeśli chcemy, aby liczył r w truskawce, musimy to zrobić, nadreprezentując to w danych, aby zachęcić model do wcześniejszego nauczenia się tego. Ale działa! :)

Bardzo podoba mi się nowy artykuł DeepSeek-OCR. To dobry model OCR (może trochę gorszy niż dots), a tak, zbieranie danych itd., ale w każdym razie to nie ma znaczenia. Bardziej interesującą częścią dla mnie (szczególnie jako osoba z zamiłowaniem do wizji komputerowej, która tymczasowo udaje osobę zajmującą się językiem naturalnym) jest to, czy piksele są lepszymi wejściami do LLM niż tekst. Czy tokeny tekstowe są marnotrawne i po prostu okropne jako wejście. Może ma sens, że wszystkie wejścia do LLM powinny być tylko obrazami. Nawet jeśli przypadkiem masz czysty tekst jako wejście, może wolałbyś go renderować, a następnie wprowadzać: - większa kompresja informacji (zobacz artykuł) => krótsze okna kontekstowe, większa efektywność - znacznie bardziej ogólny strumień informacji => nie tylko tekst, ale np. pogrubiony tekst, kolorowy tekst, dowolne obrazy. - wejście może być teraz przetwarzane z łatwością i jako domyślne z dwukierunkową uwagą, a nie autoregresywną uwagą - znacznie potężniejsze. - usuń tokenizator (na wejściu)!! Już narzekałem, jak bardzo nie lubię tokenizatora. Tokenizatory są brzydkie, oddzielne, nie są etapem end-to-end. "Importują" całą brzydotę Unicode, kodowania bajtów, dziedziczą wiele historycznego bagażu, ryzyko bezpieczeństwa/łamania zabezpieczeń (np. bajty kontynuacji). Sprawiają, że dwa znaki, które wyglądają identycznie dla oka, wyglądają jako dwa zupełnie różne tokeny wewnętrznie w sieci. Uśmiechnięty emoji wygląda jak dziwny token, a nie... rzeczywiste uśmiechnięte oblicze, piksele i wszystko, co się z tym wiąże. Tokenizator musi odejść. OCR to tylko jedno z wielu użytecznych zadań wizji -> tekst. A zadania tekst -> tekst mogą być przekształcone w zadania wizji -> tekst. Nie odwrotnie. Więc wiele wiadomości od użytkownika to obrazy, ale dekoder (odpowiedź asystenta) pozostaje tekstem. O wiele mniej oczywiste jest, jak realistycznie wyjść z pikselami... lub czy byś chciał. Teraz muszę również walczyć z pokusą, aby zająć się wersją nanochatu tylko z wejściem obrazów...

Fajny, krótki post ilustrujący, jak prosta może być dyfuzja tekstu (dyskretna). Dyfuzja (tj. równoległe, iteracyjne odszumianie, top) jest wszechobecnym paradygmatem generatywnym w obrazach/wideo, ale autoregresja (tj. od lewej do prawej, w dół) jest dominującym paradygmatem w tekście. W przypadku dźwięku widziałem trochę obu. Wiele prac na temat dyfuzji wygląda dość gęsto, ale jeśli pozbawisz je formalizmu matematycznego, otrzymasz proste algorytmy bazowe, np. coś znacznie bliższego dopasowywaniu przepływu w ciągłym, lub coś takiego w dyskretnym. To twój waniliowy transformer, ale z dwukierunkową uwagą, gdzie iteracyjnie ponownie próbkowujesz i ponownie maskujesz wszystkie tokeny w swoim "płótnie tokenów" w oparciu o harmonogram szumów, aż uzyskasz ostateczną próbkę na ostatnim kroku. (Dwukierunkowa uwaga jest znacznie potężniejsza, a jeśli trenujesz z nią, otrzymujesz znacznie silniejsze modele językowe autoregresywne, niestety sprawia, że trening jest znacznie droższy, ponieważ teraz nie możesz równolegle przetwarzać wzdłuż wymiaru sekwencji). Więc autoregresja wykonuje `.append(token)` do płótna tokenów, podczas gdy tylko zwraca uwagę wstecz, podczas gdy dyfuzja odświeża całe płótno tokenów za pomocą `.setitem(idx, token)` przy jednoczesnym zwracaniu uwagi w obu kierunkach. Ludzka myśl naiwna wydaje się trochę bardziej jak autoregresja, ale trudno powiedzieć, że nie ma więcej komponentów podobnych do dyfuzji w jakiejś ukrytej przestrzeni myśli. Wydaje się całkiem możliwe, że można dalej interpolować między nimi lub uogólniać je dalej. I to jest komponent stosu LLM, który wciąż wydaje się trochę elastyczny. Teraz muszę powstrzymać się od pokusy, aby zbaczać w kierunku trenowania nanochatu z dyfuzją.