レッスン: Embedding と vector 保存

学習のねらい

前レッスンでドキュメントをチャンクに分割しました。LLMが質問とチャンクの関連性を判断するためには、テキストデータを数値のベクトルに変換する必要があります。 このレッスンでは、テキストをベクトルに変換する「Embedding」の概念、適切なEmbeddingモデルの選び方、そして生成されたベクトルを効率的に保存・検索するための簡易的な「ベクトルストア」の実装方法について学びます。

Embedding (埋め込み)とは

Embeddingとは、テキストデータ(単語、文、チャンク全体など)を、意味的に近いものが近い位置に配置されるような多次元の数値ベクトルに変換する技術です。 例えば、「リンゴ」と「ミカン」は果物として似ているため、Embeddingモデルはこれらのベクトルを近い場所に配置します。一方、「車」のベクトルは「リンゴ」から遠い場所に配置されます。

Embeddingの仕組み

Embeddingモデルは、大量のテキストデータで学習されており、テキストの単語や文脈のパターンを数値として表現する能力を持っています。 例えば、「猫がソファで眠っている」と「子猫がクッションで寝ている」という文は意味が似ているため、Embeddingによって生成されるベクトルも互いに近い距離に位置します。このベクトルの「近さ」は、コサイン類似度などの指標で測られます。

Embedding モデルの選び方

Embeddingモデルには様々な種類があり、それぞれ性能や特徴、コストが異なります。

• オープンソースモデル: Hugging Faceなどで公開されており、ローカル環境で実行できます。プライバシー要件が厳しい場合やコストを抑えたい場合に適しています。例: sentence-transformers シリーズ。
• 商用API: OpenAI、Anthropic、Voyage AI、Google Geminiなどが提供するEmbedding APIです。高品質なEmbeddingを簡単に利用できますが、APIコールごとに費用が発生します。
  • OpenAI: text-embedding-ada-002 (汎用性が高く広く使われている)
  • Voyage AI: voyage-large-2 (検索性能が高いことで知られる)
  • Google Gemini: text-embedding-004 など

モデル選定のポイント

1. 性能: 検索精度に直結するため、タスクに合った高品質なモデルを選びましょう。ベンチマーク結果などを参考にします。
2. コスト: API利用料はモデルやプロバイダーによって異なります。大量のドキュメントをEmbeddingする場合、コストは無視できません。
3. 速度: 大量のチャンクを処理する場合、Embedding生成にかかる時間も考慮が必要です。
4. 言語サポート: 英語以外の言語を扱う場合、その言語に特化したモデルや多言語対応モデルを選びます。

本レッスンでは、手軽に試せるOpenAIのtext-embedding-ada-002またはVoyage AIのモデルの使用を推奨します。

SQLite / 簡易ベクトルストア

生成したベクトルは、後で検索できるように保存しておく必要があります。本格的なRAGシステムでは、PineconeやWeaviateなどの専用の「ベクトルデータベース」が使われますが、小規模なシステムや学習目的であれば、簡易的な方法で十分です。

SQLite を使った簡易ベクトルストア

SQLiteは、軽量なファイルベースのデータベースで、Python標準ライブラリでも扱えるため、手軽にベクトルを保存するのに適しています。

• テーブル構造:
  • id (プライマリキー): 各チャンクを一意に識別するID
  • content: チャンクの元のテキスト内容
  • embedding: Embeddingベクトルを文字列(JSON形式など)で保存
  • metadata: チャンクのメタデータを文字列(JSON形式など)で保存

保存と検索のイメージ

1. 保存:
   • 各チャンクに対してEmbeddingモデルを呼び出し、ベクトルを生成します。
   • チャンクのテキスト、生成されたベクトル、メタデータをSQLiteのテーブルに挿入します。
2. 検索:
   • ユーザーからの質問をEmbeddingします。
   • 質問のベクトルと、データベースに保存されているすべてのチャンクベクトルとの類似度を計算します。
   • 類似度が高い上位K件のチャンクを検索結果として取得します。

Embedding の再計算のタイミング

一度Embeddingを生成して保存すれば、毎回再計算する必要はありません。しかし、以下のような場合には再計算が必要です。

• ドキュメントの更新/追加: 新しいドキュメントが追加されたり、既存のドキュメントが更新されたりした場合、関連するチャンクのEmbeddingを再生成する必要があります。
• Embeddingモデルの変更: より高性能なEmbeddingモデルに切り替えた場合、すべてのチャンクのEmbeddingを新しいモデルで再生成することで、検索精度が向上する可能性があります。
• チャンク分割戦略の変更: チャンクのサイズや分割方法を変更した場合も、基本的にすべてのチャンクを再生成し、Embeddingし直す必要があります。

これらの変更が発生した際に、効率的にEmbeddingを更新する仕組みも考慮しておくと良いでしょう。

まとめ

Embeddingは、テキストの意味を数値で表現し、LLMが関連情報を検索するための鍵となる技術です。適切なEmbeddingモデルを選び、生成されたベクトルを効率的に保存・管理することで、RAGシステムの検索精度を大きく左右します。 簡易的なベクトルストアとしてSQLiteを活用し、ドキュメントの更新に応じてEmbeddingを再計算する運用も視野に入れましょう。