Un token no es una palabra ni una medida de inteligencia

«Token» es una de esas palabras técnicas que se cuelan en el discurso comercial y empiezan a significar más de lo que significan. Un anuncio dice «un millón de tokens de contexto» y el oyente entiende «cabe un libro entero y lo entenderá»; las dos cosas son inciertas. Conviene desmontar la unidad antes de dejar que decida por nosotros. La capacidad que se lleva usted de aquí es sencilla y dura: separar token, palabra y ventana de contexto, y medir una tarea por la información útil que resuelve, no por un contador.

Qué es exactamente un token

Un token es una pieza de texto que un sistema convierte en una unidad procesable. Puede coincidir con una palabra entera, pero también con parte de una palabra, un signo de puntuación o un espacio. Los modelos de lenguaje no leen letras ni palabras: trocean el texto en estas piezas según un vocabulario aprendido, y las palabras frecuentes suelen ocupar un token mientras que las raras, largas o técnicas se parten en varios. Por eso el mismo texto no tiene el mismo número de tokens que de palabras, y —esto es lo que casi nadie dice— dos sistemas distintos pueden trocear el mismo párrafo de forma diferente y dar cuentas distintas.

De ahí salen dos consecuencias prácticas. La primera: el idioma importa. Un texto en un idioma poco representado en el vocabulario, o un fragmento de código, suele consumir más tokens que su equivalente en inglés corriente, aunque diga lo mismo — una especie de «impuesto» silencioso sobre quien no escribe en la lengua para la que se optimizó el troceador. La segunda: comparar precios o límites entre proveedores por «número de tokens» sin fijarse en cómo trocea cada uno es comparar dos reglas con marcas distintas.

Para qué sirve el contador, y para qué no

Los tokens son, ante todo, la unidad de la factura y del reloj. Los servicios comerciales de modelos de lenguaje cobran por tokens: los que entran en la petición y los que el modelo genera como respuesta. La latencia —el tiempo que tarda— también crece con cuántos hay que procesar y producir, de modo que el mismo contador sirve para estimar dos costes a la vez, el del dinero y el del reloj. Como estimación de coste y de tiempo, el contador es útil y honesto: si sabe cuántos tokens entran y salen en una tarea típica, sabe cuánto le costará repetirla mil veces.

Lo que el contador no dice es si la respuesta será correcta. Los modelos Transformer trabajan sobre secuencias de tokens y mecanismos de atención —la arquitectura que describió Attention Is All You Need en 2017, prescindiendo de la recurrencia para procesar la secuencia entera en paralelo—, pero atender a más tokens no es comprenderlos mejor. Un texto breve puede omitir la excepción que decide el caso; uno largo puede repetir un dato tres veces sin usarlo bien. El número mide cuánto material entra, no cuánto de ese material se aprovecha.

Hay además una asimetría de coste que conviene conocer: en las tarifas habituales, generar un token de salida cuesta más que procesar uno de entrada, a veces varias veces más — porque producir texto nuevo es computacionalmente más caro que leer el que ya existe. Un modelo que responde con parrafadas no solo es más lento; es más caro por respuesta que uno igual de bueno que va al grano. Contar tokens, entonces, no es tacañería: es la diferencia entre saber lo que paga y descubrirlo en la factura.

Ni una medida de inteligencia

La segunda mitad del título es la que más se olvida. Ni el número de tokens que un modelo acepta ni el tamaño de su ventana miden su inteligencia. Un sistema puede tragarse un millón de tokens y fallar un paso de lógica que un niño resuelve; puede tener el contexto más grande del mercado y equivocarse en una resta. La capacidad de razonar se mide por cómo resuelve tareas, no por cuánto texto admite de entrada — igual que la memoria de un despacho no se mide por el tamaño de sus archivadores, sino por lo que se hace con lo archivado. Cuando un anuncio ofrece la cifra de tokens como si fuera una nota de coeficiente intelectual, está cambiando una medida de capacidad —difícil, discutible, específica de cada tarea— por una de capacidad de almacenamiento, que es fácil de imprimir y no dice lo mismo.

Por qué una ventana más grande no garantiza mejor lectura

La confusión más cara del momento es tratar la ventana de contexto —cuántos tokens caben de una vez— como si fuera comprensión. No lo es, y hay evidencia medida. El estudio Lost in the Middle examinó cómo usan los modelos los contextos largos en tareas de preguntas sobre varios documentos y de recuperación de pares clave-valor, y encontró un patrón con forma de U: el rendimiento es más alto cuando la información relevante está al principio o al final del contexto, y se degrada de forma notable cuando el modelo tiene que ir a buscarla en el medio. Es decir, ampliar la ventana no asegura que el modelo aproveche de verdad todo lo que cabe en ella; puede «perder» justo lo que está enterrado en el centro.

Ese hallazgo no es una curiosidad de laboratorio: es una instrucción de uso. Si mete un documento largo y el dato que decide la respuesta va en el párrafo del medio, tiene más posibilidades de que el sistema lo pase por alto que si lo coloca al principio o al final. La ventana grande es una condición necesaria para que quepa el material; no es suficiente para que se lea bien.

Cómo usar el contador con criterio

De todo lo anterior sale una rutina que sirve con cualquier modelo. Antes de recortar un texto para que quepa, defina la tarea: qué pregunta tiene que responder el sistema. Conserve lo que cambia la respuesta —instrucciones, fechas, cifras, excepciones, fuentes— y elimine lo que no —saludos, duplicados, relleno—. Si el documento es grande, divídalo por secciones y pida al modelo que cite el fragmento exacto que usó, para poder comprobarlo. Y, aprovechando lo que enseña Lost in the Middle, ponga lo crítico en los bordes: lo primero y lo último de un prompt largo es donde el modelo mira mejor.

La metáfora útil es la de una mesa de trabajo. Los tokens son el espacio de la mesa; la ventana de contexto, su tamaño. Poner primero los papeles que necesita para decidir es gestión; creer que una mesa más grande garantiza que alguien los leerá todos con atención es un espejismo. Una mesa enorme cubierta de papeles mal ordenados no es mejor que una pequeña con los tres documentos que importan encima.

El hábito que queda

Cuando una herramienta presuma de muchos tokens, hágale tres preguntas: ¿qué tarea concreta cabe ahí dentro?, ¿qué dato es crítico para resolverla? y ¿cómo comprobaré que se usó de verdad? El número de tokens es una restricción técnica —de coste, de tiempo, de capacidad—, no una promesa de calidad. La calidad depende de la pregunta que se hace, de las fuentes que se meten y de la revisión que se aplica. Saber leer un «un millón de tokens» como lo que es —un tamaño de mesa, no una garantía de lectura— es una capacidad que seguirá sirviendo cuando la cifra de moda sea otra.