Embeddings
Un embedding es una lista de números que representa el significado de un texto o imagen para que lo parecido quede cerca. Cómo se comparan y qué errores evitar.
¿Qué es un embedding?
Un embedding convierte algo complejo en una lista de números. Esa lista se aprende a partir de datos: un modelo ajusta sus valores para que los elementos que aparecen en contextos parecidos reciban vectores cercanos. Es la idea que John Rupert Firth resumió en 1957: una palabra se caracteriza por la compañía que tiene.
Ejemplo ilustrativo: “silla” y “taburete” quedarían más cerca entre sí que “silla” y “tormenta”. No porque alguien los haya etiquetado a mano, sino porque aparecen en contextos parecidos en los datos de entrenamiento.
Los embeddings no son el significado en sí. Son una aproximación numérica útil para comparar. Cuando esa aproximación no coincide con lo que el usuario quiere, la comparación falla.
¿Cómo se generan y qué tamaño tienen?
Un embedding lo produce un modelo de embeddings: le das un texto (o una imagen) y devuelve el vector. Hay un recorrido histórico útil de conocer:
- Embeddings de palabras. En 2013, un equipo de Google liderado por Tomas Mikolov creó word2vec, que popularizó esta técnica. Cada palabra tiene un único vector, sin importar la frase.
- Embeddings contextuales. Modelos posteriores como ELMo y BERT generan un vector distinto para cada aparición de una palabra, así que “banco” de una plaza y “banco” de dinero no tienen por qué quedar iguales.
- Otros tipos. También existen embeddings de imágenes, de grafos de conocimiento y de interacciones de usuarios, que se usan en recomendación.
El tamaño depende del modelo. Según la documentación de OpenAI, text-embedding-3-small devuelve 1536 números por defecto y text-embedding-3-large, 3072. Más números no significan “mejor” por sí solos: significan más espacio de almacenamiento y más cálculo por cada comparación.
¿Cómo se comparan dos embeddings?
La medida más común es la similitud coseno, que compara la dirección de dos vectores sin importar su longitud. Su valor va de -1 a 1, y baja a un rango de 0 a 1 cuando los componentes no pueden ser negativos. Cerca de 1, los vectores apuntan en direcciones parecidas; en 0 no hay relación; en -1 apuntan en sentidos opuestos. OpenAI recomienda la similitud coseno para sus modelos.
Ejemplo ilustrativo con solo dos dimensiones (los reales tienen cientos o miles). Con A = (3, 4), B = (4, 3) y C = (-4, 3):
| Par | Similitud coseno | Lectura |
|---|---|---|
| A y B | 0,96 | Casi la misma dirección: muy parecidos |
| A y C | 0 | Perpendiculares: sin relación |
Esto permite una operación que sirve para muchas funciones: dado el vector de una consulta, buscar los vectores más cercanos de una colección. Ese es el núcleo de la búsqueda semántica. Cuando la colección es grande, los vectores se guardan en una base de datos vectorial.
¿Por qué le importa a un diseñador?
Porque los embeddings explican comportamientos que el usuario percibe:
- Resultados “parecidos” pero no idénticos. Una búsqueda por significado puede mostrar un resultado que no contiene la palabra escrita. Eso puede ser útil o confuso, según el caso.
- Agrupación automática. Si el producto agrupa tickets, notas o diseños por similitud, la calidad de los grupos depende de los embeddings.
- Recuperación para RAG. Los fragmentos de documentos que llegan al modelo se eligen muchas veces por similitud de embeddings. Si la recuperación falla, la respuesta también.
- Recomendaciones. “Quizá te interese” suele salir de comparar vectores de elementos o de usuarios.
- Sesgos heredados. Los embeddings reflejan asociaciones presentes en los datos. Bolukbasi y colaboradores (2016) mostraron que embeddings de palabras entrenados con Google News reproducían estereotipos de género, y propusieron un método para reducirlos. Más sobre el tema en sesgos en modelos.
¿Cuándo NO conviene usarlos?
Cuando la búsqueda necesita coincidencias exactas: un número de pedido, un código de producto, un nombre propio que debe encontrarse tal cual. Ahí una búsqueda por palabras clave o un índice tradicional suele ser más fiable. Muchos productos combinan ambas: búsqueda exacta para identificadores y embeddings para lenguaje natural.
Tampoco ayudan cuando la colección es muy pequeña (por ejemplo, diez opciones de un menú): un filtro simple basta y es más fácil de explicar al usuario.
Ejemplo
Ejemplo ilustrativo: una biblioteca de componentes de diseño tiene 400 entradas con descripciones. El equipo genera un embedding por entrada. Cuando alguien escribe “botón para confirmar una acción destructiva”, el sistema devuelve “diálogo de confirmación” y “botón de peligro” aunque ninguno contenga las palabras exactas. Pero también devuelve un componente de “alerta” que el diseñador no esperaba.
Ese resultado no es un error del sistema: es una señal. Qué puede hacer el diseñador:
- Revisar las descripciones de los componentes para que digan para qué sirven, no solo cómo se ven.
- Mostrar junto al resultado una explicación breve de por qué apareció.
- Armar una lista de 20 o 30 consultas reales con la respuesta esperada y repetirla cada vez que cambie el modelo o las descripciones.
Errores comunes
- Tratar un embedding como si fuera el significado exacto del texto.
- Comparar vectores generados por modelos distintos. Cada modelo tiene su propio espacio y, a menudo, un tamaño distinto (1536 contra 3072 números, por ejemplo).
- Olvidar guardar el texto original y la referencia a la fuente.
- Evaluar la búsqueda con un par de consultas en lugar de un conjunto representativo.
- Usar embeddings para identificadores que deberían buscarse de forma exacta.
- Ignorar los sesgos del modelo en funciones que clasifican o recomiendan personas.