Letzte Nacht habe ich nanochat d32 beigebracht, wie man 'r' in Erdbeere (oder ähnlichen Variationen) zählt. Ich dachte, das wäre ein gutes/unterhaltsames Beispiel dafür, wie man nanochat Fähigkeiten hinzufügen kann, und ich habe hier einen vollständigen Leitfaden geschrieben: Dies geschieht über eine neue synthetische Aufgabe `SpellingBee`, die Beispiele generiert, in denen ein Benutzer nach dieser Art von Problem fragt, und eine ideale Lösung von einem Assistenten. Wir trainieren dann mittelfristig/SFT nach, um dem LLM die Fähigkeit zu verleihen, oder trainieren weiter mit RL, um es robuster zu machen. Es gibt viele Details, die besonders bei kleineren Modellgrößen richtig gemacht werden müssen, und der Leitfaden führt durch diese. Als kurze Übersicht: - Sie müssen Vielfalt in den Benutzeraufforderungen/Anfragen sicherstellen. - Bei kleinen Modellen wie nanochat insbesondere müssen Sie sehr vorsichtig mit den Tokenisierungsdetails sein, um die Aufgabe für ein LLM einfach zu machen. Insbesondere müssen Sie auf Leerzeichen achten, und dann müssen Sie die Berechnung des Denkens über viele Token der teilweisen Lösung verteilen: Zuerst standardisieren wir das Wort in Anführungszeichen, dann buchstabieren wir es (um die Tokens aufzubrechen), dann iterieren wir und halten einen expliziten Zähler, usw. - Ich ermutige das Modell, das Problem auf zwei verschiedene Arten zu lösen: auf eine manuelle Weise (mentale Arithmetik im Kopf) und auch durch die Nutzung des Python-Interpreters, auf den nanochat Zugriff hat. Das ist ein bisschen "Rauch und Spiegel", weil jede Lösung momentan "sauber" ist, ohne Fehler. Man könnte entweder die Aufgabe anpassen, um Fehler zu simulieren und Wiederherstellungen durch Beispiele zu demonstrieren, oder RL durchführen. Höchstwahrscheinlich funktioniert eine Kombination aus beidem am besten, wobei das erste als Prior für das RL fungiert und ihm Dinge gibt, mit denen es arbeiten kann. Wenn nanochat ein viel größeres Modell wäre, würde man erwarten oder hoffen, dass diese Fähigkeit irgendwann leichter "herauskommt". Aber da das "Gehirn" von nanochat d32 die Größe einer ~Honigbiene hat, müssen wir, wenn wir wollen, dass es r's in Erdbeere zählt, dies tun, indem wir es in den Daten überrepräsentieren, um das Modell zu ermutigen, es früher zu lernen. Aber es funktioniert! :)

Ich mag das neue DeepSeek-OCR-Papier ganz gerne. Es ist ein gutes OCR-Modell (vielleicht ein bisschen schlechter als Dots), und ja, Datensammlung usw., aber das spielt keine Rolle. Der interessantere Teil für mich (insbesondere als jemand, der im Herzen Computer Vision ist und sich vorübergehend als jemand aus der natürlichen Sprachverarbeitung ausgibt) ist, ob Pixel bessere Eingaben für LLMs sind als Text. Ob Text-Tokens verschwenderisch und einfach schrecklich sind, als Eingabe. Vielleicht macht es mehr Sinn, dass alle Eingaben für LLMs nur Bilder sein sollten. Selbst wenn Sie zufällig eine reine Texteingabe haben, möchten Sie sie vielleicht rendern und dann einspeisen: - mehr Informationskompression (siehe Papier) => kürzere Kontextfenster, mehr Effizienz - signifikant mehr allgemeiner Informationsstrom => nicht nur Text, sondern z.B. fetter Text, farbiger Text, beliebige Bilder. - Eingaben können jetzt mit bidirektionaler Aufmerksamkeit einfach und standardmäßig verarbeitet werden, nicht autoregressiver Aufmerksamkeit - viel leistungsfähiger. - Löschen Sie den Tokenizer (bei der Eingabe)!! Ich habe bereits darüber geschimpft, wie sehr ich den Tokenizer nicht mag. Tokenizer sind hässlich, separat, kein End-to-End-Schritt. Er "importiert" all das Hässliche von Unicode, Byte-Codierungen, er erbt viel historisches Gepäck, Sicherheits-/Jailbreak-Risiko (z.B. Fortsetzungsbytes). Er macht zwei Zeichen, die für das Auge identisch aussehen, intern im Netzwerk zu zwei völlig unterschiedlichen Tokens. Ein lächelndes Emoji sieht aus wie ein seltsamer Token, nicht wie ein... tatsächliches lächelndes Gesicht, Pixel und alles, und all das Transferlernen, das damit einhergeht. Der Tokenizer muss weg. OCR ist nur eine von vielen nützlichen Vision -> Text-Aufgaben. Und Text -> Text-Aufgaben können so gestaltet werden, dass sie Vision -> Text-Aufgaben sind. Nicht umgekehrt. So viele Benutzer-Nachrichten sind Bilder, aber der Decoder (die Antwort des Assistenten) bleibt Text. Es ist viel weniger offensichtlich, wie man realistisch Pixel ausgibt... oder ob man das möchte. Jetzt muss ich auch dem Drang widerstehen, eine bildbasierte Eingabeversion von nanochat zu entwickeln...

Schöner, kurzer Beitrag, der veranschaulicht, wie einfach die diskrete Diffusion sein kann. Diffusion (d.h. parallel, iterierte Rauschunterdrückung, oben) ist das weit verbreitete generative Paradigma in Bildern/Videos, während die Autoregression (d.h. von links nach rechts unten) das dominante Paradigma im Text ist. Bei Audio habe ich ein bisschen von beidem gesehen. Viele Diffusionspapiere wirken etwas dicht, aber wenn man die mathematische Formalität wegnimmt, hat man einfache Basisalgorithmen, z.B. etwas, das viel näher am Flussabgleich in kontinuierlichen Daten liegt, oder etwas wie dies in diskreten Daten. Es ist dein Vanilla-Transformer, aber mit bidirektionaler Aufmerksamkeit, bei dem du iterativ alle Tokens in deiner "Tokens-Leinwand" basierend auf einem Rauschzeitplan neu samplest und neu maskierst, bis du die endgültige Probe im letzten Schritt erhältst. (Bidirektionale Aufmerksamkeit ist viel mächtiger, und du erhältst viel stärkere autoregressive Sprachmodelle, wenn du damit trainierst, leider macht es das Training auch viel teurer, weil du jetzt nicht mehr über die Sequenzdimension parallelisieren kannst). Die Autoregression fügt also ein `.append(token)` zur Tokens-Leinwand hinzu, während sie nur rückwärts aufpasst, während die Diffusion die gesamte Tokens-Leinwand mit einem `.setitem(idx, token)` aktualisiert, während sie bidirektional aufpasst. Menschliches Denken fühlt sich naiv eher wie Autoregression an, aber es ist schwer zu sagen, dass es nicht mehr diffusionsähnliche Komponenten in einem latenten Raum des Denkens gibt. Es scheint durchaus möglich, dass man weiter zwischen ihnen interpolieren oder sie weiter verallgemeinern kann. Und es ist ein Bestandteil des LLM-Stacks, der sich immer noch etwas fungibel anfühlt. Jetzt muss ich dem Drang widerstehen, in die Nebengeschichte über das Training von Nanochat mit Diffusion abzuschweifen.