“Un mapa del significado donde las ideas parecidas viven cerca unas de otras.”
Los tokens: la unidad de lenguaje para un modelo
Un LLM no lee palabras. Lee tokens. Un token es un trozo de texto, normalmente una subpalabra: «hola» es un token, «increíble» son tres («in», «creí», «ble»), un emoji es uno o dos, un carácter chino es uno. La división exacta la decide un tokenizador entrenado junto al modelo.
¿Por qué subpalabras y no palabras enteras? Dos razones. (1) El vocabulario se mantiene pequeño (entre 50 000 y 100 000 tokens aproximadamente) en lugar de millones, lo que mantiene la red manejable. (2) El modelo puede tratar palabras nuevas que nunca vio durante el entrenamiento, componiéndolas a partir de piezas familiares. «Sden-izado» es nuevo, pero «sden», «iz» y «ado» están todos en el vocabulario.
Los embeddings: convertir tokens en significado
Cada token del vocabulario se asigna a un vector, una lista de, pongamos, 4096 números. Ese vector se llama el embedding del token. Se *aprende durante el entrenamiento*, no se diseña a mano. Tras el entrenamiento, las palabras parecidas acaban con vectores parecidos.
En concreto: los vectores de «rey» y «reina» están cerca. También los de «París» y «Berlín». Es célebre que se pueda hacer aritmética: vector(«rey») − vector(«hombre») + vector(«mujer») ≈ vector(«reina»). El significado se ha comprimido en geometría.
Embeddings estáticos frente a embeddings contextuales
Los primeros métodos de embedding (word2vec 2013, GloVe 2014) le daban a cada palabra *un* vector para siempre. Útil pero limitado: «banco» (de río) y «banco» (de dinero) tenían el mismo vector. Los LLM modernos usan embeddings contextuales: el vector de «banco» en «orilla del banco del río» es genuinamente distinto del de «banco» en «cuenta del banco». El vector que obtienes depende de toda la frase.
¿Cómo? El embedding inicial de un token no es más que una búsqueda en una tabla, pero luego fluye a través de capas de atención (capítulo 5) que lo *mezclan* con los embeddings de los tokens cercanos. Para cuando llega a la última capa, el vector de cada token ha absorbido información sobre su contexto. Eso es el embedding contextual en una frase.
Qué hay realmente en esos números
Cada dimensión del vector no es «la dimensión del género» ni «la dimensión de la comida». Las direcciones que portan significado no están alineadas con los ejes. Se aprenden, repartidas entre muchas dimensiones. A veces puedes encontrar direcciones interpretables como «realeza», «plural» o «ciudad capital», pero no vienen pretiquetadas. La investigación en interpretabilidad es un campo joven que intenta releer los vectores convirtiéndolos en conceptos humanos.
Los embeddings fuera de los LLM
Los embeddings no son solo un artefacto interno de los LLM; son un producto por sí mismos. Puedes llamar a una API, darle un trozo de texto y recibir de vuelta un vector de 1024 o 4096 dimensiones. Ese vector es la entrada para:
- Búsqueda semántica: «encuéntrame documentos sobre las contrataciones del cuarto trimestre» en lugar de «encaja las palabras exactas».
- RAG (generación aumentada por recuperación): encontrar los documentos adecuados y luego pasárselos al LLM.
- Agrupación: agrupar tickets de soporte por tema sin etiquetas.
- Recomendación: productos cuyo embedding está cerca de lo que le gustó al usuario.
- Detección de anomalías: señalar entradas cuyo embedding está lejos de todo lo demás.
Los embeddings resultan ser una de las aplicaciones más útiles, baratas y de menor riesgo de la tecnología LLM. Volvemos al RAG en el capítulo 7.
Una línea por cada uno
- Los modelos leen tokens, no palabras. Los precios, los límites y muchos fallos sutiles viven en esta capa.
- Cada token se asigna a un vector aprendido (embedding) de modo que los significados parecidos acaban cerca en el espacio vectorial.
- Los embeddings modernos son contextuales: la misma palabra tiene vectores distintos en frases distintas.
- Los embeddings son útiles por sí mismos: búsqueda semántica, RAG, agrupación, recomendación, detección de anomalías.
Adónde ir ahora