埋め込み（Embedding）とベクトル検索
単語・文・画像を「意味を座標にした数値の列（ベクトル）」へ変換する技術。意味が近いものはベクトルも近くなるので、キーワード一致ではなく“意味”で検索・比較できる。
- 1.埋め込み = テキストや画像を「意味を表す数百〜数千次元のベクトル」に変換すること。意味が近い＝ベクトルが近い。
- 2.近さは主にコサイン類似度（向きの近さ）で測る。これを大量データで高速にやる仕組みがベクトルDB・近似最近傍検索。
- 3.「検索→関連文書を取り出してLLMに渡す」RAG や、推薦・重複検出・分類の土台になる。万能ではなく、似た“見た目”に引っ張られることもある。
「犬」と「子犬」は文字としては別物ですが、意味は近い。埋め込みはこの「近さ」を座標の近さとして表現します。逆に「犬」と「銀行」は遠い座標になります。
「意味を座標にする」とはどういうことか
イメージしやすいよう、世界を**たった2次元（X軸・Y軸）**だと仮定してみます。実際の埋め込みは数百〜数千次元ですが、考え方は同じです。
↑ Y
猫 ● | ● 子犬
●犬 |
----------- + -----------→ X
| ● 自動車
王 ● | ● トラック
● 女王 |
- 「犬・猫・子犬」は近くに集まる（どれも動物）
- 「自動車・トラック」も近くに集まる（どれも乗り物）
- 動物グループと乗り物グループは遠く離れる
各点の位置を表す (X, Y) の組がそのまま「埋め込みベクトル」です。実際には [0.12, -0.87, 0.33, ...] のように、何百個もの数字が並びます。一つひとつの数字に「これは色」「これは大きさ」といった人間が読める意味はありません。あくまで全体として、意味の近いものが近くに来るよう学習された結果です。
初期の単語埋め込み（word2vec）で話題になった例。ベクトルどうしの足し引きで意味の関係が表せることがあります（king - man + woman ≒ queen）。「埋め込みが意味を空間として捉えている」ことの直感的なデモですが、いつもきれいに成り立つわけではない点には注意。
近さはどう測る？──コサイン類似度
2つのベクトルが「近い＝意味が似ている」かを数値化します。よく使うのがコサイン類似度で、ざっくり言うと**「2本の矢印の向きがどれだけ揃っているか」**です。
- 向きがほぼ同じ → 類似度 1 に近い（意味が近い）
- 直角（無関係） → 類似度 0 付近
- 真逆 → -1 に近い
ポイントは、長さ（大きさ）ではなく向きで測ること。文章の長短に左右されにくいので、テキスト検索と相性が良いです。
| 測り方 | 見ているもの | 向いている用途 |
|---|---|---|
| コサイン類似度 | ベクトルの「向き」の近さ | テキストの意味検索（最も一般的） |
| ユークリッド距離（L2） | 2点間の直線距離（位置の近さ） | 画像特徴・座標的なデータ |
| 内積（ドット積） | 向き＋大きさをまとめて評価 | 長さ正規化済みなら実質コサインと同じ |
ユークリッド距離は小さいほど似ている、コサイン類似度は大きいほど似ている。向きが逆なので混同しがちです。多くのベクトルDBは長さを1にそろえて（正規化して）扱うため、その場合は内積もコサインも順位は一致します。
大量データから高速に探す──ベクトルDBと近似最近傍
「質問に近い文書」を探すとは、問い合わせベクトルに最も近いベクトルを大量の中から見つけることです。これを**最近傍探索（Nearest Neighbor Search）**と呼びます。
素朴にやると、全データと1つずつ類似度を計算する総当たり O(n)。数百万件あると重すぎます（→ 規模で効く考え方は 計算量と Big-O 記法 を参照）。
そこで実務では**近似最近傍探索（ANN）**を使います。多少の取りこぼしを許す代わりに、インデックス（HNSW・IVF など）で候補を絞り、桁違いに速く「だいたい一番近いもの」を返します。これを担うのが ベクトルDB／ベクトル検索エンジン（pgvector、Pinecone、Faiss、Elasticsearch のベクトル機能など）です。
| 観点 | 従来のキーワード検索 | ベクトル検索（埋め込み） |
|---|---|---|
| 一致の基準 | 単語が文字として一致するか | 意味が近いか |
| 「車」で検索 | 「車」を含む文書のみ | 「自動車」「マイカー」も拾える |
| 表記ゆれ・言い換え | 弱い（同義語辞書が必要） | 強い（言い換えに対応しやすい） |
| 完全一致・固有名詞 | 強い（型番・IDに最適） | 苦手なことがある |
キーワード検索（厳密一致に強い）とベクトル検索（意味に強い）は得意分野が逆。両方を組み合わせるハイブリッド検索が品質・安定性ともに有利なことが多いです。ベクトル検索は万能の置き換えではなく、足りない部分を補う道具と捉えるのが実践的。ベクトルDB全般の位置づけは データベース も参考に。
何に使う？──RAG・推薦・分類
埋め込み＋類似検索は、いまの AI アプリの基盤部品です。代表例：
- RAG（検索拡張生成）: 質問を埋め込み → 社内文書などから関連箇所を検索 → 取り出した文章をプロンプトに添えて LLM に答えさせる。モデルを再学習せずに最新・固有の知識を使わせる定番手法。詳しくは ファインチューニングと RAG。
- 推薦: 商品・記事・楽曲をベクトル化し、「いま見ているものに近いもの」を提示。
- 重複検出・クラスタリング: 似た問い合わせ・記事をまとめる、FAQ の重複を見つける。
- 分類・ゼロショット判定: ラベル文も埋め込み、最も近いラベルに振り分ける。
RAG の答えの質は、**LLM 以前に「正しい文書を検索できたか」**でほぼ決まります。検索が的外れだと、モデルはその誤った情報をもとに、もっともらしい誤答（ハルシネーション）を返しがち。検索の精度・チャンク（文書の分割粒度）・件数の調整が効きます。
つまずきポイント
実際に使うと、次のような落とし穴があります。
| 誤解・落とし穴 | 実際 |
|---|---|
| 埋め込めば意味を“理解”している | あくまで分布の近さ。論理や事実の正しさは保証しない |
| 似ている＝意味が同じ | 文体・トピックなど“見た目”の近さに引っ張られることがある |
| どのモデルのベクトルでも比較できる | 別モデルの埋め込みは座標系が違い、混ぜると無意味 |
| 次元数が多いほど高性能 | コスト増。タスクに合うモデル選びの方が効く |
検索対象（文書側）と問い合わせ（質問側）は、必ず同じ埋め込みモデルでベクトル化します。モデルが違うと座標系が噛み合わず、近さの比較が成立しません。モデルを切り替えたら、**既存データも全部作り直して入れ直す（再インデックス）**必要があります。
埋め込みは「意味を数値の地図に落とす」発想そのものがシンプルで強力です。一方で、地図はあくまで近似。何で似ているのか／取りこぼしはないかを意識して、キーワード検索や LLM と組み合わせて使うのが、実務での勘所です。
AI/機械学習 Article
埋め込み（Embedding）とベクトル検索を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
埋め込み
比較で見る軸
難易度: intermediate / カテゴリ: AI/機械学習 / タグ数: 4
導入後に効く点
近さは主にコサイン類似度（向きの近さ）で測る。これを大量データで高速にやる仕組みがベクトルDB・近似最近傍検索。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- intermediate
- カテゴリ
- AI/機械学習
- タグ数
- 4
判断チェックリスト
- 自社の用途が「埋め込み / ベクトル検索」に近いか確認する。
- 強みである「埋め込み = テキストや画像を「意味を表す数百〜数千次元のベクトル」に変換すること。意味が近い＝ベクトルが近い。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。