こんにちは、みなさん。
今日は、インターネット黎明期や検索機能を作ったことのあるエンジニアなら一度は経験したであろう「ある苦しみ」について話したいと思います。
それは、コンピュータが「文字は理解するけど意味は理解しない」時代の話です。
この問題こそ、Embedding(埋め込み表現)が生まれた最大の理由でした。
ちょっと昔話に付き合ってください。
昔の検索エンジンは「文字列」にしか興味がなかった
ある EC サイトを作っているとします。
データベースには商品名として 「メンズ 高級デニムパンツ」 と登録されています。
一方、ユーザーは検索欄にこう入力します:
「ジーンズ 男性用」
しかし結果は——
「該当する商品はありません」
ユーザーは 2 分眺めて離脱…。
「デニムもジーンズも同じ意味なのに?」と思いますよね。
でも当時の検索システムは、ただの Keyword Matching(キーワード一致) でした。
コンピュータにとっては:
- 「デニム」と「ジーンズ」は 完全に別の文字列
- 逆に「デニム(布)」よりも「牛(動物)」のほうが文字的には近い
- 意味なんて 1mm も理解していない
という状態でした。
つまり、人間がコンピュータの都合に合わせて“正しい単語”を入力しないといけなかったのです。
Embedding の登場:文字ではなく“意味”を見る時代へ
Embedding は、単語をただの文字列ではなく、
多次元空間のベクトル(座標)として表現する技術です。
この空間では:
- 意味が似ている単語 → 近くに配置
- 意味が違う単語 → 遠くに配置
という自然な関係が生まれます。
例えばイメージとして(あくまで例です):
| 単語 | ベクトル例 |
|---|---|
| 王 | [0.99, 1.0, 0.05] |
| 女王 |
[0.99, 1.0, 0.95](王のすぐ隣) |
| サツマイモ |
[0.0, 0.0, 0.0](どこか遠く) |
文字列ではなく、意味の位置関係で単語が表現されるようになった瞬間です。
Embedding を使うと検索はこう変わる
例の検索システムに戻ってみましょう。
ユーザーが「ジーンズ」と入力すると:
- AI は文字列ではなく ベクトルへ変換
- データベース内の商品名も 全てベクトル化済み
- ベクトル空間で「近い位置」にあるデータを探す
- 「デニムパンツ」のベクトルが近いと判定される
- 検索結果としてヒットする
つまり AI は、
単語そのものではなく“意味の距離”でマッチングする のです。
Embedding が支えている現代のサービス
Embedding は、現代の多くのサービスを支える重要技術になりました。
-
YouTube / Netflix / TikTok
視聴内容の“雰囲気・特徴”がベクトル化され、似た動画が推薦される。 -
ChatGPT
多少の誤字・口語・俗語でも意味を理解できるのは Embedding のおかげ。 -
Semantic Search / RAG / 類似文章検索
すべて Embedding を基盤にしている。
コンピュータは、
「文字一致マシン」→「意味を理解するアシスタント」
へと進化したのです。
まとめ
Embedding によって、
人間の言語とコンピュータの言語の間にあった大きなギャップが埋められました。
次に Google で曖昧な検索をしても正しい結果が返ってきたら、
裏側で頑張っている数千次元のベクトルたちに、少しだけ感謝してあげてください。
次回予告(もし需要があれば)
もし興味があれば、
「OpenAI Embeddings を使って 5 分で作るセマンティック検索エンジン」
という実装記事も書こうと思います。
「読みたい!」という方はぜひコメントください 🙌
関連する記事
AIの「ハルシネーション」?あなた専用データをAIに“参照”させるRAG (Retrieval-Augmented Generation)の仕組みとは
昔の検索エンジンはなぜこんなに頑固だったのか? Embedding がもたらす「意味が伝わる」世界
Semantic Caching 再入門:高速化・コスト削減と「文脈の罠」をどう超えるか
RAG × Re-ranking: 検索品質を最大化するための最新手法