Douyin のクラウドネイティブ ベクトル データベースが「非主流」から「ニューノーマル」へと進化

1. ベクターデータベースの背景

1. 非構造化データの検索問題

構造化データとは、明確で固定されたフィールドとタイプを持つ 2 次元テーブルとして表現できるデータのことです。非構造化データとは、テキスト、画像、ビデオなど、2 次元の表として表現できないデータのことです。 Douyin グループの製品マトリックスは毎日膨大な量のデータを生成しますが、そのうち構造化データはごく一部を占め、大部分は非構造化データです。業界では一般的に、非構造化データが全データの 80% を占めると考えられていますが、Douyin グループのビジネス モデルでは、非構造化データの割合はさらに高くなります。これらの非構造化データをどのように有効活用するかが、製品機能の向上やビジネス成果の向上に重要です。

非構造化データの検索では、テキスト検索を例にとると、転置インデックスは従来、BM25 および TF-IDF アルゴリズムと組み合わせて使用​​されます。このアプローチにはいくつか問題があります。

• テキストの一般化と意味検索機能が不十分です。
• 単語のセグメンテーション結果に基づいて、写真やビデオなどのマルチモーダルシナリオに一般化することは困難です。
• データが増え続けるとパフォーマンスが不十分になります。

しかし、現在ではベクトル表現を生成するディープラーニングにより、テキストは言語モデル（doc2vec、bert、LLMなど）を通じてベクトルに変換され、非構造化データの検索問題がベクトル近似検索問題に変換されます。

2. ベクトル検索の核となる概念

ベクトル検索とは、多数のベクトルの中から、特定のベクトルに類似したベクトルのグループを見つけることです。ここで明確にする必要がある 3 つの質問があります。

• ベクトル間の類似性を測定するにはどうすればよいでしょうか?一般的に使用されるメトリックは、ユークリッド距離、内積、コサイン距離です。
• 取得する必要がある結果はいくつですか?通常は整数 topK が指定されます。
• 検索結果を評価するには？検索精度と検索効率という2つの指標のバランスをとる必要がある

通常、計算能力と応答時間によって制限されるため、ベクトル検索ではほぼ最適な結果しか得られません。一般的なプラクティスは、次の 3 つのカテゴリに分類できます (3 つのカテゴリを組み合わせることもできます)。

• 近似最近傍アルゴリズム (ANN)。プルーニングは、検索を高速化するために補助構造の助けを借りて実行されます。一般的なものには、HNSW、IVF などがあります。
• 量子化アルゴリズム。 PQ アルゴリズム、スカラー量子化などの相関計算のオーバーヘッドを削減することで、検索プロセスを高速化します。
• 実装の最適化。 SIMD ハードウェア命令セットアクセラレーション ソリューション。メモリ配置: キャッシュヒット率を向上します。

Douyinグループの実践:

• ANNアルゴリズムに関しては、オープンソースのHNSWを最適化し、IVFアルゴリズムを独自に開発することで、検索精度を維持しながらパフォーマンスを向上させました。
• 量子化に関しては、PQ量子化に加え、int16、int8、int4量子化をサポートするスカラー量子化アルゴリズムセットも独自に開発し、単一のT4グラフィックカード（2億個の候補ベクトル）での検索を実現しました。
• SIMD やメモリ配置などの実装レベルの最適化についても多くの作業が行われてきました。

3. 検索アルゴリズムからベクトルデータベースへ

これらのベクトル検索機能を統合することでベクトルデータベースが形成されます。

ベクター データベースのインターフェイスには、ベクターの保存と取得が含まれます。機能別に見ると、保存、検索、分析が含まれます。同時に、オンライン サービスとして、高可用性、高パフォーマンス、使いやすさを実現する必要があります。

これらを完了した後、コアベクトル検索機能を備えたベクトルデータベースが誕生しました。これは、ストレージとコンピューティングを統合したベクター データベースです。

2. ベクターデータベースの技術的進化

1. ベクトル・スカラー混合検索

ベクター データベースをビジネス シナリオに導入すると、ベクター データは構造化データと組み合わせて使用​​されることが多いことがわかります。たとえば、ドキュメントをベクトルとして表現する場合、検索時の権限フィルタリングを容易にするために、ドキュメントが属する部門も保存する必要があります。このような要件は、ベクトルに関連付けられた構造化データを使用したフィルタリングに抽象化できます。

業界では通常、このフィルタリング要件に対して 2 つのソリューションを提供しています。

• 後濾過。 topK の結果を特定の倍数で拡張してより多くのベクトルを取得し、構造化データを使用して topK をフィルタリングして保持します。ベクトル検索と DSL フィルタリングの結果の重複がほとんどない場合、呼び出された結果は topK よりも少なくなる可能性があります。したがって、この方法は、構造化フィルタリングの割合が低く、ベクトルリコール結果の割合が高いシナリオに適しています。
• まずフィルタリングします。まず DSL を使用してデータセットをフィルタリングし、結果内のベクトルを検索します。このソリューションは、DSL フィルタリング結果が少ないシナリオに適しています。結果が大きい場合、パフォーマンスは大幅に低下します。

業界では通常、2 つのソリューションを組み合わせて検索タスクを調整し、データ分布を分析してどちらのソリューションを使用するかを決定します。ただし、データ量が増えると、両方の検索リンクのパフォーマンスが低下する状況が発生する可能性があります。

Douyin グループの実践: この問題を解決するために、技術チームは、検索プロセス中にベクトル検索と DSL フィルタリング (構造化フィルタリング) を同時にサポートする DSL 方向エンジンを開発しました。このエンジンには次の機能があります。

• 高性能: DSL フィルタリングを実行する場合、類似性計算のためにベクトルの一部のみを抽出する必要があるため、メモリの連続性が中断され、ベクトル検索のパフォーマンスが低下します。したがって、DSL フィルタリング判断のオーバーヘッドは十分に低くする必要があり、オンライン検索のパフォーマンスを保証するには、ベクトル検索のオーバーヘッドよりもはるかに低くする必要があります。
• 論理的に完全: DSL 構文は、さまざまなシナリオやユーザーに応じて対応する検索フィルター条件のカスタマイズをサポートし、ビジネスのオンライン検索をサポートします。
• 要求に応じた終了: ベクトルの取得およびフィルタリング プロセス中に、取得効果を保証するために十分なノードがトラバースされる場合は、取得プロセスをできるだけ早く終了する必要があります。
• 実行計画の最適化: 推定された DSL フィルタリング結果とベクトル分布に基づいて、実行する検索リンクについて総合的な決定が行われます。

DSL 方向エンジンに加えて、サブインデックスの分割、適応精度調整、オンラインのマルチウェイインデックスのマージなど、さまざまなカスタマイズされた機能も実装し、完全なベクトル検索ツールライブラリセットを作成しました。

2. 統合ストレージとコンピューティングから個別のストレージとコンピューティングへのアップグレード

機能は徐々に充実してきましたが、当社のベクター データベースは当初、ストレージ コンピューティング アーキテクチャ (ストレージとコンピューティングの両方が同じマシン上にある) に基づいて実装されました。しかし、推進の過程で、このアーキテクチャの使用に関するいくつかの問題が徐々に明らかになりました。たとえば、ドキュメント検索のシナリオでは、一部のドキュメントは品質が高く、高精度のリコールが必要になります。グローバルドキュメントの補足として、部門内のドキュメントリストと部門外のドキュメントリストを区別し、個別に表示する必要もあります。これには、同じベクター データに対して、異なる検索可能なセット、異なる精度のインデックス、および異なる候補セットを生成する必要があります。

ストレージとコンピューティングの統合フレームワークでは、オンライン検索プロセスに影響を与えないように、少数のスレッドを使用してインデックス再構築プロセスを非同期的に完了します。データ分布の変化に適応するために、このインデックスを定期的に再構築する必要があります。さらに、一部のビジネス シナリオでは、異なる候補と異なる精度を持つ検索戦略を使用する必要があります。各戦略ごとにインデックスのセットを作成すると、インデックス構築のリソース消費がさらに増加し​​、インデックス構築の効率が低下し、オンライン サービスの安定性に影響します。

そのために、ストレージとコンピューティングを分離するアーキテクチャのアップグレード作業を段階的に実行してきました。

当社のストレージとコンピューティングの分離アーキテクチャは、主に 3 つの部分に分かれています。

• ベクトルストレージ。ユーザーはベクトルをベクトル ストレージに保存します。
• バッチビルド。バッチ ビルド クラスターは、ベクター インデックスの構築プロセスを自動的にスケジュールします。このプロセスでは、候補セットがスクリーニングされ、さまざまな精度要件に応じてさまざまなパラメータが調整され、対応するインデックスが構築され、その後、P2P パイプラインを通じてオンライン マルチコピー検索サービスに配信されます。
• オンライン検索サービス。リアルタイムのオンライン検索を担当します。

この設計では、1 つのベクトルに対する複数のインデックスの問題を解決し、複数のシナリオをサポートするだけでなく、次の利点も得られます。

• インデックス構築リソースを節約し、一度構築して複数の場所に配布します。
• インデックス構築を高速化します。統合ストレージおよびコンピューティング システムでは、リアルタイム検索パフォーマンスに影響を与えないように、構築プロセスでは少数のスレッドのみを使用できます (CPU を完全にロードすることはできません)。ストレージとコンピューティングが分離されると、そのような制限はなくなり、CPU をフルに活用できるようになります。
• ビルド プロセスがオンライン検索サービスに影響を与えなくなったため、オンライン検索サービスの安定性が大幅に向上しました。
• 自動パラメータチューニングに特に適しています。このストレージとコンピューティングの分離フレームワークに基づいて、ベクターデータの書き込み後、インデックス構築前、およびオンラインになった後に、ユーザーがインデックス構築パラメータと検索パラメータを継続的に調整できるようにサポートする一連の自動パラメータ調整ツールライブラリを構築しました。

3. ストリーミングアップデート

より高いタイムリーさが求められるビジネスへのアクセスが増えるにつれ、新しいコンテンツの検索効率をいかに効果的に向上させるかが、重要なビジネス上の懸念事項となっています。たとえば、ドキュメント取得のシナリオでは、ドキュメントが作成されたばかりの場合や新しいドキュメントが承認された場合、ユーザーはそのドキュメントを取得する前に 30 分待つ必要がありますが、これはビジネス上許容されません。この問題を解決するために、ストリーミング更新機能を開発しました。

ストリーミング更新機能を備えたインデックス構築プロセスは 2 つの部分に分かれています。

• バッチおよびストリーミング更新イベント生成プロセスを最適化します。新しいバージョンのインデックスが公開される前に、時間のかかるバッチ ビルド プロセスが実行されます。構築プロセス中に、新しいデータ更新イベントが引き続き表示されます。これには、バッチ バージョンの更新が完了すると、ストリーミング更新イベント サブスクリプションがバッチ更新が開始されたイベント時間にコールバックされる必要があります。更新イベントのストリーミングを続行する前に、遅延が均等になるまで待機します。
• インデックス更新のやり直し。インデックスをリアルタイムで更新するために、HNSW インデックスや IVF インデックスなどのベクトル インデックスに対して同時かつ安全な変換を行いました。オンライン検索サービスを提供しながら、基本的にベクトルの追加、削除、変更、クエリを実装できます。ここで DSL インデックスについて言及するのは、DSL インデックスにはデータの一貫性に対する高い要件があるためです。 DSL 更新操作では多くのフィールドが書き込まれるため、データ一貫性セキュリティと更新同時実行セキュリティがオンライン取得パフォーマンスに大きな影響を与えます。そのため、デュアルバッファソリューションを採用しました。書き込み操作は更新バッファでのみ発生し、取得バッファはロックフリーの取得プロセスをサポートします。全体的なデュアルバッファソリューションでは、数秒の更新遅延も実現できます。

4. クラウドネイティブへの変革

Douyin グループの製品マトリックスの製品がベクター データベースに接続されるケースが増えるにつれて、導入コスト、運用・保守コスト、ハードウェア コストなど、各事業ごとにストレージとコンピューティングを分離するフレームワークを構築するためのコストが高くなります。この問題を解決するために、ストレージとコンピューティングの分離フレームワークをさらに繰り返しました。

• マルチテナントオーケストレーション変革

①ベクトルストレージ部分をベクトルストレージクラスタに変換します。

②インデックス構築部をインデックス構築クラスタに変換します。

③オンライン検索サービスがマルチテナント対応に変わります。

当社のリソース スケジューリング モジュールは、データを自動的に取得してインデックス構築タスクを開始し、それをオンラインのマルチテナント検索サービスに配布できます。変換されたオンライン検索サービスは多方向インデックスをサポートしており、オンライン サービスのオーバーヘッドをさらに削減できます。当初は、サービスの安定性を確保するために、オンライン検索サービスのオーケストレーションは手動で行われていました。

• 自動スケジュール

ビジネスが成長するにつれて、マルチテナント サービスの安定性を確保するために、インデックス サイズはますます大きくなります。手動オーケストレーションを最適化し、不合理な手動クラスター選択などの問題を解決します。自動スケジューリング フレームワークを開発しました。

オンライン検索サービスの配置転換は主にスロット方式を採用しています。スロットは、インデックスの最小のスケジュール単位です。インデックス メタ情報管理スケジューリング サービスは、オンライン検索サービスのクォータとリアルタイムの呼び出しトラフィックに基づいて、スロットの呼び出しと呼び出しを自動的に実行します。

自動スケジューリング ソリューションの立ち上げをサポートするために、多くの補助モジュールを開発しました。たとえば、インデックスのトラフィック認識モジュールは、インデックス全体のトラフィックの変化にできるだけ早く対応するために、スケジューリング サービスに情報を提供するために使用されます。もう 1 つの例は、インデックス クォータ管理システムです。このシステムは、一部のインデックス トラフィックの突然の増加がオンライン検索クラスター全体の安定性に影響するのを防ぎます。

重要なモジュールの 1 つは、インデックスの正確な価格設定システムです。オンライン サービス全体のコンピューティング コストを削減するために、メモリが小さくリクエスト量が少ないインデックスをいくつか同じインスタンスにスケジュールします。この時点で、コストをどのように計算し、配分するかが重要になります。サービスのコスト統計と割り当てを実行するために、クロック サイクル精度のオーバーヘッド監視を実装しました。

5. Volcano EngineベクターデータベースVikingDBの技術概要

大規模言語モデルの台頭により、ベクトル データベースの商業的価値が徐々に明らかになってきています。 TikTok グループの内部ベクターデータベースと全く同じサービスを提供するために、Volcano Engine 上でクラウドネイティブ ベクター データベースを立ち上げることにしました。社内での調査と最適化の結果もこの製品に同期させます。

全体的な製品構成を下図に示します。製品全体は Volcano Engine のクラウド インフラストラクチャをベースとしており、当社が徹底的に磨き上げ、最適化したさまざまなエンジンを提供し、マルチモーダル データの書き込みから、ベクター生成、オンライン検索、オンライン化後の柔軟なスケジュール設定と監視まで、フルリンク ソリューションの完全なセットを提供します。

ユーザーがシステムにアクセスすると、多言語 SDK または http API を通じて独自の非構造化データを書き込むことができます。次に、クエリ分析ツールを使用してデータを管理および分析します。簡単な設定でスケジュールを自動化できます。非構造化データからベクター生成までのパイプラインは、プラットフォーム上の自動スケジューリングを通じて実装されます。データが書き込まれた後、インデックスがオンラインになる前の自動パラメータ調整、オンラインになった後のストリーミング更新、および全体的なオンライン検索効果とリソースコストを最適化するための継続的な自動パラメータ調整もサポートします。オンライン取得フェーズでは、サービス全体のオンデマンド適応型弾性スケジューリングをサポートします。データの書き込みからオンライン取得まで、フルリンクの監視とアラームにより、オンライン サービスの安定性が確保されます。この製品セットをベースに、インテリジェントな質問と回答、インテリジェントな検索、インテリジェントな広告推奨、大規模言語モデルに基づく著作権重複排除など、幅広いシナリオに展開していく予定です。

このクラウドネイティブ ベクター データベースには、次の主な利点があります。

• 極めて優れたパフォーマンス: Volcano Engine 内部に複数の独自開発インデックス アルゴリズムが組み込まれており、複数の内部数百億のライブラリ、数百億のベクトル検索スケール、および 10 ミリ秒以内の検索パフォーマンスをサポートします。
• リアルタイム: ベクター データのリアルタイム書き込みと更新、リアルタイム インデックス作成、自動インデックス作成をサポートします。
• 安定性と効率性: ストレージとコンピューティングの分離アーキテクチャ、単一データと複数のシナリオ、コンピューティング リソースの節約、オンライン安定性の向上、高可用性の確保。
• 複数のシナリオにおけるベスト プラクティス: 20 を超える社内ビジネス、数百億のデータベースにおける複数の検索プラクティス、Feishu Q&A、Feishu Documents、検索ミドルウェア、e コマース検索などの複数の社内大規模モデル シナリオにおける実装プラクティス。

3. ベクトルデータベースの応用展望

このセクションでは、クラウドネイティブ ベクター データベースにおける当社のテクノロジーと利点を紹介した後、ベクター データベースの展望について説明します。

1. 大規模言語モデル（LLM）の機能の補完

ビッグ言語モデルでは、プロンプトはビッグ言語モデルへの入力です。プロンプトの情報内容は、最終的な回答の品質に影響します。ただし、アルゴリズムの原理と計算能力の制限により、プロンプトの長さは制限されます。複数回の調整、パーソナライズされた質問と回答の認識、特定の分野における知識の注入など、いずれの場合も、より長いプロンプトが必要になります。第二に、トレーニングサンプルの制限により、大規模言語モデルの適時性に欠陥があります。トレーニング データが切断されたときに入力された情報のみを知ることができます。タイムリーな回答が必要なシナリオにはサポート対策が必要です。ベクターデータベースはこの問題をある程度解決できます。

• 大規模モデルにおける長期記憶の補足。複数回の調整とパーソナライズされた回答の場合、調整プロセスとユーザーの質問と回答の結果は、テキストエンコードを通じてベクター データベースに書き込まれます。そして、ユーザーが質問すると、その質問がベクトルに変換され、ベクトルデータベース内の長期記憶が検索され、履歴がレビューされます。過去の調整結果と、現在の質問に最も近いユーザー自身の質問と回答が検索され、大規模言語モデルのコンテキストに注入され、回答全体の品質が最適化されます。
• 特定の分野の知識を補足します。ドメイン知識をベクター データベースに組み込むことができます。ユーザーが質問すると、関連するテキスト情報が事前に取得され、大規模モデルのコンテキストに取り込まれ、専門分野における大規模言語モデルの回答パフォーマンスが最適化されます。
• 大規模モデルの適時性を最適化します。たとえば、ストリーミング更新機能を通じて、リアルタイムのホットニュースをベクター データベースに書き込むことができます。ユーザーがリアルタイムでホットな質問をすると、ホットな情報がベクトル データベースを通じて取得され、大規模言語モデルのコンテキストに配置されて、回答効果が最適化されます。

2. 潜在的なセキュリティソリューションとしての大規模言語モデル（LLM）

プロンプトの長さの制限に加えて、大規模言語モデルにおけるもう 1 つの大きな問題は、データのセキュリティです。たとえば、決済業界では、決済シナリオでは chatGPT を慎重に使用することを推奨しています。インターネット業界では、セキュリティ上の理由から chatGPT を無効にしている企業も多くあります。

現在、セキュリティに関しては 2 つの懸念があります。

まず、ユーザーの質問が記録されるため、質問が漏洩する可能性があります。

第二に、ユーザー A が尋ねた質問は、モデルをトレーニングするためのトレーニング データとして使用され、他のユーザー B が質問時にユーザー A が提供した個人情報を取得する可能性があります。これらの問題は、質問応答データの使用方法を制御することで解決されると予想されます。

しかし、別のタイプの問題は、大規模言語モデルのメカニズムの観点からは解決が困難です。大規模言語モデルに含まれる情報が多いほど、回答の品質は向上します。理論的には、大規模な言語モデルをトレーニングしたり最適化したりする場合、そのモデルにすべてのグローバル情報が含まれていることを期待します。しかし、ビジネス シナリオに戻ると、社内に機密性の高い文書があったり、人によって情報に対する権限が異なったりする場合があります。大規模言語モデルにグローバル情報、つまり高レベルの情報が含まれている場合、権限のないユーザーが大規模言語モデルの質問と回答を通じて権限を超えた情報を取得できる可能性があります。この問題は、ベクター データベースを使用することで大幅に軽減できます。ベクトルデータベースの管理メカニズムを通じて、階層的な権限を持つ知識ベースシステムを開発できます。このように、質問するときに、各ユーザーは自分が権限を持つナレッジ ベースからのみ情報を取得し、取得した情報をコンテキストとして使用して、現在の一連の回答を最適化できます。

最後に、非構造化データ検索におけるベクター データベースの機能に基づき、私たちだけでなく業界全体も、ベクター データベースがビッグ モデル エコシステム全体のインフラストラクチャとなり、業界におけるビッグ モデルの推進と応用をサポートすると考えています。