Cómo funciona una base de datos vectorial: embeddings, búsqueda vectorial y memoria humana
Un modelo mental basado en la memoria para la búsqueda vectorial: cómo funcionan los embeddings, la similitud, los índices de vecino más cercano y los filtros de metadatos dentro de una base de datos vectorial para RAG.
Fuentes: Your Brain Is a Vector Database. It Just Doesn’t Call Itself That.
Pueden pasar años sin pensar siquiera en un maestro de la infancia. Luego, un olor a tiza, el aroma de la cafetería escolar o una canción que solía sonar durante el viaje en autobús de regreso traen a esa persona de vuelta de inmediato y de manera vívida. Nunca se buscó ese nombre específico; apareció algo similar y el recuerdo surgió por sí solo.
Ese es el comportamiento que los sistemas de búsqueda semántica, la generación mejorada por recuperación de información (RAG) y los sistemas de recomendación basados en IA intentan reproducir, aunque de forma imperfecta pero seria, y el componente que lo hace posible es la base de datos vectorial. La recuperación por asociación constituye un buen modelo mental para explicar qué son los vectores, cómo se mide la similitud, cómo escala la búsqueda del vecino más cercano y cómo las distintas partes forman un proceso de recuperación de información. También señala dónde deja de ser válida esa analogía, ya que esos son precisamente los puntos en los que los sistemas en producción suelen fallar.
Almacenamiento por significado en lugar de por nombre
La memoria humana no cuenta con un índice alfabético. No existe una carpeta mental llamada “Comida” que contenga una subcarpeta “Italiana” con un archivo denominado “Pizza”. Esa estricta jerarquía es la forma en que una base de datos convencional organiza los datos: cada registro se encuentra en una dirección conocida y se accede a él mediante una clave exacta.
En cambio, la memoria se organiza por significado y asociación: por contexto, por sensaciones, por la forma en que una cosa se relaciona con otras. La idea de la pizza está vinculada a las noches de viernes, a un viaje a Nápoles, a la comida reconfortante, a las tiras de queso, al aroma del orégano y, quizás, a un compañero de cuarto en la universidad que arruinó todas las tandas de masa casera. Pensar en pizza no abre un único archivo; activa todo un conjunto de recuerdos relacionados, comenzando por los más fuertemente vinculados.
Una base de datos vectorial utiliza exactamente este principio. Los elementos se almacenan según su significado y se recuperan en función de cuán similares son a la solicitud, y no porque una clave coincida al cien por ciento.
Qué codifica un vector de embedding
Para comprender la base de datos primero es necesario entender qué contiene. Un vector, en este contexto, es simplemente una lista ordenada de números que representa un significado.
Una máquina no tiene una comprensión real de qué es la pizza. Lo que un modelo de embedding puede aprender, al procesar enormes cantidades de texto, es la asociación que tiene una palabra. “Pizza” aparece cerca de “queso”, “italiano”, “masa”, “horno” y “rebanada”. Esos términos están relacionados con “pizza”, pero difieren de los términos asociados a “sushi”, aunque tienen muchas similitudes con los términos relacionados a “pan plano” o “calzone”.
El modelo condensa esos patrones en una lista de números de longitud fija, que suele contener de unos cientos a un par de miles de valores; 384 y 1,536 son tamaños típicos. Ningún número en particular lleva una etiqueta legible, pero juntos permiten posicionar el elemento con precisión en un espacio de alta dimensión. La propiedad importante es la siguiente: las entradas con significados similares terminan con vectores que se encuentran cerca unos de otros. “Pizza” queda cerca de “pan plano” y muy lejos de “informe de ganancias trimestrales”.
En otras palabras, el significado se convierte en distancia. Todo lo demás deriva de ese único paso.
Similitud como un espectro, no como una coincidencia
Una consulta tradicional es binaria: una fila satisface la condición o no la satisface. Al filtrar por “perro”, se obtienen filas que contienen exactamente “perro”, sin nada relacionado con “cachorro”, “golden retriever” o “compañero de cuatro patas leal”.
La similitud semántica reemplaza esa respuesta de sí o no por una puntuación que indica cuán similares son dos significados. En una escala ilustrativa, “cachorro” podría obtener una puntuación de 0.94 frente a “perro”, “lobo” algo como 0.71, y “factura” alrededor de 0.08. La métrica suele ser la similitud coseno o una distancia relacionada como el producto escalar o la distancia euclidiana, y la elección adecuada depende de cómo se entrenó el modelo de embedding.
Esto refleja el efecto del polvo de tiza: no se trata de una coincidencia exacta, sino de un indicio que activa recuerdos cercanos, los cuales a su vez activan a los vecinos. En una base de datos vectorial, la mecánica es numérica. La consulta se convierte en un vector, y la base de datos devuelve los elementos almacenados cuyos vectores están más cerca de él. “Cerca” significa similar en significado.
Por eso, una búsqueda de “¿cómo soluciono una consulta lenta en una base de datos?” puede mostrar un documento titulado “Optimización del rendimiento de las consultas a gran escala”, aunque las dos frases apenas compartan palabra alguna. Sus vectores están cerca porque expresan la misma intención.
Una advertencia sobre los números
Las puntuaciones de similitud son relativas, no absolutas. Un valor de 0.8 de un modelo de embedding no es comparable con un 0.8 de otro, e incluso dentro de un mismo modelo el rango típico depende del dominio. Considere las puntuaciones como una forma de clasificar candidatos, y si aplica un umbral, cámbielo según sus propios datos en lugar de elegir un número redondo.
Una corrección relacionada: el SQL basado únicamente en palabras clave no puede expresar similitud semántica, pero eso no significa que las bases de datos SQL estén excluidas. Extensiones como pgvector, que se explican a continuación, añaden columnas vectoriales y operadores de similitud a Postgres, de modo que esta capacidad puede existir dentro de una base de datos relacional.
Búsqueda de vecino más cercano a gran escala
¿Cómo localiza realmente la base de datos los vectores más cercanos? La operación principal se denomina búsqueda de vecino más cercano, y hacerla rápida es la razón principal por la que existen las bases de datos vectoriales.
Imagínese cada elemento almacenado como una estrella en una galaxia, dispuesta según su significado, con elementos relacionados agrupados en la misma región. Una consulta introduce una nueva estrella en esa galaxia y pregunta cuáles son las cinco estrellas existentes más cercanas.
El enfoque ingenuo mide la distancia desde la consulta hasta cada vector almacenado, ordena los resultados y devuelve los mejores. Para miles de vectores, esto es rápido y perfectamente adecuado. Pero para millones o miles de millones, comparar con todo se vuelve extremadamente costoso muy rápidamente.
Por lo tanto, los sistemas de producción dependen de algoritmos de vecino más cercano aproximado (ANN). En lugar de visitar cada estrella, utilizan un índice que reduce la búsqueda a regiones prometedoras, aceptando una pequeña pérdida en precisión a cambio de una gran ganancia en velocidad. El algoritmo más utilizado hoy en día es HNSW, abreviatura de Hierarchical Navigable Small World. No es necesario conocer su funcionamiento interno para usar una base de datos vectorial, pero debe saberse que es la razón por la cual una búsqueda entre cien millones de embeddings puede completarse en milisegundos.
La expresión “aproximado” merece atención. Un índice de redes neuronales artificiales puede omitir ocasionalmente al verdadero vecino más cercano, y la tasa con la que encuentra los resultados reales más relevantes, denominada precisión de recuperación, depende de los parámetros del índice que equilibran la memoria y la latencia con la precisión. Si la calidad de la recuperación parece inexplicablemente irregular a gran escala, vale la pena revisar la configuración del índice; nuestra guía sobre ajustar índices HNSW para RAG en producción aborda en profundidad esos parámetros.
Dentro de la base de datos vectorial
En esencia, una base de datos vectorial es un almacenamiento optimizado para una única tarea: conservar vectores y realizar búsquedas de vecino más cercano sobre ellos de manera muy rápida.
Imagínese una biblioteca que ignora el Sistema Decimal de Dewey y organiza los libros según su “sentimiento”. Los libros sobre el duelo están junto a los sobre la pérdida, estos a su vez junto a los sobre la soledad, luego el aislamiento, y finalmente los relatos de expediciones en solitario. Nadie asignó manualmente esas categorías; el orden surgió porque los lectores atraídos por uno suelen querer también los demás.
Pinecone, Weaviate, Chroma y Qdrant son ejemplos de esa biblioteca. Se les carga con incrustaciones de documentos, descripciones de productos, imágenes convertidas en vectores o patrones de comportamiento de usuarios, y ellos mantienen el índice para que las búsquedas sigan siendo rápidas a medida que la colección crece.
Cada registro almacenado generalmente tiene tres partes:
- Un ID que identifica de forma única el elemento.
- El vector que representa su significado.
- Metadatos opcionales como título, fecha, categoría o URL de origen, que pueden utilizarse para filtrar resultados.
Los metadatos son más valiosos de lo que parecen a primera vista. Una solicitud realista sería algo así: encontrar los cinco documentos más similares a la consulta, pero solo aquellos de los últimos 30 días y únicamente de la base de conocimientos del equipo de ingeniería. Eso es una búsqueda vectorial combinada con un filtro de metadatos, y la mayoría de los sistemas en producción dependen de esta combinación. También es importante cómo se aplica el filtro: filtrar después de la búsqueda de similitud puede dejarle con menos resultados de los que solicitó, así que verifique si su base de datos filtra durante la búsqueda en sí.
El pipeline de recuperación RAG de principio a fin
Ya sea que esté dentro de un sistema RAG, una función de búsqueda semántica o cualquier aplicación que utilice conocimientos almacenados, la recuperación sigue los mismos cuatro pasos.
- Incrustar el contenido. Cada documento, artículo, descripción de producto o registro que se desee que sea buscable pasa por un modelo de incrustación, y el vector resultante se almacena junto con el contenido original. Los documentos largos suelen dividirse primero en fragmentos, ya que un único vector para todo un manual mezcla demasiadas ideas entre sí.
- Incrustar la consulta con el mismo modelo. Esto no es opcional. Diferentes modelos de incrustación generan vectores en espacios no relacionados, por lo que comparar una consulta de un modelo con documentos de otro da como resultado distancias sin sentido. Cambiar de modelo implica volver a incrustar toda la colección.
- Buscar. El vector de la consulta se envía a la base de datos, la búsqueda de vecinos más cercanos encuentra los vectores almacenados más próximos, y se devuelven los resultados principales, generalmente junto con puntuaciones de similitud.
Desde el punto de vista del usuario, una respuesta relevante aparece en cuestión de momentos. Bajo este proceso, el significado se convierte en números, esos números se comparan con millones de elementos almacenados, se devuelven las coincidencias más cercanas y se genera una respuesta a partir de contenido real.
Por qué la búsqueda vectorial está en todas partes ahora
Hace poco, las bases de datos vectoriales eran una herramienta de nicho que solo se utilizaba al desarrollar búsquedas semánticas o sistemas de recomendación especializados. Actualmente, forman parte estándar de muchas aplicaciones de inteligencia artificial. RAG necesita un lugar donde almacenar y consultar las incrustaciones de documentos. Los agentes consultan bases de conocimiento por su significado. Las recomendaciones a gran escala se basan en la similitud vectorial. La búsqueda multimodal, como encontrar imágenes a partir de una descripción de texto o productos a partir de una foto subida, también funciona mediante vectores.
Si está desarrollando aplicaciones basadas en modelos de lenguaje grande en entornos de producción, es muy probable que ya dependa de la búsqueda vectorial o que lo haga pronto. Lo alentador es que la idea central ya es familiar: desde que existimos, la memoria ha estado recuperando las asociaciones más cercanas a todo lo que llega a nuestros sentidos. Una base de datos vectorial hace lo mismo con números, en milisegundos, con millones de elementos.
Donde falla la analogía con la memoria
La comparación con el cerebro es útil para la intuición, pero hay algunas diferencias importantes en la práctica:
- La memoria se adapta continuamente; un modelo de embedding está congelado. Si el vocabulario de tu dominio cambia, los vectores no se actualizan por sí solos.
- La memoria combina el contexto sin esfuerzo; un vector solo captura lo que se le ha proporcionado. Un texto de origen mal dividido o con ruido genera vecinos de mala calidad.
- La similitud no equivale a relevancia. Dos pasajes pueden ser similares en significado, pero solo uno responde realmente a la pregunta, por lo que muchos sistemas añaden búsquedas por palabras clave o un paso de reclasificación adicional.
Poniéndose manos a la obra
Puedes experimentar sin necesidad de crear ninguna infraestructura:
- ChromaDB funciona localmente dentro de Python sin necesidad de cuenta, clave API ni despliegue, y solo requiere unas pocas líneas de código para instalarse e inicializarse. Es adecuado para el aprendizaje y proyectos pequeños.
- Qdrant ofrece un nivel gratuito en la nube y un cliente en Python bien estructurado, ideal cuando se desea algo cercano a un entorno de producción sin tener que gestionar servidores uno mismo. Verifique los límites actuales del plan antes de confiar en ellos.
- pgvector es una extensión para Postgres. Si ya utiliza Postgres, esta extensión agrega la búsqueda vectorial sin introducir una base de datos separada, lo que mantiene la arquitectura simple.
Sea cual sea la opción que elija, el flujo de trabajo es idéntico: elige un modelo de embedding, incrusta su contenido, almacena los vectores, incrusta las consultas recibidas y realiza la búsqueda. Los conceptos permanecen los mismos; solo cambia la biblioteca cliente.
El modelo mental en pocas líneas
- Un embedding convierte el significado en una posición, de modo que los elementos similares terminan cerca uno del otro.
- Las puntuaciones de similitud clasifican a los candidatos; calibre cualquier umbral con sus propios datos.
- Los índices ANN como HNSW sacrifican un poco de precisión en la recuperación a cambio de grandes ganancias de velocidad a gran escala.
- Los filtros de metadatos convierten la similitud bruta en respuestas que respetan las reglas de tiempo, origen y acceso.
- Las consultas y los documentos deben compartir un mismo modelo de embedding, y la calidad de la recuperación depende tanto del particionamiento y de la calidad de los datos como de la base de datos.
Leer más
- Cómo realmente funcionan las bases de datos vectoriales: desde los embeddings hasta la búsqueda híbrida: Explica cómo los embeddings codifican el significado, cómo escalan la búsqueda y el indexado por similitud, y cuándo la búsqueda híbrida y las bases de datos vectoriales son adecuadas para los sistemas de IA empresariales.