Machine Learning Mastery: por qué un vector store no es suficiente para aplicaciones de IA

Machine Learning Mastery analizó un error común en la arquitectura de aplicaciones de IA: tratar un vector store como una base de datos completa para todo el producto. En la etapa de demo, esto a menudo es suficiente, pero en producción, junto con la búsqueda vectorial, casi siempre se necesita una capa relacional clásica.

Dónde destaca el vector store

Las bases de datos vectoriales se han convertido en un componente estándar de sistemas RAG porque resuelven un problema que SQL ordinario maneja mal: búsqueda por significado, no por coincidencia exacta de palabras. Cuando un usuario hace una pregunta, el sistema la convierte en un embedding y busca los fragmentos de documento más cercanos semánticamente. Esto permite que la IA encuentre textos relevantes incluso cuando no contienen la misma formulación que la consulta.

Esto es especialmente útil con datos no estructurados — documentos internos, correspondencia, PDFs y bases de conocimiento. Si alguien pregunta sobre derechos del inquilino cuando hay moho en un apartamento, la búsqueda vectorial encontrará secciones sobre estándares de vivienda u obligaciones del propietario, incluso si la frase "condiciones de vida peligrosas" no aparece en el documento. Este enfoque maneja mejor errores tipográficos, paráfrasis y contexto implícito.

Por eso el vector store se convirtió en el componente básico de la búsqueda de IA donde las formulaciones casi nunca coinciden palabra por palabra.

Dónde se necesita SQL

El problema es que la flexibilidad de la búsqueda vectorial simultáneamente la convierte en una herramienta imprecisa para tareas operacionales. Responde bien a "qué es semánticamente similar", pero no funciona donde necesitas una respuesta rigurosa sin probabilidades y tolerancias. Una vez que aparecen usuarios, límites, pagos y estados de objetos en un producto, la búsqueda aproximada comienza a obstaculizar en lugar de ayudar. Por eso en un sistema de producción, una base de datos relacional sigue siendo el lugar donde viven todos los "hechos duros":

• derechos de acceso y límites de tenant, donde un error se convierte en una fuga de datos;
• metadatos de documentos — autor, URL, fecha de carga, hash de archivo, estado de publicación;
• facturación, auditoría, logs y cualquier registro que deba ser consistente;
• estado de la aplicación: si un chat está archivado, si un flag está habilitado, qué plan tiene el usuario.

También hay otro aspecto práctico: el filtrado SQL preciso reduce alucinaciones del modelo. Si la IA debe resumir solo tickets de alta prioridad cerrados en los últimos 7 días por el equipo de frontend, primero necesitas seleccionar estrictamente exactamente esos registros, y solo entonces pasar su texto al modelo. Esto es más barato, más rápido y más seguro que confiar en que la búsqueda vectorial sola devolverá aleatoriamente el conjunto de datos perfectamente limitado. Esencialmente, SQL aquí no compite con el LLM, sino que prepara el área de trabajo correcta para él.

Esquema híbrido

El autor propone no elegir entre los dos enfoques, sino combinarlos en una única capa de datos. Un escenario típico se ve así: primero, la base de datos relacional verifica el usuario, su rol y la lista de documentos a los que tiene acceso, y solo entonces el vector store busca coincidencias semánticas dentro de este subconjunto seguro. Para asistentes de IA corporativos, esto no es una optimización, sino un límite de seguridad.

Sin tal filtrado preliminar, el sistema corre el riesgo de mostrar a los usuarios datos de otro equipo o incluso de otro cliente. El patrón inverso también funciona. Después de que la búsqueda vectorial devuelve fragmentos relevantes, la aplicación puede extraer metadatos de SQL: quién autorizó el documento, cuándo se actualizó, qué estado de confianza tiene.

Entonces el modelo responde no abstractamente, sino con contexto — por ejemplo, vinculado a la actualidad del documento o al departamento que lo emitió. Para bases de conocimiento internas y agentes de soporte, esto notablemente aumenta la confianza en la respuesta y ayuda a los usuarios a verificar rápidamente su origen.

Para equipos que no quieren mantener dos bases de datos diferentes, Machine Learning Mastery destaca específicamente pgvector — una extensión de PostgreSQL para búsqueda por similitud. En esta variante, los embeddings viven junto a campos estructurados, y una única consulta puede simultáneamente verificar permisos, filtrar registros por fecha y estado, y luego clasificarlos por proximidad semántica. El tradeoff es simple: a escala moderada, esto notablemente simplifica la infraestructura, pero a volúmenes de miles de millones de vectores, sistemas especializados como Pinecone o Milvus siguen siendo más rápidos. Sin embargo, para cientos de miles o algunos millones de vectores, este enfoque a menudo resulta ser el punto de partida más pragmático.

Qué significa esto

La conclusión principal es simple: vector store es una parte importante de la pila de IA, pero no un reemplazo completo para ella. Si tu producto trabaja con usuarios, controles de acceso, pagos y estado del sistema, no puedes prescindir de una base de datos relacional. Para la mayoría de equipos, un inicio razonable es PostgreSQL con pgvector o una combinación de SQL más una base de datos vectorial separada, donde cada tecnología maneja solo la clase de tareas que resuelve mejor. Cuanto más temprano aparezca esta separación en la arquitectura, menos posibilidades hay de que la versión demo se desmorone en el primer crecimiento real.