¿Cómo usar esta herramienta?
- Teclee o pegue su texto en el campo de entrada — o arrastre un archivo .txt/.md/.json (hasta 10 MB) al campo.
- Elija una familia de tokenizer (BPE / WordPiece / Unigram) — las fichas de tokens se actualizan en vivo.
- Cambie vistas: flujo de tokens · comparación 3 familias · multilingüe · pasos de algoritmo.
¿Por qué un Tokenizer Playground?
Quien trabaja con modelos de lenguaje tropieza tarde o temprano con un número más importante que el número de palabras: el número de tokens. Los tokens son las unidades en las que los modelos perciben el texto — normalmente menores que una palabra pero mayores que una letra. El Tokenizer Playground descompone su texto en vivo justo en esas unidades y muestra cada token como ficha codificada por color con token-ID, longitud en bytes y offset de bytes. Pase el cursor sobre cualquier token y verá exactamente qué entrada del vocabulario coincide.
A diferencia de un contador clásico de palabras, un tokenizer ilumina también su propio algoritmo. Tres familias están representadas en el playground: Byte-Pair-Encoding, WordPiece y Unigram. Son las tres escuelas dominantes de las que derivan los tokenizers multilingües actuales. El playground las muestra no como una caja negra, sino como un algoritmo paso a paso rastreable.
Tres familias, tres estrategias — ¿qué las distingue?
Familia BPE (Byte-Pair-Encoding) arranca cada tokenización en caracteres individuales. Luego se fusionan pares según un orden de frecuencia entrenado hasta que ninguna regla más encaja. Marca distintiva: un espacio antes de cada inicio de palabra se conserva como carácter especial (Ġ en la visualización) — eso convierte « the » y « ▁the » (con espacio inicial) en dos tokens distintos. Esta familia es la elección más frecuente en modelos decoder-only para generación de texto. Fuente: Sennrich, Haddow, Birch 2016.
Familia WordPiece elige desde la izquierda la subpalabra más larga del vocabulario que encaja. Las piezas siguientes dentro de la misma palabra reciben el marcador de continuación « ## » — de modo que sale play + ##ing. Pone típicamente la entrada en minúsculas antes. Esta familia se ve en modelos encoder-only bidireccionales clásicos para clasificación y comprensión. Consecuencia: la misma palabra con distinta capitalización produce tokens idénticos.
Familia Unigram (estilo SentencePiece) trata la tokenización como problema de optimización. Cada entrada de vocabulario tiene una log-probabilidad; Viterbi encuentra la segmentación con la suma total más alta. Los inicios de palabra llevan un marcador Unicode (▁). Esta familia es la elección estándar de modelos encoder-decoder multilingües y es preferida cuando la mezcla de escrituras latinas, asiáticas y caracteres especiales es la norma. Fuente: Kudo 2018.
¿Qué me muestra el heatmap multilingüe?
La pestaña heatmap toma un contenido idéntico — el pangrama clásico « el zorro marrón rápido salta sobre el perro perezoso » — y lo traduce a seis idiomas: inglés, alemán, francés, español, japonés y árabe. Para cada idioma, el playground cuenta las palabras (basado en un límite de palabra Unicode) y los tokens (basado en la familia actual elegida) y calcula la ratio tokens por palabra. Sobre 2 se vuelve caro; sobre 4 el idioma queda estructuralmente desfavorecido.
El fenómeno está bien documentado. Un estudio de 2023 mostró que la misma traducción en 22 idiomas produce diferencias de tokens de 1,5 a 14 veces — con inglés siempre en el extremo más barato. El heatmap del playground muestra ese efecto al instante: inglés aterriza típicamente en 1,0–1,3 tokens por palabra, alemán por los compuestos en 1,5–2,0, japonés por la ambigüedad de límites de palabra en 2,5 y más.
¿Cómo muestra la traza del algoritmo la tokenización paso a paso?
Una caja negra es difícil de aprender. Por eso la pestaña de pasos de algoritmo muestra todo el desarrollo de la tokenización sobre su entrada actual. En BPE, la entrada se descompone primero en caracteres individuales. Luego en cada paso se fusiona el par con el rango de merge más alto y se muestra el resultado intermedio. Verá p. ej.: « merge ‘t’ + ‘h’ → ‘th’ (regla #1) », luego « merge ‘th’ + ‘e’ → ‘the’ (regla #22) », luego « no hay más merge posible — terminado ».
En WordPiece cada paso parece distinto. La traza muestra el cursor izquierdo y el match de subpalabra: « match ‘play’ (4 caracteres) », luego « match ‘##ing’ (3 caracteres) ». Si no se encuentra subpalabra, aparece « no hay match en posición N — [UNK] » y la pasada termina. En Unigram la traza muestra el Viterbi-backtrack: cada posición recibe una log-probabilidad, se elige el camino con la suma más alta y los tokens se muestran en el orden en que aparecen.
¿Qué significa el token-ID junto a cada pieza?
Cada tokenizer tiene una tabla de mapeo fija: token-string → token-ID. El ID es el número que el modelo recibe realmente — la cadena es solo la forma legible para humanos. En el playground el ID se muestra junto a cada ficha. Token-ID = -1 significa: esta pieza no está incluida en el vocabulario de muestra. El tokenizer recurre entonces a caracteres individuales, lo que dispara el número de tokens.
Es exactamente el comportamiento fuera de vocabulario de los tokenizers reales en la práctica. Visible en nombres propios raros, términos técnicos, inserciones de idioma extranjero o emoji. Quien pruebe un prompt con « Đorđević » verá que ese único nombre cuesta entre 8 y 12 tokens — mientras un nombre inglés frecuente cabe en uno o dos.
¿Para qué sirve la comparación 3-familias?
En la pestaña de comparación, su entrada corre en paralelo por las tres familias. Directamente arriba hay tres contadores de tokens y un valor Δ — la diferencia con la familia más eficiente. Es la respuesta a una pregunta recurrente en la práctica: « ¿Ahorro tokens si cambio de familia? » La respuesta depende de la entrada. El texto claro en inglés es muy similar en las tres. El código fuente es notablemente más compacto en BPE porque las reglas de merge aprenden secuencias de código frecuentes. El texto CJK es más eficiente en Unigram (con buen vocabulario SentencePiece) porque allí existen tokens multi-carácter para sílabas frecuentes.
¿Qué no está deliberadamente en el playground?
Tres funciones quedan fuera del alcance a propósito. Primero: sin calculadora de coste con precios en euros o dólares — cambian con frecuencia y dependen de cada proveedor. Segundo: sin constructor de chat-template (etiquetas de sistema, usuario y asistente). Distintos modelos usan distintas convenciones, y un constructor de plantillas acopla demasiado rápido a un único modelo. Tercero: sin subidas de vocabulario — supondría un riesgo de seguridad (archivos de vocabulario manipulados podrían contener piezas inseguras).
Estas lagunas son intencionadas. Mantienen el playground ligero, rápido y neutral respecto al proveedor. Quien necesite una estimación exacta de costes de tokens para un modelo concreto usa su tokenizer oficial. Quien quiera entender el algoritmo y comparar tres familias en paralelo — para eso está hecho el playground.
¿Qué hay con la privacidad y el RGPD?
Su texto queda en la memoria del navegador. No hay servidor, ni localStorage, ni cookies, ni analytics, ni petición de red. En la pestaña de red de DevTools no aparece nada tras cargar la página. Cierre la pestaña y todo queda borrado — por diseño. El botón « Copiar estadísticas » también realiza únicamente una llamada local a la Clipboard API, sin tráfico de red.
Desde la perspectiva del RGPD no se procesan datos personales en el sentido del art. 4 porque el procesamiento ocurre localmente en su dispositivo. Incluso prompts sensibles (snippets de código, notas personales, textos jurídicos) quedan en la pestaña. Esta arquitectura hace el playground utilizable en entornos corporativos con requisitos estrictos de cumplimiento.
Última actualización: