Embeddings de texto: cómo convertir palabras en vectores útiles

Actualizado: 2026-05-03

Los embeddings son la representación numérica de texto que permite a los modelos de IA “entender” similitud semántica. Detrás de la búsqueda semántica, los sistemas de RAG, la clasificación moderna de texto y casi cualquier producto NLP actual, hay embeddings. Desglosamos qué son exactamente, cómo elegir un modelo y los casos donde realmente aportan frente a alternativas más simples.

Puntos clave

• Un embedding es un vector de N dimensiones (típicamente 384, 768 o 1536) donde textos semánticamente parecidos producen vectores cercanos medidos por distancia coseno.
• Tres familias dominan la elección práctica: OpenAI ada-002 (managed, simple), Sentence Transformers (open source, privacidad), BGE (open source, máxima calidad en inglés).
• El chunking importa más que el modelo elegido: un mal chunking es la causa número uno de RAG con bajo rendimiento.
• Los embeddings no son la herramienta correcta para búsqueda exacta ni filtrado por metadatos — para eso hay keyword search y SQL.
• La calidad del corpus y del chunking supera en impacto la diferencia entre modelos del top-3.

Qué es un embedding, de verdad

Un embedding es un vector de N dimensiones (típicamente 384, 768 o 1536) que representa el significado de un texto. La propiedad clave: textos con significado parecido producen vectores cercanos medidos por distancia coseno.

Ejemplo conceptual:

"perro" → [0.21, -0.43, 0.88, ...]
"can"   → [0.19, -0.41, 0.86, ...]    # cercano
"coche" → [-0.55, 0.71, 0.04, ...]    # lejano

Los modelos que generan embeddings son redes neuronales entrenadas en grandes corpus para que esta propiedad se cumpla. Hoy hay docenas, con trade-offs distintos en calidad, dimensión, velocidad y coste.

Modelos relevantes

Tres familias dominan la elección práctica:

OpenAI Embeddings (text-embedding-ada-002)

• Dimensión: 1536.
• API gestionada: simple, sin infraestructura, paga por token.
• Coste: alrededor de $0.10 por millón de tokens — muy bajo.
• Calidad: buena para casos generales en inglés y razonable en multilingüe.
• Lock-in: no puedes ejecutarlo localmente; los datos pasan por OpenAI.

Es el “default razonable” si no quieres pensar en infra ni en modelos. Para muchos proyectos pequeños y medianos, es la elección sensata.

Sentence Transformers (all-MiniLM, all-mpnet, etc.)

• Open source, descargables de Hugging Face^[1].
• Dimensión: 384 (MiniLM) o 768 (mpnet) típicamente.
• Velocidad: MiniLM es muy rápido; mpnet más lento pero mejor calidad.
• Coste: la inferencia es local, pagas solo el cómputo (CPU funciona, GPU acelera).
• Privacidad: nada sale de tu infra.

Excelente cuando la privacidad importa o quieres evitar dependencia de un proveedor externo.

Modelos BGE (BAAI General Embedding)

• bge-large-en-v1.5 y bge-base-en-v1.5 publicados por la Beijing Academy of AI.
• Liderato actual en benchmarks de retrieval (MTEB) en inglés.
• Open source, ejecutables localmente.
• Dimensión: 1024 (large) o 768 (base).

Si te importa la máxima calidad en retrieval y puedes ejecutar modelos de 1-2 GB localmente, BGE es probablemente la mejor opción gratuita.

Cómo elegir entre ellos

Un árbol de decisión razonable:

• Privacidad crítica o coste API es problema → Sentence Transformers o BGE local.
• Inglés exclusivo, máxima calidad → BGE o E5.
• Multilingüe (ES, EN, FR…) y simplicidad → OpenAI ada-002 o multilingual-e5-base.
• Velocidad por encima de todo → MiniLM (encoder en CPU funciona razonable).
• No quieres pensar en infra → OpenAI ada-002.

La diferencia de calidad entre los top-3 es notable en benchmarks pero menor de lo que uno espera en aplicaciones reales — la calidad del corpus y del chunking suele importar más que la diferencia entre modelos del top.

Casos de uso donde aportan

Los casos donde embeddings son la herramienta correcta:

• Búsqueda semántica. “Encuentra documentos que hablen de X” donde X puede expresarse de muchas formas. Mucho mejor que keyword search cuando los usuarios no usan los términos exactos del corpus.
• RAG. Recuperar contexto relevante para un LLM antes de generar respuesta. La pieza central del 90% de productos LLM-aplicados. Ver también Chroma y pgvector como opciones de almacenamiento.
• Clasificación zero-shot o few-shot. Categorizar textos sin entrenar un clasificador clásico — embedding del texto + similaridad a etiquetas embebidas.
• Detección de duplicados o casi-duplicados. Encontrar contenido similar (productos en catálogo, posts de blog, FAQ).
• Recomendación basada en contenido. “Otros artículos relacionados” basándose en similitud del texto, no en historial de clicks.
• Detección de anomalías textuales. Identificar texto que se aleja del patrón típico del corpus.

Casos donde no son la mejor opción

A veces se aplican embeddings por defecto cuando otra cosa funcionaría mejor:

• Búsqueda de coincidencia exacta. “Quiero documentos con esta palabra exacta” → keyword search (Elasticsearch BM25, Postgres FTS) es mejor.
• Filtrado por metadatos estrictos. “Posts del autor X publicados en 2022” → SQL o un índice tradicional.
• Corpus pequeño (<200 documentos) → puedes simplemente meter todos en el prompt del LLM (si caben) y saltarte la BD vectorial.
• Búsqueda híbrida con filtros complejos → mejor una BD vectorial con filtros nativos (Weaviate, Qdrant) que un sistema casero.

El detalle del chunking

Para embeddings de documentos largos, no embebes el documento entero — lo partes en chunks. Decisiones que importan:

• Tamaño: 200-500 tokens por chunk es un rango típico. Demasiado pequeño pierde contexto; demasiado grande diluye la señal.
• Solape: 10-20% de tokens compartidos entre chunks consecutivos para no cortar conceptos a medias.
• Estructura: respetar headers, párrafos y tablas si es posible. Cortar en mitad de una tabla genera chunks sin sentido.

Un mal chunking es la causa número uno de RAG con bajo rendimiento — más que la elección del modelo de embedding. Esta es la razón por la que frameworks como LangChain incluyen splitters configurables como RecursiveCharacterTextSplitter.

Conclusión

Los embeddings son la pieza más versátil del toolkit moderno de NLP. La elección de modelo importa menos de lo que parece para muchos casos; lo que más impacta es cómo procesas el texto antes (chunking, normalización) y qué haces con los vectores después (búsqueda, ranking, filtros). Empieza con la opción más simple que cumpla tus restricciones de privacidad y coste, mide, y migra solo cuando sea necesario.

1. Hugging Face