ストーリー
テキストのベクトル化
Embeddingとは
Embeddingは、テキスト(単語、文、段落)を固定長の数値ベクトルに変換する処理です。
Embedding変換の例:
"RAGシステムの構築方法" → [0.023, -0.156, 0.892, ..., 0.445]
↑ 1536次元のベクトル(OpenAI text-embedding-3-small)
"検索拡張生成の実装手順" → [0.019, -0.148, 0.887, ..., 0.451]
↑ 意味が近いため、ベクトルも近い
"今日の天気予報" → [0.756, 0.312, -0.045, ..., -0.221]
↑ 意味が異なるため、ベクトルも遠い
意味的類似度の計算
ベクトル間の類似度を計算する主要な手法は以下の通りです。
| 距離/類似度指標 | 計算方法 | 値の範囲 | 特徴 |
|---|---|---|---|
| コサイン類似度 | ベクトル間の角度 | -1 ~ 1 | 最も一般的。ベクトルの大きさに依存しない |
| ユークリッド距離 | ベクトル間の直線距離 | 0 ~ 無限大 | 直感的だが次元の呪いに弱い |
| 内積(ドット積) | ベクトルの内積 | 負 ~ 正 | 正規化済みベクトルではコサイン類似度と同等 |
コサイン類似度の計算:
similarity(A, B) = (A・B) / (|A| × |B|)
例:
"RAGシステム構築" vs "検索拡張生成実装" → 0.92(非常に類似)
"RAGシステム構築" vs "今日の天気予報" → 0.15(ほぼ無関係)
"RAGシステム構築" vs "ベクトルDB設計" → 0.78(関連性あり)
「コサイン類似度が0.8以上なら強い関連、0.5-0.8は中程度の関連、0.5未満は弱い関連と考えるのが目安だ」 — 田中VPoE
Embeddingモデルの種類と比較
主要なEmbeddingモデル
| モデル | 提供元 | 次元数 | 最大トークン | 日本語対応 | コスト |
|---|---|---|---|---|---|
| text-embedding-3-small | OpenAI | 1536 | 8191 | 良好 | 低 |
| text-embedding-3-large | OpenAI | 3072 | 8191 | 良好 | 中 |
| text-embedding-ada-002 | OpenAI | 1536 | 8191 | 良好 | 低 |
| Cohere embed-v3 | Cohere | 1024 | 512 | 良好 | 中 |
| voyage-3 | Voyage AI | 1024 | 32000 | 良好 | 中 |
| multilingual-e5-large | Microsoft | 1024 | 512 | 優秀 | 無料(OSS) |
| BGE-M3 | BAAI | 1024 | 8192 | 優秀 | 無料(OSS) |
モデル選定の基準
| 選定基準 | 考慮事項 |
|---|---|
| 精度 | MTEBベンチマークのスコアを参照 |
| 日本語対応 | 日本語テキストの検索精度を検証 |
| コスト | API呼び出し単価 × 想定ドキュメント数 |
| レイテンシ | リアルタイム検索の場合は応答速度が重要 |
| 最大トークン数 | チャンクサイズの上限に影響 |
| 次元数 | ベクトルDB の格納サイズとクエリ速度に影響 |
| 運用形態 | API利用 vs 自前ホスティング |
選定フローチャート:
コスト制約が厳しい?
├── Yes → OSSモデル(multilingual-e5-large, BGE-M3)
└── No → 精度最優先?
├── Yes → text-embedding-3-large or voyage-3
└── No → text-embedding-3-small(コスパ良好)
Embeddingの実践的な考慮事項
クエリとドキュメントの非対称性
検索クエリとドキュメントは性質が異なります。一部のモデルは非対称検索に最適化されています。
| 種別 | 特徴 | 例 |
|---|---|---|
| クエリ | 短い、質問形式 | 「RAGの検索精度を上げるには?」 |
| ドキュメント | 長い、説明形式 | 「RAGの検索精度を向上させるためには、以下の手法が有効です…」 |
非対称Embedding(Instruction付き)の例:
# E5モデルの場合、プレフィックスを付与
query: "query: RAGの検索精度を上げるには?"
document: "passage: RAGの検索精度を向上させるためには、..."
Embeddingの次元削減
高次元のEmbeddingは精度が高い一方、ストレージとクエリ速度に影響します。
| 次元数 | ストレージ(100万ドキュメント) | クエリ速度 | 精度 |
|---|---|---|---|
| 256 | 約1GB | 非常に高速 | 低〜中 |
| 768 | 約3GB | 高速 | 中〜高 |
| 1536 | 約6GB | 中程度 | 高 |
| 3072 | 約12GB | やや低速 | 非常に高 |
OpenAI text-embedding-3モデルは
dimensionsパラメータで次元数を指定可能。精度とコストのトレードオフを調整できる。
バッチ処理の最適化
大量ドキュメントをEmbedding化する場合のベストプラクティス:
| 項目 | 推奨 |
|---|---|
| バッチサイズ | API制限内で最大化(OpenAI: 2048テキスト/リクエスト) |
| 並列度 | レート制限を考慮(RPM/TPMを監視) |
| リトライ | 指数バックオフ付きリトライ |
| キャッシュ | 同一テキストのEmbeddingをキャッシュ |
| 進捗管理 | 処理済みドキュメントIDを記録し、中断時の再開に対応 |
まとめ
| ポイント | 内容 |
|---|---|
| Embeddingの役割 | テキストを数値ベクトルに変換し、意味的類似度の計算を可能にする |
| 類似度指標 | コサイン類似度が最も一般的。値が1に近いほど類似 |
| モデル選定 | 精度、日本語対応、コスト、レイテンシを総合的に判断 |
| 実践上のポイント | 非対称検索対応、次元削減、バッチ処理最適化 |
チェックリスト
- Embeddingの基本概念と目的を理解した
- コサイン類似度による類似度計算を理解した
- 主要なEmbeddingモデルの特徴を比較できる
- モデル選定の基準を理解した
次のステップへ
次は「ベクトルDBの全体像」を学びます。Embeddingで生成したベクトルを効率的に格納・検索するためのベクトルDBの選定基準を理解しましょう。
推定読了時間: 30分