No hace falta entender álgebra lineal para usar embeddings bien. Hace falta entender qué representan y, sobre todo, qué no representan. La mayoría de los errores que veo al usarlos no son matemáticos, son conceptuales.

Qué es en realidad un embedding

Un embedding es una lista de números, un vector, que representa un texto (o una imagen, o un audio) de forma que ese vector captura algo del significado del contenido original. Dos textos con significado parecido producen vectores que están cerca entre sí en ese espacio. Dos textos sin relación producen vectores lejanos.

Eso es todo lo que hay que entender a nivel conceptual. El modelo que genera el embedding ha aprendido, durante su entrenamiento, a colocar contenido parecido en zonas cercanas de ese espacio de muchas dimensiones. No hay que interpretar qué significa cada número individual del vector, igual que no interpretas cada píxel de una foto por separado para entender qué muestra.

Por qué "cerca" significa "parecido"

La forma habitual de medir esa cercanía es la similitud de coseno: mide el ángulo entre dos vectores, no su distancia en línea recta. Cuanto más pequeño el ángulo, más parecidos son los significados que representan.

Esto es lo que permite la búsqueda semántica: en vez de buscar coincidencias exactas de palabras, como haría un buscador de texto clásico, buscas vectores cercanos al vector de tu consulta. Por eso una búsqueda con embeddings encuentra "cómo reducir el consumo de batería" aunque el documento diga "optimizar la duración de la batería": las palabras no coinciden, el significado sí, y por tanto los vectores están cerca.

Para qué se usan de verdad, más allá de RAG

RAG es el uso más mencionado ahora mismo, pero no es el único:

  • Deduplicación de contenido. Detectar textos que dicen lo mismo con palabras distintas, algo que una comparación de texto literal no pilla.
  • Clustering. Agrupar documentos o mensajes por tema sin tener que definir las categorías de antemano.
  • Recomendación. Encontrar contenido "parecido a este" basándose en significado, no en etiquetas manuales.
  • Detección de anomalías. Un texto cuyo embedding queda lejos de todos los demás en un conjunto suele ser, efectivamente, distinto al resto.

Errores típicos al usarlos

  • Comparar vectores de modelos distintos. El embedding de un texto generado con un modelo no es comparable con el generado con otro modelo, aunque ambos tengan el mismo número de dimensiones. Cada modelo construye su propio espacio. Mezclar embeddings de proveedores o versiones distintas en la misma búsqueda da resultados sin sentido.
  • Confundir similitud semántica con corrección factual. Que dos frases sean semánticamente cercanas no significa que una confirme la otra. "El proyecto se retrasó" y "el proyecto se adelantó" pueden tener vectores relativamente próximos porque hablan del mismo tema, no porque digan lo mismo. La similitud mide de qué habla el texto, no si es verdad ni si concuerda.
  • No normalizar antes de comparar. Dependiendo del modelo y de la métrica que uses, comparar vectores sin normalizar puede sesgar los resultados hacia textos más largos o con ciertas características léxicas, no hacia los más relevantes.
  • Asumir que más dimensiones es siempre mejor. Más dimensiones capturan más matices, pero también cuestan más en almacenamiento y en tiempo de cómputo para cada comparación. Para un proyecto pequeño, un modelo con menos dimensiones suele ser indistinguible en calidad práctica y mucho más barato de operar.

Cómo elegir uno sin volverte loco

No hace falta el modelo de embeddings "mejor del mercado" para empezar. Hace falta uno que funcione bien en el idioma de tu contenido (esto importa más de lo que parece: un modelo entrenado sobre todo con inglés puede rendir peor en español) y que sea consistente: una vez eliges uno, generas todos los embeddings de tu corpus con ese mismo modelo y no lo cambias sin regenerar todo lo anterior.

Cambiar de modelo de embeddings a mitad de proyecto no es un ajuste menor, es empezar la base de datos vectorial de cero. Merece la pena decidirlo con calma una vez, no ir probando modelos sueltos con el corpus ya construido.