Elasticsearch fue genial, pero las bases de datos vectoriales son el futuro
Esta publicación se publicó originalmente en The New Stack y se vuelve a publicar aquí con permiso.
Durante décadas, la coincidencia de palabras clave, también conocida como búsqueda de texto completo, ejemplificada por Elasticsearch, ha sido la opción predeterminada para sistemas de recuperación de información como la búsqueda empresarial y los motores de recomendación.
A medida que avanzan las tecnologías de búsqueda impulsadas por IA, hay un cambio hacia la búsqueda semántica, lo que permite a los sistemas comprender tanto el significado como la intención detrás de las consultas de los usuarios. Los modelos de embedding y las bases de datos vectoriales se han vuelto fundamentales para este cambio.
La búsqueda semántica supera la coincidencia de palabras clave al representar los datos como embeddings vectoriales, proporcionando una comprensión más matizada de la intención de búsqueda y transformando aplicaciones que van desde la generación aumentada por recuperación (RAG) hasta la búsqueda multimodal.
En la práctica, los sistemas eficaces de recuperación de información necesitan tanto comprensión semántica como coincidencia exacta de palabras clave. Por ejemplo, los usuarios esperan que los resultados de búsqueda muestren conceptos relacionados con sus consultas de búsqueda, al tiempo que respeten el texto literal utilizado en la consulta, como términos y nombres especiales, y devuelvan los resultados de coincidencia exacta.
Una búsqueda semántica impulsada por vectores densos ayuda a comprender el significado (como saber que ‘car’ y “automobile” son lo mismo) y la búsqueda tradicional de texto completo proporciona los resultados precisos que los usuarios esperan (como encontrar coincidencias exactas para “Python 3.9”). Como resultado, muchas organizaciones están adoptando un enfoque de búsqueda híbrida, combinando las fortalezas de ambos métodos para equilibrar la relevancia semántica flexible con la coincidencia exacta y predecible de palabras clave.
El desafío de la búsqueda híbrida
Una forma común de implementar la búsqueda híbrida es utilizar una base de datos vectorial diseñada específicamente, como Milvus de código abierto, para una búsqueda semántica eficiente y escalable, junto con motores de búsqueda tradicionales como Elasticsearch u OpenSearch para la búsqueda de texto completo.
Si bien este enfoque puede producir buenos resultados, también introduce una nueva capa de complejidad. Gestionar dos sistemas de búsqueda distintos significa lidiar con infraestructuras, configuraciones y tareas de mantenimiento separadas, lo que crea una carga operativa más pesada y aumenta la posibilidad de posibles problemas de integración.
Elasticsearch vs Milvus en la búsqueda híbrida
Figura: Elasticsearch vs Milvus en la búsqueda híbrida
Una solución unificada para la búsqueda híbrida proporcionaría muchos beneficios:
Mantenimiento de infraestructura reducido: Gestionar un sistema en lugar de dos reduce drásticamente la complejidad operativa, ahorrando tanto tiempo como recursos. Esto también significa menos cambios de contexto y carga mental para dominar dos conjuntos diferentes de APIs.
Gestión de datos consolidada: Una estructura de tabla unificada permite almacenar datos tanto densos (basados en vectores) como dispersos (basados en palabras clave) junto con etiquetas de metadatos compartidas. Usar dos sistemas separados requeriría almacenar las etiquetas de metadatos dos veces para que ambos lados puedan realizar filtrado de metadatos.
Consulta optimizada: Una sola solicitud puede llevar a cabo tanto tareas de búsqueda semántica como de texto completo, eliminando la necesidad de realizar dos llamadas API a sistemas separados.
Seguridad y control de acceso mejorados: Un enfoque unificado permite una gestión de seguridad más sencilla y robusta, ya que todos los controles de acceso pueden administrarse de forma centralizada dentro de una base de datos vectorial, lo que mejora el cumplimiento y la coherencia en materia de seguridad.
Cómo un enfoque vectorial unificado simplifica la búsqueda híbrida
En la búsqueda semántica, los modelos de aprendizaje automático “incrustan” el texto como puntos, conocidos como vectores densos, en un espacio de alta dimensión según su significado. Los textos con semánticas similares están más cerca entre sí en este espacio. Por ejemplo, “manzana” y “fruta” podrían estar más cerca en este espacio que “manzana” y “coche.” Esto nos permite encontrar rápidamente texto relacionado semánticamente con solo calcular la distancia entre cada punto mediante algoritmos de vecinos más cercanos aproximados (ANN).
Este método también puede aplicarse a la búsqueda de texto completo codificando documentos y consultas como vectores dispersos. En los vectores dispersos, cada dimensión representa un término y el valor indica qué tan importante es cada término en el documento.
Los términos que no están presentes en el documento tienen un valor de cero. Dado que cualquier documento determinado suele usar solo una pequeña parte de todos los términos posibles del vocabulario, la mayoría de los términos no aparecerán en el documento. Esto significa que los vectores resultantes son dispersos: la mayoría de sus valores son cero. Por ejemplo, en el conjunto de datos MS-MARCO, comúnmente utilizado para evaluar tareas de recuperación de información, aunque hay alrededor de 9 millones de documentos y un millón de términos únicos, un sistema de búsqueda suele dividir esta gran colección en segmentos más pequeños para facilitar su gestión.
Incluso a nivel de segmento, con cientos de miles de términos en su vocabulario, cada documento suele contener menos de 100 términos, lo que significa que más del 99 % de los valores de cada vector son cero. Esta dispersión extrema tiene implicaciones importantes para la forma en que almacenamos y procesamos estos vectores de manera eficiente.
Este patrón de dispersión puede aprovecharse para optimizar el rendimiento de la búsqueda manteniendo la precisión. Las bases de datos vectoriales diseñadas originalmente para vectores densos pueden adaptarse para manejar estos vectores dispersos de manera eficiente. Por ejemplo, la base de datos vectorial de código abierto Milvus acaba de lanzar soporte nativo para búsqueda de texto completo utilizando Sparse-BM25, una implementación de vectores dispersos del algoritmo BM25 utilizado por Elasticsearch y otros sistemas de búsqueda de texto completo. Sparse-BM25 habilita la optimización basada en aproximaciones para la búsqueda de texto completo con:
Algoritmo de recuperación eficiente con poda de datos: Al aplicar una poda basada en heurísticas para descartar los documentos con los valores de vector disperso más bajos en el índice del segmento e ignorar los vectores dispersos de bajo valor en la consulta de búsqueda, una base de datos vectorial puede reducir significativamente el tamaño del índice y optimizar el rendimiento con una pérdida mínima de calidad.
Habilitación de optimizaciones de rendimiento adicionales: Representar la frecuencia de términos como un vector disperso en lugar de un índice invertido permite optimizaciones adicionales basadas en vectores. Estas incluyen:
La indexación mediante grafos se usa para una búsqueda más eficiente que los escaneos por fuerza bruta.
Cuantización de producto (PQ) / cuantización escalar (SQ) para reducir aún más la huella de memoria.
Además de estas optimizaciones, la implementación de Sparse-BM25 también hereda varias ventajas a nivel de sistema de la base de datos vectorial de alto rendimiento Milvus:
Implementación eficiente de bajo nivel y gestión de memoria: El motor central de indexación vectorial en Milvus está implementado en C++, lo que ofrece una gestión de memoria más eficiente que un sistema basado en Java como Elasticsearch. Esto por sí solo reduce la huella de memoria al ahorrar gigabytes en comparación con un enfoque basado en JVM.
Compatibilidad con MMap: De forma similar al uso que hace Elasticsearch de la caché de páginas para el almacenamiento de índices tanto en memoria como en disco, Milvus admite mapeo de memoria (MMap) para ampliar la capacidad de memoria cuando el índice supera la memoria disponible.
Por qué los stacks de búsqueda tradicionales se quedan cortos en la búsqueda vectorial
Elasticsearch fue creado para índices invertidos tradicionales, lo que hace fundamentalmente difícil optimizar toda la arquitectura para la búsqueda de vectores densos. El impacto es claro: incluso con solo 1 millón de vectores, Elasticsearch tarda 200 milisegundos (según pruebas en Elastic Cloud totalmente gestionado) en devolver el resultado de búsqueda, en comparación con 6 ms en Milvus (según pruebas en Zilliz Cloud totalmente gestionado), lo que supone una diferencia de rendimiento de más de 30 veces. El rendimiento medido en consultas por segundo (QPS) también presenta una diferencia de 3 veces, donde la instancia de mayor rendimiento en Zilliz Cloud alcanza 6000 QPS, mientras que Elastic Cloud llega como máximo a 1900 QPS. Además, Zilliz Cloud es 15 veces más rápido que Elastic Cloud al cargar los datos vectoriales y construir el índice. Esta brecha de rendimiento se amplía a escala, donde la implementación Java/JVM de Elasticsearch tiene dificultades para igualar la escalabilidad de las bases de datos vectoriales basadas en C++/Go. Además, Elasticsearch carece de funciones críticas de búsqueda vectorial, como índices basados en disco (DiskAnn, MMap), filtrado de metadatos optimizado y búsqueda por rango.
VectorDBBench Benchmarking Results.jpg
Figura: resultados de benchmarking de VectorDBBench (fuente)
Conclusión
Las bases de datos vectoriales, ejemplificadas por Milvus, están preparadas para superar a Elasticsearch como la solución unificada para la búsqueda híbrida. Al integrar la búsqueda de vectores densos con técnicas optimizadas de vectores dispersos, las bases de datos vectoriales ofrecen un rendimiento, una escalabilidad y una eficiencia superiores. Este enfoque unificado simplifica la infraestructura, reduce la huella de memoria y mejora las capacidades de búsqueda, convirtiéndolo en el futuro de las necesidades avanzadas de búsqueda. Como resultado, las bases de datos vectoriales proporcionan una solución integral que combina de forma fluida la búsqueda semántica y de texto completo, superando a los sistemas de búsqueda tradicionales como Elasticsearch.
Sigue leyendo
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
Zilliz Cloud Launches in AWS Australia, Expanding Global Reach to Australia and Neighboring Markets
We're thrilled to announce that Zilliz Cloud is now available in the AWS Sydney, Australia region (ap-southeast-2).
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.