Aseară am învățat nanochat d32 cum să numere "r" în căpșuni (sau variații similare). M-am gândit că acesta ar fi un exemplu bun/distractiv despre cum să adăugați capabilități la nanochat și am scris un ghid complet aici: Acest lucru se face printr-o nouă sarcină sintetică "SpellingBee" care generează exemple de utilizator care cere acest tip de problemă și o soluție ideală de la un asistent. Apoi reglam fin pe acestea pentru a înzestra LLM cu capacitatea sau ne antrenăm în continuare cu RL pentru a-l face mai robust. Există multe detalii de obținut corect, mai ales la dimensiuni mai mici ale modelelor, iar ghidul le parcurge. Ca o scurtă prezentare generală: - Trebuie să asigurați diversitatea solicitărilor/interogărilor utilizatorilor - Pentru modelele mici, cum ar fi nanochat, trebuie să fii foarte atent cu detaliile de tokenizare pentru a ușura sarcina unui LLM. În special, trebuie să fii atent la spațiile albe, apoi trebuie să împrăștii calculul raționamentului pe mai multe jetoane de soluție parțială: mai întâi standardizăm cuvântul între ghilimele, apoi îl scriem (pentru a împărți tokenurile), apoi iterăm și păstrăm un contor explicit etc. - Încurajez modelul să rezolve modelul în două moduri separate: manual (aritmetică mentală în cap) și, de asemenea, prin utilizarea instrumentului interpretorului Python la care nanochat are acces. Acesta este un pic "fum și oglinzi" pentru că fiecare soluție atm este "curată", fără greșeli. S-ar putea fie să ajustăm sarcina pentru a simula greșelile și să demonstreze recuperările prin exemplu, fie să ruleze RL. Cel mai probabil, o combinație a ambelor funcționează cel mai bine, în care primul acționează ca prior pentru RL și îi oferă lucruri cu care să lucreze. Dacă nanochat ar fi un model mult mai mare, te-ai aștepta sau te-ai aștepta ca această capacitate să "iasă" mai ușor la un moment dat. Dar pentru că "creierul" nanochat d32 este de dimensiunea unei ~albine, dacă vrem să numere r în căpșuni, trebuie să o facem suprareprezentând în date, pentru a încuraja modelul să o învețe mai devreme. Dar funcționează! :)

Îmi place destul de mult noua lucrare DeepSeek-OCR. Este un model OCR bun (poate puțin mai rău decât punctele), și da, colectarea de date etc., dar oricum nu contează. Partea mai interesantă pentru mine (mai ales ca viziune computerizată care se deghizează temporar într-o persoană de limbaj natural) este dacă pixelii sunt intrări mai bune pentru LLM-uri decât textul. Dacă jetoanele de text sunt risipitoare și pur și simplu groaznice, la intrare. Poate că are mai mult sens ca toate intrările la LLM-uri să fie doar imagini. Chiar dacă se întâmplă să aveți o intrare de text pur, poate ați prefera să o redați și apoi să o introduceți: - mai multă compresie a informațiilor (vezi lucrarea) = > ferestre de context mai scurte, mai multă eficiență - Flux de informații semnificativ mai general = > nu doar text, ci de exemplu text îngroșat, text colorat, imagini arbitrare. - intrarea poate fi acum procesată cu atenție bidirecțională cu ușurință și implicit, nu cu atenție autoregresivă - mult mai puternică. - ștergeți tokenizatorul (la intrare)!! Am vorbit deja despre cât de mult nu-mi place tokenizatorul. Tokenizatorii sunt urâți, separați, nu de la un capăt la altul. "Importă" toată urâțenia Unicode, codificările de octeți, moștenește o mulțime de bagaje istorice, risc de securitate/jailbreak (de exemplu, octeți de continuare). Face ca două personaje care arată identic cu ochiul să arate ca două jetoane complet diferite intern în rețea. Un emoji zâmbitor arată ca un jeton ciudat, nu un... față zâmbitoare reală, pixeli și toate celelalte, și toată învățarea prin transfer pe care o aduce. Tokenizatorul trebuie să dispară. OCR este doar una dintre multele sarcini utile de > text vizual. Iar sarcinile text > text pot fi transformate în sarcini de viziune >text. Nu invers. Atât de multe mesaje de utilizator sunt imagini, dar decodorul (răspunsul Asistentului) rămâne text. Este mult mai puțin evident cum să scoateți pixelii în mod realist... sau dacă doriți. Acum trebuie să mă lupt și cu dorința de a căuta o versiune a nanochat-ului doar cu intrare de imagine...

O postare scurtă și frumoasă care ilustrează cât de simplă poate fi difuzarea textului (discretă). Difuzia este paradigma generativă omniprezentă în imagine/video, dar autoregresia (adică mergeți de la stânga la dreapta jos) este paradigma dominantă în text. Pentru audio am văzut un pic din ambele. O mulțime de lucrări de difuzie arată puțin dense, dar dacă elimini formalismul matematic, ajungi la algoritmi simpli de bază, de exemplu ceva mult mai aproape de potrivirea fluxului în continuu, sau ceva de genul acesta în discret. Este transformatorul tău vanilie, dar cu atenție bidirecțională, unde re-eșantionați și re-mascați toate jetoanele din "pânza de jetoane" pe baza unui program de zgomot până când obțineți eșantionul final la ultimul pas. (Atenția bidirecțională este mult mai puternică și obțineți modele de limbaj autoregresive mult mai puternice dacă vă antrenați cu ea, din păcate face antrenamentul mult mai scump, deoarece acum nu puteți paraleliza între întunericul secvenței). Deci, autoregresia face un '.append(token)' la canvasul token-urilor în timp ce merge doar înapoi, în timp ce difuzia reîmprospătează întreaga pânză token cu un '.setitem(idx, token)' în timp ce participă bidirecțional. Gândirea umană se simte mai degrabă ca o autoregresie, dar este greu de spus că nu există mai multe componente asemănătoare difuziei într-un spațiu latent al gândirii. Se pare foarte posibil să puteți interpola în continuare între ele sau să le generalizați mai departe. Și este o componentă a stivei LLM care încă se simte puțin fungibilă. Acum trebuie să rezist tentației de a antrena nanochat cu difuzie.