埋め込み（Embedding）とは？テキストをベクトル化する仕組み

「iPhone」で探すと、「スマートフォン」の記事が出てこない

チャンクに切り分けたら、次はそれを検索できる形にします。ここでも Indexing の話が続きます。

従来の全文検索は、文字列が一致するかどうかだけを見ます。だから「iPhone」で検索すると、内容がぴったりの記事でも本文に「スマートフォン」としか書いていなければ一件も出てきません。

社内文書ではこれが日常的に起きます。現場は「お給料のルール」と呼び、規程には「給与規定」と書いてあるからです。同義語の辞書を人力で登録していく方法もありますが、資料が増えるほど破綻しますし、新しい言い回しが出るたびに追加が必要になります。必要なのは、文字ではなく意味で並べる仕組みです。

意味を、座標に変える

そこで使うのが埋め込み（Embedding）です。テキストを埋め込みモデルに入れると、数百から数千個の数値の並びが返ってきます。これがベクトルです。

この数値の並びは、意味の空間における住所のようなものです。似た意味の文章は近い場所に、無関係な文章は遠い場所に置かれます。「犬」と「子犬」は隣どうし、「宇宙」と「カレー」は遠く離れた場所に着地します。

近さの測り方として、RAG ではコサイン類似度がよく使われます。2 つのベクトルが同じ向きを指しているほど 1 に近づき、無関係なほど 0 に近づく、という指標です。向きだけを見るので、文章が長いか短いかに左右されません。長い規程と短い質問文を比べられるのは、この性質のおかげです。

数値がそれぞれ何を表しているかは、人間には読めません。モデルが学習の過程で勝手に決めた軸だからです。読めなくても、近さは計算できます。RAG に必要なのはそれだけです。

入れるときと引くときで、同じ物差しを使う

埋め込みは 2 回登場します。資料をしまうときと、質問が届いたときです。ここに実務でいちばん多い事故があります。

資料は OpenAI のモデルでベクトルにして、質問は別会社のモデルでベクトルにする。この構成は、エラーも警告も出ないまま、まったく的外れな検索結果を返し続けます。座標の取り方が違う 2 枚の地図で距離を測っているようなもので、数値としては計算できてしまうからです。しかも結果が空になるわけではなく、それらしい順位が付いて返ってくるので、設定を疑うまで時間がかかります。

同じ理由で、埋め込みモデルを新しいものに入れ替えるときは、既存の資料を全件ベクトルに変換し直す必要があります。片方だけ差し替えることはできません。件数が多いほど時間も費用もかかるので、モデル選びは最初に済ませておきたい判断です。

選ぶときに見るのは 3 つです。日本語をきちんと扱えるか。一度に入る長さの上限がどれくらいか。そして次元の数です。次元が多いほど細かい違いを表せますが、保存容量と計算量もその分増えます。長さの上限は、そのままチャンクをどこまで大きくできるかの制約になります。

とくに 1 つ目は、公開されている性能比較が英語中心であることが多いので、日本語の資料を扱うなら数字をそのまま信じないでください。