La nuit dernière, j'ai appris à nanochat d32 à compter les 'r' dans fraise (ou des variations similaires). Je pensais que ce serait un bon exemple amusant de la façon d'ajouter des capacités à nanochat et j'ai rédigé un guide complet ici : Cela se fait via une nouvelle tâche synthétique `SpellingBee` qui génère des exemples d'un utilisateur demandant ce type de problème, et une solution idéale d'un assistant. Nous procédons ensuite à un entraînement intermédiaire/SFT pour affiner le modèle LLM avec cette capacité, ou nous formons davantage avec RL pour le rendre plus robuste. Il y a de nombreux détails à bien gérer, surtout pour les modèles plus petits, et le guide les aborde. En résumé : - Vous devez garantir la diversité dans les invites/requêtes des utilisateurs. - Pour les petits modèles comme nanochat en particulier, vous devez faire très attention aux détails de tokenisation pour faciliter la tâche d'un LLM. En particulier, vous devez faire attention aux espaces, puis vous devez répartir le calcul de raisonnement sur de nombreux tokens de solution partielle : d'abord, nous standardisons le mot entre guillemets, puis nous l'épelons (pour décomposer les tokens), puis nous itérons et gardons un compteur explicite, etc. - J'encourage le modèle à résoudre le problème de deux manières distinctes : une manière manuelle (calcul mental dans sa tête) et également via l'utilisation d'outils de l'interpréteur Python auquel nanochat a accès. C'est un peu "fumée et miroirs" car chaque solution pour le moment est "propre", sans erreurs. On pourrait soit ajuster la tâche pour simuler des erreurs et démontrer des récupérations par exemple, soit exécuter RL. Très probablement, une combinaison des deux fonctionne le mieux, où le premier agit comme le préalable pour le RL et lui donne des éléments avec lesquels travailler. Si nanochat était un modèle beaucoup plus grand, on s'attendrait ou espérerait que cette capacité "émerge" plus facilement à un moment donné. Mais parce que le "cerveau" de nanochat d32 est de la taille d'une ~abeille, si nous voulons qu'il compte les r dans fraise, nous devons le faire en le sur-représentant dans les données, pour encourager le modèle à l'apprendre plus tôt. Mais ça fonctionne ! :)

J'aime beaucoup le nouveau papier DeepSeek-OCR. C'est un bon modèle OCR (peut-être un peu moins bon que dots), et oui, la collecte de données, etc., mais de toute façon, cela n'a pas d'importance. La partie qui m'intéresse le plus (surtout en tant que passionné de vision par ordinateur qui se fait temporairement passer pour une personne de traitement du langage naturel) est de savoir si les pixels sont de meilleurs inputs pour les LLM que le texte. Si les tokens de texte sont gaspillés et juste terribles, à l'entrée. Peut-être qu'il est plus logique que tous les inputs aux LLM ne devraient être que des images. Même si vous avez un input de texte pur, peut-être que vous préféreriez le rendre et ensuite l'alimenter : - compression d'information plus importante (voir le papier) => fenêtres de contexte plus courtes, plus d'efficacité - flux d'information général significativement plus important => pas seulement du texte, mais par exemple du texte en gras, du texte coloré, des images arbitraires. - l'input peut maintenant être traité avec une attention bidirectionnelle facilement et par défaut, pas d'attention autoregressive - beaucoup plus puissant. - supprimer le tokenizer (à l'entrée) !! J'ai déjà râlé sur combien je n'aime pas le tokenizer. Les tokenizers sont laids, séparés, pas une étape de bout en bout. Il "importe" toute la laideur de l'Unicode, des encodages de bytes, il hérite d'un lourd bagage historique, risque de sécurité/jailbreak (par exemple, les bytes de continuation). Il fait en sorte que deux caractères qui semblent identiques à l'œil apparaissent comme deux tokens complètement différents en interne dans le réseau. Un emoji souriant ressemble à un token étrange, pas à un... véritable visage souriant, pixels et tout, et tout l'apprentissage par transfert que cela implique. Le tokenizer doit disparaître. L'OCR n'est qu'une des nombreuses tâches utiles de vision -> texte. Et les tâches texte -> texte peuvent être transformées en tâches vision -> texte. Pas l'inverse. Donc, beaucoup de messages utilisateurs sont des images, mais le décodeur (la réponse de l'Assistant) reste du texte. C'est beaucoup moins évident comment sortir des pixels de manière réaliste... ou si vous le voudriez. Maintenant, je dois aussi lutter contre l'envie de faire un version de nanochat uniquement avec input d'image...

Beau post court illustrant à quel point la diffusion de texte simple (discrète) peut l'être. La diffusion (c'est-à-dire le débruitage parallèle itéré, top) est le paradigme génératif omniprésent dans l'image/vidéo, mais l'autoregression (c'est-à-dire aller de gauche à droite en bas) est le paradigme dominant dans le texte. Pour l'audio, j'ai vu un peu des deux. Beaucoup de papiers sur la diffusion semblent un peu denses, mais si vous dépouillez le formalisme mathématique, vous vous retrouvez avec des algorithmes de base simples, par exemple quelque chose de beaucoup plus proche de l'appariement de flux en continu, ou quelque chose comme ça en discret. C'est votre transformateur classique mais avec une attention bidirectionnelle, où vous rééchantillonnez et remasquez itérativement tous les tokens dans votre "toile de tokens" en fonction d'un calendrier de bruit jusqu'à obtenir l'échantillon final à la dernière étape. (L'attention bidirectionnelle est beaucoup plus puissante, et vous obtenez des modèles de langage autoregressifs beaucoup plus forts si vous vous entraînez avec, malheureusement cela rend l'entraînement beaucoup plus coûteux car maintenant vous ne pouvez pas paralléliser à travers la dimension de séquence). Donc, l'autoregression fait un `.append(token)` à la toile de tokens tout en n'assistant qu'en arrière, tandis que la diffusion rafraîchit l'ensemble de la toile de tokens avec un `.setitem(idx, token)` tout en assistant de manière bidirectionnelle. La pensée humaine semble naïvement un peu plus comme l'autoregression, mais il est difficile de dire qu'il n'y a pas plus de composants semblables à la diffusion dans un certain espace latent de pensée. Il semble tout à fait possible que vous puissiez encore interpoler entre eux, ou les généraliser davantage. Et c'est un composant de la pile LLM qui semble encore un peu fongible. Maintenant, je dois résister à l'envie de m'égarer dans l'entraînement de nanochat avec la diffusion.