ベクトルインデックスの概念を解明する

ChatGPT が一般公開されて以来、LLM (大規模言語モデル)、RAG (検索拡張生成)、ベクターデータベースに関する新しい話題が議論されない日はありません。テクノロジーの世界では、LLM の可能性が話題になっています。LLM は、私たちの生活を変える最新のテクノロジーとして捉えられています。ある人にとっては良い変化ですが、他の人にとっては悪い変化をもたらすかもしれません。これに加えて、検索拡張生成 (RAG) は、常に変化する知識環境に適応するための動的なソリューションとして登場しました。しかし、舞台裏ではベクトルインデックスとデータベースというもう一つの重要な要素が存在します。

LLM、RAG、ベクターデータベースについては広く徹底的に議論されてきましたが、これらのイノベーションをサポートする (ベクター) インデックスについてはあまり知られていません。この記事では、ベクターインデックスの概念をわかりやすく説明し、インデックスによって大規模なコレクション内の情報を簡単に見つけられるようになる仕組みを説明します。

1. インデックスとは何ですか?

誰もが経験したことがあるでしょう。あなたと友達は彼女の家で会うのですが、彼女が事前に教えてくれる情報は「私は大都市圏に住んでいます」ということだけです。上記の大都市圏に到着すると、次のような恥ずかしい状況に遭遇するでしょう。

Unsplash の Yim による写真

まあ、助けがなければ、彼女の居場所を見つけるのにしばらく時間がかかるでしょう!入り口にナビゲーションマップがあればよかったのですが…

インデックス作成とはまさにこれです。つまり、人 (またはデータ) がどこにいるかをすばやく見つけることです。

ヒント: イエローページ (https://www.yellowpages.com/) は、名前に基づいて人の家を見つけるのに役立つ索引です。

インデックスは、データに対するデータ取得操作の速度を向上させるために使用されるデータ構造です。言い換えれば、必要な情報をすぐに見つけられるように情報を整理する方法です。

通常、データのインデックス作成にはキーが使用されます。データはキーに基づいて順序付けされて保存され、複数のキーを使用してインデックスを作成できます。たとえば、以前のイエローページ Web サイトでは、最初のキーは姓で、2 番目のキーは名です。

インデックスには必ずしもすべてのデータが格納されるわけではありません。データ全体の中から特定のデータを素早く見つけてアクセスするために使用される重要な部分にのみ焦点を当てています。

本の最後にある索引は、この良い例です。索引には、対応する単語が使用されているページが示されています。つまり、各単語は文自体ではなくページ番号にマッピングされます。

インデックスは検索エンジンやデータベースの背後に「隠されて」おり、データ取得操作の効率と速度を向上させる上で重要な役割を果たします。

したがって、データをどのように整理するかの選択は非常に重要であり、状況に応じて異なります。

たとえば、イエローページの例では、インデックスが電話番号で整理されていても、名前しか知らなければ、住所を見つけるのは非常に困難です。

情報はそこにあります。最終的には見つかりますが、必要な時間を考えると試すことすらできません。一方、イエローページでは、ページを一目見るだけで、前に戻る必要があるのか、それとも前に進む必要があるのかを正確に判断できます。辞書の順序付けにより、ほぼ対数的な検索が可能になります。このため、インデックスの選択は非常に重要です。

一般的に言えば、インデックスには非常に明確な目的があります。インデックスは、データの高速な挿入や取得を実行するように設計することも、範囲クエリ (「今年の 5 月 1 日から 8 月 15 日までのすべてのデータを取得する」) などのより特殊なクエリを実行するように設計することもできます。最適化する操作の選択によって、インデックスの外観が決まります。

オンライントランザクション処理 (OLTP) データベースとオンライン分析処理 (OLAP) データベースの主な違いは、最適化する操作の選択です。OLTP は行の操作 (エントリの更新など) に重点を置いていますが、OLAP データベースは列の操作に重点を置いています。 2 種類のデータベースは同じ操作を対象としていないため、同じインデックスは使用されません。

（１）インデックスとデータ構造の違いは何ですか？

データ構造 (https://w.wiki/7ma9) は、データを効率的にアクセスおよび操作できるようにコンピューター内でデータを整理して保存する方法です。この説明では、インデックスとデータ構造の違いがわかりにくい場合があります。では、それらの違いは何でしょうか?

つまり、インデックスは主にデータの挿入、検索、並べ替え、フィルタリングに使用されますが、データ構造はより一般的です。インデックスはデータ構造を使用して構築されますが、通常はデータ自体は保存されません。

映画のデータベースについて考えると、インデックスが更新されるたびに大きなファイルを移動することは望ましくありません。ファイル自体ではなく、ファイルへのポインターを保存しているからです。ポインタは、ディスク上のファイルのアドレスと考えることができます。

インデックスの概要がわかったので、数値の例に焦点を当ててみましょう。一般的な（数値）インデックスをいくつか示します。

逆インデックス
ハッシュインデックス
Bツリー
位置依存ハッシュ (LSH)

インデックスの仕組みをよりよく理解するために、最も基本的なインデックスの 1 つである転置インデックスを見てみましょう。

（２）逆索引

転置インデックスは、検索エンジンで使用される標準的なインデックスです。

情報の場所を素早く見つけられるように設計されており、検索時間を最適化するように設計されています。

つまり、転置インデックスは、本の索引のように、コンテンツをその場所にマッピングします。

多くの場合、特徴をその特徴を持つデータにマッピングするために使用されます。

たとえば、同じ建物に誰が住んでいるかを知りたいとします。

まず、各建物に対応する名前のテーブルが必要です (このテーブルは Alice を見つけるのに役立つはずです)。

このテーブルは、誰かがそのエリアに到着したり、そのエリアから出たりするたびに更新されます。

このテーブルで建物 B に住んでいる人を見つけたい場合は、テーブル全体を反復処理する必要があります。

これは技術的には可能ですが、計算時間はテーブルのサイズに応じて直線的に増加するため、拡張できません。

そのエリアにあるアパートの数を考えてみましょう。すべてのアーカイブを 1 つずつ調べて B 棟の住人全員を見つけようとすると、かなりの時間がかかります。

もう 1 つの解決策は、逆インデックスを使用することです。つまり、建物をキーとして使い、そこに住んでいる人にリンクしたテーブルを維持します。

このテーブルは以前のテーブルと同時に維持されます。新しい人物を追加または削除するコストは以前よりもわずかに高くなりますが、取得時間はほぼゼロに短縮されました。

建物 B に住んでいる人を見つけるには、この表の「建物 B」の行にアクセスするだけで結果が得られます。

もう一つの典型的な例を挙げましょう。逆電話番号検索は、電話番号の逆インデックスでもあります。

実際には、転置インデックスは単なる (ユーザー、関心) のペアよりも複雑なデータを処理するため、もう少し複雑になります。インデックスは通常、ハッシュテーブル (https://w.wiki/7mdQ) に保存されます。

転置インデックスは比較的単純ですが、検索エンジンで最も一般的なインデックスの 1 つです。

（３）索引とデータベース

データベースはインデックスに基づいて構築されます。インデックスは、データベースデータへのポインターまたは参照を格納することにより、データベース内のデータ検索を強化します。実際のデータは保存されませんが、データにすばやくアクセスする手段として機能し、クエリのパフォーマンスが大幅に向上します。

データベースは単なるインデックスではなく、包括的なデータ管理システムです。実際のデータを保存、整理、管理し、データの整合性を強化し、トランザクションを処理し、インデックス作成以外のさまざまな機能を提供することで、データの保存と操作の中心ハブになります。インデックスはデータベース内のデータ取得を高速化しますが、データベースはデータの保存、管理、取得のための完全なエコシステムです。

つまり、インデックスはデータベース内の道標のようなもので、探しているデータへの道を示します。対照的に、データベースは実際のデータが存在するリポジトリであり、そのデータを管理および操作するためのさまざまなツールと機能が備わっています。

使用ケースによっては、データを完全に管理するとコストがかかりすぎる可能性があるため、データベース全体ではなくインデックスのみが必要になる場合があります。

2. ベクトルインデックスとベクトルデータベース

（１）ベクトルインデックスとは何ですか？

つまり、ベクトルインデックスは、キーがベクトルであるインデックスです。

転置インデックスの例では、キーは単語 (趣味と名前) です。ベクトルのインデックス作成では、固定サイズの数値のシーケンスであるベクトルを操作します。

サイズ4のベクトル2つ

「数学は苦手だからベクトルは使いたくない」という声が聞こえてきそうです。

心配しないでください。ベクトルのインデックスを理解するために数学が得意である必要はありません。

知っておく必要があるのは、ベクトルを使用すると、強力で最適化された操作に依存できるようになるということです。

おそらく最初に自問する質問は、「あなたのベクトルの何がそんなに興味深いのか？」でしょう。

ついにアリスを彼女の家で見つけ、今度は何か食べるものを探したいとします。一番近いレストランを探した方がいいかもしれません。つまり、レストランのリストを検索すると、レストラン、その特別メニュー、住所が記載された表が表示されます。見つけられる情報を見てみましょう:

それは役に立たないように思えますね。唯一の選択肢は、リストを調べて、住所を一つずつ読み、それが自分からどれくらい近いかを手動で評価することです。最も近い場所を自動的にランク付けすることもできますが、生の住所に基づいて距離を計算するのは困難です (2 つの通りが近くにある場合でも名前が異なる場合があります)。

各レストランの正確な緯度と経度を表す GPS 位置の表があると想像してください。

各位置はサイズ 2 のベクトルです。これらのベクトルを使用すると、簡単で高速な計算で自分の位置までの距離を簡単に計算できます。すると、最も近いレストラン、つまり、あなたに最も近いレストランをすぐに検索できます。

今なら最寄りのレストランを簡単に見つけることができます！

興味深い点は、ベクトル (この場合は GPS 位置) に基づいてテーブルを直接インデックス付けすることで、インデックス付けを最適化し、距離が最も短いエントリをすばやく見つけることができることです。

ベクトルインデックスは、特定のベクトルに最も近い、または最も類似するベクトルを効率的に取得するように設計された特殊なインデックスです。これらのインデックスは、最適化された数学演算を利用して、最も類似したベクトルを効率的に識別します。

この場合、使用される距離は古典的な距離ですが、既存のすべての距離または類似性には、コサイン類似度測定などのインデックスが使用されます。

Locality-Sensitive Hashing (LSH) は、データセット内で最も類似した k 個のデータポイントを見つけるために最も広く使用されているインデックスの 1 つであり、さまざまな距離や類似性に対して機能します。

「それはいいのですが、私のデータベースではベクトルを使用していません」。

これが面白いところです。何でもベクトルに変換できるのです。

単純にバイナリ表現を採用するのはノイズが含まれる可能性があるため非効率的であるため、データの特性を保持する表現を見つけることが重要です。

さまざまな情報をベクトルとして表現し、ベクトルインデックスを使用することは、システム効率を向上させる標準的なアプローチになっています。ベクトル化は芸術になりました。

たとえば、画像のデータセットがあり、特定の画像に最も類似した画像を見つけることができるデータベースが必要な場合は、画像の SIFT 記述子を使用できます。

（２）ベクターインデックスとベクターデータベースの違いは何ですか？

ベクターインデックスとベクターデータベースの違いは、インデックスとデータベースの違いと同じです。インデックスは、データが配置されている場所をすばやく見つけられるように設計されていますが、ベクターデータベースは、ベクターインデックスを使用して検索クエリをすばやく実行しますが、追加の操作とプロパティを提供しながらデータを保存および維持します。

3. LLM と RAG の関係は何ですか?

ベクトルインデックスについて理解できたところで、LLM と RAG に関する多くの議論でベクトルインデックスについても議論されているのはなぜかと疑問に思うかもしれません。その理由を理解するために、まず検索拡張生成 (RAG) とは何かを簡単に説明しましょう。 AG は、LLM の固有の限界、つまり限られた知識に対する独創的な解決策です。

LLM はトレーニングに使用されたデータのみを知っています。知識を増やすための 1 つの手法はプロンプトエンジニアリングです。これは、クエリプロンプトに追加データを統合します。「このデータ {data} が与えられた場合、この質問に答えてください: {question}」。

このアプローチはうまく機能しますが、スケーラビリティという新たな課題に直面しています。ヒントのサイズは制限されているだけでなく、含まれるデータが増えるほど、クエリのコストが高くなります。

これを克服するために、検索拡張生成では、最も類似したデータのみを挿入することでデータの量を制限します。ここで、ベクトルインデックスが役立ちます。

仕組みは次のとおりです:

すべての文書は最初にLLM（1）を使用してベクトルに変換されます。具体的には、LLM のエンコーダー部分が使用されます。

これらのベクトルはベクトルインデックス（2）内の文書をインデックスするためのキーワードとして使用されます。

クエリを実行する際、クエリはLLM（3）を使用してベクトル化されます。得られたベクトルはベクトルインデックスで照会され、最も類似した文書が取得されます（4）。これらの文書はヒントエンジニアリング（5）を使用してクエリに回答するために使用されます。

検索拡張生成（RAG）はLLMとベクトルインデックスに依存します

それでおしまい！

ご覧のとおり、LLM と同様に、RAG でもベクトルインデックスが中心的な役割を果たします。

ベクトルインデックスの代わりにベクトルデータベースを使用することを好む人もいます。複数のアプリケーションで同じデータを再利用する限り、問題はありません。ただし、検索効率やアプリケーションごとにインデックスを定義する柔軟性が主な関心事である場合は、単一のベクトルインデックスを展開する方が簡単で高速になることがよくあります。

結論は

これで、LLM と RAG に関する熱心な議論に参加するために必要な背景知識がすべて身についたと思います。

インデックスはデータ検索において中心的な役割を果たします。データ取得は今後もデータテクノロジーの重要な要素であり続ける可能性が高いため、インデックス作成 (ベクターインデックス作成を含む) が何であるかを理解することが重要です。

より高度なインデックス作成テクニックを学習したい場合は、LSH に関する私の記事を読むことをお勧めします。より実践的なことを学びたい場合や、リアルタイム検索拡張生成 (RAG) を実際に体験したい場合は、これらの技術の威力を直接体験できる LLM アプリケーション (https://github.com/pathwaycom/llm-app) を検討してください。