ベクトルモデルは、AI における不遇な存在です。画像生成ほど魅力的でもなく、LLM チャットボットほど話題を呼ぶこともなく、人工超知能の予測ほど破滅的なものでもありません。セマンティックなベクトルモデルは難解で技術的であり、一般消費者が直接利用することはあまりありません。
ベクトルモデルは、セマンティクスを高次元空間における幾何学的関係に変換するベクトルです。しかし、それらを扱わない人に言ってみても、退屈して目をそらすでしょう。
だからといって、それらが重要でない、あるいは革新的でないということではありません。テキストのセマンティクスを高次元空間のベクトルとして表現することは1950 年代から存在していましたが、トランスフォーマーアーキテクチャを備えたニューラルネットワークは、それを音声、画像、ビデオ、そしてほぼすべての種類のデジタルデータに拡張しました。過去 10 年間の計算セマンティクスの質的な向上は変革をもたらし、検索エンジン、レコメンデーションアルゴリズム、自動分類器、および意思決定システムへの影響は、ニュースになることはほとんどありませんが、非常に大きなものでした。
この過小評価されている革命で見落とされていることの 1 つは、最近のトランスフォーマーベースのものを含むほとんどのニューラルネットワークが、暗黙的にベクトルモデルであるということです。大規模言語モデル、生成画像モデル、および機械翻訳システムはすべて、入力を本質的なセマンティクスを保持する高次元ベクトル空間（つまり、ベクトルモデルを作成する）に変換し、それを使用して出力を生成します。これらのモデルは、情報検索やその他の目的のためにベクトルモデルを生成するように容易に再利用できます。
この記事では、生成言語モデル（LLM など）を使用してテキストベクトルモデルを生成する際に関わる主な問題と、この作業を使用してモデルを改善する方法について説明します。
tagエンコーダーとデコーダー
「エンコーダー」と「デコーダー」という用語は、AI モデル開発でよく使用されますが、多くの場合、非常に紛らわしい方法で使用されます。これらの用語は、電気工学および情報理論の概念に関連しており、ニューラルネットワークが実際よりも理論的であった時代に遡ります。
元の概念では、エンコーダーは入力をマシンで使用可能な形式に変換し、デコーダーはその逆を行い、データをより人間が使いやすいものに変換します。それが非常に抽象的に思える場合は、そのとおりです。そこで、具体的な例を見てみましょう。
従来のデジタル電子機器（AI ではない）では、エンコーダーは、マイクでキャプチャされたアナログサウンドのような豊富な入力ソースを、コンピューターのメモリ、物理的なデジタルメディアに保存したり、インターネットのようなデジタルネットワークを介して送信したりできるバイナリシーケンスに変換するデバイスです。
ベクトルモデルと生成 AI につながった初期の研究の多くは機械翻訳で行われ、基本的なアーキテクチャはこの図と密接に一致していました。
ベクトルモデルは、エンベディングベクトルを生成するためのアダプターが追加された、エンコーダー-デコーダー機械翻訳モデルの「エンコーダー」半分と見なすことができます。
また、生成モデルは「デコーダー」半分と見なすことができます。
ニューラルネットワークモデルについてこのように考えるのは、非常に直感に反する可能性があります。データモデリング、セマンティクス、および圧縮の関係は複雑で非常に抽象的ですが、AI モデルを理解する上で重要です。エンコーダーモデルとデコーダーモデルの違いは、アーキテクチャではなく、その使用方法にあります。
tagトランスフォーマーベースのエンコーダーとデコーダーは同じです
エンコーダーとデコーダーはかなり抽象的な概念ですが、トランスフォーマーベースのモデルについて話している場合、両方ともほぼ同一のアーキテクチャを持っています。
以下の例は、生成言語モデルとテキストベクトルモデルを示していますが、いくつかの小さな変更を加えることで、他のメディアタイプにも同じことが当てはまります。
エンコーダーのみのモデルとデコーダーのみのモデルはどちらもテキストを入力として受け取り、トークン化を適用してからベクトル化を行います。これは基本的に、辞書でトークンを検索し、各トークンに対応するベクトルを代入してから、必要に応じてパディングを追加します。その結果、モデルの残りの部分に対する固定長の入力ベクトルが得られます。
デコーダーのみの生成言語モデルでは、この入力ベクトルはトランスフォーマーモデルに渡され、次にその出力を 1 つまたは複数のトークンに変換するデコーダーアダプターに渡されます。テキスト生成モデルは、これらの新しいトークンを入力に追加し、再度実行してさらにトークンを追加します。
トークンを生成するデコーダー装置を除いて、この図のほぼすべてがトランスフォーマーベースのテキストベクトルのアーキテクチャと共有されています。エンコーダー装置はベクトルのを出力します。
2 つの主な違いは、基本的にアーキテクチャにあるのではなく、トレーニング方法と使用方法にあります。
生成言語モデルは通常一方向（または「因果的」）です。つまり、前のトークンのみを見て次のトークンを生成します。ベクトルモデルは通常双方向（または「非因果的」）です。
これはトレーニング方法に影響します。生成モデルのトレーニングは、テキストの量から学習することで、一度に 1 つのトークンずつ渡されます。ベクトルモデルは通常、「マスクされた言語モデリング」（MLM）手法を使用して事前トレーニングされます。つまり、ギャップの前後の単語を見て、欠落している単語のセマンティック表現を生成します。
それにもかかわらず、原則として、生成 LLM をベクトルモデルに変換するということは、デコーダー装置をエンコーダーに置き換え、新しい用途に合わせて微調整するだけです。
では、なぜそうしないのでしょうか？
tagトランスフォーマーベースのエンコーダーとデコーダーは異なります
研究者たちは、生成言語モデルをテキストベクトルモデルに変換しない 3 つの大きな理由を提示しましたが、最近、それぞれの理由に疑問が投げかけられています。
双方向（「非因果的」）アテンションは、一方向（「因果的」）アテンションよりも優れています。
画期的な BERT モデル以来、双方向アテンションは、より多くの情報が利用可能であるという理由だけで、一方向よりも優れていると当然のことと見なしてきました。モデルは、トークンを先行する単語のコンテキストだけでなく、完全なコンテキストで見ることができます。
ただし、最近の研究（Wang et al. 2023、Gisserot-Boukhlef et al. 2025)）では、どの要素に注目しているかによって、それぞれにいくつかの小さな利点があるものの、双方向と一方向の事前トレーニングの結果に大きな違いはないことが示唆されています。
生成 LLM は次元の呪いに苦しめられ、汎化が苦手です。
LLM は、優れたベクトルモデルになるように設計されていません。それらの内部ベクトル表現（隠れ層）は、通常、ベクトルモデルが持つよりもはるかに多くの次元を持っています。モデルが大きすぎると、大きなセマンティック空間にコンパクトな表現が含まれている必要がないため、汎化に失敗する可能性があります。
この問題は、次元の呪いと呼ばれることもあり、ニューラルネットワークを悩ませています。
ベクトルモデルとは異なり、生成言語モデルは相対評価されます。生成モデルは内部のベクトルモデルを直接使用するのではなく、それらを詞元に変換して得られる言語を使用します。モデルが流暢かつ首尾一貫して話しているように見える場合、我々はそれを高く評価します。一方、ベクトルモデルは、正しい汎化を必要とする実際のタスクを実行する必要があります。そのため、次元の呪いは生成モデルにとってはそれほど重要ではないように思えますが、ベクトルモデルにとっては致命的です。
しかし、最近、生成言語モデルは次元の呪いをある程度克服しました。100億未満のパラメータを持つ高性能な生成小言語モデル（SLM）は現在非常に一般的であり、ベクトルモデルへの関心よりも、より小型で効率的な言語モデルを求める欲求によって動機付けられていますが、それらを利用してより良いモデルを構築することができます。
既に試した人がいますが、うまくいきませんでした。
ベクトルモデルと生成モデルの二面性は新しいものではありませんが、生成モデルから適合されたベクトルモデルは、通常、同等の性能を持つベクトルモデルよりもはるかに大きくなっています。OpenAIは2022年にGPT-3をベクトルモデルに適合させましたが、約1750億のパラメータにもかかわらず、約10億未満のパラメータを持つMLMで学習されたベクトルモデルとほぼ同等の性能を発揮します。
しかし、NVIDIAが70億パラメータのMistral-7B SLMから適合させたNV-Embedモデルファミリーは、標準的なベクトルモデルのベンチマークで最先端の性能を達成しました。これは、生成言語モデルの適合が実際には非常にうまくいくことの十分な証拠です。
tag生成モデルを適合させる利点
デコーダースタイルの生成言語モデルをエンコーダースタイルのベクトルモデルに転用することは、短所はないかもしれませんが、少なくとも表面上は利点もないようです。しかし、実際には、いくつかの具体的な利点があります。
まず、生成言語モデルはAIの魅力的な部分であるため、多くの研究と資金の焦点となっています。それらから適合されたベクトルモデルは、追加のコストをほとんどかけずにその余分な注目と努力を流用することができます。新しいベクトルモデルをゼロから開発してトレーニングすることは、事前トレーニングされたモデルを最適化するために使用される対照的なファインチューニングと比較して費用のかかる作業であるため、この純粋な経済的利点は非常に重要です。
例として、最近リリースされたモデルjina-code-embeddings-1.5bとjina-code-embeddings-0.5bは、それぞれコード生成バックボーン、具体的にはQwen2.5-Coder-1.5BとQwen2.5-Coder-0.5Bに基づく最初のコードベクトルモデルです。複雑でコストのかかる事前トレーニングを行う代わりに、優れたベクトルモデルのためにそれらをトレーニングすることにすべての注意を集中することができたため、ベクトルモデルとしてのパフォーマンスを大幅に向上させました。
次に、生成モデルの機能を新しいドメインに転送することが可能です。
jina-embeddings-v4モデルはまさにそれを行います。38億パラメータのビジョン言語モデルであるQwen2.5-VL-3B-Instructをマルチモーダルベクトルモデルに適合させています。図、スクリーンショット、およびその他の視覚的なドキュメント画像の入力に対するベクトルモデルとしての卓越したパフォーマンスは、生成モデルの既存の自然言語理解能力に依存しています。言語を理解し、画像内の印刷されたテキストを解析し、最終的に優れたベクトルモデルを生成するために、最初にモデルをゼロからトレーニングする代わりに、既存の画像ベクトルモデルと生成言語モデルから知識を転送し、ベクトルモデルのタスクに対する対照的なトレーニングに焦点を当てることができました。
tagベクトルモデルは仕事をこなす
他のすべての条件が同じであれば、生成言語モデルをベクトルモデルのバックボーンとして使用することに明確な利点はありません。テキストベクトルモデルをゼロから構築する必要がある場合、双方向または単方向の事前トレーニングを使用するかどうかはあまり関係ないようです。データの品質、タスクの専門化、およびベクトルモデルの品質のためのファインチューニングに投資する方がはるかに重要です。
しかし、他のすべての条件は同じではありません。
ベクトルモデルは、生成AIが非常に有名な印象的なデモのような資金を得ていません。代わりに、精度、品質、およびコストがすべてを左右する重要な、実際に存在するユースケースがあります。情報検索、分類タスク、レコメンデーションシステム、スパムおよび詐欺検出、コンテンツモデレーション — これらはすべて、ベクトルモデルが現在行っている実際の仕事です。
ベクトルモデルはそれほど魅力的ではありませんが、仕事をこなします。したがって、AIの魅力的な側面からのより多くの資金を、その赤毛の継子に転用できるのであれば、それは十分に公平であるように思えます。
