Vector Database
Una base de datos que almacena texto como vectores numéricos para que puedas buscar por significado en lugar de por palabras clave exactas, que es el motor de recuperación sobre el que funcionan la mayoría de los sistemas RAG.
Una base de datos vectorial almacena embeddings: representaciones numéricas de texto (o imágenes, o audio) donde el significado similar se asigna a puntos cercanos en el espacio. En lugar de coincidir con palabras clave exactas, incrustas la consulta del usuario de la misma manera y pides a la base de datos los vectores más cercanos. Eso es búsqueda por similitud, y es lo que permite a un sistema encontrar “cómo cancelo mi plan” cuando el documento en realidad dice “procedimiento de terminación de la suscripción”.
En una canalización RAG esta es la capa de recuperación. La calidad de tus respuestas depende en gran medida de ella: buenos embeddings y buena búsqueda devuelven los fragmentos correctos para alimentar al modelo, los malos alimentan basura y el modelo resume esa basura con confianza. Por eso la recuperación, no el modelo, suele ser donde los proyectos RAG tienen éxito o fracasan.
Aquí está la parte que los proveedores se saltan: a menudo no necesitas una base de datos vectorial dedicada. Si tu corpus es pequeño (miles, no millones de fragmentos), una extensión vectorial sobre el Postgres que ya ejecutas (pgvector) es más simple, más barata y un sistema menos que operar. Si tu búsqueda es mayormente por palabras clave, la búsqueda de texto completo simple puede superar directamente a la búsqueda vectorial. Recurre a una base de datos vectorial especializada cuando la escala, la latencia o la búsqueda híbrida a gran volumen lo justifiquen de verdad, no porque esté en el diagrama de arquitectura.
Elegimos deliberadamente la opción lo bastante aburrida bajo Inteligencia Artificial, porque cada sistema adicional es una cosa más que mantener viva a las 3 de la madrugada.