はじめに
モチベーションとしては生成AI関連としてここ3～4ヶ月でRAG構成（Retrieval-Augmented Generation）の記事が目に止まるようになり、RAGによるメリット等概要は知ってるつもりでしたが、具体的な構成ってどうなるの？というのは、あやふやだったりしまして、、、調べるとベクトルDBが既に盛り上がってましたので、遅れてはマズイ！とおもいお勉強かねて記事にさせてもらいました。
RAGとは
RAGは、大規模言語モデル(LLM)と外部検索システム（つまりDB）を組み合わせた設計パターンの1つで、LLM単体では回答するベースとなる知識が訓練データに依存しますが、RAGを用いることで、LLMはリアルタイムで外部の情報源にアクセスし、より正確な回答を生成することが可能になります。
また、以下は私のRAG構成イメージ図になりますが、RAG構成は後述するベクトルDBだけでなく、従来のリレーショナルDBであっても成り立つみたいでした。
何を採用するかは「どこに何の情報があり、何とLLMを組み合わせたいか」によって様々かと思います。会社導入シナリオを妄想したときに、まずは現行稼働しているRDBMSがあるからそれを活用してLLMで何か出来ないか！？ってパターンは結構ありそうだなぁと感じました。
※グラウンディングというワードもありますが、これはLLMのハルシネーションを抑制する概念としての手法で、RAGは設計としての手法となります。
ベクトルデータベースとは
ベクトルデータベースとは、端的には情報をベクトル化したものをデータオブジェクトとして保存するデータベースのことです。以下の特徴があります。
- インデクシング
画像、音声、テキストからベクトルを抽出し、インデックスへ保管すします。ベクトル化にはLLMでも使われているTransformersを使うのが主流なようです。またインデックス作成に何種類かアルゴリズムもありチューニング要素になる（勉強中です＞＜） - データ検索
類似するベクトルを高速に検索するために、現在は近似最近傍探索アルゴリズムが主流のようです。近年はデータセットも大規模なケースが多いこともあり、低レイテンシに検索できることが重要視されています。 - スケーラビリティ
大量のデータと高いクエリ負荷に対応できるようにスケールアウト可能な設計されています。クラウドネイティブ思考からkubernetes前提の製品らはスケーラビリティの考慮がほぼされています。
ベクトルDB製品
ネットで調べると、よく出てきますがここでも概要レベルでご紹介します。
（今回はパブリッククラウド上のサービスは並べてません。OSSが多いです）
-
Milvus/Zilliz
多様なアルゴリズムと高いスケーラビリティが評価されています。特に、ディスク上のベクトルインデックスの効率的な実装を提供する点で、他のベンダーと差別化しています。 -
LanceDB
1番の特徴は、マルチモーダルデータ（画像、オーディオ、テキストなど）と、革新的なカラム型データフォーマットへの対応です。これにより、効率的なデータストレージと高速な検索が可能になります。 -
Pinecone
セットアップの容易さと、完全なクラウドネイティブ設計により際立っています。ドキュメントが充実しているそうで、ベクトル化やベクトルインデックスに関する事前知識がなくても、迅速にシステムを稼働させることができます。 -
Vald
高度に分散されたアーキテクチャと、高速なANN検索アルゴリズム（NGT）を使用する点が特徴です。これにより、ANNアルゴリズムとして最速の部類に入る効率的なベクトルインデックスを実現しています。 -
Qdrant
Rustで構築されており、その性能とリソース効率が特に注目されています。Dockerを介して簡単にシステムを立ち上げることができ、スケーラビリティはパーティショニングとRaft合意プロトコルによって達成されます。 -
Vespa
エンタープライズ市場に対応した強力なハイブリッド検索機能を提供します。特にキーワード検索とカスタムベクトル検索の組み合わせにより、高速で正確、スケーラブルな検索結果を生成します。 -
Weaviate
Dockerを利用した簡単なセットアッププロセスと、ミリ秒未満の高速な検索結果を提供するキーワード検索とベクトル検索の両方をサポートする点が強みです -
Elasticsearch
エンタープライズ向けの大規模検索エンジンとして有名かと思いますが、ベクトルDBとしての拡張機能をもっており、既存システムとして持っている所ならば、導入の敷居はかなり低いかと思います。
気になった機能
-
ハイブリッド検索機能
Vespaで実装されているハイブリッド検索機能は、キーワード検索とベクトル検索を組み合わせ回答の類似性を再ランク付けすることで、ユーザが間違って解釈しているキーワードに対しても回答精度を高めることができます。 -
マルチモーダルデータ
LanceDBはマルチモーダルデータ（画像、オーディオ、テキスト）に対して分散インデックス作成と検索を行うように設計されており、LLM側もマルチモーダル対応していれば、テキスト以外のフォーマットでもRAG構成が組み込めるのではと思いました（いつか検証してみたい）
何を選んだらいい？
今は切磋琢磨している時期に思いますので、いくつか観点はあるかと思います。
検索機能
多くはハイブリット検索機能を実装済みのようですが、ドキュメントデータベースとベクトルデータベースの両方が必要なります。機能要件と合わせ、運用コストやリソースをとりあえず最小にしたい希望があれば、キーワード検索のみ機能する構成や製品を選ぶのも選択肢と思いました。
ホスティング
SaaS化による収益プランを多くの製品で持っているので、それを使うのが導入・運用は楽かと思います。自分たちでデプロイする場合、多くはクラウドネイティブ構成のため、オンプレミスかEKSのようなPaaSサービスを使うも良いかと思いますが、オンプレミスだとKubernetesの構築・運用のスキルも必要になります。ただChromaとLanceDBの場合は組み込み型の提供があるため、非常に簡単にセットアップできると思います。
コスト
設備コストは長期的みればオンプレミスが安くなる傾向になるので、システムのライフサイクルを念頭に確認した方が良さそうです。早めのロードマップとデータ規模感に合わせて、ホスティングを変えることで、
が、長期的に見ればオンプレミスの方が基盤コストは安くなります。
また規模によりますが、データは溜めるほどコストになるので、古いデータ、利用頻度の低いデータは削除または安いストレージ領域にスナップショットするなどコスト最適化の対処が必要になります。（ベクトルDBのデータ規模感がまだちゃんと調べられてない点もありますが、データ管理機能での製品差分は別途調査したいと思います）
運用
サービスレベル高く考えるならクラウドネイティブ構成であれば、ローリングアップデートで対処出来るように思いますが、先述の通り日々の運用は手がかかると思います。組み込みの場合は別途調査の上、バージョンアップ時のことを検討しておく必要がありそうです。
認証・アクセス制御
組み合わせるデータ特性や利用者のドメインの広さ合わせて、アクセス元のユーザの立場や所属を読み取り、検索可能とする範囲を制御する必要があると思います。LLMがユーザ情報を把握し、適切な権限でアクセスするために各製品のセキュリティ機能は把握しておく必要があります。（こちらも別途調査又は検証してみたいと思います）
終わりに
今回は机上調べただけ（投稿回数稼ぎ目的あり、、笑）で、検証したいこともたくさん出来ましたので、続きのような形で投稿できたらと思います。
幅広いサービスに適用できることが期待されているLLMだけあり、短期間さぼっただけで知らないこと多かったので、やはり技術アンテナはより高めておく必要あると感じました。