Ieri sera ho insegnato a nanochat d32 come contare le 'r' in fragola (o varianti simili). Pensavo che questo sarebbe stato un buon/divertente esempio di come aggiungere capacità a nanochat e ho scritto una guida completa qui: Questo viene fatto tramite un nuovo compito sintetico `SpellingBee` che genera esempi di un utente che chiede questo tipo di problema e una soluzione ideale da un assistente. Poi facciamo un midtrain/SFT finetune su questi per dotare il LLM della capacità, o ulteriormente addestriamo con RL per renderlo più robusto. Ci sono molti dettagli da sistemare, specialmente con modelli più piccoli, e la guida li affronta. Come panoramica breve: - Devi garantire diversità nei prompt/query degli utenti - Per modelli piccoli come nanochat, in particolare, devi prestare molta attenzione ai dettagli della tokenizzazione per rendere il compito facile per un LLM. In particolare, devi fare attenzione agli spazi bianchi, e poi devi distribuire il calcolo del ragionamento su molti token di soluzione parziale: prima standardizziamo la parola tra virgolette, poi la scriviamo (per spezzare i token), poi iteriamo e manteniamo un contatore esplicito, ecc. - Sto incoraggiando il modello a risolvere il compito in due modi separati: un modo manuale (aritmetica mentale nella sua testa) e anche tramite l'uso dello strumento dell'interprete Python a cui nanochat ha accesso. Questo è un po' "fumo e specchi" perché ogni soluzione al momento è "pulita", senza errori. Si potrebbe modificare il compito per simulare errori e dimostrare recuperi per esempio, o eseguire RL. Molto probabilmente, una combinazione di entrambi funziona meglio, dove il primo funge da prior per il RL e gli fornisce elementi su cui lavorare. Se nanochat fosse un modello molto più grande, ti aspetteresti o spereresti che questa capacità "emergesse" più facilmente a un certo punto. Ma poiché il "cervello" di nanochat d32 è delle dimensioni di un ~ape, se vogliamo che conti le r in fragola, dobbiamo farlo sovra-rappresentandolo nei dati, per incoraggiare il modello a impararlo prima. Ma funziona! :)

Mi piace abbastanza il nuovo documento DeepSeek-OCR. È un buon modello OCR (forse un po' peggiore di dots), e sì, la raccolta dei dati ecc., ma comunque non importa. La parte più interessante per me (soprattutto essendo un appassionato di visione artificiale che si sta temporaneamente spacciando per una persona di linguaggio naturale) è se i pixel siano migliori input per i LLM rispetto al testo. Se i token di testo siano spreconi e semplicemente terribili, come input. Forse ha più senso che tutti gli input ai LLM dovrebbero essere solo immagini. Anche se ti capita di avere input di puro testo, forse preferiresti renderizzarlo e poi fornirlo: - maggiore compressione delle informazioni (vedi documento) => finestre di contesto più brevi, maggiore efficienza - flusso di informazioni significativamente più generale => non solo testo, ma ad esempio testo in grassetto, testo colorato, immagini arbitrarie. - l'input può ora essere elaborato facilmente e per default con attenzione bidirezionale, non attenzione autoregressiva - molto più potente. - elimina il tokenizer (all'input)!! Ho già lamentato quanto disprezzi il tokenizer. I tokenizer sono brutti, separati, non sono una fase end-to-end. "Importano" tutta la bruttezza di Unicode, delle codifiche byte, ereditano un sacco di bagagli storici, rischi di sicurezza/jailbreak (ad esempio, byte di continuazione). Fanno sembrare due caratteri che appaiono identici all'occhio come due token completamente diversi internamente nella rete. Un'emoji sorridente sembra un token strano, non un... vero volto sorridente, pixel e tutto, e tutto l'apprendimento trasferito che porta con sé. Il tokenizer deve andare. L'OCR è solo uno dei tanti compiti utili di visione -> testo. E i compiti di testo -> testo possono essere trasformati in compiti di visione -> testo. Non viceversa. Quindi molti messaggi dell'utente sono immagini, ma il decodificatore (la risposta dell'assistente) rimane testo. È molto meno ovvio come output realisticamente i pixel... o se lo vorresti. Ora devo anche combattere l'impulso di deviare in una versione di nanochat solo con input di immagini...

Bel post breve che illustra quanto possa essere semplice la diffusione del testo (discreta). La diffusione (cioè, denoising parallelo e iterato, top) è il paradigma generativo pervasivo nell'immagine/video, ma l'autoregressione (cioè, andare da sinistra a destra in basso) è il paradigma dominante nel testo. Per l'audio ho visto un po' di entrambi. Molti articoli sulla diffusione sembrano un po' densi, ma se si rimuove il formalismo matematico, si finisce con semplici algoritmi di base, ad esempio qualcosa di molto più vicino al flow matching in continuo, o qualcosa del genere in discreto. È il tuo transformer vaniglia ma con attenzione bidirezionale, dove si ri-campionano e ri-mascherano iterativamente tutti i token nel tuo "canvas di token" in base a un programma di rumore fino a ottenere il campione finale all'ultimo passo. (L'attenzione bidirezionale è molto più potente, e ottieni modelli di linguaggio autoregressivi molto più forti se ti alleni con essa, sfortunatamente rende l'addestramento molto più costoso perché ora non puoi parallelizzare lungo la dimensione della sequenza). Quindi l'autoregressione sta facendo un `.append(token)` al canvas di token mentre si concentra solo all'indietro, mentre la diffusione sta aggiornando l'intero canvas di token con un `.setitem(idx, token)` mentre si concentra in modo bidirezionale. Il pensiero umano sembra naivemente un po' più simile all'autoregressione, ma è difficile dire che non ci siano componenti più simili alla diffusione in qualche spazio latente di pensiero. Sembra abbastanza possibile che tu possa ulteriormente interpolare tra di loro, o generalizzarli ulteriormente. Ed è un componente dello stack LLM che sembra ancora un po' fungibile. Ora devo resistere all'impulso di deviare nel addestrare nanochat con la diffusione.