Igår kväll lärde jag nanochat d32 hur man räknar 'r' i jordgubbar (eller liknande varianter). Jag tänkte att detta skulle vara ett bra/roligt exempel på hur man lägger till funktioner i nanochat och jag skrev upp en fullständig guide här: Detta görs via en ny syntetisk uppgift 'SpellingBee' som genererar exempel på en användare som ber om denna typ av problem, och en idealisk lösning från en assistent. Vi finjusterar sedan midtrain/SFT på dessa för att ge LLM kapaciteten, eller tränar ytterligare med RL för att göra den mer robust. Det finns många detaljer att få rätt, särskilt vid mindre modellstorlekar, och guiden går igenom dem. Som en kort översikt: - Du måste se till att det finns en mångfald i användarnas uppmaningar/frågor - Särskilt för små modeller som nanochat måste du vara riktigt försiktig med tokeniseringsdetaljerna för att göra uppgiften enkel för en LLM. I synnerhet måste du vara försiktig med blanksteg, och sedan måste du sprida resonemangsberäkningen över många symboler för partiell lösning: först standardiserar vi ordet till citattecken, sedan stavar vi ut det (för att dela upp tokens), sedan itererar vi och behåller en explicit räknare, etc. - Jag uppmuntrar modellen att lösa modellen på två olika sätt: på ett manuellt sätt (huvudräkning i huvudet) och även via verktygsanvändning av Python-tolken som nanochat har tillgång till. Detta är lite "rök och speglar" eftersom varje lösning uttagsautomat är "ren", utan misstag. Man kan antingen justera uppgiften för att simulera misstag och demonstrera återställningar genom exempel, eller köra RL. Troligtvis fungerar en kombination av båda bäst, där den förstnämnda fungerar som föregångare för RL och ger den saker att arbeta med. Om nanochat var en mycket större modell skulle du förvänta dig eller hoppas på att den här funktionen lättare skulle "poppa ut" någon gång. Men eftersom nanochat d32 "hjärna" är lika stor som ett ~honungsbi, om vi vill att den ska räkna r i jordgubbar, måste vi göra det genom att överrepresentera den i data, för att uppmuntra modellen att lära sig det tidigare. Men det fungerar! :)

Jag gillar verkligen det nya DeepSeek-OCR-pappret. Det är en bra OCR-modell (kanske lite sämre än prickar), och ja datainsamling etc., men det gör ändå inget. Den mer intressanta delen för mig (särskilt som en datorseende i hjärtat som tillfälligt maskerar sig som en person med naturligt språk) är om pixlar är bättre ingångar till LLM:er än text. Om texttoken är slösaktiga och bara hemska, vid indata. Kanske är det mer meningsfullt att alla ingångar till LLM:er bara ska vara bilder. Även om du råkar ha ren textinmatning kanske du föredrar att rendera den och sedan mata in den: - Mer informationskomprimering (se papper) = > kortare kontextfönster, mer effektivitet - Betydligt mer allmän informationsström = > inte bara text, utan t.ex. fet text, färgad text, godtyckliga bilder. - Inmatning kan nu enkelt bearbetas med dubbelriktad uppmärksamhet och som standard, inte autoregressiv uppmärksamhet - mycket kraftfullare. - Ta bort tokenizern (vid ingången)!! Jag har redan rantat om hur mycket jag ogillar tokenizern. Tokenizers är fula, separata, inte från början till slut. Den "importerar" all fulhet i Unicode, byte-kodningar, den ärver en hel del historiskt bagage, säkerhets-/jailbreak-risk (t.ex. fortsättningsbyte). Det gör att två tecken som ser identiska ut med ögat ser ut som två helt olika tokens internt i nätverket. En leende emoji ser ut som en konstig token, inte en... Faktiskt leende ansikte, pixlar och allt, och all överföringsinlärning som det medför. Tokeniseraren måste gå. OCR är bara en av många användbara visuella > textuppgifter. Och text-> textuppgifter kan göras till vision->textuppgifter. Inte tvärtom. Så många användarmeddelanden är bilder, men avkodaren (assistentsvaret) förblir text. Det är mycket mindre uppenbart hur man matar ut pixlar realistiskt ... eller om du vill. Nu måste jag också kämpa mot lusten att sidequesta en version av nanochat som bara är för bildinmatning...

Trevligt, kort inlägg som illustrerar hur enkel text (diskret) diffusion kan vara. Diffusion (d.v.s. parallell, itererad nedtoning, överst) är det genomgripande generativa paradigmet i bild/video, men autoregression (d.v.s. gå från vänster till höger nederst) är det dominerande paradigmet i text. När det gäller ljud har jag sett lite av båda. Många diffusionspapper ser lite täta ut, men om man tar bort den matematiska formalismen får man enkla baslinjealgoritmer, t.ex. något som är mycket närmare flödesmatchning i kontinuerlig, eller något liknande i diskret. Det är din vaniljtransformator men med dubbelriktad uppmärksamhet, där du iterativt samplar om och maskerar om alla tokens i din "tokenduk" baserat på ett brusschema tills du får det slutliga provet i det sista steget. (Dubbelriktad uppmärksamhet är mycket kraftfullare, och du får mycket starkare autoregressiva språkmodeller om du tränar med den, tyvärr gör det träningen mycket dyrare eftersom du nu inte kan parallellisera över sekvensdim). Autoregression gör därför en ".append(token)" till token-arbetsytan medan den bara deltar bakåt, medan diffusionen uppdaterar hela token-arbetsytan med en ".setitem(idx, token)" när den deltar dubbelriktat. Mänskligt tänkande känns naivt nog lite mer som autoregression, men det är svårt att säga att det inte finns fler diffusionsliknande komponenter i något latent tankerum. Det känns fullt möjligt att man kan interpolera dem ytterligare, eller generalisera dem ytterligare. Och det är en komponent i LLM-stacken som fortfarande känns lite fungibel. Nu måste jag motstå frestelsen att gå in i träning nanochat med diffusion.