Cómo 123RF escaló la búsqueda visual a más de 200 millones de recursos con Zilliz Cloud
<50ms de latencia
frente a ~100 ms en producción
50 % de ahorro en costos
después de migrar desde OpenSearch
Más de 200 millones de vectores
en toda la biblioteca de imágenes
Indexación masiva
millones importados en cuestión de horas
The biggest immediate impact for the company would be the cost side of things. We were able to bring the estimated cost of our search cluster from above five digits a month to a significantly lower figure. That would be the biggest improvement for our company.
Su-Meng Yong
Acerca de 123RF
123RF, parte de Inmagine Group, es una de las plataformas de contenido de stock más grandes del mundo, que atiende a millones de profesionales creativos con una biblioteca de más de 200 millones de imágenes, videos y archivos de audio. La búsqueda es el núcleo de la experiencia de 123RF: cada consulta debe mostrar el contenido visual más relevante de un catálogo masivo y en constante crecimiento. Cuando el aumento de los costos y el rendimiento poco fiable en OpenSearch amenazaron esa experiencia, 123RF recurrió a Zilliz Cloud, reduciendo los costos de infraestructura en más de un 50%, disminuyendo a la mitad la latencia de las consultas y eliminando las fallas de indexación que habían afectado su configuración anterior.
El desafío
Anteriormente, 123RF dependía de OpenSearch como su infraestructura principal de búsqueda. La plataforma se construyó originalmente en torno a la búsqueda de palabras clave de texto completo, pero con la llegada de la era de la IA, el equipo comenzó a experimentar con la búsqueda semántica basada en embeddings para ofrecer resultados más relevantes. Añadieron el plugin KNN sobre su clúster de OpenSearch existente en lugar de reconstruir desde cero.
Esa decisión implicó un costo creciente. Tres problemas interrelacionados terminaron haciendo insostenible el statu quo:
Costos en aumento: Ejecutar un clúster de OpenSearch con KNN habilitado a una escala de más de 200 millones de vectores llevó los gastos operativos mensuales a cifras de cinco dígitos y siguió aumentando.
Rendimiento poco fiable: La latencia y el rendimiento de las consultas se volvieron impredecibles bajo tráfico real de producción, degradando la experiencia de búsqueda para los usuarios finales.
Inestabilidad de indexación: Debido a que la biblioteca de 123RF crece a diario, los nuevos activos deben indexarse continuamente. El clúster de OpenSearch experimentaba fallas frecuentes de nodos durante estas operaciones de indexación, lo que requería intervención continua de DevOps.
OpenSearch no fue diseñado específicamente para la búsqueda de similitud vectorial. Su plugin KNN proporcionaba una solución alternativa, pero gestionarlo a escala generaba una sobrecarga operativa que el equipo no podía absorber de manera sostenible.
Por qué Zilliz Cloud
Cuando Su-Meng Yong y su equipo se propusieron encontrar una alternativa, evaluaron varias opciones de bases de datos vectoriales dedicadas, como Pinecone y Weaviate. Tres criterios guiaron la decisión:
Escala: La solución debía manejar cientos de millones de vectores de manera fiable sin degradación del rendimiento.
Eficiencia de costos: Algunas alternativas se descartaron porque costarían más de operar a la escala requerida por 123RF.
Madurez y comentarios de la comunidad: Zilliz Cloud es un servicio totalmente gestionado basado en la base de datos vectorial de código abierto Milvus, que cuenta con una comunidad dinámica.
La solución
123RF implementó Zilliz Cloud para impulsar dos flujos de trabajo de búsqueda complementarios:
Búsqueda de texto a imagen: Las consultas de los usuarios se convierten en embeddings vectoriales, que luego se comparan con la biblioteca de imágenes indexada mediante similitud vectorial, devolviendo resultados semánticamente relevantes.
Búsqueda inversa de imágenes: Los usuarios suben una imagen; el sistema genera su embedding y busca activos visualmente similares en toda la biblioteca.
La capa de embeddings utiliza CLIP, un modelo de embeddings multimodal de código abierto, sobre el cual el equipo iteró en dos versiones de modelo con el apoyo del equipo de soluciones de Zilliz. La flexibilidad de usar cualquier modelo de embeddings —no un modelo de proveedor prescrito— se señaló como una ventaja significativa.
Una canalización diaria por lotes convierte todos los nuevos envíos de colaboradores en embeddings y los ingiere en el clúster de Zilliz Cloud, manteniendo el índice actualizado sin intervención manual.
Tres capacidades de la plataforma resultaron especialmente valiosas durante la implementación:
Escalado dinámico: El clúster puede escalarse hacia arriba o hacia abajo en función de la carga de consultas prevista, una capacidad que no estaba disponible en la configuración anterior de OpenSearch.
Trabajos de importación masiva: La función de trabajos de importación de Zilliz Cloud permite indexar de millones a decenas de millones de filas en cuestión de horas, resolviendo el cuello de botella crónico de indexación que había causado fallos de nodos en OpenSearch.
Boost Ranker (función personalizada): 123RF requería lógica empresarial personalizada en su clasificación de búsqueda. El equipo de ingeniería de Zilliz desarrolló una función Boost Ranker específicamente para este caso de uso, que ahora se ejecuta en producción.
Resultados y beneficios
>50% de reducción de costes
El impacto más inmediato fue financiero. Con la ayuda del equipo de Zilliz, 123RF redujo sus costes mensuales de infraestructura de búsqueda a una fracción del gasto original — una reducción de más del 50%.
"La búsqueda es el corazón de nuestra plataforma — es la forma en que millones de usuarios encuentran el contenido adecuado. Migrar a Zilliz Cloud no solo redujo drásticamente nuestros costes de infraestructura; le dio a nuestro equipo de ingeniería la confianza de que la búsqueda escalará con nuestro negocio en lugar de frenarlo."
— Su-Meng Yong, Engineering Team Lead, 123RF
< 50ms de latencia lograda
Después de varias iteraciones de optimización con el equipo de Zilliz, 123RF redujo la latencia media de las consultas de 100ms a 30-50ms — una mejora de aproximadamente el 50% — manteniendo al mismo tiempo el rendimiento de nivel de producción y las cargas de tráfico diarias.
Indexación sin tiempo de inactividad
Los problemas de caída de nodos que afectaban a OpenSearch durante la ingesta diaria de contenido desaparecieron por completo. Anteriormente, el equipo no podía indexar nuevas imágenes en el clúster con la suficiente rapidez sin degradar el rendimiento de búsqueda para los usuarios activos. Utilizando la capacidad de importación masiva de Zilliz Cloud, el equipo ahora indexa de millones a decenas de millones de nuevas filas en cuestión de horas — sin impacto alguno en el rendimiento de las consultas. Un pipeline automatizado diario convierte el nuevo contenido de stock enviado en embeddings y los ingiere en el clúster, manteniendo el índice de búsqueda actualizado sin intervención manual.
Libertad operativa
Como servicio totalmente gestionado, Zilliz Cloud eliminó la carga de gestión del clúster que había consumido el tiempo del equipo de DevOps. El equipo de ingeniería pasó de apagar incendios de infraestructura a crear funciones de producto.
"Realmente nos ahorra mucho tiempo tanto a mi equipo como a los desarrolladores, al no tener que lidiar con muchos problemas, con mucha autogestión del clúster." — — Su-Meng Yong, Engineering Team Lead, 123RF
Qué viene después
Con la búsqueda de imágenes completamente migrada y estable, 123RF planea llevar sus flujos de trabajo de búsqueda de vídeo y audio a Zilliz Cloud. El equipo también está abierto a explorar integraciones con LangChain o LlamaIndex en el futuro para ampliar las capacidades de búsqueda de su plataforma.
- Acerca de 123RF
- El desafío
- Por qué Zilliz Cloud
- La solución
- Resultados y beneficios
- Qué viene después
Contenido
Industria
Medios de comunicación
Tecnología utilizada
The fully managed version really saves both my team and the developers a lot of time from having to deal with a lot of problems, a lot of self-managing of the cluster. And regarding latency — we went from an initial 100 milliseconds to now sub 30 to 50 milliseconds, a roughly 50% reduction while being able to maintain production throughput.
Su-Meng Yong