Probablemente deberías prestar atención a los tokenizers

• Mientras ayudaban a desarrollar una app de IA que maneja datos de e-commerce, detectaron un problema: la retrieval-augmented generation (RAG) funcionaba bien con algunas consultas, pero no con otras
• Al resolver este tipo de problemas, es importante revisar los datos de entrada (el texto fuente indexado y las consultas de usuario usadas en la búsqueda)
• En particular, parecía necesario optimizar aspectos de chunking y tokenización

[Tokenization]

• La tokenización es el proceso de descomponer texto en piezas más pequeñas llamadas tokens mediante un tokenizer
• Estos tokens se mapean a IDs de token, que son valores enteros que identifican de forma única cada token dentro del vocabulario del tokenizer
• El vocabulario del tokenizer es el conjunto de todos los tokens posibles usados para entrenarlo
• Pueden surgir problemas cuando los tokens de un texto no existen en el vocabulario del tokenizer del LLM
• La mayoría de los LLM tienen vocabularios grandes de entre 30k y 300k
• La mayoría de los LLM más usados dependen de tokenizers de subpalabras (BPE, Wordpiece, etc.)
• Tipos de tokenizer
  • word: divide según espacios, signos de puntuación, etc.
  • character: divide por caracteres individuales (a veces incluso la puntuación)
  • subword: divide los tokens en subpalabras que pueden parecer carentes de significado
  • La mayoría de los LLM usan tokenizers de subpalabras
    • BPE(Byte-Pair Encoder): la librería tiktoken de OpenAI
    • Wordpiece: Cohere, MiniLM-L6-v2, etc.

Comparación entre MiniLM-L6-v2 y tiktoken

• El tamaño del vocabulario del tokenizer del modelo MiniLM-L6-v2 es 30522, mucho menor que el de tiktoken(200019)
• Al tokenizar la oración "tokenizer tokenizes text into tokens"
  • MiniLM-L6-v2: [CLS] token ##izer token ##izes text into token ##s [SEP]
  • tiktoken: token, izer, token, izes, text, into, tokens
• La librería tiktoken de OpenAI implementa un tokenizer BPE y se usa en los modelos LLM de ChatGPT
• El vocabulario de MiniLM-L6-v2 también incluye letras alemanas y caracteres japoneses

Tokenización de emojis, errores tipográficos y términos específicos de dominio

• MiniLM-L6-v2 tokeniza los emojis como tokens [UNK]
• tiktoken fue entrenado con algunos tokens de caracteres Unicode, pero aun así puede causar problemas en RAG
• Los nombres de productos específicos de dominio, como "Gucci Savoy Leathertrimmed Printed Coatedcanvas Suitcase", tampoco se tokenizan correctamente
• En el caso de una oración con errores tipográficos ("I hve received wrong pckage")
  • MiniLM-L6-v2: i, h, ##ve, received, wrong, pc, ##ka, ##ge
  • tiktoken: I, h, ve, received, wrong, p, ck, age

[Embeddings]

• Un tokenizer por sí solo no sirve de mucho. Principalmente se desarrolló para hacer análisis numérico complejo a partir de la frecuencia de tokens individuales
• Para preservar el significado contextual del texto, se necesita una forma de capturar las relaciones entre tokens
• Los embeddings son vectores que representan tokens y capturan bien los significados y relaciones entre palabras del texto
• Los embeddings son un subproducto del entrenamiento de transformadores y se aprenden realmente a partir de grandes volúmenes de texto tokenizado
• Cuando se solicita generación de texto, lo que se entrega al LLM como entrada son justamente embeddings
• Un LLM se compone de dos elementos principales: encoder y decoder
  • Tanto el encoder como el decoder reciben embeddings como entrada
  • La salida del encoder también es un embedding, que se pasa a las cabezas de cross-attention del decoder y cumple un papel importante en la generación (predicción) de tokens de salida
• En un pipeline RAG, el texto primero se tokeniza, luego se convierte en embeddings y después se ingresa al transformador
  • Los IDs de token sirven como índices dentro del vocabulario del tokenizer y también se usan para recuperar embeddings de la matriz de embeddings
  • Los embeddings recuperados se ensamblan como tensores y se entregan como entrada al transformador
• Flujo del encoder: tokenización del texto -> recuperación del embedding de cada token -> ensamblado del tensor de embeddings -> entrada al transformador -> codificación -> paso de la salida del encoder al cross-attention del decoder -> generación de la salida del decoder

Ejemplos de embeddings

• "You can break it 😞" y "You can not break it 😊" tienen sentimientos opuestos, pero en MiniLM-L6-v2 la distancia entre embeddings es muy pequeña
• OpenAI muestra mejor rendimiento porque su vocabulario de tokens maneja mejor los emojis
• OpenAI también maneja mejor los errores tipográficos
• Sin embargo, incluso en OpenAI, si se agrega un espacio al final de la oración, la distancia entre embeddings se separa más de lo esperado
• Los desarrolladores también tienen dificultades al tratar formatos de fecha. Las expresiones de tiempo relativo ("se envió ayer") pueden ser un problema aún mayor
• Las diferencias en la notación monetaria (£40, $50, 40£, 50¢, etc.) también pueden causar problemas extraños
• En datos específicos de dominio, como el caso del bolso Gucci, normalmente se resuelve con fine-tuning, pero siempre hay que revisar los datos y las métricas de evaluación

Conclusión

• Este artículo ayuda a entender mejor cómo los tokenizers pueden afectar una app RAG y por qué conviene prestarles atención
• En aplicaciones con agentes, garbage-in garbage-out no siempre producirá resultados al nivel esperado
• Incluso una limpieza ligera del texto de entrada puede ayudar mucho
  • Estandarizar los formatos de fecha de manera consistente
  • Eliminar espacios en blanco finales siempre que sea posible (se comprobó su impacto en los embeddings)
  • Aplicar lo mismo a otros datos numéricos, como precios en distintas monedas
• Ojalá llegue el día en que no haya que pensar en absoluto en los tokenizers. Que se puedan descartar por completo
• Entonces ya no haría falta lidiar con errores tipográficos, espacios en blanco arbitrarios ni ataques adversariales basados en la perplexity de palabras. Un tipo de tristeza podría desaparecer de la noche a la mañana
• Hasta entonces, tokeniza de manera responsable

Opinión de GN⁺

• Este artículo muestra bien cómo los tokenizers y los embeddings pueden afectar el rendimiento de apps de IA basadas en RAG. En especial, explica con casos reales qué hay que cuidar al tratar emojis, errores tipográficos y términos específicos de dominio, por lo que puede ser de gran ayuda para desarrolladores
• Sin embargo, tanto MiniLM-L6-v2 como tiktoken de OpenAI, presentados en este artículo, son modelos optimizados para inglés, por lo que al tratar otros idiomas, como el coreano, puede haber consideraciones adicionales. En el caso del coreano, suele usarse tokenización basada en análisis morfológico, por lo que también valdría la pena revisar sus ventajas, desventajas y limitaciones
• Además, aunque este artículo se enfoca en el papel del tokenizer y los embeddings dentro del pipeline RAG, en entornos reales de producción hay muchos más factores a considerar, como preprocesamiento de datos, ajuste de hiperparámetros y aligeramiento del modelo. Por eso, conviene tomar el contenido de este texto como punto de partida y buscar el mejor enfoque mediante distintos experimentos y evaluaciones durante el desarrollo real
• Por otro lado, también existe la opinión de que la importancia de los tokenizers está disminuyendo con la aparición de grandes modelos de lenguaje como GPT-4. Esto se debe a que estos modelos operan no a nivel de token, sino a nivel de oración o párrafo, por lo que el impacto de la calidad de cada token en el rendimiento podría ser relativamente menor. Aun así, todavía no hay suficiente investigación al respecto como para afirmarlo con certeza
• Por último, como se menciona en el artículo, solo con limpiar y estandarizar los datos de entrada por adelantado ya se puede mejorar mucho el rendimiento del modelo. Al desarrollar servicios reales, es muy importante construir un pipeline robusto de preprocesamiento de datos que tenga en cuenta la diversidad y el ruido de las entradas de usuario. Además, parece necesario invertir suficientes recursos en tareas de etiquetado y anotación para asegurar datos de entrenamiento de alta calidad

[GN⁺]

Opinión de Hacker News

• La tokenización no se considera la parte "sexy" de los LLM, pero algunos la ven como una oportunidad. Artículos como xVal proponen estrategias de especialización de la tokenización. La ortografía y las tareas a nivel de caracteres son otro problema que podría beneficiarse de innovaciones en tokenización

  • Los LLM son débiles para contar el número de caracteres de una palabra o para omitir caracteres. Por ejemplo, GPT-4o escribe y ejecuta un pequeño programa en Python para contar instancias de caracteres. La tokenización borra de forma efectiva el conocimiento sobre los caracteres del prompt y afecta directamente de manera negativa el rendimiento en estas tareas

• Hay que entender los datos para poder hacer trabajo significativo. La razón principal por la que mucha gente usa herramientas automatizadas de procesamiento de datos es porque no quiere ver los datos directamente. Quieren que la computadora pueda ver los datos y pedir recopilar información adicional

• Agradecí especialmente la parte sobre errores tipográficos en la publicación del blog. Estoy ayudando con una aplicación similar a RAG en un proyecto, y me preocupa el efecto que pequeños errores tipográficos o diferencias de formato en las consultas de los usuarios puedan tener en el cálculo de distancia de embeddings

  • Estoy pensando si deberíamos agregar errores tipográficos/sustituciones/uso de mayúsculas intencionales a los datos de entrenamiento para que aprenda que "wrk" y "work" probablemente son sinónimos

• Tengo experiencia trabajando en una app que usaba Elasticsearch para manejar la similitud entre entradas de 1-2 oraciones y documentos de más de un párrafo con consultas avanzadas de texto. Fue interesante cuánto puede influir la estrategia de tokenización en consultas específicas

  • Por ejemplo, en casos como "W-4" o "W4", la tokenización estándar puede dividir en "-" o en el límite entre letras y números. Esa entrada puede volverse completamente imposible de identificar en el índice

• Siento que en el artículo faltó discutir soluciones para cada problema. Sugiero ejecutar la corrección ortográfica antes de tokenizar, o tokenizar en paralelo la palabra mal escrita y sus posibles correcciones

  • No sé cómo resolver el problema de los nombres de marca. Este problema podría ser más grave en idiomas menos comunes o en idiomas que usan muchas palabras compuestas

• Muchos desarrolladores están acostumbrados a desarrollar en un espacio tradicional (determinista), pero no logran cambiar su forma de pensar los problemas en un espacio estadístico. Las apps con LLM son, en última instancia, un espacio estadístico

  • Como desarrollador, me cuesta explicar este problema a los usuarios

• La mayoría de quienes implementan RAG no piensan en la tokenización, sino en los embeddings

  • Dividen el corpus de datos en chunks y calculan embeddings para cada chunk. Generan una consulta y calculan embeddings para cada consulta. Clasifican los chunks del corpus por distancia respecto a la consulta. Construyen el valor de retorno
  • Este artículo resalta la importancia de trabajo oculto y relativamente mundano que puede tener un gran impacto en el rendimiento del sistema

• No puedo reproducir algunos de los números de la publicación del blog. Por ejemplo, en el código que usa SentenceTransformer, el resultado de calcular la similitud coseno entre dos oraciones es distinto de lo esperado

• He visto en varias implementaciones de RAG el problema de asumir que el documento objetivo será una buena clave de búsqueda para la consulta entrante. En un proyecto reciente, la relevancia de búsqueda mejoró mucho al separar la clave de búsqueda del valor de retorno (el documento dividido en chunks) y usar un LM para generar e insertar la clave adecuada

• Aunque se dice que muchos vocabularios de LLM grandes son bastante grandes, solo el inglés ya tiene más de un millón de palabras. Entre 30k y 300k tokens parece poco