OpenArtはZilliz Cloudで800万以上のAIビデオクリエイター向けマルチモーダル検索を実現
25 s → 300 ms
P99検索レイテンシ、ES → Zilliz
約85%低減
移行後のコストを計算する
ネイティブのマルチベクトル検索
画像とテキストのベクトルを一緒にクエリする
456M
再エンベディングなしで移行されたベクトル
「クリエイターは、一枚の画像を作って終わりではありません。キャラクター、世界観、ストーリーを構築し、これまでに生成したすべてのものが次のシーンの素材になります。Zilliz Cloudを使えば、そのライブラリ全体をひとつの創造的な記憶として扱うことができるのです。」
John Qiao
OpenArtについて
OpenArtは、世界で最も広く利用されているAI画像・動画生成プラットフォームのひとつであり、趣味のクリエイター、マーケター、現役のエンターテインメント専門家など、800万人以上のクリエイターが利用しています。Google、OpenAI、Seedanceなどの100以上のモデルをひとつのキャンバスにまとめていますが、モデル自体はコモディティ化された部分です。OpenArtがその上に構築しているのは継続性（continuity）、つまり、シーンをまたいでキャラクターを保持するCharacter Builder、複数シーンのストーリーを作るOne-Click Story、そしてクリエイターが予告編、広告、ソーシャル動画を作るために使うストーリーボードスイートです。その背後にある野心は、AIネイティブなIP（知的財産）をあらゆるクリエイターの手の届く範囲に置くこと、つまり、持続し成長するキャラクターや世界を実現することで、単発の画像ではないものを生み出すことにあります。
継続性は難しい部分であり、それは生成時だけの問題ではありません。AI動画における課題は、15秒の良い映像を作ることではなく、その次の15秒を作り、それを同じストーリーに属させることです。さらに下流には別の結果もあります。クリエイターは何ヶ月も同じ世界に戻ってきて、これまでに生成したすべてのものが次のシーンの参照資料になります。クリエイター自身の過去のカタログは、ファイル名や日付ではなく意味によって検索可能でなければならず、そこでOpenArtはZilliz Cloudを活用しています。
課題
OpenArtのクリエイター検索は、Elasticsearchのベクトル検索で動作していました。ライブラリが小さいうちは問題ありませんでした。生成履歴が数億ベクトルを超える頃には、4つの問題が発生していました。
- P99検索レイテンシが25秒に達しました。 Elasticsearchのインデックスライフサイクル管理はログデータ向けに作られているため、OpenArtのインデックスは約90日ごとにhot→warm→cold→frozenとロールされ、コーパスの大半が最終的にfrozenになりました。しかし、ベクトル検索はその逆のアクセスパターンを持ちます。というのも、トップKをランク付けするには全スコアを計算する必要があるからです。すべての検索がfrozenティアにアクセスし、応答のためにデータをネットワーク越しに引き出していました。
- インデックス数が指数関数的に増加しました。 Elasticsearchは90日ごとに少なくとも1つの新しいインデックスを作成し、それらをマージすることがなかったため、クエリが照会しなければならないインデックス数は増え続けました。増え続けるライブラリでは、チームは約2年以内に検索が急激に劣化すると見込んでいました。
- OpenArtは、検索プラットフォーム全体の料金を払って、その1つの狭い機能だけを使っていました。 さらに、チームはワークロードの実際のニーズを測定する前にサイジングを行ったため、クラスターは過剰プロビジョニングになっていました。
- マルチベクトル検索は手作りする必要がありました。 Elasticsearchには画像ベクトルとテキストベクトルを一緒にクエリするネイティブな方法がなかったため、OpenArtは独自のデュアルkNNアルゴリズムを書き、両方の検索を実行して結果を融合しフィルタリングするためにサードパーティ製コンポーネントを組み込む必要がありました。これは、OpenArtの差別化要因ではない機能に対する恒久的なメンテナンス項目です。
Zilliz Cloudを選ぶ理由
OpenArtのエンジニアリングチームはPineconeとQdrantを評価しましたが、どちらも適していませんでした。チームはまた、会社の初期にMilvus自体を運用したことがあり、気に入っていました。当時、候補から外れた理由はセルフホスティングの運用負荷でした。Zilliz Cloudはその反対意見を取り除きました。オープンソースのMilvusと同じチームによって構築され、Milvus APIと100%互換性があるため、チームの既存の知識とクライアントコードをそのまま引き継ぐことができました。
OpenArt自身のデータに対するベンチマークがパフォーマンスを確認し、評価はそこで終了しました。Zilliz Cloudが際立っている点は4つあります。
ベクター検索がデータを読み取る方法に合わせて構築されたアーキテクチャ。 Zilliz Cloudはデータ温度に基づいてデータ階層を自ら管理します。頻繁に取得されるデータはキャッシュに昇格させ、不要になったデータはコールドストレージに降格させます。アプリケーションが考慮すべきライフサイクルポリシーはなく、セグメントレベルの自動コンパクションがデータの増加に伴ってバックグラウンドでデータを統合します。この2つの機能は、OpenArtが抱えてきた障害モード、つまりフローズン層の走査と無制限なインデックスの増殖を正確に解決します。そのため、OpenArtの検索はライブラリが成長しても遅くなりません。
ネイティブなマルチベクター検索。 単一のZilliz Cloudコレクションが複数のベクターフィールドを保持し、1つのリクエストでそれらをまとめてクエリし、構成可能な重み付けで結果を統合します。これはまさにOpenArtがElasticsearchの上に手作業で構築してきた機能であり、これをネイティブに得られたことで、チームは自前のコードを削除できました。
価格設定は保存データではなく、オンデマンドのコンピューティングに連動。 代替案の1つはデータ量で課金するものでしたが、これはクリエイティブアーカイブにとっては間違った軸です。コーパスは永遠に成長し続ける一方で、常にクエリされるのはごく一部だからです。Zilliz Cloudのオンデマンド・コンピューティングベースのモデルにより、OpenArtは必要なパフォーマンスに合わせてサイズを決め、ワークロードの変化に応じてリサイズできます。過去のデータに税金を払う必要はありません。
インフラストラクチャの専門家なしで運用可能。 マネージドサービスであっても、それを利用する人々が日常的に使えるものでなければなりません。OpenArtは、ドキュメントを読まなくても直感で操作できるほどコンソールが明確であると感じました。これは、10年分の機能が積み重なり、決して使うことのない汎用検索プラットフォームとは対照的です。
「私たちは何百万人ものクリエイターにサービスを提供しているため、すべてのインフラは高速で予測可能で、誰も監視する必要がないものでなければなりません。Zilliz Cloudは、そのハードルを最初の試みでクリアした数少ない製品の1つです。」 — ダニー・シオン、OpenArt ソフトウェアエンジニア
ソリューション: Zilliz CloudがOpenArtを支える方法
OpenArtはZilliz Cloudを使用して、検索ボックスの背後でクリエイター自身の生成履歴に対するベクター検索を実行します。これは対象プランのサブスクライバーが利用できます。数か月かけて何千もの画像やクリップを作成したクリエイターが、キャラクター名、気分、シーンなどのフレーズを入力すると、ファイル名や日付ではなく意味によってランク付けされた自身の過去の作品が返されます。
この作業は見た目よりも困難です。生成物にはメタデータが付属しないからです。タイトルもタグもフォルダもありません。それを説明するのは、アセット自体と、それを生成したプロンプトの2つだけです。OpenArtは両方をインデックス化します。それぞれが他方にはない情報を持つからです。プロンプトには、クリエイターが求めた内容が名前、意図、スタイルの言葉として含まれ、アセットには、モデルが実際に生成したもの、しばしばプロンプトとは異なるものが含まれます。どちらか一方だけを検索すると、ライブラリの半分が失われます。
OpenArtは3つのサービスに作業を分割しています。
- アプリケーションとプライマリデータベースはGoogle Cloud上で動作します。
- 埋め込みサービスはModal上で動作します。チームがサーバーレスGPU関数で自社ホストするJina CLIPモデルです。
- ベクターストレージと検索はZilliz Cloudに任せます。チームはモデル層を自社の管理下に置き、スケールが必要な層を委ねます。
AI画像・動画生成は継続的に作成され、検索されるのはずっと後になるため、OpenArtはシステムを、まったく異なる時間とペースで動作する2つの独立した半分として構築しました。
- 書き込みパスは、新しい生成物をすべてベクターに変換し、Zilliz Cloudに格納します。作成イベントによってトリガーされ、バックグラウンドで常に実行されます。誰もその完了を待っていません。
- 読み取りパスは、クリエイターが検索ボックスに入力したときだけ実行されます。数ミリ秒以内に応答する必要があります。誰かがスピナーを見ているからです。
書き込み側はクエリパス上には決して存在しません。両者が交わるのはコレクションそのものだけです。この分離こそが、継続的な取り込みがクエリレイテンシとして現れない理由です。
書き込みパス：OpenArtが生成物を2つのベクトルに変換する仕組み
- 対象プランのクリエイターが画像またはクリップを生成すると、OpenArtはそのスナップショットをGoogle Cloud上のプライマリデータベースに書き込みます。
- このイベントをトリガーにGoogle Cloud Functionが起動し、Modal上のOpenArtのエンベディングサービスを呼び出します。Jina CLIPは画像とテキストを同じベクトル空間にマッピングするため、単一のモデルでチームが必要とする両方のベクトルを取得できます。
- OpenArtはこれら2つのベクトルをZilliz Cloudに書き込みます。生成されたアセット用に1つ、その背後にあるプロンプト用に1つです。さらに生成IDと、読み取りパスでフィルタリングするスカラーフィールド（ユーザーIDとプロジェクトID）も一緒に書き込みます。
OpenArtは動画も同じ経路で処理します。各生成クリップからスナップショットフレームをキャプチャし、それを画像としてエンベディングするため、別のパイプラインを追加することなく、クリップを静止画と一緒に検索できます。
さらに、検索は有料機能であるため、対象プランのクリエイターの過去の全カタログが検索可能になる必要があります（その日以降に作成されたものだけでなく）。スケジュールされたバックフィルジョブがバックグラウンドで継続的に実行され、対象プランのクリエイターをスイープし、各クリエイターの履歴を同じエンベディング＆書き込み経路でページング処理します。これはパイプラインのセーフティネットも兼ねており、リアルタイムパスが書き込めなかったものは、後続のパスでバックフィルが拾い上げます。
読み取りパス：OpenArtが検索に応答する仕組み
- クリエイターがクエリを入力すると、OpenArtはそれを同じModalホスト型モデルに送信し、クエリベクトルに変換します。
- OpenArtはZilliz Cloudに対して、両方のベクトルフィールドを対象に、設定された重みとユーザー・プロジェクトフィルターを付与した単一のマルチベクトル検索を発行します。
- Zilliz Cloudは2つの結果セットを融合し、検索後ではなく検索内でフィルターを評価して、トップKを返します。OpenArtはレンダリング前に、Google Cloud上の自社データベースに対して最終的なマッチングとフィルタリングを実行します。
OpenArtはクエリごとに1,000件以上の結果を要求します。これはセマンティック検索としては異常に大きいトップKですが、インターフェースではなくワークロードによって決まっています。大量に生成するクリエイターの場合、単一プロジェクトのアセットだけで1,000件を超え、「man」のような広範なクエリはその数倍に正当にマッチします。
同じクエリは旧スタックではこれとはまったく異なる動作でした。ライフサイクルポリシーがこれまでに作成したすべてのインデックスにファンアウトし（そのほとんどは凍結されていました）、トップKをランク付けできるまでネットワーク経由でデータを取得していました。Zilliz Cloudでは、OpenArtは1つのコレクションに対して1回の呼び出しを行うだけで、約300ミリ秒で回答を得られます。
OpenArtが2つの検索を1つに統合した方法
画像とプロンプトの結果を組み合わせることは、まさにOpenArtがElasticsearch上でデュアルkNNフュージョンレイヤーを手作業で構築した目的そのものでした。Zilliz Cloudが複数のベクトルフィールドをネイティブにクエリするため、チームはそのコードを削除し、取得処理を単一のリクエストとして再表現しました。そして、2つのフィールド間の重み付けをフィーチャーフラグでラップしました。関連性は、OpenArtが再実装するものではなく、本番環境でチューニングするものになりました。
OpenArtの移行方法
OpenArtは約4億5,600万ベクトルのレガシーセットを移行し、その切り替えを利用してデータクレンジングを実施しました。製品が不要になったレコードを削除し、旧取り込み経路が静かに導入していたバグを修正しました。プロジェクトの範囲を限定した1つの決定が、プロジェクトを管理可能に保ちました。チームは既存のエンベディングモデルを維持したのです。数億のアセットを再エンベディングすることは、移行を再構築に変えてしまったでしょう。Zilliz Cloudが顧客が選択した任意のモデルのベクトルを保存するため、OpenArtはモデルレイヤーに触れることなくストレージと検索を移行できました。
結果と利点
- 検索レイテンシは、Elasticsearch を使用した場合の25秒から、P99で約300ミリ秒に低下しました — 約80倍高速で、クリエイターが避ける検索ボックスと、実際に使う検索ボックスの違いです。
- 計算コストは約85%削減 — 同じワークロードを、それに適したエンジン上で実行します。
- OpenArtは、手作りされたフュージョンアルゴリズムを本番パイプラインから削除しました。 Zilliz Cloud にネイティブなマルチベクター検索により、デュアルkNNコードとそのサードパーティ製のつなぎは不要になり、関連性のチューニングはエンジニアリングプロジェクトではなく、設定変更となっています。
- 4億5,600万件のベクターが、単一の埋め込みを再実行することなくZilliz Cloudに移行されました なぜなら、Zilliz Cloudはモデル非依存だからです — 移行を再構築ではなく移行のままに保ちます。
戦略的な成果は、OpenArtが最も実感しているものです。検索はもはやインフラプロジェクトではなくなりました。検索を稼働させ続けるために使われていたエンジニアリング能力は、製品に戻りました — 具体的には、OpenArtが現在、体験全体を構築しているエージェント層へです。
ベクターデータベースを選ぶチームへのOpenArtのアドバイス
これを2回経験したOpenArtのチームは — 最初は自己ホスト型Milvusから、次にElasticsearchから — この決定を短いリストに要約しています。
- 料金モデルがワークロードの特性に合っているか確認する。 何に対して課金されるかを尋ね、次にどの数値が最も速く増えるかを尋ねてください。それらが同じ数値である場合、成功に応じて拡大する問題を抱えています。
- アーキテクチャがアクセスパターンに合っているか確認する。 機能リストではなく、ストレージ設計を読んでください。データを古くなるとアクセス不能にするポリシーはログには適していますが、ベクター検索には適していません。
- プロビジョニングする前に、自社のパフォーマンス要件を把握する。 OpenArtの最大のコストミスは、プロファイリングしていないワークロードに対してハードウェアを過剰にプロビジョニングしたことでした。まず測定してください。
- 移行を、ものを捨てる機会と捉える。 持ち越すものはすべて、永遠にコストを支払い、検索することになります。
今後の展開
OpenArtは現在、クリエイター自身の生成履歴全体の検索にZilliz Cloudを使用しており、次の3つの方向に拡張する予定です。
- 共有アセットとテンプレートライブラリ。チームのラベリング作業とレコメンドテンプレートの両方にセマンティック検索が必要です。
- スカラーフィルタリング。移行中は延期されていましたが、現在は再び優先順位が上がっています。
- エージェントメモリ。これはチームが最も関心を持っているものです。OpenArtが個別のツールから、それらを調整するエージェントへと移行するにつれて — 15秒の生成を1分または3分のフィルムに引き伸ばす — エージェントは、クリエイターがどのプロジェクトに取り組んでいるか、どのブランドの広告を作成しているかを、セッションをまたいで記憶する必要があります。これはベクター検索の問題であり、OpenArtが今後Zilliz Cloudの利用を拡大する分野です。
"OpenArtは、AIネイティブな創作がどのようなものかを定義しています。何百万ものクリエイターが、シーンをまたいで一貫性を持つキャラクターやストーリーを構築しています。私たちは、Zilliz Cloudがその背後にある検索基盤であることを誇りに思い、彼らのエージェントが記憶を持ち始めるにつれて、彼らとともに構築を続けることに興奮しています。" — ジェームズ・ルアン, Zilliz CTO
無料でZilliz Cloudを試す
Zilliz Cloudは、エンタープライズAI向けのフルマネージドのVector DatabaseおよびVector Lakebaseであり、Milvus APIと互換性があります。大規模な高パフォーマンスのベクター検索を、エンタープライズグレードのセキュリティとメンテナンス不要の運用で提供し、マルチモーダルデータレイクのオープン性、拡張性、経済性を拡張しています — 本番AIのための非構造化データを検索、分析、管理する単一のプラットフォームです。
マルチモーダル検索、RAG、またはエージェントメモリを構築している場合でも、Zilliz CloudはOpenArtを支えるのと同じ検索基盤を提供します。無料でZilliz Cloudを始める、または当社のチームにお問い合わせください。
「旧検索システムはP99で25秒かかっていました。それは許容できませんでした。Zilliz Cloudのおかげで1秒の3分の1未満に短縮され、自社で維持管理していた検索コードを削除することもできました。」
Danny Xiong