OpenArt обеспечивает мультимодальный поиск для 8M+ создателей ИИ-видео с помощью Zilliz Cloud
25 s → 300 ms
P99 задержка поиска, ES → Zilliz
~85% ниже
Рассчитать стоимость после миграции
Нативный мультивекторный поиск
Изображение и текстовые векторы запрашиваются вместе
456M
Векторы перенесены без повторного эмбеддинга
«Создатели не создают одно изображение и не уходят. Они выстраивают персонажа, мир, историю, и всё, что они когда-либо генерировали, становится материалом для следующей сцены. Zilliz Cloud позволяет нам рассматривать всю эту библиотеку как единую творческую память».
John Qiao
Об OpenArt
OpenArt — одна из самых используемых в мире платформ генерации изображений и видео на базе ИИ: на ней более 8 миллионов создателей — от любителей и маркетологов до профессиональных работников индустрии развлечений. Она объединяет более 100 моделей от Google, OpenAI, Seedance и других в едином пространстве, но сами модели — лишь товарная часть. То, что OpenArt создает поверх них, — это непрерывность: Character Builder, который удерживает персонажа между сценами, One-Click Story для многосценных повествований и набор инструментов для раскадровки, который создатели используют для производства трейлеров, рекламы и видео для соцсетей. Амбиция всего этого — сделать нативную для ИИ интеллектуальную собственность доступной любому создателю: персонажи и миры, которые сохраняются и развиваются, а не разрозненные изображения, которые исчезают.
Непрерывность — самое сложное, и не только на этапе генерации. Задача ИИ-видео не в том, чтобы создать пятнадцать хороших секунд, а в том, чтобы создать следующие пятнадцать, которые принадлежат той же истории. У этого есть и последствие на дальнейших этапах: создатели возвращаются к миру в течение месяцев, и всё, что они когда-либо генерировали, становится референсным материалом для следующей сцены. Собственный бэк-каталог создателя должен быть находим по смыслу, а не по имени файла или дате — и именно здесь OpenArt задействует Zilliz Cloud.
Проблема
Поиск по работам создателей в OpenArt работал на векторном поиске Elasticsearch. Он справлялся, пока библиотека была небольшой. К тому времени, когда история генераций превысила несколько сотен миллионов векторов, четыре вещи сломались.
- P99 задержка поиска достигала 25 секунд. Управление жизненным циклом индексов Elasticsearch предназначено для данных логов, поэтому оно переводило индексы OpenArt из hot в warm, затем в cold и frozen примерно каждые 90 дней, и большая часть корпуса оказывалась во frozen — но векторный поиск требует противоположного паттерна доступа, потому что ранжирование top K означает оценку всех данных. Каждый поиск обращался к frozen-уровню и перетаскивал данные по сети для ответа.
- Количество индексов росло экспоненциально. Elasticsearch создавал как минимум один новый индекс каждые 90 дней и никогда не объединял их, поэтому количество индексов, по которым должен был распределяться запрос, постоянно умножалось. При библиотеке, которая только растет, команда прогнозировала резкое ухудшение поиска примерно через два года.
- OpenArt платил за целую поисковую платформу, чтобы использовать одну её узкую функцию. Вдобавок кластер был переобеспечен ресурсами, потому что команда определила его размер до того, как измерила реальные потребности рабочей нагрузки.
- Мультивекторный поиск приходилось реализовывать вручную. В Elasticsearch не было нативного способа запрашивать вектор изображения и вектор текста вместе, поэтому OpenArt пришлось написать собственный алгоритм двойного kNN и подключить сторонние компоненты для выполнения обоих поисков, объединения результатов и их фильтрации — постоянная статья обслуживания для функции, которая не является отличительной особенностью OpenArt.
Почему Zilliz Cloud
Инженерная команда OpenArt оценила Pinecone и Qdrant, и ни один из них не подошел. Команда также запускала сам Milvus в первые дни существования компании, и он им нравился; что тогда заставило отказаться от него — операционная нагрузка собственного хостинга. Zilliz Cloud устранил это возражение: он создан той же командой, что и open-source Milvus, и на 100% совместим с API Milvus, поэтому существующие знания и клиентский код команды перенеслись.
Бенчмарки на собственных данных OpenArt подтвердили производительность, и на этом оценка закончилась. Четыре вещи выделяют Zilliz Cloud:
Архитектура, созданная под то, как векторный поиск читает данные. Zilliz Cloud сам управляет уровнями данных на основе их температуры: он перемещает данные в кэш, когда они часто запрашиваются, или понижает их до холодного хранилища, когда они не нужны, — без какого-либо жизненного цикла, о котором приложению пришлось бы думать, а сегментная автоматическая компакция объединяет данные в фоне по мере их роста. Эти две возможности решают ровно те проблемы, с которыми жил OpenArt, — обход замороженных уровней и бесконтрольное размножение индексов, — поэтому поиск OpenArt не замедляется по мере роста библиотеки.
Нативный многовекторный поиск. Одна коллекция Zilliz Cloud хранит несколько векторных полей и запрашивает их вместе в одном запросе, объединяя результаты с настраиваемым весом. Это именно та возможность, которую OpenArt собирал вручную поверх Elasticsearch, и получение её из коробки позволило команде удалить собственный код.
Ценообразование привязано к вычислениям по требованию, а не к объёму хранимых данных. Одна из альтернатив выставляла счёт за объём данных — это неправильная ось для творческого архива, где корпус растёт бесконечно, но в любой момент запрашивается лишь его часть. Модель Zilliz Cloud на основе вычислений по требованию позволяет OpenArt подбирать мощность под нужную производительность и менять её при изменении нагрузки, вместо того чтобы платить налог на историю.
Эксплуатация без специалиста по инфраструктуре. Управляемый сервис всё равно должен быть пригоден для повседневного использования теми, кто с ним работает. OpenArt обнаружил, что консоль достаточно понятна, чтобы навигировать по ней интуитивно, не читая документации, — разительный контраст с универсальной поисковой платформой, несущей десятилетие накопленных функций, которыми они никогда бы не воспользовались.
«Мы обслуживаем миллионы создателей, поэтому каждый элемент инфраструктуры должен быть быстрым, предсказуемым и не требовать постоянного наблюдения. Zilliz Cloud — один из немногих, кто прошёл эту планку с первой попытки». — Дэнни Сюн, инженер-программист, OpenArt
Решение: как Zilliz Cloud обеспечивает работу OpenArt
OpenArt использует Zilliz Cloud для запуска векторного поиска за поисковой строкой по истории генераций создателя, доступной подписчикам на соответствующих тарифах. Создатель, сделавший за месяцы тысячи изображений и клипов, вводит фразу — имя персонажа, настроение, сцену — и получает свои прошлые работы, ранжированные по смыслу, а не по имени файла или дате.
Эта задача сложнее, чем кажется, потому что генерация приходит без метаданных. Нет ни названия, ни тега, ни папки. Есть только два артефакта, которые её описывают: сам ассет и промпт, который его создал. OpenArt индексирует оба, потому что каждый несёт то, чего нет у другого: промпт содержит то, о чём просил создатель, — имена, намерения, слова, описывающие стиль, — а ассет содержит то, что модель фактически произвела, что часто не одно и то же. Поиск только по одному из них теряет половину библиотеки.
OpenArt разделяет работу между тремя сервисами.
- Приложение и основная база данных работают на Google Cloud.
- Сервис эмбеддингов работает на Modal — модель Jina CLIP, которую команда размещает сама на серверной GPU-функции.
- Хранение векторов и поиск отданы Zilliz Cloud. Команда оставляет слой моделей под своим контролем и передаёт уровень, который должен масштабироваться.
Генерация изображений и видео с помощью ИИ происходит непрерывно, а поиск по ней выполняется намного позже, поэтому OpenArt построил систему как две независимые половины, которые работают в совершенно разное время и с разной скоростью.
- Путь записи превращает каждую новую генерацию в векторы и отправляет их в Zilliz Cloud. Он работает постоянно в фоне, запускается событиями создания, и никто его не ждёт.
- Путь чтения работает только тогда, когда создатель вводит текст в поисковой строке. Он должен вернуть результат за несколько сотен миллисекунд, потому что кто-то смотрит на индикатор загрузки.
Сторона записи никогда не находится на пути запроса — единственное место, где они встречаются, это сама коллекция. Именно это разделение объясняет, почему непрерывная загрузка никогда не проявляется как задержка поиска.
Путь записи: как OpenArt превращает генерацию в два вектора
- Создатель на подходящем тарифе генерирует изображение или клип, и OpenArt записывает его снимок в свою основную базу данных в Google Cloud.
- Функция Google Cloud запускается по этому событию и вызывает сервис эмбеддингов OpenArt на Modal. Поскольку Jina CLIP отображает изображения и текст в одно и то же векторное пространство, одна модель предоставляет команде оба нужных вектора.
- OpenArt записывает эти два вектора в Zilliz Cloud — один для сгенерированного ассета, другой для соответствующего промпта — вместе с ID генерации и скалярными полями, по которым путь чтения будет фильтровать: ID пользователя и ID проекта.
OpenArt обрабатывает видео по тому же маршруту: извлекает кадр-снимок из каждого сгенерированного клипа и превращает его в эмбеддинг изображения, так что клипы можно искать наравне со статичными изображениями без второго пайплайна.
Кроме того, поиск — это платная функция, поэтому весь накопленный каталог создателя по подходящему тарифу должен стать доступным для поиска, а не только то, что он создает с этого дня. Запланированная фоновая задача обратного заполнения (backfill) выполняется непрерывно: она проходит по создателям на подходящих тарифах и прогоняет историю каждого через тот же маршрут эмбеддинга и записи. Это также подстраховка пайплайна: всё, что не удалось записать в реальном времени, backfill подхватывает при следующем проходе.
Путь чтения: как OpenArt отвечает на поисковый запрос
- Создатель вводит запрос, и OpenArt отправляет его в ту же модель на Modal, чтобы получить вектор запроса.
- OpenArt выполняет единый многовекторный поиск в Zilliz Cloud по обоим векторным полям, с настроенными весами между ними и прикрепленными фильтрами по пользователю и проекту.
- Zilliz Cloud объединяет два набора результатов, применяет фильтры внутри поиска, а не после него, и возвращает top K. OpenArt выполняет финальное сопоставление и фильтрацию по своей базе данных в Google Cloud перед рендерингом.
OpenArt запрашивает более тысячи результатов на запрос — необычно большой top K для семантического поиска, обусловленный нагрузкой, а не интерфейсом: у активного создателя ассеты одного проекта уже превышают тысячу, а широкий запрос вроде «man» правомерно находит в несколько раз больше совпадений.
Тот же запрос на старом стеке выглядел совершенно иначе. Он расходился по всем индексам, которые когда-либо создавала политика жизненного цикла, большинство из них были заморожены, и тянул данные по сети, пока не мог ранжировать top K. На Zilliz Cloud OpenArt делает один вызов к одной коллекции и получает ответ примерно за 300 миллисекунд.
Как OpenArt превратил два поиска в один
Объединение результатов по изображениям и промптам — именно для этого OpenArt вручную создал слой слияния двойного kNN на Elasticsearch. Поскольку Zilliz Cloud нативно поддерживает запросы по нескольким векторным полям, команда удалила этот код и выразила поиск как единый запрос, а затем обернула веса между двумя полями в фича-флаг. Релевантность стала тем, что OpenArt настраивает в продакшене, а не тем, что приходится переписывать заново.
Как OpenArt мигрировал
OpenArt перенес устаревший набор из примерно 456 миллионов векторов и использовал переход для наведения порядка в данных: удаление записей, которые продукту больше не нужны, и исправление ошибок, которые незаметно вносил старый путь приема данных. Одно решение по объему работ ограничило проект: команда сохранила свою существующую модель эмбеддингов. Повторное эмбеддинг сотен миллионов ассетов превратило бы миграцию в перестройку с нуля. Поскольку Zilliz Cloud хранит векторы любой модели, которую выбирает заказчик, OpenArt перенес хранение и поиск, не затрагивая уровень модели.
Результаты и преимущества
- Задержка поиска упала с 25 секунд при использовании Elasticsearch до примерно 300 миллисекунд на P99 — примерно в 80 раз быстрее, и это разница между поисковой строкой, которой создатели избегают, и той, которой они пользуются.
- Стоимость вычислений снизилась примерно на 85% — та же рабочая нагрузка, но на движке, созданном для неё.
- OpenArt убрал самодельный алгоритм слияния из производственного конвейера. Благодаря нативной мультивекторности Zilliz Cloud код dual-kNN и его сторонние связки исчезли, а настройка релевантности теперь — это изменение конфигурации, а не инженерный проект.
- 456 миллионов векторов были перемещены в Zilliz Cloud без повторного запуска ни одной эмбеддинг-модели, потому что Zilliz Cloud не зависит от модели — что превратило миграцию в миграцию, а не в перестройку.
Стратегический результат — тот, который OpenArt ощущает сильнее всего: поиск перестал быть инфраструктурным проектом. Инженерные мощности, которые раньше уходили на поддержание поиска, вернулись в продукт — а именно, в агентный слой, вокруг которого OpenArt теперь строит весь свой пользовательский опыт.
Советы OpenArt командам, выбирающим векторную базу данных
Проделав это дважды — сначала уйдя от самостоятельно размещённого Milvus, затем от Elasticsearch, — команда OpenArt сводит решение к короткому списку.
- Проверьте, соответствует ли модель ценообразования форме вашей рабочей нагрузки. Спросите, за что вы платите, а затем — какой из ваших показателей растёт быстрее всего. Если это один и тот же показатель, у вас проблема, которая растёт вместе с вашим успехом.
- Проверьте, соответствует ли архитектура вашему шаблону доступа. Читайте описание дизайна хранения, а не список функций. Политика, которая выводит данные из зоны досягаемости по истечении времени, хороша для логов, но не подходит для векторного поиска.
- Знайте свои требования к производительности до начала выделения ресурсов. Самая большая ошибка OpenArt в затратах была связана с избыточным выделением аппаратных ресурсов для нагрузки, которую они не профилировали. Сначала измеряйте.
- Относитесь к миграции как к возможности избавиться от лишнего. Всё, что вы переносите, вы оплачиваете и ищете через это вечно.
Что дальше
Сегодня OpenArt использует Zilliz Cloud для поиска по истории генераций самого создателя и планирует расширить его в трёх направлениях:
- Общая библиотека ассетов и шаблонов, где и работа команды по разметке, и шаблоны рекомендаций нуждаются в семантическом поиске.
- Фильтрация по скалярным полям, отложенная на время миграции и теперь снова поднимающаяся в списке приоритетов.
- Память агента, которая интересует команду больше всего. По мере того как OpenArt переходит от отдельных инструментов к агенту, который ими оркестрирует, — превращая 15-секундную генерацию в минутный или трёхминутный фильм, — агенту приходится помнить между сеансами, над каким проектом работает создатель и для какого бренда он делает рекламу. Это задача векторного поиска, и именно здесь OpenArt ожидает дальнейший рост использования Zilliz Cloud.
"OpenArt определяет, как выглядит AI-нативное творчество: миллионы создателей строят персонажей и истории, которые складываются в единое целое между сценами. Мы гордимся тем, что Zilliz Cloud является поисковой основой этого, и рады продолжать строить вместе с ними, когда их агенты начнут запоминать." — Джеймс Луан, технический директор Zilliz
Попробуйте Zilliz Cloud бесплатно
Zilliz Cloud — это полностью управляемая векторная база данных и Vector Lakebase для корпоративного ИИ, совместимое с API Milvus. Оно обеспечивает высокопроизводительный векторный поиск в огромных масштабах с безопасностью корпоративного уровня и эксплуатацией без обслуживания, дополненное открытостью, масштабируемостью и экономикой мультимодальных озер данных — единая платформа для поиска, анализа и управления неструктурированными данными для продакшен-ИИ.
Создаёте ли вы мультимодальный поиск, RAG или память агентов, Zilliz Cloud предоставляет ту же поисковую основу, на которой работает OpenArt. Начните бесплатно работать с Zilliz Cloud или поговорите с нашей командой.
"Наш старый поиск занимал 25 секунд на P99. Это было неприемлемо. Zilliz Cloud сократил его до менее чем трети секунды и позволил нам удалить код поиска, который мы поддерживали самостоятельно."
Danny Xiong