Por qué no basta un LIKE: bases de datos vectoriales

Cuarta entrega de la serie. Ya tenemos los fragmentos convertidos en vectores. Falta guardarlos en algún sitio donde buscarlos por proximidad sea viable. Ese sitio no es una tabla con una columna de texto, y explicar por qué no lo es aclara bastante de lo que viene después.

El problema de la búsqueda literal

Casi cualquier sistema documental empieza con una búsqueda por palabras. En su forma más simple, un LIKE '%devolución%' sobre una columna de texto. Funciona, es exacta y no requiere ninguna infraestructura nueva. También falla de forma característica en cuanto el usuario deja de escribir con tus palabras.

Un LIKE no sabe que «devolver», «devolución» y «devuelvo» son la misma raíz. No sabe que «reembolso» y «devolución del importe» son casi lo mismo. No sabe que «me llegó roto, ¿qué hago?» es una pregunta sobre la política de devoluciones. Y a cambio de esa ignorancia devuelve cualquier documento que contenga la cadena, aunque sea en una nota al pie irrelevante. Ni recall ni precisión: sólo coincidencia de caracteres.

La búsqueda de texto completo mejora bastante ese punto de partida. Un índice invertido con análisis lingüístico aplica stemming (reducción a la raíz), elimina palabras vacías, y puntúa los documentos con una función como BM25, que premia los términos raros y penaliza los documentos largos. Es una tecnología madura, rápida y sorprendentemente buena: sigue siendo competitiva y forma parte de casi cualquier sistema RAG serio, como veremos al hablar de búsqueda híbrida.

Pero BM25 sigue siendo, en el fondo, coincidencia de términos con estadística encima. Si la pregunta y el documento no comparten ninguna palabra, la puntuación es cero. «¿Cuánto tarda en llegarme el dinero?» no encuentra «el abono se hace efectivo en un plazo de siete días hábiles», porque no hay un solo término en común más allá de las preposiciones. El usuario tiene la pregunta correcta y el corpus tiene la respuesta correcta, y el sistema no las une.

Buscar por significado

La búsqueda vectorial, o búsqueda densa, resuelve exactamente ese caso. La pregunta se convierte en un vector con el mismo modelo con el que se vectorizaron los fragmentos, y se buscan los fragmentos cuyo vector está más cerca. Como la proximidad codifica significado y no vocabulario, dos textos sin palabras en común pueden ser vecinos.

La operación central es simple de enunciar: dado un vector de consulta, devuelve los k más cercanos según una métrica de distancia. Se le llama búsqueda de vecinos más próximos, y es lo único que hace falta pedirle a la base de datos.

Lo difícil es hacerlo rápido. Calcular la distancia entre la consulta y todos los vectores del corpus —lo que se llama búsqueda exhaustiva o de fuerza bruta— es exacto pero lineal: con un millón de fragmentos de 768 dimensiones cada consulta implica del orden de mil millones de operaciones aritméticas. Para diez mil vectores eso se resuelve en milisegundos y no hace falta nada más. Para diez millones, no es viable dentro del presupuesto de latencia de una consulta interactiva.

De ahí nace la razón de ser de una base de datos vectorial: construir una estructura de índice que permita encontrar los vecinos probables sin mirarlos todos.

Qué ofrece una base vectorial además de buscar

Un motor vectorial de producción no es sólo un índice. Las piezas que lo hacen utilizable en un sistema RAG son estas.

• Almacenamiento del vector con su carga útil. Cada punto guarda el vector, el texto original del fragmento y un conjunto de metadatos arbitrarios. Sin esto tendrías que hacer una segunda consulta a otra base de datos para recuperar el texto, y ese viaje extra se paga en cada pregunta.
• Inserción, actualización y borrado por identificador. Suena trivial y no lo es: muchos índices vectoriales están optimizados para construirse una vez y consultarse muchas, y borrar de verdad —no marcar como borrado— puede exigir reconstruir el índice. Es el detalle que decide si puedes cumplir una petición de supresión de datos en minutos o en el próximo ciclo de reindexación.
• Filtrado por metadatos. Restringir la búsqueda a un subconjunto: sólo documentos de un departamento, sólo posteriores a una fecha, sólo los que el usuario tiene permiso de ver.
• Consultas por lotes. Resolver varias consultas en una sola llamada, necesario en cuanto usas técnicas que lanzan varias variantes de la misma pregunta.
• Búsqueda híbrida. Combinar puntuación densa y puntuación léxica en una sola operación. No todos los motores la ofrecen de forma nativa, y es un criterio de selección de peso.

El filtrado por metadatos merece un apartado propio

Es la funcionalidad que más se subestima al elegir motor y la que más problemas da después. El caso es siempre el mismo: quiero los cinco fragmentos más parecidos de entre los que cumplen una condición. Hay tres formas de resolverlo y no son equivalentes.

Filtrado posterior. Se buscan los k vecinos más próximos y después se descartan los que no cumplen el filtro. Es lo más fácil de implementar y lo que hace por defecto cualquier montaje casero. Su defecto es grave: si el filtro es selectivo —«sólo documentos de 2025», y 2025 es el 3% del corpus— puedes pedir diez resultados y quedarte con cero. No es que el sistema devuelva peores resultados: es que devuelve una lista vacía teniendo material relevante en el índice.

Filtrado previo. Se resuelve primero la condición y se busca sólo dentro del subconjunto. Da siempre los resultados correctos, pero si el subconjunto es grande la búsqueda vuelve a ser exhaustiva y se pierde la ventaja del índice.

Filtrado durante la búsqueda. El recorrido del índice consulta el filtro sobre la marcha y sólo considera los candidatos válidos. Es lo que implementan los motores dedicados serios, con distintos nombres, y es la única solución que mantiene a la vez la exactitud y la velocidad. Cuando en la entrega dedicada a elegir motor hablemos de criterios de selección, este será uno de los cuatro.

La consecuencia de diseño es que el esquema de metadatos hay que pensarlo antes de indexar, no después. Añadir un campo filtrable a diez millones de puntos ya indexados es, según el motor, desde una operación rutinaria hasta una reindexación completa.

El problema nuevo: la búsqueda deja de ser exacta

Aquí está el cambio conceptual que hay que asumir. Una consulta SQL con un WHERE tiene una respuesta correcta y el motor la devuelve. Si no la devuelve, hay un fallo. Una búsqueda vectorial indexada no garantiza devolver los vecinos verdaderos: devuelve unos muy probables, y la proporción de aciertos es un parámetro de configuración.

A esa proporción se le llama recall del índice: de los k vecinos que devolvería una búsqueda exhaustiva, cuántos devuelve realmente el índice. Un índice configurado con valores agresivos de velocidad puede quedarse en un recall que deja fuera resultados válidos; uno configurado con valores conservadores se acerca a la exhaustiva y tarda mucho más. Cada motor expone ese compromiso con parámetros distintos, y muchos equipos lo aceptan sin saberlo al usar los valores por defecto.

Esto tiene tres implicaciones prácticas que conviene tener claras desde el principio.

La primera es que la misma consulta puede devolver resultados distintos tras una reconstrucción del índice, aunque los datos no hayan cambiado. Los índices aproximados dependen del orden de inserción y, algunos, de decisiones aleatorias. Si tienes pruebas automáticas que comparan resultados exactos, fallarán sin que nada esté roto.

La segunda es que el recall del índice y la calidad de la recuperación son cosas distintas y hay que medirlas por separado. Un índice con recall perfecto no salva a un modelo de embeddings que coloca el fragmento correcto en el puesto cuarenta. Y al revés: puedes tener un modelo excelente y estar perdiendo resultados por una configuración de índice que nadie revisó.

La tercera es que hay un tamaño por debajo del cual todo esto sobra. Con unos pocos miles de fragmentos, la búsqueda exhaustiva es exacta, instantánea y no tiene parámetros que ajustar. Montar infraestructura vectorial dedicada para un corpus de dos mil documentos es resolver un problema que no se tiene. Un índice plano en memoria, o una extensión vectorial sobre la base de datos que ya usas, cubre el caso sobradamente.

Lo que una base vectorial no arregla

Conviene decirlo porque el mercado empuja en la dirección contraria. Cambiar de motor vectorial casi nunca mejora la calidad de las respuestas de un sistema RAG. Los motores se diferencian en escala, operativa, coste, capacidades de filtrado y madurez; no en «encontrar mejor» el fragmento relevante. Quien decide eso es el modelo de embeddings, el troceado y la estrategia de recuperación.

Tampoco resuelve el punto débil de la búsqueda densa: los identificadores exactos. Una referencia de producto, un número de expediente, un nombre propio poco frecuente o un artículo concreto de una norma se encuentran mucho mejor con búsqueda léxica que con similitud vectorial. Un sistema que sólo busca por vectores falla justo en las consultas donde el usuario ha sido más preciso, que suelen ser las más importantes. La respuesta a eso no es un motor mejor, es combinar las dos señales.

Qué viene ahora

La siguiente entrega abre el índice y mira cómo consigue no comparar la consulta con todos los vectores: qué es la búsqueda aproximada de vecinos, cómo funcionan las dos familias de índices que dominan la práctica —los grafos navegables por capas y las particiones por centroides—, qué hacen exactamente parámetros como M, ef_search o nprobe, y cómo se compra recall pagando en latencia y en memoria. Es la entrega más técnica del bloque.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.