【ITニュース解説】An embedding is a lookup table, and everything else is how you fill it

エンべディングとは、機械学習、特に自然言語処理の分野で、単語や文章といったテキスト情報をコンピューターが扱いやすい数値の並び（ベクトル）に変換したものである。これは、ちょうど辞書やハッシュマップのような「ルックアップテーブル」として機能する。まず、テキストは「トークナイザー」という仕組みによって、一つ一つの単語や文字の断片（トークン）に分解され、それぞれに固有の数値IDが割り当てられる。この数値IDが、エンべディングのテーブルにおける行番号の役割を果たす。そして、その行番号に対応する箇所には、ある一定の長さを持った数値の並び、つまりベクトルが格納されている。モデルは、この数値IDを使ってテーブルから該当するベクトルを「検索」するだけで、特別な変換は行わない。例えば、GPT-2という大規模言語モデルの場合、その入力テーブルは50,257行768列の巨大な数値の行列であり、合計で3800万個以上の数値が学習によって決定されている。特定の単語のトークンIDが11,241番であれば、このテーブルの11,241行目にある768個の数値がその単語のエンべディングとなる。この「アドレス」は訓練が始まる前に固定されているが、その「内容」はモデルの学習を通じて獲得される。

このエンべディングの「ルックアップテーブル」の中身がどのように埋められるかには、主に二つの方法がある。一つ目の方法は、エンべディングが言語モデル自体の「パラメータ」として扱われる場合である。この場合、テーブルの各行（ベクトル）は最初はランダムな数値で初期化され、モデルが学習を進める中で、次の単語を予測するといったタスクをうまくこなせるように、勾配という仕組みを通じて数値が更新されていく。つまり、モデルの学習過程の一部として、自然にその意味合いが形成される。この方法では、特定の単語やトークンに割り当てられたベクトルは固定されており、その単語がどのような文脈で使われても同じベクトルが取り出される。

二つ目の方法は、多くのシステムエンジニアが実際に利用するケースであり、学習済みのモデルを使ってテキストからベクトルを「計算」する方法である。この場合、エンべディングは事前に保存されたテーブルから単純に検索されるのではなく、入力されたテキスト全体の文脈を考慮して、その場で動的に生成される。例えば、「銀行」という単語は「川岸の銀行」と「銀行口座」という異なる文脈で使われることがある。一つ目の方法ではどちらの「銀行」も同じベクトルになるが、二つ目の方法では、モデルが文脈を理解し、同じ「銀行」という単語であっても異なる意味合いを反映したベクトルを生成する。これが「文脈依存型エンべディング」と呼ばれるもので、単語の周りの情報がベクトルの内容に影響を与える。

文脈依存型エンべディングでは、入力された文章中の各単語ごとにベクトルが生成される。しかし、多くの場合、文章全体を表現する一つのベクトルが求められる。そこで登場するのが「プーリング」という処理である。プーリングは、文章内の複数の単語ベクトルを一つにまとめる役割を担う。例えば、一般的なプーリング方法の一つに「平均プーリング」があり、これは、文章中の有効な単語ベクトルの合計をその単語数で割ることで、一つの代表ベクトルを生成する。他にも、文章の最初の単語のベクトルを採用する「CLSプーリング」や、各次元で最大値を取る「最大プーリング」など、様々な方法が存在する。どのプーリング方法を選択するかは、モデルの訓練時に決定され、その選択が最終的な文章ベクトルの性質に大きく影響する。プーリングの後には、しばしば「正規化」というステップが続く。これは、生成されたベクトルを単位長（長さが１となる）に調整する処理で、ベクトル間の類似度を計算する際に、ベクトルの長さの違いによる影響を排除し、方向だけに着目できるようにする目的がある。これらのプーリングと正規化の具体的な方法は、モデルの一部として組み込まれており、同じモデルであっても、これらの後処理が異なると、結果として得られるベクトルも異なるものになる。

生成されたエンべディング（ベクトル）は、テキスト間の類似度を計算するために広く使われる。例えば、ある検索クエリのエンべディングと、多数の文書のエンべディングを比較することで、クエリに最も関連性の高い文書を効率的に見つけ出すことが可能になる。ベクトルが単位長に正規化されている場合、コサイン類似度（二つのベクトルのなす角度のコサイン値）は単なるドット積（内積）として計算できるため、高速な比較が可能となる。文書検索システムでは、この処理を大規模に行うことで、何百万もの文書の中から瞬時に最適なものを特定する。この際、エンべディングの「次元数」（ベクトルの数値の個数）は、インデックスのサイズと、それに伴うメモリやストレージのコストに直結する。例えば、384次元のエンべディングを持つ1000万件の文書を格納する場合、索引構造を含めずに15.4GBものデータが必要となり、次元数が倍になればコストも倍になる。したがって、次元数の選択は、モデルの性能だけでなく、システムの運用コストにも大きく影響する重要な決定となる。また、類似度として得られる数値（例えばコサイン類似度）自体は、絶対的な「確信度」を示すものではなく、あくまでもモデルが定義する空間内での「位置関係」を示すものである点に注意が必要である。異なるモデル間で直接類似度を比較することは避けるべきである。

システムエンジニアがデータベースを扱う上で慣れ親しんでいる概念に「スキーママイグレーション」がある。これは、データベースの構造（スキーマ）を変更する際に、既存のデータを新しい構造に合わせて変換する仕組みを指す。しかし、エンべディングの世界には、このような「マイグレーション」の概念が存在しない。これは、エンべディング空間が人間の手で設計されたものではなく、モデルの学習過程で自律的に形成されるためである。モデルが異なれば、同じ単語や文章から生成されるエンべディングも異なる空間に存在し、互換性はない。古いモデルで作成されたエンべディングを格納したインデックスを、新しいモデルで生成されたエンべディングを使って検索しようとすると、そのパフォーマンスは著しく低下する。これは、データベースのスキーマ変更で起こるような明確なエラーとして現れるのではなく、検索結果の精度が「静かに」悪化するという形で現れるため、問題の発見が困難である場合が多い。例えば、ある古いモデルで作成されたインデックスに対して、別の新しいモデルでクエリをかけると、上位5件の検索結果のうち、正しいものが60%程度しか残らないといった状況が発生する。これは、ランダムな検索よりもましではあるものの、期待される性能からはほど遠い結果である。

このような問題への対策として、MLエンジニアはいくつかの習慣を身につける必要がある。まず、エンべディングが生成された際のモデル情報（モデルのハッシュ値、プーリングモード、正規化ステップ、処理可能なシーケンス長など）を、インデックスのメタデータとして厳密に保存し、クエリ発行時にこれらの情報が一致しない場合は検索を拒否するべきである。これにより、互換性のないエンべディングでの検索を防ぐことができる。次に、エンべディングインデックスの更新は「カットオーバー」方式で行うことが推奨される。これは、新しいモデルで構築したインデックスを古いインデックスと並行して運用し、準備が整ったらすべてのクエリを一斉に新しいインデックスに切り替える方法である。一部ずつ更新する「ローリングアップデート」は、古いエンべディングと新しいエンべディングが混在する状態を生み出し、検索精度が不安定になるリスクがあるため避けるべきである。また、モデルの変更による影響を評価する際には、コサイン類似度の絶対値ではなく、「近傍のオーバーラップ」（特定のクエリに対して上位k件の検索結果がどれだけ一致するか、recall@k）を測定することが重要である。これは、類似度の数値自体がモデルによって変動するのに対し、近傍の集合はモデル間の「ずれ」をより直接的に示す指標となるためである。最後に、エンべディングの次元数は、インデックスの記憶容量や処理速度に直接影響するコストであることを常に意識し、現在のデータ量だけでなく、将来的なデータ規模を見越して適切な次元数を選択する必要がある。これらはいずれもモデルの性能を向上させる「モデリング」の作業とは異なり、システム運用やデータ管理の側面に属するエンジニアリングの課題である。エンべディングインデックスは、見かけ上は数値の列を持つデータベースのように見えるが、その背後にあるモデルの特性を理解し、適切な運用を行うことが極めて重要である。