Gisteravond heb ik nanochat d32 geleerd hoe je 'r' in aardbei (of vergelijkbare variaties) telt. Ik dacht dat dit een goed/leuk voorbeeld zou zijn van hoe je mogelijkheden aan nanochat kunt toevoegen en ik heb hier een volledige gids geschreven: Dit gebeurt via een nieuwe synthetische taak `SpellingBee` die voorbeelden genereert van een gebruiker die om dit soort probleem vraagt, en een ideale oplossing van een assistent. We trainen vervolgens door middel van midtrain/SFT finetuning op deze voorbeelden om het LLM de mogelijkheid te geven, of we trainen verder met RL om het robuuster te maken. Er zijn veel details die goed moeten zijn, vooral bij kleinere modelgroottes, en de gids loopt hier doorheen. Als een kort overzicht: - Je moet zorgen voor diversiteit in gebruikersprompts/vragen - Voor kleine modellen zoals nanochat, moet je echt voorzichtig zijn met de tokenisatie-details om de taak gemakkelijk te maken voor een LLM. In het bijzonder moet je voorzichtig zijn met witruimtes, en dan moet je de redeneertaken verspreiden over veel tokens van gedeeltelijke oplossingen: eerst standaardiseren we het woord in aanhalingstekens, dan spellen we het (om tokens op te splitsen), dan itereren we en houden we een expliciete teller bij, enz. - Ik moedig het model aan om het probleem op twee verschillende manieren op te lossen: een handmatige manier (mentale rekenkunde in zijn hoofd) en ook via het gebruik van de Python-interpreter waar nanochat toegang toe heeft. Dit is een beetje "rook en spiegels" omdat elke oplossing op dit moment "schoon" is, zonder fouten. Men zou de taak kunnen aanpassen om fouten te simuleren en herstel door middel van voorbeelden te demonstreren, of RL uitvoeren. Waarschijnlijk werkt een combinatie van beide het beste, waarbij de eerste als de prior voor de RL fungeert en het dingen geeft om mee te werken. Als nanochat een veel groter model was, zou je verwachten of hopen dat deze mogelijkheid op een gegeven moment gemakkelijker "tevoorschijn" zou komen. Maar omdat de "hersenen" van nanochat d32 de grootte van een ~bij zijn, als we willen dat het r's in aardbei telt, moeten we dit doen door het in de data te over-representeren, om het model aan te moedigen het eerder te leren. Maar het werkt! :)

Ik vind het nieuwe DeepSeek-OCR-paper best leuk. Het is een goed OCR-model (misschien iets slechter dan dots), en ja, dataverzameling enzovoort, maar het maakt niet uit. Het interessantste deel voor mij (vooral als iemand die van nature een computer vision persoon is en tijdelijk zich voordoet als een taalpersoon) is of pixels betere inputs voor LLM's zijn dan tekst. Of teksttokens verspilling zijn en gewoon verschrikkelijk, als input. Misschien is het logischer dat alle inputs voor LLM's alleen maar afbeeldingen zouden moeten zijn. Zelfs als je toevallig pure tekstinput hebt, misschien geef je er de voorkeur aan om het weer te geven en dat dan in te voeren: - meer informatiecompressie (zie paper) => kortere contextvensters, meer efficiëntie - aanzienlijk meer algemene informatiestroom => niet alleen tekst, maar bijvoorbeeld vetgedrukte tekst, gekleurde tekst, willekeurige afbeeldingen. - input kan nu gemakkelijk en standaard met bidirectionele aandacht worden verwerkt, niet autoregressieve aandacht - veel krachtiger. - verwijder de tokenizer (bij de input)!! Ik heb al geklaagd over hoezeer ik de tokenizer niet leuk vind. Tokenizers zijn lelijk, apart, geen end-to-end fase. Het "importeert" al het lelijke van Unicode, byte-encoderingen, het erft veel historische bagage, beveiligings-/jailbreakrisico (bijv. voortgangsbytes). Het maakt van twee karakters die identiek lijken voor het oog, twee volkomen verschillende tokens intern in het netwerk. Een glimlachende emoji lijkt op een vreemd token, niet op een... echte glimlachende gezicht, pixels en al, en al het transferleren dat daarbij komt. De tokenizer moet weg. OCR is slechts een van de vele nuttige vision -> teksttaken. En tekst -> teksttaken kunnen worden omgevormd tot vision -> teksttaken. Niet omgekeerd. Dus veel de gebruikersboodschap is afbeeldingen, maar de decoder (de assistentrespons) blijft tekst. Het is veel minder voor de hand liggend hoe je pixels realistisch kunt outputten... of je dat zou willen. Nu moet ik ook de neiging bestrijden om een zijpad te nemen naar een alleen-afbeelding-input versie van nanochat...

Leuke, korte post die illustreert hoe eenvoudig tekst (discrete) diffusie kan zijn. Diffusie (d.w.z. parallel, iteratieve denoising, top) is het wijdverspreide generatieve paradigma in beeld/video, maar autoregressie (d.w.z. van links naar rechts onder) is het dominante paradigma in tekst. Voor audio heb ik een beetje van beide gezien. Veel diffusie papers lijken een beetje dicht, maar als je de wiskundige formalismen wegstrip, houd je eenvoudige baseline-algoritmen over, bijv. iets dat veel dichter bij flow matching in continu is, of iets als dit in discrete. Het is je vanilla transformer maar met bi-directionele aandacht, waarbij je iteratief alle tokens in je "tokens canvas" opnieuw monster en opnieuw maskeert op basis van een ruis schema totdat je het uiteindelijke monster op de laatste stap krijgt. (Bi-directionele aandacht is veel krachtiger, en je krijgt veel sterkere autoregressieve taalmodellen als je ermee traint, helaas maakt het trainen veel duurder omdat je nu niet meer kunt paralleliseren over de sequentiedimensie). Dus autoregressie doet een `.append(token)` aan het tokens canvas terwijl het alleen achterwaarts aandacht geeft, terwijl diffusie het hele tokens canvas ververst met een `.setitem(idx, token)` terwijl het bidirectioneel aandacht geeft. Menselijk denken voelt naief een beetje meer als autoregressie, maar het is moeilijk te zeggen dat er niet meer diffusie-achtige componenten zijn in een of andere latente ruimte van denken. Het lijkt heel goed mogelijk dat je verder tussen hen kunt interpoleren, of ze verder kunt generaliseren. En het is een component van de LLM-stack die nog steeds een beetje vervangbaar aanvoelt. Nu moet ik de drang weerstaan om af te dwalen naar het trainen van nanochat met diffusie.