Embedding とベクトル検索
はじめに
コンピュータはどうやって「猫と犬は似ているが、車とは似ていない」ことを理解するのか？ 人間にとっては常識ですが、コンピュータにとって「猫」「犬」「車」は3つの無関係な文字列に過ぎません。Embedding（埋め込み）技術はこの問題を解決する鍵です——文字を数値ベクトルに変換し、コンピュータにも意味的な「距離感」を理解させます。
この記事で学べること
この章を学び終えると、次の能力が身につきます：
- 直感的理解：Embedding とは何か、なぜ「猫」と「犬」のベクトルが近くなるのかを理解
- 類似度計算：コサイン類似度、ユークリッド距離などの核心的な測定方法を習得
- インデックスの原理：ベクトルデータベースが数百万件のデータからミリ秒で検索する仕組みを理解
- 技術選定：主要なベクトルデータベースの特徴と適したシーンを理解
- エンドツーエンドフロー：テキストからベクトル、検索までの完全なパイプラインを習得
| 章 | 内容 | コアコンセプト |
|---|---|---|
| 第1章 | Embedding の概念 | 意味空間、ベクトル表現 |
| 第2章 | 類似度計算 | コサイン類似度、ユークリッド距離 |
| 第3章 | ベクトルインデックス | ブルートフォース検索 vs ANN |
| 第4章 | ベクトルデータベース | Pinecone、Milvus、Chroma |
| 第5章 | エンドツーエンドパイプライン | テキスト→ベクトル→保存→検索 |
0. 全景図：文字から数値への架け橋
自然言語処理の世界には、根本的な課題があります：コンピュータは数値しか認識せず、文字を認識しません。
初期のアプローチでは各単語に番号を割り当てていました（One-Hot エンコーディング）。例えば「猫」=001、「犬」=010、「車」=100。しかしこれには致命的な問題があります：すべての単語間の距離が同じ。「猫」から「犬」までの距離と「猫」から「車」までの距離はまったく同じ——これは明らかに直感に反します。
Embedding の革命的な点は：各単語を密な低次元ベクトル空間にマッピングし、意味的に近い単語を自然に集めることです。この空間では、「猫」と「犬」は近くにあり、「車」は遠くにあります——コンピュータがついに意味を「理解」できるようになりました。
One-Hot から Embedding への飛躍
- One-Hot：次元 = 語彙サイズ（数万次元の可能性）、各ベクトルは1つの1だけで残りはすべて0、疎で意味情報なし
- Embedding：次元は通常 768〜1536、各数値が意味を持ち、密で豊かな意味情報を含む
- 重要なブレイクスルー：Word2Vec（2013）が「単語の意味はその文脈で定義できる」ことを証明し、Embedding 時代の幕開けとなった
1. Embedding の概念：文字を座標に変える
Embedding の核心思想は一言でまとめられます：一組の数値（ベクトル）で単語や文の意味を表現する。
二次元座標系を想像してください。「猫」を座標 (0.2, 0.7) に、「犬」を (0.3, 0.6) に、「車」を (0.9, 0.1) に配置します。「猫」と「犬」の座標が非常に近く、「車」が遠く離れていることがわかります。これが Embedding の直感です——意味的類似度が空間的距離になったのです。
Word Embedding Space Visualization
Semantically similar words stay closer in vector space and form natural clusters
💡 Embedding models map text into high-dimensional vector spaces, often 768 to 1536 dimensions. This demo simplifies that into 2D to show the core idea: semantically similar words have shorter vector distances。
Embedding の3つの重要な特性
- 意味的クラスタリング：類似した意味の単語が自動的に集まる（動物のクラスタ、食べ物のクラスタ、テクノロジーのクラスタ）
- 類推関係：ベクトル演算が意味関係を表現できる。古典的な例：king - man + woman ≈ queen
- 次元の意味：各次元が何らかの意味的特徴を暗黙的にエンコードしている（「動物かどうか」「大きさ」「感情傾向」など）
| エンコーディング方式 | 次元 | 意味情報 | 典型的な応用 |
|---|---|---|---|
| One-Hot | 語彙サイズ（~50000） | なし | 従来の NLP |
| Word2Vec | 100〜300 | 単語レベルの意味 | 単語類似度、類推推論 |
| BERT Embedding | 768 | 文脈的意味 | 文理解、質問応答 |
| OpenAI text-embedding-3 | 1536〜3072 | 深層意味 | RAG、意味検索 |
2. 類似度計算：ベクトル間の「近さ」を測る
ベクトル表現が得られたら、次の問題は当然：2つのベクトルがどれだけ似ているかをどう測るか？ これは地図上で2つの都市がどれだけ近いかを測るのと同じです——直線距離を測ることも、方向が一致しているかを見ることもできます。
Vector Similarity Calculator
Drag vector endpoints to observe similarity metrics in real time
💡Cosine similarityfocuses only on direction and is useful for semantic text comparison; Euclidean distanceconsiders both direction and magnitude and fits absolute-distance scenarios.
2つの核心的測定方法
- コサイン類似度（Cosine Similarity）：2つのベクトルの方向が一致しているかを測定。値域 [-1, 1]。1 は方向が完全に同じ、0 は直交（無関係）、-1 は完全に逆。テキスト意味比較の第一選択。ベクトルの長さに影響されないため。
- ユークリッド距離（Euclidean Distance）：2つのベクトル端点間の直線距離を測定。値域 [0, ∞)。0 は完全に一致、値が大きいほど類似していない。「絶対的な大きさ」を考慮する必要があるシーンに適する。
| 測定方式 | 数式の直感 | 値域 | 適したシーン |
|---|---|---|---|
| コサイン類似度 | 方向を見て、長さを無視 | [-1, 1] | テキスト意味検索、レコメンドシステム |
| ユークリッド距離 | 端点の直線距離を見る | [0, ∞) | 画像特徴、クラスタ分析 |
| 内積 | 方向 × 長さ | (-∞, +∞) | 正規化ベクトルの高速計算 |
| マンハッタン距離 | 座標軸に沿った距離 | [0, ∞) | 高次元疎ベクトル |
3. ベクトルインデックス：数百万ベクトルをミリ秒で検索する方法
100万件のドキュメントがあり、それぞれが1536次元のベクトルに変換されているとします。ユーザーが質問をし、最も類似した10件を見つける必要があります。最も直接的な方法は1件ずつ類似度を計算すること——しかしこれは1536次元のベクトル演算を100万回行うことを意味し、遅すぎます。
これがベクトルインデックスの解決する問題です：空間を時間と交換し、前処理でインデックス構造を構築し、検索速度を O(n) から近似的に O(log n) に下げる。
Vector Index Strategy Comparison
Compare brute-force search with approximate nearest neighbor search
| Strategy | Time complexity | Accuracy | Use case |
|---|---|---|---|
| Brute force | O(n) | 100% | Small datasets (<10K) |
| ANN (IVF) | O(n/k) | ~95% | Large datasets (>100K) |
| HNSW | O(log n) | ~98% | High-performance retrieval |
ブルートフォース検索 vs 近似最近傍（ANN）
- ブルートフォース検索（Flat）：1件ずつ比較、100%正確だが遅い。データ量が少ない（< 10万）シーンに適する。
- IVF（転置ファイルインデックス）：まずベクトル空間を複数の領域に分割（クラスタリング）、検索時は最も近い数領域のみを検索。図書館をテーマ別に分区し、本を探すときは関連エリアだけに行くようなもの。
- HNSW（階層的ナビゲーション可能小世界グラフ）：多層グラフ構造を構築し、粗粒度から細粒度へ層ごとにナビゲーション。まず世界地図で国を特定し、次に県レベル、最後に街路図を見るようなもの。
- PQ（積量子化）：高次元ベクトルを短いコードに圧縮し、わずかな精度を犠牲に大幅なメモリ節約。超大規模データセットに適する。
| インデックスタイプ | 構築速度 | 検索速度 | 再現率 | メモリ使用量 | 適した規模 |
|---|---|---|---|---|---|
| Flat（ブルートフォース） | 構築不要 | 遅い | 100% | 高い | < 10万 |
| IVF | 中程度 | 速い | 95%+ | 中 | 10万〜1000万 |
| HNSW | 遅い | 非常に速い | 99%+ | 高い | 10万〜1000万 |
| PQ | 中程度 | 速い | 90%+ | 非常に低い | > 1000万 |
| IVF-PQ | 中程度 | 速い | 92%+ | 低い | > 1億 |
4. ベクトルデータベース：ベクトルのために生まれたストレージエンジン
ベクトルとインデックスアルゴリズムが揃ったら、それらを保存・管理する場所が必要です。従来のデータベース（MySQL、PostgreSQL）は構造化データの処理に優れていますが、高次元ベクトルの類似度検索には力不足です。ベクトルデータベースはこのシーンのために特別に設計されました。
Mainstream Vector Database Comparison
Click a card to see details and compare use cases across vector databases
Scenario recommendations
ベクトルデータベースの核心能力
- 効率的な保存：高次元浮動小数点ベクトルに最適化された保存形式
- ANN 検索：複数の近似最近傍インデックスアルゴリズム（HNSW、IVF など）を内蔵
- メタデータフィルタリング：ベクトル検索と同時にタグ、時間などの条件でフィルタリング
- リアルタイム更新：ベクトルの動的な追加・削除・変更をサポート、インデックス全体の再構築不要
- 水平スケーリング：分散アーキテクチャで億単位のベクトル規模をサポート
| データベース | タイプ | 特徴 | 適したシーン |
|---|---|---|---|
| Pinecone | フルマネージドクラウドサービス | 運用不要、すぐに使える | ラピッドプロトタイピング、中小規模本番 |
| Milvus | オープンソース分散 | 高性能、拡張可能 | 大規模本番環境 |
| Chroma | オープンソース軽量 | 組み込み可能、API が簡潔 | ローカル開発、小規模プロジェクト |
| Weaviate | オープンソースクラウドネイティブ | ベクトル化内蔵、GraphQL | 自動ベクトル化が必要なシーン |
| Qdrant | オープンソース高性能 | Rust 実装、フィルタリング強力 | 複雑なフィルタリングが必要なシーン |
| pgvector | PG 拡張 | 既存の PG インフラを再利用 | すでに PostgreSQL を使用しているチーム |
5. エンドツーエンドパイプライン：テキストから検索までの完全なフロー
各コンポーネントを理解したところで、それらをつなげて、完全なベクトル検索システムがどのように動作するかを見てみましょう。
全体のフローは2つのラインに分かれます：オフライン書き込み（ドキュメントをベクトルに変換して保存）とオンライン検索（質問をベクトルに変換して検索）。
Embedding Generation Pipeline
Step through the full conversion from text to vector
オフライン書き込みフロー
- ドキュメント読み込み：様々なソース（PDF、Webページ、データベース）から生テキストを読み取り
- テキスト前処理：クリーニング、ノイズ除去、正規化（HTMLタグ、特殊文字の除去など）
- テキスト分割：戦略に従って長文テキストを適切なサイズの断片に分割（200〜500 tokens）
- ベクトル化：埋め込みモデル（OpenAI text-embedding-3-small など）を呼び出して各断片をベクトルに変換
- ベクトルデータベースに保存：ベクトルと元のテキスト、メタデータを一緒にデータベースに書き込み
オンライン検索フロー
- クエリ受信：ユーザーが自然言語の質問を入力
- クエリベクトル化：同じ埋め込みモデルで質問をベクトルに変換
- 類似度検索：ベクトルデータベースで Top-K の最も類似したドキュメント断片を検索
- 後処理：再ランキング、重複除去、メタデータフィルタリング
- 結果返却：最も関連性の高いドキュメント断片を呼び出し元に返す（または LLM に渡して回答を生成）
| 段階 | 重要な選択 | 推奨ソリューション |
|---|---|---|
| 埋め込みモデル | 精度 vs コスト vs 速度 | OpenAI text-embedding-3-small（コスパ良好） |
| 分割戦略 | 粒度 vs 意味的完全性 | 再帰的分割、200〜500 tokens |
| ベクトルデータベース | 規模 vs 運用コスト | 小規模は Chroma、本番は Pinecone/Milvus |
| 類似度測定 | 意味 vs 正確 | コサイン類似度（テキストシーン第一選択） |
| Top-K 値 | 再現率 vs ノイズ | まず20件検索し、再ランキング後にTop 5を取得 |
まとめ
Embedding とベクトル検索は「人間の言語」と「機械の理解」をつなぐ架け橋であり、RAG、意味検索、レコメンドシステムなどの AI アプリケーションの基盤インフラです。
本章の重要ポイントを振り返ります：
- Embedding の本質：テキストを高次元ベクトル空間にマッピングし、意味的類似度を空間的距離に変換
- 類似度測定：コサイン類似度は方向を重視（テキストに適する）、ユークリッド距離は絶対距離を重視
- インデックスがパフォーマンスの鍵：HNSW と IVF で数百万ベクトルの検索をミリ秒級に
- ベクトルデータベース選定：小規模は Chroma/pgvector、本番環境は Pinecone/Milvus
- エンドツーエンド思考：ドキュメント読み込みから最終検索まで、各段階の選択が最終効果に影響
参考資料
- OpenAI Embeddings ドキュメント - 公式埋め込みモデル使用ガイド
- Pinecone Learning Center - ベクトルデータベースと検索の体系的なチュートリアル
- FAISS Wiki - Facebook オープンソースのベクトル検索ライブラリドキュメント
- Word2Vec 原論文 - Embedding 時代の幕開けとなった論文
- MTEB ランキング - 埋め込みモデルパフォーマンス比較ランキング