導入
この記事は、2023 年 9 月 5 日に QCon グローバル ソフトウェア開発カンファレンス 2023 · 北京駅で開催された同名の基調講演「大規模ベクター データベース シナリオにおける BES の探求と実践」 - ベクター データベース サブフォーラムから編集されたものです。
全文は 5989 ワード、推定読了時間は 15 分です。
ベクトル データベースは、ベクトル データの保存とクエリを行うために特別に設計されたデータベース システムです。エンベディング技術により、画像、音声、テキストなどのデータの特徴を抽出し、ベクトル形式で表現できます。ベクトル間の距離は、元のデータ間の特徴の類似性を表します。したがって、元データなどの特徴ベクトルをベクトル データベースに保存し、画像検索アプリケーションなどのベクトル検索技術を通じて類似の元データを見つけることができます。
1. ベクトルデータベースアプリケーションの紹介
ベクトル検索の技術は、大規模なモデルが出現する前に十分に開発されました。深層学習技術の発展に伴い、ベクトル データベースは、画像、音声、ビデオの検索と推奨のシナリオに加え、意味検索、テキストの質問と回答、顔認識などのシナリオでも広く使用されています。
大規模モデルの出現により、人間とコンピューターの対話方法が変化し、人工知能テクノロジーに新たな革命がもたらされ、多数の AI ネイティブ アプリケーションが生み出されました。
しかし、まだ開発の初期段階にあり、実用化にはまだ多くの課題が残されています。
第一に、知識能力が十分ではなく、大規模なモデルは一般的な質問に答えることができますが、垂直分野ではトレーニング データが限られているため、回答の専門性にはまだ改善の余地があります。さらに、大型モデルは幻覚の問題も抱えており、答えは事実を歪曲することになる。
さらに、大規模モデルのトレーニング サイクルとコストは非常に高いため、頻繁にトレーニングすることができません。そのため、リアルタイム データの取得が困難になり、時間にあまり依存しないいくつかの一般的な質問にしか答えることができません。
知識に加えて、大規模なモデルでは個人データのセキュリティを確保することも困難です。たとえば、私は自分に関するプライベート データを大規模モデルに提供しますが、この大規模モデルが他の人にサービスを提供するとき、この個人情報が答えとして読み上げられる可能性があります。
では、個人データのセキュリティを保護しながら、大規模モデルの知識機能を強化するにはどうすればよいでしょうか?
下図の右側のように、気象庁が発表する気象警報ニュースを質問の際に持参すると、大型模型が質問に的確に答えてくれます。
外部データ素材やツールを通じて大規模モデルの機能を強化するこの技術システムは、プロンプト ワード エンジニアリングと呼ばれます。
上記の議論から、プロンプトワードエンジニアリングが大規模モデルの適用にとって非常に重要であることがわかります。以下では、プロンプトワードプロジェクトの構築方法を詳しく紹介します。
大規模なモデル アプリケーションの中核となるワークフローを見てみましょう。
外部のリアルタイム ニュース、専門知識、業界データ、その他のデータを定期的にベクトル形式に埋め込み、ベクトル データベースに保存することで、大規模モデルの外部ナレッジ ベースを段階的に構築できます。ユーザーが質問すると、まずナレッジ ベースから最も関連性の高いコンテンツを取得し、次にプロンプトの単語をつなぎ合わせて大規模モデルの回答能力を強化できます。
これにより、大規模モデルを再トレーニングすることなく外部のリアルタイム データと知識を導入し、大規模モデルの解答能力を強化し、大規模モデルの解答の事実からの逸脱を減らすことができます。ベクトル データベースを通じて外部ナレッジ ベースを構築すると、業界データのプライバシーとセキュリティを効果的に確保できます。
さらに、ユーザーの会話履歴はベクトル知識ベースに保存され、その後の会話中に関連性の高い会話履歴を抽出できるため、トークン数の制限によって引き起こされる大規模な言語モデルにおける長期記憶の不足の問題が解決されます。大規模な言語モデルで。
2. Baidu Intelligent Cloud BES のエンジニアリング実践
Elasticsearch は、Apache Lucene に基づく分散検索および分析エンジンです。検索エンジン データベースの分野で第一位にランクされ、世界で最も人気のあるオープン ソース ソリューションです。構造化データと非構造化データを含む複数のデータ タイプをサポートし、インターフェイスシンプルで使いやすく、ドキュメントも充実しており、業界での実践事例が多数あります。
Baidu Smart Cloud Elasticsearch (BES) は、オープンソース Elasticsearch に基づいて構築された成熟したパブリック クラウド製品であり、クラウド上でのリソース保証と運用および保守機能を備えています。BES は 2015 年にリリースされ、パブリック クラウド ベンダーによって提供される初の ES ホスティング サービスでした。2018 年に、Baidu NLP 単語セグメンテーション プラグインを導入し、オブジェクト ストレージ BOS に基づくスナップショットとリカバリをサポートしました。2020 年には、オブジェクト ストレージ BOS に基づくホットとコールド分離アーキテクチャなどの機能をサポートし、Baidu 内で広く使用され、十分なエンジニアリングの蓄積があるベクトル検索機能を提供しました。2023 年には、大規模モデルのシナリオ ニーズを満たすために、ベクトル検索シナリオのベクトル エンジン、パッケージ リソース、その他の側面を最適化します。
BES のアーキテクチャは、管理および制御プラットフォームと BES クラスター インスタンスの 2 つの部分で構成されます。管理および制御プラットフォームは、グローバル レベルでの統合クラスター管理、監視と警報、クラスターの拡張と縮小、およびホットとコールドの分離スケジューリングのためのプラットフォームです。BES クラスター インスタンスは、クラウド ホストとクラウド ディスク上に構築された Elasticsearch クラスター サービスのセットであり、ノードのロード バランシングは BLB 4 層プロキシを通じて行われます。ディスク上のデータは、ポリシーを通じてオブジェクト ストレージ BOS に定期的に保存され、ストレージ コストを削減できます。
BESのインデックスアーキテクチャは全体としてShared Nothing + MPPコンピューティングアーキテクチャを採用しており、ESのデータフローを再利用しています データはインデックスとシャードに従って整理されています シャードは複数のコピーを設定でき、標準で分散されますESのやり方とルーティング。これにより、ベクトル検索を行う際に、データを分散させたノード上でローカルな計算が行われ、マルチノード並列計算によりクエリ効率が向上します。容量拡張と併せてレプリカの数を増やすことで、クエリに参加できるノードとリソースの数を増やすことができ、それによってサービス全体のクエリ QPS が向上します。
ベクター データは ES 標準の方法で管理されるため、スカラー データと使用方法に大きな違いはありません。ベクター データはスカラー データと一緒に書き込むことができ、ES のスカラー データの検索機能と処理機能を再利用します。ユーザーは、ES の Bulk インターフェイスを通じてデータをバッチで書き込むことができ、データが各シャードに書き込まれた後、いくつかのフラグメント ファイルがディスク上に形成され、取得機能が提供されます。ES は、取得効率を向上させるために、バックグラウンドで定期的にシャードの結合をスケジュールします。クエリを実行する場合、任意のノードにクエリリクエストを送信し、そのノードがコーディネーションノードとなり、各シャードにクエリを発行して並列計算を行い、結果にTopKの結果をマージして返します。
BES でのベクトルの使用も非常に簡単ですので、以下に使用例を見てみましょう。まず、インデックスのマッピングを定義し、ベクトル関連のパラメーターを指定する必要があります。このステップはテーブルを作成するのと同じです。その後、ES の Bulk インターフェイスを通じてデータを書き込むことができます。実際のシナリオでは、通常、元のデータは埋め込み機能を通じてベクトル化され、バッチで書き込まれます。ES スタイルに近い、定義した構文を通じてベクトルの取得を実行できます。
ベクトル インデックスの実装に関しては、自社開発のプラグインを通じてベクトル関連機能を実装することを選択しました。C++ を通じてコア エンジンを実装し、ES の JNI を通じて呼び出します。
自社開発のプラグインを選択することで、第一に、C++ 実装に基づいて最下位層に近い極限のパフォーマンスを達成し、SIMD やその他の最適化を促進して計算を高速化できることを望みます。第二に、基礎となるストレージ形式の実装が可能であることを望みます。これは、より優れたパフォーマンスを達成するのにも便利です。第 3 に、取得ロジックをより柔軟に制御し、実行プランを書き換えて、より複雑なクエリを実装できます。
ここでのコアのベクター検索エンジン部分については、コミュニティ内の優れたベクター ライブラリの実装に基づいて二次開発を行うことを選択します。ES 上で nmslib と faiss の解凍パフォーマンスを比較しました (8cu 仮想マシンに基づくテスト、書き込まれたデータによって生成されたセグメントはマージされません、データ セット SIFT-1M 128 次元)、HNSW の再現率が高いことがわかります。全体的なメモリ消費量は比較的多くなりますが、nmslib の実装の方が優れています。
ベクトル検索エンジンの実装を変換することで、レベル 0 ベクトル データ ストレージの HNSW インデックス タイプのカスタム Lucene 列型ストレージ データを再利用し、mmap を通じてロードしました。これにより、データの冗長性が減り、リソースの無駄が削減される一方で、mmap を介してデータをロードすることにより、メモリが不十分な場合、一部のページがメモリからスワップアウトされてから、メモリにロードされます。メモリでは、メモリ + ディスクのハイブリッド ストレージ メディアもある程度サポートされています。
具体的な最適化に着手する前に、現在の主流のグラフ アルゴリズムの原則を確認してみましょう。
グラフ アルゴリズムは、ナビゲート可能なスモールワールド理論に基づいた比較的新しい近似ベクトル検索のアイデアで、具体的には、全結合グラフでは 2 つの点が 6 ホップで接続できることを意味します。ベクトル間の距離関係に基づいて現実世界と同様の「スモールワールド」ネットワークを構築することで、貪欲なアルゴリズムを使用して距離に基づいて接続を確立し、一度に 1 ホップずつターゲットのベクトル固定点に近づくことができます。
小さな世界にポイントが挿入され続けると、前述したエッジを構築するために近くのポイントを選択するという考え方に従って、新しく挿入されるポイントはますます小さな円に限定されます。遠くのポイントとの接続を確立するのに多くの時間がかかり、ホップ数が増加します。
この問題を解決するために、業界は、リンク リスト検索アルゴリズムのスキップ リストと同様の考え方を使用する HNSW アルゴリズムを提案しました。さまざまなレベルでグラフを構築し、固定点の数を上に向かって指数関数的に減らして疎なグラフを形成します。このようにして、グラフが疎になるほど、遠くの場所とよりよく接続できるようになります。
HNSW インデックスのクエリ応答は速く、再現率は比較的高いですが、構成速度が遅く、CPU とメモリのオーバーヘッドが高いなどの欠点もあります。HNSW の合成プロセスでは、挿入された各ポイントの取得と計算が必要ですが、多数のポイントを挿入すると計算コストも膨大になるため、データのインポートが非常に遅くなり、フロント デスクがブロックされる原因になります。
したがって、ベクトル インデックスの構築をバックグラウンドの非同期構築メカニズムに変換し、データをディスクに書き込んだ後に直接返すことができます。その後、ES のマージ戦略またはユーザーのタイミングを通じて、バックグラウンドで HNSW インデックスの構築がトリガーされます。ストリーミング構築方法により、作曲プロセスでのメモリ消費が削減されます。また、フロントエンドのクエリ要求への影響を避けるために、独立したスレッド プールを使用して構築されています。
同時に、ES のフラグメント マージ戦略も最適化しました。
ES のデフォルトのマージ戦略は、マージに参加するフラグメントの数、マージによって生成される新しいフラグメントのサイズなどのいくつかの条件に基づいて、マージに参加するフラグメントのセットを選択し、計算します。さまざまな組み合わせのスコアを計算して最適なものを選択し、フラグメントの組み合わせをマージします。一般に、リソース消費とクエリ効率のバランスをとるために、複数回のマージが実行されます。ただし、ベクトル インデックスの構築コストは ES のネイティブ データ型の構築コストよりも高いことが多いため、フラグメント マージのプロセス オーバーヘッドを削減するために、ベクトル インデックスのマージ戦略を調整し、複数回のマージを 1 回のマージに変更しました。
さらに、データを書き込む前にターゲット インデックスの自動構築をオフにすることもサポートしており、データをバッチで書き込み、フラグメントをマージした後、API を介してベクター インデックスの構築を 1 回で完了できるため、データベースのバッチ充填に適しています。シナリオ。
さらに、BES は複数のベクトル インデックス タイプと距離計算アルゴリズムもサポートしています。また、トレーニングによって生成する必要があるベクトル インデックスのプロセス サポートも提供します。たとえば、IVF シリーズ インデックスについては、まず IVF アルゴリズムの原理を確認してみましょう。
IVF は転置インデックスの略で、転置インデックスとは検索エンジンの用語で、文書の Web ページからキーワードを抽出して逆検索構造を確立し、キーワードから元の文書を検索することを指します。では、ベクターデータのキーワードは何でしょうか? 現実世界のベクトルは、一般に空間分布的にクラスタ状に分布しており、クラスタリング特性を持っています。下の写真をご覧ください。
K-means アルゴリズムを通じてベクトルのクラスタリング中心を抽出します。その後、ベクトルが位置するクラスタリング中心がベクトルのキーワードになります。これを使用して転置インデックスを作成すると、検索エンジンのように最初にクラスタリング中心をヒットできます。 . を実行し、クラスター中心以下の各ベクトルを激しく検索することで、グローバル検索と比較して大量のデータをフィルター処理できます。1 つのクラスタリング センターを見つけるのが十分正確ではないと思われる場合は、さらに複数のクラスタリング センターを見つけることもできます。見つけた数が多いほど、結果の精度が高くなります。
IVF などのベクトル インデックスの場合、BES 構築プロセスでは、最初にトレーニング データを書き込み、次に API を呼び出してモデルをトレーニングします。このステップでは、学習データに基づいてクラスタリングが実行され、各クラスターの中心が計算されます。モデルがトレーニングされた後、実際のデータを書き込むための新しいインデックスを作成し、トレーニングされたモデルに基づいてベクトル インデックスを構築します。特定のベクトル インデックスの構築と結合メカニズムは、以前に説明したものと同じです。
ベクトルデータにラベルを付けて、取得したベクトルがラベルと一致することを確認するなど、ベクトル取得を実行する前にスカラー条件に従ってデータをフィルタリングする必要があるシナリオが数多くあります。
このような要望に応えるために、まず ANN の検索を行い、その検索結果をもとにフィルタを実行して最終結果を得るポストフィルタとプレフィルタの 2 つの方法が考えられます。結果セットのサイズが大幅に大きくなり、K よりも小さくなります。プレフィルターとは、最初にデータをフィルター処理し、次にフィルター結果に基づいて最近傍検索を実行することを指します。この方法では通常、K 個の結果が保証されます。
したがって、アルゴリズムがグラフを走査して最近傍を選択するプロセスでフィルター条件を満たすベクトルのみを考慮するように、元の HNSW 実装を変更しました。具体的なプロセスは、最初に ES のスカラー データ インデックスに基づいてフィルターを実行して、呼び出されたドキュメントの ID リストを取得し、次に ID リストに基づいてビットマップを構築し、JNI 呼び出しを通じてビットマップ データをベクトル エンジンに渡します。 HNSW 取得プロセス中、ビットマップに従って、近くの頂点がフィルタリングされ、フィルタ条件を満たすベクトルのリストが取得されます。
実際のテストでは、パフォーマンスとリコールがあまり理想的ではないことが判明しました。テストデータといくつかの情報の調査を通じて、フィルタリング率が増加すると、頂点がフィルタリングされるため接続されたパスの数が減少し、これがHNSWアルゴリズムの収束速度に直接影響し、行き止まりに達しやすくなることがわかりました。 、結果として再現率が低くなります。データによると、フィルタリング率が 90% を超えると、パフォーマンスと再現率が急激に低下します。
したがって、ここでは実行計画を書き換え、スカラー フィルタリングとブルート フォース検索アルゴリズムを組み合わせることにしました。フィルタリング率が 90% 以上に達すると、フィルタ結果データのブルート フォース検索で満足のいく結果が得られます。同時に、SIMD 命令は暴力的な検索の効率を加速するためにも使用されます。
BES のその後の開発計画は、主に以下の側面に焦点を当てています。
1 つ目は使いやすさであり、ベクター データベースは主に大規模モデルのアプリケーション開発者を対象としているため、すぐに使える製品エクスペリエンスを提供し、ユーザーが理解して使用する敷居を下げることが期待されています。現在、BES が自社開発したベクトル エンジンを使用するには、ユーザーが ES に精通している必要があります。たとえば、ES の DSL を使用してクエリ ロジックを表現できる必要があります。SQLによるknn検索をサポートするなど、より一般的で使いやすい方法が提供されれば、さらに使いやすくなります。
2 つ目は機能的な機能で、さまざまなニーズやシナリオに対応するために、DiskAnn や Baidu が自社開発した Puck&Tinker アルゴリズムなど、より多くのインデックス作成アルゴリズムや類似性アルゴリズムをサポートする必要があります。また、インデックスの構築と取得の効率を向上させるために、異種コンピューティング機能をサポートすることを検討してください。
パフォーマンス コストの観点から見ると、大規模なアプリケーション シナリオでは、システムのオーバーヘッドを削減し、リソースの使用効率を最適化するために、より詳細な最適化が必要になります。たとえば、ES は JVM 上で実行され、ベクトル エンジンは C++ で開発され、JNI 呼び出しを通じて実行されます。では、グローバル メモリ リソースをより柔軟に管理し、さまざまな顧客のワークロードに適応し、リソース使用率を最大化するにはどうすればよいでしょうか?これが、将来の主要な最適化の方向性の 1 つになります。
最後に、BES は現在マネージド クラスターの形式になっています。ユーザーは自分のビジネス レベルに応じてクラスター リソースを評価し、合理的なパッケージを選択する必要があります。これはユーザーに一定のコストをもたらします。リソースをより動的かつ柔軟にし、ユーザーを支援するにはどうすればよいですか?コストを削減しますか? しきい値を使用してコストを削減することも、私たちの最適化の方向性です。
先ほど述べた Puck&Tinker アルゴリズムは、Baidu が 100% 自社開発したベクトル検索アルゴリズムであり、検索ビジネスにおける大規模な実際の検索で検証されています。
最初の国際ベクトル検索コンテスト BigANN では、パックは参加した 4 つのデータセットすべてで 1 位にランクされました。BIGANN-10M データセットでは、同様の再現率で、Puck のパフォーマンスは HNSW の 1.7 倍に達しますが、メモリ消費量は HNSW のわずか約 21% です。Puck はオープンソースです。皆さんもhttps://github.com/baidu/puck/tree/main/docs に注目してください。
3. 事例の共有
3.1 マルチモーダルなデータ取得
ここではBESの実践事例を紹介します。
1 つ目は、ビデオ Web サイトのマルチモーダル検索シナリオにおけるベクトル機能の適用です。具体的なシナリオは、ビデオをフレームに分割し、フレームに対して画像特徴処理と時間モデリングを実行し、ニューラル ネットワークを通じてフレーム シーケンスをベクトルに変換し、BES に書き込み、マテリアル ベクトル ライブラリを構築することです。次に、BES でのベクトル検索を通じて、最も類似性の高い結果が呼び出され、上流のビジネス サービスに入力され、ビデオ マーキング、短いビデオ、パーソナライズされた推奨事項などのシナリオがサポートされます。
3.2 Qianfan大型モデルプラットフォーム
Qianfan Large Model Platform のナレッジ ベースは、大規模言語モデルの知識の質問と回答のシナリオ向けに特別に設計された製品で、顧客がアップロードしたナレッジを管理し、高速なクエリと検索機能を提供するように設計されています。
Baidu Intelligent Cloud BES に基づいて、ユーザーは効率的な方法で大量のナレッジ ベース ドキュメントを保存および取得し、企業のプライベート ドメインのナレッジを迅速に管理し、ナレッジの質問と回答のアプリケーションを構築する能力を構築できます。また、顧客データのプライバシーとセキュリティを確保できます。
ここでの申請方法は2つあります。1 つ目の方法は、大規模なモデルのナレッジ ベースを独立して展開して、ローカル ドメインでナレッジ検索アプリケーションを構築することです。2 つ目の方法は、プラグイン アプリケーションを Qianfan プラットフォームに直接バインドして、質問と回答、生成の 3 種類のアプリケーションをサポートすることです。 、タスク。
以上が共有内容のすべてです。
クリックして原文を読み、製品情報の詳細をご覧ください
- - 終わり - -
推奨読書
文生図の大規模実践: 百度による AIGC ペイント ツール探索の裏話が明らかに!
Python スクリプトによる OC コード再構築の実践のサポート (2): データ項目はモジュール アクセス データ パスのコード生成を提供します
Baidu のオープンソース高性能検索エンジン Puck について InfoQ に相談してください
検索プレゼンテーション層のシナリオ技術に関する簡単な説明 - TanGo の実践
Alibaba Cloudが深刻な障害に見舞われ、全製品が影響(復旧) Tumblr がロシアのオペレーティングシステムAurora OS 5.0 を冷却新しいUIが公開 Delphi 12とC++ Builder 12、RAD Studio 12多くのインターネット企業がHongmengプログラマーを緊急採用UNIX時間17 億時代に突入しようとしている (すでに突入している) Meituan が兵力を募集し、Hongmeng システム アプリの開発を計画Amazon が Linux 上の .NET 8 への Android の依存を取り除くために Linux ベースのオペレーティング システムを開発独立した規模はFFmpeg 6.1「Heaviside」がリリースされました