LLMアプリケーションで使用する Vector Databaseの比較 2024/03/30 第33回勉強会

自己紹介 ● 名前: 西岡 賢一郎 ○ Twitter: @ken_nishi ○ note: https://note.com/kenichiro ○ YouTube: 【経営xデータサイエンスx開発】西岡 賢一郎のチャンネル (https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg) ● 経歴 ○ 東京大学で位置予測アルゴリズムを研究し博士 (学術) を取得 ○ 東京大学の博士課程在学中にデータサイエンスをもとにしたサービスを提供する株式会社ト ライディアを設立 ○ トライディアを別のIT会社に売却し、CTOとして3年半務め、2021年10月末にCTOを退職 ○ CDPのスタートアップ (Sr. PdM)・株式会社データインフォームド (CEO)・株式会社ディース タッツ (CTO) ○ 自社および他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験

本日のお話 ● はじめに ● LLMアプリケーションとVector Database ● Vector Databaseの概要 ● Vector Databaseの種類と比較 ● Vector Database選択のためのガイドライン

はじめに プレゼンテーションの目的: LLMアプリケーションに適したVector Databaseの 選択を助けること ● 概要: Vector Databaseの基本概念、主要な特徴、種類、応用事例、選択の ためのガイドラインを提示 ● 主要なトピック: LLMアプリケーション、Vector Databaseの必要性、技術 的課題、LangChainとRAG

今回の話に含まれないもの ● RAG (Retrieval Augmented Generation) の仕組み ● 最近傍探索のアルゴリズムの詳細 ● Vector Databaseやライブラリの詳細

LLMアプリケーションとは ● LLMの定義 ○ Large Language Models (LLM) ○ AIモデルが大規模なテキストデータから言語の構造や意味を学習 ● LLMの特徴 ○ 言語の本質的な理解 ○ 様々なタスクを実行可能 ● LLMアプリケーションの事例 ○ 文章生成 ■ ニュース記事の自動要約 ■ 小説の続きを書くクリエイティブなタスク ○ 感情分析 ○ 翻訳 ○ 対話システム ■ チャットボット ■ 仮想アシスタント ● LLMアプリケーション開発の課題: 大量の非構造化データの効果的な入力方法

Vector Databaseの必要性 ● 構造化されていないデータの増加: テキスト、画像、 動画などの非構造化データが急増 ● Vector Databaseによる解決策: ○ 非構造化データをベクトル表現に変換し、効 率的に格納・検索 ○ 類似度検索により、関連性の高いデータを高 速に取得

Vector Databaseの概要

Vector Databaseの基本概念 ● Vector Database: 高次元ベクトルデータを格納・検索するためのデータ ベース ● 主要な機能とメリット: ○ 高速な類似度検索: コサイン類似度、ユークリッド距離など ○ スケーラビリティ: 大規模データにも対応 ○ 柔軟なデータモデル: 構造化・非構造化データを統合

Vector Databaseの主要な特徴 ● 高速な (近似) 最近傍探索 ● スケーラビリティ: 水平・垂直スケーリングによる拡張性 ● マルチテナンシー: 複数のユーザーやアプリケーションをサポート ● 豊富なAPI: RESTful API、Python、JavaなどのSDK ● ユーザーインターフェース (連携): Webベースの管理画面、可視化ツールな ど

Vector Databaseの種類と比較

LangChainでサポートされているVector Database? ● Vectore Storeとは、埋め込みデータの保存とベクト ル検索の実行をやってくれるLangChainの機能の一 つ ● LangChainのVectore Storeのページにいくと Chroma, FAISS, Lanceの3つの事例が紹介されてい る ○ https://python.langchain.com/docs/modul es/data_connection/vectorstores/ ● LangChainを使うならこの3つから選べばいいかと思 いきや実はそうではない。

LangChainがサポートしているVector DB ● LangChainがサポートしているVector Databaseは ソースコードを確認するのが一番早い ○ https://github.com/langchain-ai/langchai n/tree/master/libs/langchain/langchain/v ectorstores ● Vector Storeで使えるものはVector Library (Vectore Databaseとの違いは後のスライドで説明) も含むと約50種類

Vector Databaseの種類 Vector DB 特徴 対象ユースケース Milvus ● 高いパフォーマンスと拡張性 ● 大規模データセット対応 ● 複雑なインデックス構築 ● 大規模データセットを扱うアプリケーション Weaviate ● RESTful APIとGraphQLサポート ● マルチモーダル検索 ● Dockerを使った簡単デプロイ ● マルチモーダル検索が必要な場合 ● GraphQLを使いたい場合 pgvector ● PostgreSQLの拡張機能 ● 既存のPostgreSQLインフラを活用可能 ● SQLでベクトル検索 ● 既存のPostgreSQLインフラを活用したい場合 ● SQLでベクトル検索をしたい場合 Chromadb ● シンプルで使いやすい API ● 埋め込みデータベースとしても利用可能 ● マルチモーダル検索サポート ● 小規模プロジェクト ● シンプルなVector Databaseを探している場合

Vector DatabaseとVector Libraryの違い 特徴 Vector Library Vector Database データの保存 ベクトルのみ ベクトルとオブジェクトの両方 データの更新（CRUD） 一部（例: hnswlib）を除き、インデック スは不変で更新不可 データの追加、削除、更新が可能 インポート中のクエリ 一部（例: hnswlib）を除き、インポート 中のクエリは不可 インポート中でもリアルタイムにクエリ可能 速度 インメモリ検索に最適化され、通常は データベースより高速 エンドツーエンドの処理（ベクトル検索、永続ストレージからのオブジェクト取得、 ネットワークリクエストなど）に最適化 永続性と耐障害性 スナップショットのみ。クラッシュからの 回復機能なし 即時の永続化。耐障害性あり シャーディングとレプリケーショ ン サポートなし（一部のサードパーティプ ロジェクトで可能） サポートあり（例: Weaviateはv1.17からレプリケーションに対応） バックアップ、デプロイ、 SDK 自前で構築が必要 自動バックアップ、Dockerなどのデプロイエコシステム、複数言語の SDKを提供 参考: https://weaviate.io/blog/vector-library-vs-vector-database#feature-comparison---library-versus-database

Vector Database選択のためのガイドライン

Vector Database選択のためのガイドライン ● プロジェクトの特定ニーズの評価 ○ データの種類とサイズ：画像、テキスト、音声など、扱うデータの種類と量 ○ クエリのタイプと頻度：リアルタイム検索、バッチ処理、ストリーミングデータの処理能力 ○ パフォーマンスとレイテンシー要件：応答時間とスループットのニーズ ● 技術的・運用的考慮事項 ○ スケーラビリティと拡張性：将来のデータ成長に対応できるか。 ○ インフラストラクチャ：クラウドベース、オンプレミス、ハイブリッド ○ データの安全性とプライバシー：暗号化、アクセス制御、コンプライアンス ● 汎用的な評価基準 ○ 技術サポートとコミュニティの活動：開発者ドキュメント、チュートリアル、フォーラムの 質 ○ ベンダーの安定性と将来性：企業の健全性、製品のロードマップ ○ コストとライセンス：使用料金、オープンソースライセンスの条件

ベンチマークテストは比較サイトを利用 ● すべてを自分で検証する必要はなく、ANN Benchmarksのようなサイトを使うのがおすすめ https://ann-benchmarks.com/ ● よく使われる指標を2つ ○ Recall ■ 検索の正確性を測る指標。 ■ 検索された正しい最近傍の数を、実際 の最近傍の総数で割った比率。 ■ 値が高いほど、正確な検索結果を得ら れていることを示す。 ○ Queries per second (QPS)（クエリ毎秒） ■ ライブラリの処理速度を測る指標。 ■ 1秒あたりに処理できるクエリの数。 ■ 値が大きいほど、高速にデータを検索 できることを示す。

Embedding Modelの変更の可能性も考慮に入れる ● 非構造化データをベクトル化するEmbedding Modelは、変更される可能性が あることを考慮しておく ● Modelが変われば当然ベクトルもすべて生成し直す必要がある ● Embedding Modelを変更する理由 ○ 新しいモデルのリリース (e.g. OpenAIの第3世代のEmbedding Modelのリリース) ○ APIからセルフホスティングのモデルに移行 (e.g. OpenAI APIから自社サーバにインストール された日本語特化のEmbedding Modelを使う)

pgvector ● PostgreSQLの拡張であるため、PostgreSQLの知識 が必要 ○ git clone → make & make install ○ CREATE EXTENSION vector; ● PostgreSQLなので経験のある人材を探すことは簡単 ● デフォルトのインデックスを使うと最近傍探索であ ることに注意 ● 近似最近傍探索 (ANN) を利用することも可能 ○ HNSW ○ IVFFlat ● ベクター用の特殊な演算使用できる ○ <-> : Euclidean Distance ○ <#> : Negative Inner Product ○ <=> : Cosine Distance

Chroma DB ● https://www.trychroma.com/ ● 導入はトップクラスの簡単さ ○ テストで使うために必要な作業を極端になく しており、Pythonを実行しているだけで Vector Databaseを立ち上げることが可能 ○ データの永続化はもちろんのこと、サーバー モードでの起動もできる ● 名前がすこしググりにくい (Chrome関連情報がヒッ トしてしまう) ● Embedding (デフォルトでall-MiniLM-L6-v2) の機 能も持ち合わせているが、別のEmbedding Modelを 使うケースが多いので利点とはならない。

まとめ ● LLMアプリケーションで、非構造化データを取り扱ったRAGなどを構築する 場合はVector Databaseが必要となってくる ● LangChainは主要なVector Databaseにほぼ対応しているので、LangChain によるVector Databaseの制限はないと考えて良い ● Vector Databaseを選ぶ際は、プロジェクトの特定ニーズの評価、技術的・ 運用的考慮事項、汎用的な評価基準などを考慮しながら検討する ● Embedding Modelが変更される可能性も考慮して、Vector Databaseの運用 について考えていく必要がある