Un ordenador no entiende palabras. Entiende números. Durante décadas, la forma más común de buscar información fue comparar palabras exactas: si escribía "factura" pero el documento decía "recibo", la búsqueda no encontraba nada. Los embeddings cambiaron esto al traducir el significado de palabras, frases y documentos a listas de números — vectores — que una máquina puede comparar.
Esta idea está detrás de casi todo lo que hoy llamamos inteligencia artificial aplicada: la búsqueda semántica, los asistentes que responden a partir de los documentos de la empresa, los sistemas de recomendación y la detección de contenidos parecidos. Y, cuando hay muchos vectores que comparar, entra en juego una pieza de infraestructura propia: la base de datos vectorial.
En este artículo explico, sin demasiada jerga, qué es un embedding, cómo el significado se convierte en geometría, qué distingue una base de datos vectorial de una tradicional, y dónde esto suele salir mal en la práctica.
Qué es, en realidad, un embedding
Un embedding es la representación de un fragmento de información — una palabra, una frase, un párrafo, una imagen — como un vector de números. En la práctica, es una lista de cientos o miles de valores. Un modelo entrenado para ello lee el texto y devuelve, por ejemplo, una lista como [0.021, -0.874, 0.335, ...] con cientos de valores que resumen lo que el texto "quiere decir".
Lo importante no es cada número por separado, sino la posición que el vector ocupa en un espacio con muchas dimensiones. Los textos con significados parecidos quedan cerca unos de otros; los textos sobre temas distintos quedan lejos. "Factura", "recibo" y "nota de pago" caen en el mismo vecindario, aunque no compartan una sola letra.
Cómo el significado se convierte en geometría
El modelo aprende estas representaciones a partir de enormes cantidades de texto. Al ver millones de ejemplos, nota que ciertas palabras aparecen en contextos parecidos y ajusta los vectores para reflejar esas similitudes. El resultado es un mapa en el que la distancia tiene significado: cuanto más cerca, más relacionado.
Por eso se habla de búsqueda semántica — buscar por significado y no por letras. Cuando hace una pregunta, el sistema convierte la pregunta en un vector y busca los vectores más cercanos en el espacio. No importa si usó exactamente las mismas palabras; importa si el sentido es próximo.
Búsqueda por palabras clave vs búsqueda semántica
La búsqueda clásica, por palabras clave, sigue siendo útil y rápida, sobre todo para términos exactos: un código de artículo, un nombre propio, una referencia. Pero falla cuando la misma idea puede decirse de muchas maneras. La búsqueda semántica cubre precisamente ese hueco.
- Palabras clave: encuentran coincidencias exactas, son transparentes y baratas, pero ciegas a sinónimos y reformulaciones.
- Semántica: entiende el sentido y maneja sinónimos y frases enteras, pero exige embeddings y más cálculo.
- Híbrida: en la práctica, muchas soluciones combinan ambas, usando palabras clave para precisión y vectores para cobertura.
Qué es una base de datos vectorial
Guardar diez vectores es trivial. Guardar diez millones y encontrar, en milisegundos, los más parecidos a un vector dado ya no lo es. Ese es el trabajo de una base de datos vectorial: almacenar vectores y responder rápido a la pregunta "¿cuáles son los k vectores más cercanos a este?".
Hacerlo de forma exacta, comparando con todos, sería demasiado lento a gran escala. Por eso estas bases usan índices de vecinos aproximados (ANN), que cambian algo de precisión por mucha velocidad. Estructuras como grafos de navegación (HNSW) o particiones por agrupamiento (IVF) permiten buscar solo en una fracción de los datos. Para decidir si dos vectores están "cerca", hace falta una medida: la más común es la similitud del coseno, que compara la dirección de los vectores e ignora su tamaño. Usar la métrica equivocada, o mezclar vectores de modelos distintos, produce resultados sin sentido — use siempre el mismo modelo de embeddings para indexar los documentos y para convertir las consultas.
Una base dedicada o vectores en la base que ya tiene
Hay dos grandes opciones. Las bases de datos vectoriales dedicadas se diseñaron desde cero para este problema y brillan cuando el volumen es muy grande y la latencia es crítica. Como alternativa, muchas bases de datos relacionales y motores de búsqueda ya ofrecen búsqueda vectorial como funcionalidad, lo que evita añadir otro sistema a la arquitectura.
La decisión no debe seguir la moda. Si sus datos ya viven en una base relacional y el volumen es moderado, la búsqueda vectorial integrada suele bastar y es más sencilla de mantener. Introducir un sistema nuevo solo se justifica cuando la escala y el rendimiento lo exigen.
Dónde los embeddings valen la pena
- Búsqueda interna: encontrar documentos, políticas o tickets por significado, no por palabra exacta.
- Asistentes con contexto (RAG): traer los fragmentos relevantes de una base de conocimiento para alimentar a un modelo de lenguaje antes de que responda.
- Recomendación: sugerir artículos, productos o contenidos parecidos a lo que la persona ya vio.
- Deduplicación y agrupamiento: detectar registros casi idénticos o agrupar automáticamente temas similares.
- Clasificación: encaminar una solicitud al equipo correcto según su parecido con casos anteriores.
Errores comunes a evitar
El primer error es dividir mal los documentos. Si guarda textos demasiado largos, el vector queda "diluido" y pierde precisión; si los corta demasiado, pierde contexto. El tamaño de los fragmentos merece atención y prueba.
Otros tropiezos frecuentes: mezclar embeddings de modelos distintos en el mismo índice; elegir la métrica de distancia equivocada; olvidar que los vectores envejecen — si los documentos cambian, hay que reindexar; e ignorar el coste y la latencia de generar embeddings en cada búsqueda. Por último, muchos proyectos avanzan sin ninguna forma de evaluar la calidad de los resultados, lo que hace imposible saber si un cambio mejoró o empeoró la búsqueda.
Mini-caso: de la búsqueda que no encontraba nada
Una empresa de retail con un catálogo grande recibía muchas quejas de que el buscador del sitio "no encontraba nada". Al analizar los registros, el equipo descubrió que cerca del 30% de las búsquedas terminaban sin resultados aunque el producto existía — los clientes usaban palabras distintas de las descripciones internas.
La solución fue añadir búsqueda semántica: cada producto pasó a tener un embedding de su descripción, guardado con búsqueda vectorial en la base que ya usaban, y las búsquedas se convirtieron en vectores. Mantuvieron las palabras clave para referencias exactas y combinaron ambos enfoques. En pocas semanas, las búsquedas sin resultados bajaron por debajo del 10% y la tasa de conversión desde el buscador subió de forma perceptible. El coste adicional fue modesto porque reutilizaron la infraestructura existente y solo reindexaban cuando el catálogo cambiaba.
En la práctica
Los embeddings son el puente entre el lenguaje humano y la forma en que las máquinas comparan información: convierten el significado en geometría y permiten buscar por sentido. Las bases de datos vectoriales son la infraestructura que hace viable esa comparación a gran escala. No son magia — dependen de buenas decisiones sobre división de texto, elección de modelo, métrica y evaluación.
Si está empezando, resista la tentación de montar de inmediato un sistema complejo. Empiece por un caso concreto con valor claro — una búsqueda interna, un asistente sobre documentos —, mida los resultados y use la búsqueda vectorial que su base de datos ya ofrece. Solo después, si la escala lo justifica, avance hacia soluciones dedicadas.
