Tokenización y preprocesamiento: qué conserva el modelo y qué pierde

Reeditado el 30 de julio de 2026, este artículo corrige una receta peligrosa: preprocesar texto no consiste en pasar todo a minúsculas y borrar URL, puntuación, palabras frecuentes o errores ortográficos. Esas señales pueden ser el dato. «US» y «us» no significan lo mismo; «no» puede ser una palabra frecuente y decisiva; una dirección web puede revelar la procedencia; una falta puede distinguir una consulta real de un texto editorial.

Tokenizar tampoco equivale a «separar palabras». Un token es la unidad que el modelo recibe y produce, elegida mediante un vocabulario y un algoritmo concretos. Esa elección determina coste, longitud de contexto, tratamiento de lenguas, código, números y caracteres raros. La práctica responsable conserva el original, hace explícita cada transformación y mide sus efectos antes de entrenar.

Primero, conservar una capa que no se toca

El corpus bruto necesita procedencia, fecha, permiso, codificación y un identificador estable. Las transformaciones se aplican sobre una copia y se registran con versión. Así se puede reproducir un conjunto, explicar por qué desapareció un documento y corregir una regla sin volver a recolectar. «Limpio» no es una propiedad universal: depende de la tarea, la población y el riesgo.

La normalización de Unicode resuelve que un carácter visible pueda representarse mediante secuencias distintas. El Anexo #15 del estándar Unicode define formas canónicas y de compatibilidad. No son intercambiables: una normalización de compatibilidad puede fusionar formas que el productor del texto distinguía. Hay que elegir la forma, probar ejemplos de las lenguas y dominios afectados y conservar la cadena original cuando la distinción pueda importar.

Pasar a minúsculas puede servir a un clasificador insensible a mayúsculas, pero perjudicar entidades, siglas o código. Quitar HTML puede ser razonable si se quiere el texto visible, aunque antes deben extraerse estructura, enlaces y metadatos útiles. Corregir ortografía automáticamente puede borrar dialecto, edad, intención o la huella de un ataque. Cada regla necesita una hipótesis: qué error reduce, qué información destruye y cómo se comprobarán ambas cosas.

Un token no es necesariamente una palabra

Separar por espacios falla en lenguas que no marcan así todas las fronteras y en elementos como emojis, contracciones, nombres compuestos, direcciones y código. Un vocabulario de palabras completas produce muchas unidades desconocidas. Un vocabulario de caracteres cubre casi cualquier forma, pero genera secuencias largas. Los métodos de subpalabras buscan un compromiso: conservan unidades frecuentes y dividen las raras en fragmentos reutilizables.

Sennrich, Haddow y Birch adaptaron en 2016 Byte Pair Encoding a la segmentación de palabras para traducción neuronal. La técnica empieza con unidades pequeñas y fusiona pares frecuentes hasta alcanzar un vocabulario fijado. De ese modo representa vocabulario abierto con símbolos limitados. No descubre morfemas «verdaderos»: las fusiones responden a frecuencias del corpus y pueden cortar una misma raíz de formas distintas.

SentencePiece permite entrenar modelos de subpalabras directamente sobre oraciones sin depender de una separación previa por espacios. Trata el espacio como un símbolo explícito, admite BPE y un modelo unigram, y facilita reconstruir el texto desde las piezas. Eso no significa que ignore los espacios ni que el contexto decida la segmentación en cada frase: aprende un modelo de tokenización y después lo aplica de forma definida.

El nombre del algoritmo no fija el tokenizador

Dos tokenizadores llamados BPE pueden diferir en normalizador, pretokenización, corpus, tamaño de vocabulario, símbolos reservados y tratamiento de bytes. BERT utilizó WordPiece y añadió tokens de control para marcar el inicio, la separación y las posiciones ocultas. El informe de GPT‑2 describe una variante de BPE sobre bytes diseñada para combinar la cobertura de entradas a nivel de byte con fusiones frecuentes.

La cobertura por bytes evita depender de un símbolo desconocido para caracteres representables, pero no garantiza eficiencia lingüística. Una misma palabra puede ocupar una cantidad muy distinta de tokens según lengua, escritura, espacios o acentos. Las secuencias más largas consumen contexto y cómputo y dejan menos espacio para el contenido del usuario. En números, rutas de archivo o código, cortes poco naturales también pueden dificultar operaciones que una persona considera elementales.

El tokenizador es parte del modelo, no un accesorio intercambiable. Cambiar su vocabulario modifica los identificadores que llegan a la red y vuelve incompatibles los pesos aprendidos, salvo que se diseñe una migración. Por eso una ficha debe guardar los archivos exactos del tokenizador, su hash, versión de biblioteca, normalizador, tokens especiales y reglas de truncado y relleno.

Los tokens especiales merecen una prueba propia. Marcan funciones como inicio, fin, relleno o separación de mensajes y no deben confundirse accidentalmente con texto del usuario. Hay que documentar qué cadena visible los produce, cómo se escapa una entrada que se le parece y qué componente añade cada marcador. El tokenizador no vuelve segura una instrucción: solo establece la frontera numérica que recibirán el modelo y las capas que lo rodean.

La calidad se mide por lengua, dominio y tarea

Un indicador básico es la fertilidad: cuántos tokens se necesitan para representar una palabra o una unidad comparable. También se observan longitud por documento, proporción de bytes o caracteres aislados, fragmentación de nombres y números, tasa de truncado y coste por lengua. Las distribuciones importan más que una media: los textos afectados pueden concentrarse en una comunidad o un dominio.

El estudio How Good is Your Tokenizer? comparó tokenizadores multilingües y monolingües y relacionó la calidad de tokenización con el rendimiento posterior. Su lección no es que exista una partición óptima para todas las lenguas, sino que compartir vocabulario introduce una asignación de capacidad que debe medirse. Añadir textos de una lengua al entrenamiento no garantiza que el vocabulario le conceda unidades eficientes.

La prueba debe incluir pares difíciles reales: mayúsculas, texto descompuesto y compuesto en Unicode, escrituras sin espacios, emojis con modificadores, palabras mixtas, URL, correo, decimales, fechas, código y secuencias de control. Se comprueba ida y vuelta cuando el diseño promete reconstrucción, estabilidad entre máquinas y comportamiento ante entrada inválida. Después se mide la tarea completa: una reducción de tokens solo es mejora si mantiene o eleva la calidad pertinente.

El vocabulario se aprende únicamente con la partición de entrenamiento y después se congela para validación y prueba. Si se reajusta mirando el conjunto reservado, la evaluación deja de simular una entrada desconocida. Para un dominio nuevo se compara el tokenizador existente con uno candidato bajo el mismo presupuesto: longitud, latencia, memoria, calidad de la tarea y compatibilidad. Reducir fragmentación no compensa una migración que rompe modelos, índices o cachés sin un plan verificable.

Del documento al lote de entrenamiento, sin fuga

Tras normalizar y tokenizar quedan decisiones de filtrado, duplicación y partición. Los duplicados pueden dar un peso desproporcionado a una fuente y hacer que una prueba parezca fácil si una copia entró en entrenamiento. Deduplicating Training Data Makes Language Models Better estudia repetición, memorización y solapamiento entre entrenamiento y evaluación, y muestra por qué deduplicar requiere mirar secuencias dentro de los documentos, no solo archivos idénticos.

La separación entre entrenamiento, validación y prueba debe hacerse antes de aprender decisiones que puedan mirar el contenido reservado. Los umbrales de filtrado, listas de bloqueo y detectores se versionan; se conserva el motivo de exclusión y se auditan falsos positivos por lengua. Una regla que elimina texto de baja «calidad» según un clasificador entrenado en un registro concreto puede borrar voces legítimas que escriben de otra manera.

La capacidad transferible es convertir una tubería opaca en un registro reproducible: original y procedencia; transformaciones reversibles; tokenizador exacto; métricas por lengua y dominio; y particiones sin solapamiento. La pregunta no es si los datos quedaron «limpios», sino qué información se conservó, cuál se perdió y qué prueba demuestra que esa pérdida ayuda a la tarea sin trasladar el coste a otros usuarios.