Cómo los LLM ven el texto: lo que mi sistema i18n me enseñó sobre la economía de tokens

Cuando construí el sistema de traducción i18n para mi sitio, descubrí que traducir una publicación de blog de 1.500 palabras en inglés al coreano consumía 2,8 veces más tokens que la fuente en inglés. El mismo contenido semántico, el mismo significado, pero 2,8 veces el costo de API. El japonés resultó en 2,4x. El chino tradicional en 2,1x. El español en 1,15x. La economía de tokens del contenido multilingüe me tomó por sorpresa porque no había comprendido cómo funcionan los tokenizadores.¹

TL;DR

La tokenización convierte texto legible por humanos en tokens numéricos que los modelos de lenguaje procesan. Después de traducir 27 publicaciones de blog a 6 idiomas, tengo datos reales de costos: los scripts no latinos consumen de 2 a 3 veces más tokens por unidad semántica que el inglés. El visualizador interactivo a continuación le permite pegar texto en cualquier idioma y ver el desglose de tokens. Comprender la tokenización me ayudó a presupuestar mi pipeline de traducción con precisión, optimizar mis prompts para reducir el costo en un 35% y depurar un problema de formato donde las traducciones al coreano perdían la estructura markdown porque el tokenizador dividía los marcadores de notas al pie a través de los límites de tokens.

Mis datos de costo de tokens i18n

Traduje 27 publicaciones de blog a 6 idiomas usando Claude. La calidad de traducción requería modelos de nivel Opus (nunca modelos más económicos — una lección que aprendí cuando Haiku produjo traducciones que se leían como salida de máquina). El consumo de tokens por idioma me sorprendió:

Los idiomas con script latino (español, alemán, francés) se mantuvieron dentro del 20% del inglés. Los idiomas CJK y Hangul aumentaron de 2 a 3 veces. La diferencia de costo se acumula a través de 27 publicaciones × 6 idiomas = 162 traducciones.²

Por qué existe la brecha

La mayoría de los tokenizadores (BPE, utilizado tanto por Claude como por GPT-4) se entrenan predominantemente con texto en inglés. Las palabras en inglés tienen representaciones de tokens optimizadas porque los datos de entrenamiento contienen más inglés que cualquier otro idioma. Las palabras comunes en inglés (“the”, “and”, “is”) se mapean a tokens individuales. Los bloques silábicos coreanos, los kanji japoneses y los caracteres chinos a menudo se dividen en 2-3 tokens a nivel de byte porque el tokenizador los encontró con menor frecuencia durante el entrenamiento.³

El efecto es sistemático, no aleatorio. Cada traducción al coreano cuesta aproximadamente 2,8 veces el equivalente en inglés. Puedo presupuestar con precisión porque el multiplicador es consistente.

El error de tokenización

Durante mi primer lote de traducciones al coreano, las publicaciones traducidas perdieron todo el formato markdown: las referencias de notas al pie ([^1]) desaparecieron, los bloques de código perdieron sus etiquetas de idioma y los marcadores de encabezado (##) se fusionaron con el texto del cuerpo.

El diagnóstico tomó una hora. La causa raíz: mi prompt de traducción decía “Traduce esta publicación de blog al coreano” sin especificar la preservación del formato. El tokenizador dividió la sintaxis markdown a través de los límites de tokens de manera diferente en el contexto coreano que en el contexto inglés. El modelo trató [^1] como contenido traducible en lugar de marcado estructural.

La solución: agregué restricciones explícitas a mi prompt de traducción:

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

Cada restricción eliminó un modo de fallo. La lista de restricciones creció más que la instrucción de traducción — un patrón que describo en mi marco de ingeniería de prompts OODA.⁴

Qué son los tokens

De caracteres a tokens

Un enfoque ingenuo del procesamiento de texto trataría cada carácter como una unidad de entrada. “Hello world” se convierte en 11 caracteres. El procesamiento a nivel de carácter captura cada detalle pero produce secuencias extremadamente largas: un documento de 1.000 palabras se convierte en aproximadamente 5.000 caracteres.⁵

El procesamiento a nivel de palabra reduce la longitud de la secuencia pero falla con palabras desconocidas. Un vocabulario a nivel de palabra de 50.000 entradas no puede procesar “unfathomability” a menos que esa palabra exacta haya aparecido en el entrenamiento.

La tokenización por subpalabras encuentra un punto intermedio. Las palabras comunes (“the”, “and”) permanecen como tokens individuales. Las palabras poco comunes se dividen en piezas de subpalabras. “Unfathomability” se divide en [“un”, “fath”, “om”, “ability”], donde cada pieza aparece con suficiente frecuencia para tener una representación entrenada.

Byte-Pair Encoding (BPE)

BPE, utilizado por Claude y GPT-4, comienza con bytes individuales y fusiona iterativamente los pares adyacentes más frecuentes:⁶

1. Comenzar con caracteres individuales: [l, o, w, e, r]
2. Par más frecuente: (l, o) → fusionar a [lo, w, e, r]
3. Par más frecuente: (e, r) → fusionar a [lo, w, er]
4. Par más frecuente: (lo, w) → fusionar a [low, er]
5. Par más frecuente: (low, er) → fusionar a [lower]

El vocabulario final contiene todos los bytes originales más cada token fusionado, típicamente de 50.000 a 100.000 entradas. Las palabras en inglés dominan los tokens fusionados porque el inglés domina los datos de entrenamiento.

Cómo optimicé mis prompts

Después de descubrir la brecha en el costo de tokens, optimicé mi pipeline de traducción para reducir el costo en un 35%:

Optimización 1: Agrupar por familia lingüística

Los idiomas con script latino (español, francés, alemán) comparten similitudes estructurales. Agrupo el prompt de traducción para producir los tres en una sola llamada a la API cuando la publicación fuente es lo suficientemente corta para caber en la ventana de contexto con las tres salidas. El contexto compartido (la fuente en inglés) se paga una vez en lugar de tres.⁷

Optimización 2: Deduplicación de restricciones

Mi prompt de traducción original repetía las restricciones para cada idioma. La versión optimizada define las restricciones una vez y las aplica a todas las salidas:

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

La sección de restricciones consume tokens una sola vez. La alternativa (repetir restricciones por idioma) consume 3 veces más.

Optimización 3: Instrucciones concisas

Mi prompt original usaba 340 tokens de instrucciones. Después de optimizar: 180 tokens. La reducción del 47% se acumula a través de 162 traducciones.

Los idiomas CJK se benefician menos de la optimización de prompts porque los tokens de salida (la traducción misma) dominan el costo. La salida es inherentemente más larga en términos de tokens independientemente de cuán concisas sean las instrucciones.⁸

Aplicaciones prácticas

Estimación de costos

Una heurística aproximada para texto en inglés: 1 token es aproximadamente 0,75 palabras, o aproximadamente 4 caracteres. Un documento de 1.000 palabras consume aproximadamente 1.333 tokens. Aplique el multiplicador de idioma de mi tabla anterior para contenido que no sea en inglés.⁹

Tokenización de código

El código se tokeniza de manera diferente a la prosa. Las palabras clave comunes (def, return, if) se mapean a tokens individuales. Los nombres de variables se dividen según la frecuencia:

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

Las convenciones de nomenclatura consistentes reducen el conteo de tokens. Mi infraestructura de hooks usa la convención verb-noun.sh (git-safety-guardian, recursion-guard, blog-quality-gate). El patrón consistente ayuda al tokenizador a predecir y fusionar subpalabras comunes de manera eficiente.

Depuración de comportamiento inesperado

Cuando un modelo produce una salida inesperada, la tokenización puede explicar por qué. Mi error de formato en coreano ocurrió porque el tokenizador dividió [^1] de manera diferente en el contexto coreano que en el inglés. Comprender el patrón de división llevó directamente a la solución (restricciones explícitas de preservación).

Conclusiones clave

Para ingenieros que usan APIs de LLM: - Mida los costos de tokens por idioma antes de comprometerse con soporte multilingüe; los idiomas CJK cuestan de 2 a 3 veces más por unidad semántica que el inglés - Optimice las instrucciones de los prompts (redacción concisa, restricciones deduplicadas) para una reducción de costos del 30-50% en pipelines de traducción de alto volumen - Pruebe la tokenización de términos específicos del dominio y la sintaxis markdown antes del despliegue en producción; las divisiones inesperadas causan errores de formato

Para gerentes de producto que presupuestan funciones de IA: - El soporte de idiomas distintos al inglés cuesta de 1,5 a 3 veces más por llamada a la API que el inglés; presupueste las funciones de IA multilingüe usando el multiplicador de idioma, no una estimación plana por idioma - Los límites de la ventana de contexto afectan a los idiomas CJK de manera desproporcionada; una ventana de 200.000 tokens contiene un 40% menos de contenido en coreano que en inglés

Referencias