Uso modelos de lenguaje todos los días. Le pido cosas a mis agentes, reviso lo que devuelven, los conecto a scripts y a APIs. Y aun así, hasta hace poco, por dentro seguían siendo una caja negra. Les meto texto, sale texto, y en medio pasa "algo" que no sabía explicar sin encogerme de hombros. Esa incomodidad me picaba, y esta semana la he resuelto con una visualización que lleva un tiempo dando vueltas por Hacker News y que me habría ahorrado un par de noches si la hubiera encontrado antes.
Seis letras para entenderlo todo
La herramienta de Brendan Bycroft es una de esas cosas que cuando las ves piensas "cómo no se me ocurrió". Coge un modelo diminuto, casi de juguete, y te deja recorrerlo por dentro en 3D, paso a paso, sin saltarse nada.
El ejemplo es tonto a propósito: el modelo tiene que ordenar seis letras. Entra C B A B B C y tiene que salir ABBBCC. Nada de redactar ensayos, solo ordenar alfabéticamente. Y precisamente por eso se ve.
Cada letra es un token, y este modelo solo conoce tres: A, B y C. A cada una le asigna un número, su índice. Así que la frase de seis letras entra como una lista de seis números: 2 1 0 1 1 2. Hasta aquí, todo terriblemente aburrido. Y bien.
Aquí todo es un vector de 48 posiciones
El primer salto que me hizo gracia: cada uno de esos números no entra tal cual. Se convierte en un vector de 48 posiciones. Algo así como pasar de un simple "2" a una lista de 48 numeritos. Eso se llama embedding.
Ese 48 no cae del cielo. Es una decisión de arquitectura, el tamaño de canal que eligió el modelo nano-GPT del que sale todo esto. Lo cuento porque en los comentarios de la gente que lo usó, la pregunta "¿por qué 48?" aparecía una y otra vez. Media docena de personas se quedaron atascadas justo ahí, antes de empezar, buscando una explicación profunda donde solo había un número elegido a mano.
Me recordó a algo que me pasa constantemente con la tecnología: cuando un detalle no está explicado, uno asume que esconde algo. Y casi siempre solo es un valor que alguien puso.
El viaje, capa a capa
A partir de ahí, el embedding cruza una serie de capas, las famosas transformadoras, hasta llegar abajo. En la vista 3D, las celdas verdes son números que se están procesando y las azules son pesos. Ves la suma, la multiplicación, el número moviéndose de una celda a otra. No hay magia, hay cuentas. Muchísimas cuentas, pero cuentas.
Al final del recorrido, el modelo escupe una predicción: cuál es la letra que viene después. Con seis letras de entrada, está casi seguro de que la siguiente es la A. Y entonces se coge esa predicción, se vuelve a meter por arriba, y se repite el proceso entero. Eso es toda la generación de texto: predecir el siguiente trocito, apuntarlo, y empezar de nuevo. Cuando lo ves en bucle, la palabra "generar" se queda corta; en realidad está eligiendo, un paso detrás de otro.
Lo que me llevo
Dos cosas. La primera, que entender algo no es tener una intuición vaga, es poder seguir las piezas con el dedo. Yo tenía una intuición decente sobre los modelos; ver las celdas me dio algo mejor, la mecánica.
La segunda es un aviso. La propia visualización usa palabras heredadas de la recuperación de información: atención, claves, valores. Suenan muy humanas y llevan a pensar que el modelo "atiende" o "decide" como lo haría una persona. No. Son etiquetas prestadas para unas operaciones que son pura aritmética. Cuando construyo con esto, recordármelo me evita darle más crédito del que tiene.
Conclusión
Llevo años usando herramientas que no entiendo del todo, y creo que es honesto hacerlo. Pero hay momentos en los que merece la pena parar y mirar dentro, aunque solo sea para dejar de tratar la cosa como un oráculo. Esta visualización es gratis, la hizo una sola persona, y consigue lo que muy pocos manuales: te obliga a moverte por dentro del sistema en vez de leerlo por encima. Ahora, cuando le pido algo a un agente, sé qué tipo de máquina me está contestando. Y eso, para construir, cambia bastante.