Cómo Zilliz vio el futuro de las bases de datos vectoriales y las diseñó para producción
Esta publicación es un resumen del podcast con Innovator Coffee y James Luan, vicepresidente de Ingeniería en Zilliz.
Antes de que la IA generativa se volviera masiva, las bases de datos vectoriales rara vez se discutían por sí solas. La mayor parte de la atención seguía centrada en las bases de datos relacionales, los motores de búsqueda o los frameworks de big data. La búsqueda vectorial, si llegaba a mencionarse, normalmente aparecía en artículos de investigación o dentro de bibliotecas de algoritmos, no en conversaciones sobre sistemas de producción.
Pero las bases de datos vectoriales no surgieron de la nada. Nacieron de un cambio más profundo en la forma en que se crean y utilizan los datos. Alrededor de 2017–2018, los equipos de Zilliz comenzaron a ver aparecer el mismo problema: las empresas querían trabajar con muchos más datos no estructurados —texto, imágenes, audio, logs, comportamiento de usuarios—, pero sus herramientas existentes no estaban diseñadas para ello. Las bases de datos tradicionales y la búsqueda por palabras clave podían almacenar estos datos, pero no eran buenas para comprenderlos. Manejaban bien las coincidencias exactas. El significado y la similitud eran otra historia.
Los vectores ofrecieron una forma práctica de cerrar esa brecha. Al convertir texto, imágenes y otros contenidos en embeddings, la similitud se convirtió en algo que los sistemas podían calcular directamente. Una vez que los datos se representaban de esta manera, las bases de datos ya no solo almacenaban registros. Podían recuperar información basada en el significado, no solo en palabras clave.
Por lo tanto, las bases de datos vectoriales se sitúan entre modelos potentes y datos desordenados del mundo real, haciendo que la información no estructurada sea buscable, comparable y utilizable a escala.
Entonces, ¿cómo dio la búsqueda vectorial el salto de la investigación a la producción, y hacia dónde se dirigen las bases de datos vectoriales a continuación? En un episodio reciente del podcast en inglés Innovator Coffee, James Luan, vicepresidente de Ingeniería en Zilliz, compartió su perspectiva, basándose en la historia fundacional de la empresa, el pensamiento detrás de Milvus, la base de datos vectorial de código abierto de Zilliz, y los principios de diseño que dieron forma al sistema.
De los algoritmos a la producción: la evolución de las bases de datos vectoriales
Al mirar hacia atrás a los primeros días antes de que la búsqueda vectorial estuviera lista para producción, James Luan señala que la mayor parte del progreso inicial ocurrió dentro de grandes empresas tecnológicas. Proyectos como FAISS de Meta establecieron la base técnica, pero eran bibliotecas, no bases de datos. Existían sistemas similares de búsqueda vectorial en empresas como Microsoft y Spotify, normalmente creados para uso interno y adaptados a cargas de trabajo específicas. Estas herramientas eran efectivas, pero nunca fueron diseñadas para ejecutarse como sistemas de propósito general y de larga duración.
El punto de inflexión llegó cuando la búsqueda vectorial pasó de la investigación a productos reales. Una vez que los equipos intentaron implementarla en producción, los desafíos a nivel de sistema se volvieron imposibles de ignorar. La escalabilidad, la fiabilidad y las operaciones del día a día importaban tanto como la calidad de la búsqueda. Surgieron diferentes caminos. Algunos equipos crearon servicios gestionados optimizados para inferencia en línea y una integración estrecha con grandes modelos de lenguaje. Otros adoptaron un enfoque de infraestructura más amplio, integrando la búsqueda vectorial con data lakes y bases de datos tradicionales para respaldar casos de uso a escala empresarial. En opinión de James, esta divergencia es una etapa natural en la aparición de cualquier nueva capa de infraestructura.
A medida que los grandes modelos de lenguaje maduraron y las aplicaciones llegaron a producción, el papel de las bases de datos vectoriales se expandió rápidamente. Los primeros casos de uso se centraban en la recuperación basada en similitud: sistemas de recomendación, búsqueda de imágenes y coincidencia de contenido. Durante los últimos dos o tres años, Retrieval-Augmented Generation (RAG) se ha convertido en el patrón dominante. En los sistemas RAG, las bases de datos vectoriales proporcionan a los modelos contexto relevante y fundamentado, lo que permite la recuperación de hechos y ayuda a reducir las alucinaciones.
Ese papel se vuelve aún más importante en los sistemas basados en agentes. Aquí, las bases de datos vectoriales actúan como memoria a largo plazo o casi en línea, apoyando el razonamiento de múltiples pasos, la compresión de contexto y la recuperación multimodal. James resume este cambio con un principio simple: menos estructura, más inteligencia. A medida que mejoran las capacidades de los modelos, los pipelines rígidos y el etiquetado inicial pesado pueden frenar los sistemas. Los agentes funcionan mejor cuando operan en un espacio semántico flexible y deciden dinámicamente cómo recuperar y combinar información.
Al mismo tiempo, James enfatiza que las bases de datos vectoriales no son magia. La calidad de la recuperación depende tanto de la gobernanza de datos como de los algoritmos. Los datos bien curados y relevantes para el dominio —y la evaluación continua— son esenciales. Los modelos de embedding, los rerankers y las estrategias de recuperación evolucionan rápidamente, y los equipos que pasan demasiado tiempo sin reevaluar su stack a menudo se quedan atrás.
Más allá de la inferencia, James ve que las bases de datos vectoriales desempeñan un papel cada vez mayor en el entrenamiento y la preparación de datos. A medida que los modelos multimodales se vuelven más comunes, la búsqueda vectorial se utiliza cada vez más para limpiar, deduplicar y curar grandes conjuntos de datos de texto, imágenes, video y PDFs. Con el tiempo, esto puede converger con los data lakes en una arquitectura de “vector lake”, conectando el procesamiento de datos por lotes con la inferencia en línea.
En esa visión a más largo plazo, las bases de datos vectoriales ya no son solo motores de recuperación. Se convierten en una capa semántica que abarca el entrenamiento, la inferencia y la gobernanza de datos a largo plazo, apoyando todo el ciclo de vida de los sistemas de IA.
Cómo Zilliz encontró su dirección antes de que las bases de datos vectoriales se volvieran mainstream
James describe los primeros días de Zilliz como un período de exploración más que de claridad inmediata. Tanto él como el CEO de la empresa provenían de entornos de bases de datos tradicionales, tras haber pasado años construyendo sistemas transaccionales en Oracle. Desde el principio, sabían que no querían construir otra base de datos convencional, pero cuál debía ser esa alternativa seguía siendo una pregunta abierta.
Su primer intento fue una base de datos acelerada por GPU orientada a acelerar el procesamiento de datos a gran escala mediante hardware especializado. Técnicamente, funcionó. Comercialmente, no. Las GPUs ofrecían un rendimiento sólido, pero eran caras, y para la mayoría de las cargas de trabajo del mundo real, la relación costo–rendimiento era difícil de justificar. Al mismo tiempo, los sistemas basados en CPU como ClickHouse mejoraban rápidamente, cerrando gran parte de la brecha de rendimiento a una fracción del costo.
Esa experiencia obligó a un replanteamiento más profundo. En lugar de preguntarse cómo hacer que las bases de datos fueran más rápidas, el equipo empezó a plantearse una pregunta diferente: ¿qué tipos de datos seguían estando mal atendidos? Las cargas de trabajo tradicionales de analítica y transaccionales ya contaban con soluciones maduras. Lo que destacaba eran los datos no estructurados: texto, imágenes y otros contenidos que los usuarios querían cada vez más buscar y comprender, no solo almacenar.
El punto de inflexión llegó a través de los comentarios de los usuarios. Algunos de los primeros usuarios preguntaron si el sistema podía usarse para acelerar la búsqueda de imágenes. Esa pregunta apuntó a una oportunidad más amplia: la similitud semántica a escala, habilitada por representaciones vectoriales. El equipo se dio cuenta de que los vectores —no las GPUs— eran la abstracción más fundamental. A partir de esa idea, Milvus nació como un proyecto de código abierto centrado en la búsqueda vectorial a gran escala.
James enfatiza que este giro no fue impulsado por el hype. En aquel momento, las “bases de datos vectoriales” no eran una categoría reconocida, e incluso el propio término carecía de una definición clara. Lo que guio la decisión fue una convicción arraigada en los fundamentos de las bases de datos: si la búsqueda semántica iba a importar, eventualmente necesitaría las mismas cualidades que cualquier sistema de datos crítico: escalabilidad, estabilidad y fiabilidad.
Esa elección marcó la dirección de todo lo que vino después. Al comprometerse pronto con los vectores como datos de primera clase y con las bases de datos como sistemas de larga duración, Zilliz se posicionó por delante del giro de la industria hacia aplicaciones impulsadas por IA, mucho antes de que ese cambio se hiciera ampliamente visible.
A medida que los modelos pasaron más tarde de la investigación a la producción, las bases de datos vectoriales se convirtieron en una parte central de las arquitecturas de IA empresarial, dando soporte a pipelines RAG, sistemas de agentes, recuperación multimodal y deduplicación de datos de entrenamiento a gran escala. Con esa expansión llegaron nuevas expectativas. La velocidad por sí sola ya no era suficiente. La precisión, la escalabilidad, la eficiencia de costes, la gobernanza de datos y la seguridad pasaron a ser preocupaciones de primer orden.
La conclusión de James es que construir sistemas que equilibren estas exigencias no es un problema de optimización a corto plazo. Requiere paciencia, inversión sostenida en ingeniería y un compromiso a largo plazo con los fundamentos de la infraestructura, mucho más allá del entusiasmo inicial por una nueva categoría.
Desafíos técnicos y soluciones: ejecutar bases de datos vectoriales en producción
A medida que las bases de datos vectoriales se incorporaron a sistemas reales de IA en producción, James sostiene que el éxito dejó de depender del rendimiento bruto. En los primeros despliegues, la velocidad importaba por encima de todo. Pero cuando los modelos de lenguaje grandes entraron en escena, el verdadero desafío pasó a ser construir sistemas que pudieran escalar de forma sostenible, equilibrando al mismo tiempo coste, precisión, fiabilidad y requisitos empresariales.
Coste: ir más allá de la búsqueda solo en memoria
James señala que los primeros sistemas de búsqueda vectorial dependían en gran medida de índices en memoria. Ese enfoque funcionaba cuando los conjuntos de datos eran pequeños, pero se volvió económicamente insostenible a medida que las aplicaciones impulsadas por LLM elevaban mucho más los volúmenes de datos. A esa escala, reducir la latencia en unos pocos milisegundos importa mucho menos que controlar los costes de almacenamiento.
La solución es un enfoque por niveles para el almacenamiento y la indexación. Al combinar índices en memoria, basados en disco y en almacenamiento de objetos, las bases de datos vectoriales pueden reducir los costes de almacenamiento hasta 100 veces. Este cambio no solo optimiza las cargas de trabajo existentes; hace que la recuperación a gran escala sea práctica desde el principio.
Escalabilidad y estabilidad a escala real
Las presiones de coste exponen rápidamente los límites de escalabilidad. James señala que muchos equipos comienzan con configuraciones simples de un solo nodo porque son fáciles de desplegar. Los problemas aparecen más tarde, cuando los datos crecen 10, 50 o incluso 100 veces en poco tiempo.
Esta realidad llevó a Zilliz a reconstruir Milvus como un sistema distribuido y nativo de la nube. Para James, la escalabilidad es inseparable de la estabilidad. Un sistema que puede escalar pero falla de forma impredecible bajo cargas de trabajo reales no es una infraestructura utilizable.
Subraya que la estabilidad suele ser la parte más difícil de convertir la búsqueda vectorial en un sistema de producción. Con las herramientas de código abierto existentes, muchos equipos pueden construir un prototipo funcional en seis a doce meses. Lo difícil es lograr que ese sistema se comporte de forma fiable durante largos periodos de tiempo a medida que cambian el volumen de datos, los patrones de consulta y la complejidad operativa.
A diferencia de la optimización del rendimiento, la estabilidad no proviene de un único avance decisivo. Las mejoras de rendimiento son visibles: los benchmarks pueden mostrar una mejora del 20% o del 30% en unos pocos meses. La estabilidad se construye de otra manera. Cada corrección puede mejorar el SLA solo en una fracción de un punto porcentual, apenas perceptible por sí sola. Pero mediante cientos de pequeñas mejoras acumulativas, un sistema se vuelve gradualmente lo bastante fiable como para funcionar como infraestructura a largo plazo.
Precisión: la recuperación fija el techo
En sistemas RAG y de agentes, la calidad de la recuperación determina directamente el rendimiento del modelo. Si el sistema no logra recuperar la información correcta, el modelo no tiene forma de compensarlo.
James enfatiza que la precisión no es solo una cuestión de base de datos. Depende de toda la pila de recuperación, incluidos los modelos de embeddings, las estrategias de reranking y la calidad de los datos. Dado que estos componentes evolucionan rápidamente, los equipos necesitan reevaluar sus configuraciones con frecuencia —a menudo cada pocos meses— para mantener la precisión a lo largo del tiempo.
Cómo Zilliz equilibra el código abierto y el negocio
Durante el último año o dos, James ha dedicado mucho tiempo a pensar en un desafío que surge repetidamente para las empresas de código abierto: cómo construir y sostener una comunidad activa de código abierto mientras también se dirige un negocio en crecimiento.
Los objetivos del código abierto y los comerciales no siempre se alinean de forma ordenada. Los proyectos de código abierto dependen de la apertura, la participación a largo plazo y la confianza de la comunidad, mientras que una empresa tiene objetivos de ingresos y limitaciones de crecimiento que gestionar. En los últimos años, este desajuste se ha vuelto más visible en toda la industria. James ha visto a varios equipos pasar sus proyectos de código abierto a modo de mantenimiento, no porque la tecnología dejara de funcionar, sino porque el modelo de código abierto se volvió difícil de sostener a medida que el negocio escalaba.
Pero para Zilliz, el código abierto no es solo una decisión técnica, también es una decisión de salida al mercado. En la práctica, funciona de forma muy parecida a una prueba gratuita altamente técnica: una manera de que los desarrolladores descubran, evalúen y ganen confianza en un producto mediante el uso real. Esto es especialmente importante para las startups, donde adquirir los primeros usuarios es difícil. Para un equipo impulsado por la ingeniería como Zilliz, esto resultó mucho más eficaz que el marketing tradicional o los enfoques liderados por ventas.
Al convertir Milvus en código abierto, el equipo se centró en GitHub como el principal punto de entrada. Los desarrolladores usaron Milvus en cargas de trabajo reales, compartieron comentarios y contribuyeron mejoras al proyecto. Con el tiempo, esto creó un estrecho ciclo de retroalimentación entre los usuarios, la comunidad y el desarrollo del producto.
Los resultados fueron tangibles. James señala que aproximadamente el 80% de los clientes de Zilliz Cloud comenzaron como usuarios del proyecto de código abierto Milvus. El código abierto también sirvió como un potente mecanismo de confianza: los equipos que habían ejecutado Milvus por sí mismos se sentían mucho más cómodos adoptando una oferta comercial más adelante.
Esa transición, sin embargo, nunca fue automática. James tiene claro que el código abierto por sí solo no crea un negocio. Un producto comercial debe hacer algo más que empaquetar código abierto: tiene que resolver problemas que la versión de código abierto no resuelve. Para Zilliz, ese valor reside en operar Milvus de forma fiable a escala: gestionar actualizaciones, manejar fallos y optimizar continuamente el rendimiento y el coste.
Un resultado importante de este enfoque es que muchos usuarios descubren que sus costes generales disminuyen después de pasar a la oferta gestionada. Las bases de datos vectoriales evolucionan rápidamente, impulsadas por avances en indexación, cuantización y almacenamiento. Con Zilliz Cloud, los usuarios se benefician continuamente de estas mejoras, sin asumir ellos mismos la carga de las actualizaciones ni de la gestión de la infraestructura.
Desde la perspectiva de James, este equilibrio es lo que hace sostenible el modelo. El código abierto crea acceso y confianza. La oferta comercial convierte el progreso de la infraestructura a largo plazo en valor práctico, sin socavar la apertura que atrajo a los usuarios desde el principio.
Cómo Zilliz destaca en un mercado saturado
Cuando se le pregunta cómo se ve hoy el mercado de bases de datos vectoriales, James reconoce que la rápida adopción de la IA ha saturado rápidamente el espacio. Ahora incluye servicios gestionados, plugins ligeros y un número creciente de nuevos participantes que ofrecen capacidades de búsqueda vectorial. A simple vista, muchas de estas soluciones parecen similares.
Desde el punto de vista de James, la verdadera distinción no se define por listas de funcionalidades, sino por la profundidad y madurez de los sistemas subyacentes. Crear una función básica de búsqueda vectorial es relativamente sencillo. Crear un sistema que pueda operar de manera fiable a escala, durante largos períodos de tiempo, no lo es.
Madurez de sistemas
La ventaja de Zilliz comienza con la madurez de sistemas, específicamente la escalabilidad, la estabilidad y el control de costes. Desde el principio, Milvus fue diseñada como una base de datos distribuida y nativa de Kubernetes, construida para mantenerse estable a medida que los volúmenes de datos crecen decenas de veces. Esto importa porque las cargas de trabajo vectoriales rara vez escalan de forma fluida. Los sistemas que funcionan bien a pequeña escala a menudo tienen dificultades cuando el uso se vuelve sostenido, irregular e impredecible.
El coste también forma parte de esa madurez. Zilliz invirtió pronto en indexación multinivel, combinando memoria, disco y almacenamiento de objetos. Esto ofrece a los usuarios una flexibilidad práctica para equilibrar rendimiento y coste a medida que evolucionan las cargas de trabajo, en lugar de encerrarlos en un único modo operativo costoso.
Preparación empresarial
La preparación empresarial es otro diferenciador clave. James contrasta a Zilliz con equipos que provienen principalmente de entornos centrados en modelos o en IA. Las raíces de Zilliz en la ingeniería de bases de datos tradicional llevaron a una inversión temprana en capacidades como control de acceso, aislamiento de datos, implementaciones BYOC, cifrado y cumplimiento normativo.
Estas funciones no son opcionales a escala empresarial. Son lo que permite que las bases de datos vectoriales vayan más allá de la experimentación de los desarrolladores y entren en entornos regulados como finanzas, salud y grandes organizaciones con estrictos requisitos de seguridad y gobernanza.
Fiabilidad operativa
James señala que muchos equipos subestiman la complejidad operativa a largo plazo de las bases de datos vectoriales. Los sistemas iniciales pueden funcionar bien en configuraciones controladas, pero los verdaderos desafíos aparecen cuando los datos crecen rápidamente, aumenta la concurrencia y las aplicaciones de IA pasan a producción continua.
La mayoría de las empresas no quieren invertir su tiempo y recursos en operar infraestructura compleja, especialmente en áreas altamente especializadas como la búsqueda vectorial. Aquí es donde James ve el papel de Zilliz: asumir la carga operativa de ejecutar bases de datos vectoriales a escala, para que los equipos puedan centrarse en crear aplicaciones en lugar de mantener infraestructura. A medida que el mercado madura, esta división del trabajo se vuelve cada vez más importante.
Mirando hacia el futuro: la próxima fase de las bases de datos vectoriales
Mirando de tres a cinco años hacia adelante, James adopta una visión pragmática sobre hacia dónde se dirige la industria. El crecimiento continuará, pero la pregunta clave ya no será si se pueden construir sistemas de bases de datos vectoriales, sino si pueden operarse de manera sostenible. A medida que los modelos crecen y las aplicaciones de IA se adentran más en la producción, los volúmenes de datos se expandirán rápidamente, elevando el listón para el control de costos, la fiabilidad, la precisión y la seguridad.
En ese entorno, la capacidad de reducir costos en un orden de magnitud sin comprometer la calidad de la recuperación se convierte en un punto de referencia definitorio. James cree que aquí es donde se forman las ventajas duraderas. Los líderes a largo plazo en el espacio de las bases de datos vectoriales no se decidirán por funciones o entusiasmo mediático, sino por la disciplina de infraestructura: la capacidad de ejecutar sistemas a gran escala de manera eficiente, fiable y sostenida en el tiempo.
Para escuchar la conversación completa, puedes encontrar el episodio en Spotify, Apple Podcasts y YouTube.
Sigue leyendo
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
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.
Will Amazon S3 Vectors Kill Vector Databases—or Save Them?
AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.