RAG 04：埋め込み ― 文章を「意味の地図」に置く

埋め込み＝文章を数字の並び（ベクトル）にすること

埋め込みとは、文章を数字の並びに変換することです。数字の並びのことをベクトルと呼びます。

変換を担当するのは、埋め込みモデルと呼ばれる専用の AI モデルです（モデルは、大量のデータから学習して作られた計算の仕組みのこと。LLM もモデルの一種です）。文章を渡すと、たとえば 1024 個の数字が返ってきます。

この数字の1つ1つに、人間が読める意味はありません。「3番目の数字は休暇っぽさ」のような決まりは無いのです。大事なのは、並び全体です。

埋め込みモデルは、大量の文章の組（「この質問にはこの文章が答えている」「この2つの文は同じ意味」など）で訓練（＝学習）されています。その結果、意味の近い文章からは、似た数字の並びが出るようになっています。

図では「有給休暇の日数」と「休みはいつ取れる？」を埋め込んでいます。文字はほとんど違うのに、出てきた数字の並びはよく似ています（数字は説明のための例です）。

数字になってしまえば、コンピュータは「どれくらい似ているか」を計算で測れます。文章を読んで理解する代わりに、数字の近さで意味の近さを測る。これが埋め込みの考え方です。

たとえるなら「意味の地図」の上の座標

数字の並びは、地図の上の座標だと考えると分かりやすくなります。

数字が2つなら、紙の上の横と縦の位置、つまり2次元の座標です。数字が3つなら、部屋の中の位置のような3次元です。座標に使う数字の個数を次元と呼びます。埋め込みの数字は数百〜数千個あるので、本当は数百〜数千次元の座標ですが、想像するときは2次元の地図で十分です。

社内の資料を全部埋め込んで、この地図に点として置いてみます。すると、面白いことが起きます。

「有給休暇の日数」「休暇の申請方法」「夏季休暇の案内」は、左上に寄り集まります。「交通費の精算」「経費の締め日」は右上に、「VPN の接続」「パスワード再設定」は下に集まります。

誰かが「これは休暇の資料」と分類したわけではありません。埋め込みモデルが、文章の意味だけから、似たものを近くに置いたのです。

この地図には、次のような性質があります。言い換え（「休み」と「休暇」）は近くに置かれます。モデルによっては、言語が違っても同じ意味なら近くに置けます（英語の資料に日本語で質問できる）。そして、辞書や分類を人が作る必要がありません。

質問も同じ地図に置き、いちばん近い資料を拾う

検索のときは、質問も同じように埋め込んで、同じ地図に置きます。

図の赤い点が「休みはいつ取れる？」です。休暇の塊のすぐそばに落ちました。この点から近い順に資料を並べれば、それが検索結果になります。

「休み」という文字が資料に無くても、意味が近ければ上位に来ます。これが「意味で探す」検索で、ベクトル検索や意味検索（セマンティック検索）と呼ばれます。

ここで、仕事を2つに分けて考えると整理しやすくなります。

埋め込み（この章）は、文章を地図の座標にする仕事です。ベクトル検索（第5章）は、何百万もの点の中から、質問の点に近い点を速く見つける仕事です。この章では、まず地図づくりのほうを見ていきます。

近さの測り方：矢印の「向き」がどれだけそろっているか

「近い」をどう測るのでしょうか。いちばんよく使われるのがコサイン類似度です。

名前は難しそうですが、考え方は単純です。地図の原点（すべての数字が0の、基準の点。図の左下の黒い点）から、それぞれの点に向かって矢印を引きます。そして、2本の矢印の向きがどれだけそろっているかを比べます。

図では、「有給休暇の日数」と「休みはいつ取れる？」の矢印はほぼ同じ向きで、「交通費の精算」は大きく違う向きです。

なぜ「距離」ではなく「向き」なのでしょうか。矢印の長さには、文章の長さなどの、意味とは別の要素が混ざりやすいからです。向きだけを見れば、長い資料と短い質問でも公平に比べられます。

実務の小ネタを1つ。多くの埋め込みモデルは、矢印の長さを 1 にそろえて（正規化して）返します。長さが 1 なら、コサイン類似度は、2つの並びの同じ位置の数どうしを掛けて全部足しただけの値（内積）と同じになり、計算が速くなります。データベースの設定で「コサイン」と「内積」を選ぶ場面があるのは、このためです（第5章）。

数字の数（次元）は、細かさと重さの取り引き

埋め込みの数字の個数を次元と呼びます。モデルによって、数百〜数千までさまざまです。

次元が多いほど、細かい意味の違いを持てます。その代わり、重くなります。

たとえば、1つの数字を 4 バイト（よく使われる小数の保存形式の大きさ）で保存すると、1024 次元のベクトルは 1 つで約 4KB です。チャンクが100万個あれば、ベクトルだけで約 4GB になります。次元を半分にすれば、保存も計算もおよそ半分です。

最近は、あとから次元を短く切っても使えるように訓練されたモデルがあります。この訓練方法は Matryoshka Representation Learning（マトリョーシカ表現学習、2022年の論文）と呼ばれ、入れ子人形のように、前のほうの数字だけでも大まかな意味を表せるようにしています。API に「何次元で返すか」を指定できるモデルもあります。

選び方の目安は、まずモデルの標準の次元で試し、保存量や速さが問題になってから短くすることです。短くしたら、精度がどれだけ落ちたかを必ず測ります（第12章）。

埋め込みモデルは大きく3種類

埋め込みモデルには、大きく3つの選び方があります。

どれがいいかを比べるには、公開されたベンチマーク（比較の試験）が参考になります。多言語では MTEB（Massive Text Embedding Benchmark、「大規模な文章埋め込みの試験」）、日本語では JMTEB（その日本語版）がよく使われます。モデルの名前と順位はすぐに入れ替わるので、この本では特定のモデルを勧めません。

ただし、ベンチマークの順位はあなたの資料での順位ではありません。社内の略語、業界の言い回し、表や箇条書きの多い資料…で、結果は変わります。

おすすめの決め方は、候補を2〜3個に絞り、自分の資料と、実際に来そうな質問 30〜50 個で試すことです。「正しい資料が上位5件に入ったか」を数えるだけでも、差ははっきり出ます（測り方は第12章）。

資料と質問は、必ず同じモデルで埋め込む

埋め込みでいちばん大事な約束は、「資料と質問は、同じモデルで埋め込む」です。

モデルが違えば、地図そのものが違います。モデル A の地図で「休暇」の塊が左上にあっても、モデル B の地図では右下にあるかもしれません。数字の並びの意味が、モデルごとにまったく違うからです。

図は、資料をモデル A で、質問をモデル B で埋め込んだ場合です。質問の点が、関係のない社内 IT の塊のそばに落ちてしまいました。次元の数がたまたま同じなら、エラーは出ません。ただ、変な検索結果が返るだけです。だから気づきにくいのです。

この約束から、実務上の注意が2つ出てきます。

1つ目。モデルを替えたら、資料を全部埋め込み直す必要があります。新しいモデルのほうが良さそうでも、切り替えは「全資料の再計算」とセットです。資料が多いと時間もお金もかかるので、最初のモデル選びは慎重に。

2つ目。どのベクトルをどのモデルの、どの版で作ったかを、データベースに一緒に記録しておきます。API のモデルは版が上がることがあり、同じ名前でも中身が変わる場合に備えるためです。

質問と資料で「札」を付け分けるモデルもある

モデルによっては、質問と資料に別々の札（プレフィックス＝文の先頭に付ける決まった文字）を付けて埋め込むよう決められています。

たとえば E5 系のモデル（Microsoft が公開した、広く使われる埋め込みモデルの系統）は、質問の先頭に query: 、資料の先頭に passage: を付ける約束です。API で使うモデルでも、「これは検索の質問」「これは検索される文書」のように用途を指定する引数を持つものがあります。

なぜ分けるのでしょうか。「質問」と「その答えが載っている資料」は、実は似た文章どうしではありません。質問は短く、「？」で終わり、答えそのものは含みません。資料は長く、説明が書いてあります。

「似ている文章を探す」のと「質問に答えている文章を探す」のは、少し違う仕事です。札で役割を伝えると、モデルは後者のほうに合わせて座標を作ってくれます。こうした、質問側と資料側で扱いを変える作りを非対称と呼びます。

注意点は、札を付け忘れてもエラーにならないことです。ただ黙って精度が落ちます。新しいモデルを使うときは、まず説明書（モデルカード）を読み、札や用途の指定が要るかどうかを確かめてください。

コードで見る：埋め込んで、近い順に並べる

ここまでを、TypeScript の短いコードにすると図のようになります。embed() は、使う埋め込みモデル（API やライブラリ）を呼んで、文章ごとにベクトルを返す関数だとします。図のコードは上から、①資料に passage: を付けてまとめて埋め込む、②質問に query: を付けて埋め込む、③cos で近さを計算する（長さ1にそろったベクトルなので、同じ位置の数を掛けて足す内積で足りる）、④全チャンクに近さを付けて大きい順に並べ、上位5件を取る、という順に動きます。

流れは2段に分かれています。

資料の埋め込みは、前もって1回だけです。質問が来るたびに全資料を埋め込み直すわけではありません。質問が来たときに計算するのは、質問1つ分の埋め込みと、近さの比較だけです。

コードでは、全部のチャンクと1つずつ近さを比べています。これは資料が数千件くらいまでなら十分に速い方法です。でも、100万件になると遅すぎます。そこで、比べる相手を賢く減らす仕組み（ベクトルデータベースと近似最近傍探索）が要ります。それが次の第5章です。

"passage: " と "query: " は前のページの札なので、使うモデルが札を必要としないなら付けません。

埋め込みが苦手なこと：否定・数字・珍しい固有名詞

埋め込みは「だいたいの意味」をつかむのが得意です。裏返すと、一字違いで意味が大きく変わるものは苦手です。

図の左では、「返品できます」と「返品できません」がほぼ重なっています。質問が「返品できますか？」なら、両方とも上位に来ます。どちらが正しいかを見分けるのは、検索の後の段階（第7章の並べ直しや、第8章の生成）の仕事になります。

型番やエラーコードのように「文字が完全に一致すること」が大事な場面では、昔ながらのキーワード検索のほうが強いこともよくあります。そのため、実務では両方を組み合わせるのが定番です（第6章）。

よくある落とし穴

埋め込みまわりで、実際によく起きる失敗をまとめます。

特に最後の点は見落とされがちです。コサイン類似度の値の分布（値がどのあたりに集まって出るか）はモデルによって大きく違います。あるモデルでは無関係な文章どうしでも 0.7 くらい出ることがあり、別のモデルでは関係の深い文章でも 0.5 くらいのことがあります。「絶対値」より「順位」を信じるのが安全です。

他の章とのつながり

埋め込みは、RAG の「探す」部分の土台です。前後の章と、次のようにつながっています。

第3章（チャンク分割）：埋め込むのは、チャンクです。1つのチャンクに話題が2つ混ざっていると、その点は2つの塊の間に落ち、どちらの質問にも近くなりません。「1つのチャンクに1つの話題」は、埋め込みのための約束でもあります。

第5章（ベクトル検索）：この章で作った地図の上で、何百万もの点から近い点を速く探す方法です。

第6章（ハイブリッド検索）：埋め込みが苦手な型番・番号・固有名詞を、キーワード検索で補います。

第7章（リランキング）：埋め込みで拾った候補を、質問と資料を一緒に読むモデルで並べ直します。否定の見分けのような細かい判断は、ここで効いてきます。

第12章（評価）：モデル選びや次元の変更が本当に良かったのかを、数字で確かめます。

チャンクの切り方が埋め込みの質を決め、埋め込みの質が検索の上限を決めます。後ろの章でどれだけ工夫しても、地図がずれていたら取り戻せないことを覚えておいてください。