Prueba a buscar "auto" en una base de datos relacional. Encontrarás las filas que digan exactamente "auto"… y se te escaparán "automóvil", "vehículo" y "coche", que significan lo mismo. SQL es literal: compara texto, no ideas. Durante décadas eso bastó. Pero la IA moderna necesitaba buscar por significado, y para eso hizo falta una forma nueva de guardar datos. De ahí nacen las bases de datos vectoriales.
Recordando los embeddings
En la lección de embeddings vimos que un modelo puede convertir un texto en un vector: una lista de números —cientos o miles— donde la cercanía refleja el parecido de significado. "Perro" y "gato" quedan cerca; "perro" y "termodinámica", lejos.
Una base de datos vectorial es, en el fondo, una sola idea llevada al extremo: guardar millones de esos vectores y, dado uno nuevo, encontrar a toda velocidad los más parecidos.
Qué significa "parecido"
La cercanía entre dos vectores se mide con una fórmula. La más usada es la similitud coseno, que mira el ángulo entre ellos:
Da 1 cuando apuntan en la misma dirección (significan lo mismo), 0 cuando son perpendiculares (nada que ver) y −1 cuando son opuestos. Buscar por significado se reduce, entonces, a un problema geométrico: ¿qué vectores guardados forman el ángulo más pequeño con mi consulta?
El truco que lo hace posible: ANN
Aquí surge un problema serio. Comparar tu consulta contra cada uno de mil millones de vectores, uno por uno, es : demasiado lento para responder en tiempo real. La búsqueda exacta no escala.
La solución es rendirse un poco en la exactitud a cambio de una velocidad enorme: búsqueda aproximada de vecinos (Approximate Nearest Neighbors, ANN). En lugar de revisarlo todo, estos algoritmos —el más popular se llama HNSW— construyen de antemano un índice ingenioso (a menudo un grafo de vecindades, justo la estructura que vimos) que te lleva a los candidatos buenos saltando la inmensa mayoría. Sacrificas encontrar el vecino perfecto de vez en cuando, y a cambio respondes en milisegundos sobre miles de millones de puntos. En la práctica, ese trato casi siempre conviene.
Para qué se usan de verdad: RAG
El caso estrella hoy es RAG (Retrieval-Augmented Generation), la técnica que le da a un modelo de lenguaje acceso a información que no tenía cuando se entrenó —los documentos internos de tu empresa, por ejemplo. El baile completo es este:
- Preparación — parte tus documentos en fragmentos, conviértelos en vectores con un modelo de embeddings y guárdalos en la base vectorial.
- Consulta — cuando el usuario pregunta algo, conviertes su pregunta en un vector y recuperas los fragmentos más cercanos.
- Generación — le entregas esos fragmentos al LLM como contexto y le pides que responda basándose en ellos.
El resultado: respuestas apoyadas en tus datos reales, con fuentes, y muchísimo menos propensas a inventar. La base vectorial es, literalmente, la memoria de largo plazo del sistema.
El paisaje de herramientas
- pgvector — una extensión de PostgreSQL. Le añade vectores a la base relacional que quizás ya usas: tus tablas normales y tus embeddings conviviendo en un mismo lugar. El punto de partida más sensato.
- FAISS — la biblioteca de Meta, puramente en memoria, insuperable para experimentar rápido.
- Qdrant, Weaviate, Milvos, Pinecone — bases dedicadas, pensadas para escalar a miles de millones de vectores en producción.
Un patrón muy común es empezar con pgvector —sin sumar una pieza nueva a tu infraestructura— y migrar a una base dedicada solo cuando el volumen lo pida.
En resumen
Las bases de datos vectoriales guardan significado en forma de vectores y responden la pregunta "¿qué se parece más a esto?" a escala masiva, gracias a la búsqueda aproximada de vecinos. Son la infraestructura silenciosa detrás de la búsqueda semántica, los recomendadores y, sobre todo, de RAG. Con ellas, esta serie cierra el círculo: partimos de cómo se ordenan los datos en memoria, pasamos por cómo sobreviven en tablas, y terminamos en cómo la IA moderna los consulta por lo que significan. De aquí en adelante, cuando veas embeddings o LLM, ya sabrás dónde viven sus datos.