Un modelo de embedding toma un fragmento de texto — una oración, un párrafo, un documento entero — y lo comprime en un vector de longitud fija de números de punto flotante, típicamente entre 384 y 4096 dimensiones. La magia está en cómo se organizan esos números: durante el entrenamiento, el modelo aprende a colocar textos semánticamente similares cerca uno del otro en este espacio de alta dimensión y a empujar textos disímiles lejos. El enfoque de entrenamiento estándar usa aprendizaje contrastivo, donde el modelo ve pares de textos que están relacionados (una pregunta y su respuesta, una oración y su paráfrasis) y aprende a minimizar la distancia entre sus vectores mientras maximiza la distancia de pares no relacionados. Modelos como bge-large-en de BAAI, text-embedding-3 de OpenAI y embed-v3 de Cohere usan esta receta general, aunque difieren en arquitectura, datos de entrenamiento y los objetivos contrastivos específicos que optimizan.
En la práctica, usas embeddings primero codificando tus documentos en vectores y almacenándolos en una base de datos vectorial como Qdrant, Pinecone, Milvus o FAISS. En el momento de la consulta, codificas la pregunta del usuario en un vector usando el mismo modelo y realizas una búsqueda de vecinos más cercanos para encontrar los vectores de documentos más similares. La métrica de distancia importa — la similitud del coseno es la más común, pero algunos modelos están entrenados para producto punto o distancia euclidiana. Algo que confunde a la gente: debes usar el mismo modelo de embedding tanto para documentos como para consultas. Los vectores de diferentes modelos viven en espacios completamente diferentes y no se pueden comparar, incluso si resulta que tienen el mismo número de dimensiones.
La dimensionalidad del vector de embedding representa una compensación entre expresividad y costo. Un vector de 1536 dimensiones puede capturar más matices que uno de 384 dimensiones, pero también cuesta cuatro veces más almacenar y buscar. Para un millón de documentos, la diferencia es decenas de gigabytes de RAM en tu base de datos vectorial versus unos pocos gigabytes. Algunos modelos más nuevos soportan embeddings Matryoshka, donde puedes truncar el vector a menos dimensiones con degradación gradual — usa las 1024 dimensiones completas para tu colección más importante y las primeras 256 para una menos crítica. La cuantización también ayuda: almacenar vectores como INT8 en lugar de float32 reduce la memoria 4x con sorprendentemente poca pérdida de precisión, razón por la cual los sistemas en producción usan cada vez más embeddings cuantizados.
Una idea errónea común es que los modelos de embedding entienden el significado como los humanos. Son muy buenos en similitud semántica superficial — sinónimos, paráfrasis, conceptos relacionados — pero pueden tener dificultades con la negación ("el restaurante no era bueno" y "el restaurante era bueno" frecuentemente terminan cerca), con relaciones lógicas complejas y con jerga específica del dominio en la que no fueron entrenados. Por eso los sistemas de retrieval-augmented generation frecuentemente combinan búsqueda vectorial con búsqueda por palabras clave (búsqueda híbrida) y usan un modelo de reranker como segundo pase para mejorar la precisión. El embedding recupera un conjunto amplio de candidatos; el reranker, que es más lento pero más preciso, los ordena por relevancia real. Hacer bien esta pipeline importa mucho más que elegir el modelo de embedding con el puntaje más alto en el leaderboard de MTEB.