Anoche enseñé a nanochat d32 cómo contar la 'r' en fresa (o variaciones similares). Pensé que este sería un buen/divertido ejemplo de cómo añadir capacidades a nanochat y escribí una guía completa aquí: Esto se hace a través de una nueva tarea sintética `SpellingBee` que genera ejemplos de un usuario pidiendo este tipo de problema, y una solución ideal de un asistente. Luego, realizamos un entrenamiento intermedio/SFT para afinar el modelo LLM con esta capacidad, o entrenamos más con RL para hacerlo más robusto. Hay muchos detalles que hay que acertar, especialmente en modelos más pequeños, y la guía los detalla. Como un breve resumen: - Tienes que asegurar diversidad en los prompts/consultas de los usuarios. - Para modelos pequeños como nanochat, especialmente, tienes que tener mucho cuidado con los detalles de tokenización para facilitar la tarea a un LLM. En particular, debes tener cuidado con los espacios en blanco, y luego debes distribuir el cálculo del razonamiento a través de muchos tokens de solución parcial: primero estandarizamos la palabra entre comillas, luego la deletreamos (para romper los tokens), luego iteramos y mantenemos un contador explícito, etc. - Estoy animando al modelo a resolver el problema de dos maneras separadas: una forma manual (aritmética mental en su cabeza) y también mediante el uso de herramientas del intérprete de Python al que nanochat tiene acceso. Esto es un poco "ilusión" porque cada solución en este momento es "limpia", sin errores. Se podría ajustar la tarea para simular errores y demostrar recuperaciones por ejemplo, o ejecutar RL. Lo más probable es que una combinación de ambos funcione mejor, donde lo primero actúa como el previo para el RL y le da cosas con las que trabajar. Si nanochat fuera un modelo mucho más grande, esperarías o desearías que esta capacidad "saliera" más fácilmente en algún momento. Pero dado que el "cerebro" de nanochat d32 es del tamaño de una ~abeja de miel, si queremos que cuente las r's en fresa, tenemos que hacerlo sobre-representándolo en los datos, para animar al modelo a aprenderlo antes. ¡Pero funciona! :)

Me gusta bastante el nuevo artículo de DeepSeek-OCR. Es un buen modelo de OCR (quizás un poco peor que dots), y sí, la recolección de datos, etc., pero de todos modos no importa. La parte más interesante para mí (especialmente como alguien que es un apasionado de la visión por computadora y que temporalmente se disfraza de persona de lenguaje natural) es si los píxeles son mejores entradas para los LLMs que el texto. Si los tokens de texto son derrochadores y simplemente terribles, en la entrada. Quizás tenga más sentido que todas las entradas a los LLMs deberían ser solo imágenes. Incluso si tienes una entrada de texto puro, tal vez preferirías renderizarla y luego alimentarla: - más compresión de información (ver artículo) => ventanas de contexto más cortas, más eficiencia - flujo de información general significativamente mayor => no solo texto, sino por ejemplo texto en negrita, texto de color, imágenes arbitrarias. - la entrada ahora puede ser procesada con atención bidireccional fácilmente y como predeterminado, no atención autorregresiva - mucho más poderosa. - ¡eliminar el tokenizador (en la entrada)!! Ya he expresado cuánto desagrado tengo por el tokenizador. Los tokenizadores son feos, separados, no son una etapa de extremo a extremo. "Importa" toda la fealdad de Unicode, codificaciones de bytes, hereda mucho equipaje histórico, riesgo de seguridad/escape (por ejemplo, bytes de continuación). Hace que dos caracteres que parecen idénticos a la vista se vean como dos tokens completamente diferentes internamente en la red. Un emoji sonriente se ve como un token extraño, no como una... cara sonriente real, píxeles y todo, y todo el aprendizaje por transferencia que conlleva. El tokenizador debe irse. El OCR es solo una de muchas tareas útiles de visión -> texto. Y las tareas de texto -> texto pueden hacerse para ser tareas de visión -> texto. No al revés. Así que muchos mensajes de usuario son imágenes, pero el decodificador (la respuesta del asistente) sigue siendo texto. Es mucho menos obvio cómo outputear píxeles de manera realista... o si querrías hacerlo. Ahora también tengo que luchar contra la urgencia de desviar a una versión de nanochat solo de entrada de imagen...

Bonito, breve post que ilustra lo simple que puede ser la difusión de texto (discreta). La difusión (es decir, denoising paralelo e iterado, top) es el paradigma generativo omnipresente en imagen/video, pero la autoregresión (es decir, ir de izquierda a derecha abajo) es el paradigma dominante en texto. Para audio he visto un poco de ambos. Muchos artículos sobre difusión parecen un poco densos, pero si eliminas el formalismo matemático, terminas con algoritmos base simples, por ejemplo, algo mucho más cercano al emparejamiento de flujo en continuo, o algo como esto en discreto. Es tu transformador básico pero con atención bidireccional, donde re-muestras y re-mascaras iterativamente todos los tokens en tu "lienzo de tokens" basado en un cronograma de ruido hasta que obtienes la muestra final en el último paso. (La atención bidireccional es mucho más poderosa, y obtienes modelos de lenguaje autoregresivos mucho más fuertes si entrenas con ella, desafortunadamente, hace que el entrenamiento sea mucho más costoso porque ahora no puedes paralelizar a través de la dimensión de la secuencia). Así que la autoregresión está haciendo un `.append(token)` al lienzo de tokens mientras solo atiende hacia atrás, mientras que la difusión está refrescando todo el lienzo de tokens con un `.setitem(idx, token)` mientras atiende bidireccionalmente. El pensamiento humano, de manera ingenua, se siente un poco más como la autoregresión, pero es difícil decir que no hay más componentes similares a la difusión en algún espacio latente del pensamiento. Se siente bastante posible que puedas interpolar más entre ellos, o generalizarlos aún más. Y es un componente de la pila LLM que aún se siente un poco fungible. Ahora debo resistir la urgencia de desviarme hacia el entrenamiento de nanochat con difusión.