人気のインメモリ・データ構造ストアであるRedisは、最近、強化されたRedisクエリエンジンをリリースした。この開発は、ベクトル・データベースがGenAIアプリケーションの検索拡張世代(RAG)における重要性から脚光を浴びている時に行われた。
Redis社はクエリエンジンの大幅な改良を発表し、マルチスレッディングを利用して、低レイテンシーを維持しながらクエリのスループットを向上させた。Redis社は次のように述べている。
クエリがインデックスに同時にアクセス可能にすることで、Redisを効果的に垂直方向にスケール可能になり、Redisの操作とクエリのスループットの両方をスケール可能になりました。
下図は垂直スケーリングを表している。
出典:Redisの設計の選択 - スケールアップとスケールアウト
Redis社は、データ量が数億ドキュメントに増加し、複雑なクエリがスループットを制限する可能性がある中で、この進歩は非常に重要であると強調している。Redisは、レスポンスはミリ秒以下のレイテンシーを維持し、クエリの平均レイテンシーは10ミリ秒以下であると主張している。
Redis社は、従来のシングルスレッド・アーキテクチャの限界を認めている。シングルスレッドで長時間クエリを実行すると、特に転置インデックスを使用したデータ検索のような処理では、輻輳を引き起こし、全体のスループットを低下させる可能性があると説明している。
同社はさらに、検索操作の複雑さについて詳しく説明している。
検索はO(1)の時間複雑性を持つコマンドではありません。検索は通常、複数のクエリー述語に従うために、インデックスの複数のスキャンを組み合わせます。これらのスキャンは通常、対数時間の複雑さO(log(n))で行われます。ここで、nはインデックスによってマップされるデータポイントの数です。
Redis社は、新しいマルチスレッド・アプローチがこれらの課題に効果的に対処し、Redisが単純な操作では高い性能を維持しながら、ベクトル類似検索のような計算集約的な操作ではスループットを大幅に向上させることを可能にすると主張している。
Redisは、「検索を効率的に拡張するには、データ負荷を水平方向(外に向かう方向)に分散させることと、インデックスへのアクセス(上に向かう方向)で並行処理を可能にする垂直方向のマルチスレッドを組み合わせる必要がある」と強調している。
出典:シングルシャードRedisマルチスレッドクエリエンジンのメインスレッドとスレッドプール
上の図は、複数のクエリがそれぞれ別のスレッドで実行される、新しいアーキテクチャを示している。Redis社は、3段階のプロセスを概説している。
クエリコンテキスト(プランニング)はメインスレッドで準備され、共有キューにキューイングされます。ここから、スレッドがキューを消費し、他のスレッドと同時にクエリパイプラインを実行します。これにより、他のRedisコマンドや追加クエリの準備とキューイングなど、より多くのリクエストを処理するためにメインスレッドを維持したまま、複数のクエリーを同時に実行できます。終了すると、クエリ結果はメインスレッドに送り返されます。
Redisは、この新しいアーキテクチャによって、標準的なRedis操作に対するメインスレッドの応答性を維持しながら、同時に複数の複雑なクエリを処理可能になり、システム全体のスループットとスケーラビリティが向上したと主張している。
Redisは、クエリエンジンの性能を検証するために広範なベンチマークを実施し、ベクトルデータベースプロバイダーの3つのセグメント(純粋なベクトルデータベース、ベクトル機能を備えた汎用データベース、完全に管理されたインメモリRedisクラウドサービスプロバイダー(CSP))と比較した。Redisは、そのアップグレードされたクエリエンジンが、スピードとスケーラビリティの両方で純粋なベクトルデータベースを凌駕し、総合的なパフォーマンスでは汎用データベースとフルマネージドインメモリRedis CSPを大きく上回るとしている。
ベクトル・データベース市場はここ数年で大きな盛り上がりを見せており、数多くの製品がこの分野に氾濫している。この急増は、新規参入者にとってもユーザーにとっても厳しい環境を作り出している。業界の専門家は、市場はすでにベクトル・データベースのオプションで飽和状態にあり、新製品が差別化を図り、独自の価値提案を見出すことが難しくなっていると指摘する。
Redditの主任エンジニア、Doug Turnbull氏はこう指摘する。
しかし、ベクトル検索には何十もの選択肢があります。そのような選択肢の「顧客」として、この分野は圧倒されてしまいます。ベクトル検索はますます問題ではなくなっています。現実の検索を解決するための難しい問題は、単にベクトルを取得することとは関連するものではなく、その周りのすべてです。
この視点は、AI主導のデータ検索におけるより広範な課題に対処する包括的なソリューションの必要性を強調している。
新しいRedisクエリエンジンは、従来のものと比べてクエリ処理能力が16倍向上したと主張している。特に、このクエリエンジンは、リアルタイムのRAGに依存し、ベクトル・データベースからデータを取得する間に複数のステップを迅速に処理しなければならないチャットボットなどのGenAIアプリケーションのニーズに対応している。
Gmailの生みの親であるPaul Buchheit氏は、「100msルール」を紹介した。このルールでは、すべてのインタラクションは100ミリ秒未満で発生し、ユーザーに瞬時に感じられるべきであるとしている。
RAGアーキテクチャのレイテンシ境界の内訳を見ると、ネットワークラウンドトリップ、LLM処理、GenAIアプリ操作、ベクトルデータベースクエリで、エンドツーエンドの平均応答時間は1,513ミリ秒(1.5秒)となっている。この課題に対処するため、開発者はデータアーキテクチャを再考し、100msルールに近づくリアルタイムGenAIアプリケーションを構築しなければならない。リアルタイムRAGは、AI機能を活用しながらアプリケーションのスピードを維持し、ユーザーがほぼ瞬時のインタラクションを体験し、アプリケーションへの関与を維持するために極めて重要である。
Vectera社のOfer Mendelevitch氏は、ベクトル・データベースのパフォーマンスは極めて重要だが、それはAIアプリケーション開発におけるより大きな技術的状況の一部であることを思い出させてくれる。
RAGが現在、自分のデータで信頼できるLLMベースのアプリケーションを構築するためのもっとも一般的な方法論であることは事実であり、全体的な検索機能(RAGのR)の一部として強力なセマンティック検索機能が必要であることは確かですが、ベクトル・データベースはその全体的なスタックの1ピースに過ぎず、もっとも重要なものでもないでしょう。
RisingWave Labsの創設者であるYingjun Wu氏は、ベクトル・データベースの開発について補足的な見解を示している。
新しいベクトル・データベースのプロジェクトに投資するよりも、既存のデータベースに集中し、ベクトルエンジンによってデータベースを強化し、より堅牢で強力なものにする機会を探る方が望ましいでしょう。
既存のインフラを強化するというRedisのアプローチは、この観点に合致しており、開発者により統合された効率的なソリューションを提供できる可能性がある。
包括的なベンチマーク・プロセスでは、インジェストと検索の両方のワークロードに取り組んだ。インジェストに関しては、Redisは階層型ナビゲーティブ・スモールワールド(HNSW)アルゴリズムと近似最近傍(ANN)検索を使用して、データのインジェストとインデックス作成にかかる時間を測定した。クエリについては、純粋なk-nearest neighbors(k-NN)検索に焦点を当て、スループットをRPS(requests per second)で測定し、クライアント側の平均待ち時間(ラウンドトリップタイム(RTT)を含む)を測定した。
Redisは、 gist-960-euclidean、glove-100-angular、deep-image-96-angular、dbpedia-openai-1M-angularのデータセットに対してベンチマークを行い、異なるベクトル次元と距離関数で包括的なテストを行った。シミュレーション環境には、Qdrantのvector-db-benchmarkを含む業界標準のベンチマークツールを採用し、信頼性と再現性の高い結果を実現した。
Redisはベンチマークで素晴らしいパフォーマンスを報告しているが、他の業界プレイヤーの視点を考慮することも重要だ。Redisの競合他社が実施した比較研究では、Redisの能力について異なる見解が示されている。さらに、Database-as-a-Service(DBaaS)のマネージド・プラットフォーム・プロバイダーであるScaleGridは、Redisに関する洞察を共有している。
Redisは新しいクエリエンジンをRedis Softwareですぐに利用可能にし、秋にはRedis Cloud向けにリリースする予定だ。LangChainフレームワークを使用したRedisベクトル・データベースの動作を見るには、このデモをチェックしてほしい。これは、これらのテクノロジを実際のシナリオに適用する方法を実際に垣間見ることができる。ベクトル・データベースの世界については、このPostgresMLのプレゼンテーションと、Pineconeベクトル・データベースの創設者兼CEOであるEdo Liberty氏が、RAGアプリケーションにおけるこれらの技術についての見解を語ったInfoQのポッドキャストを試してみてほしい。