埋め込みモデル（埋め込み）はブラックボックスです。テキストを入力すると、ベクトルが出力されます。そこにはラベルも、透かしも、出所を知らせるメタデータもない浮動小数点数のリストがあるだけです。もし誰かから 1024 次元のベクトルを渡されたとして、それが BGE-M3、jina-embeddings-v5-text-small、あるいは Qwen3-Embedding のどれによって生成されたか判別できるでしょうか？また、たとえ 2 つのベクトルが同じモデルから生成されたものであっても、それらが検索（retrieval）の指示で生成されたのか、分類（classification）の指示で生成されたのかを判別できるでしょうか？
結論から言うと、それは可能です。埋め込みベクトル内の数値パターンには、それを生成したモデルや、推論時に使用されたプロンプトの驚くほど強力なフィンガープリント（指紋）が含まれています。私たちは 800K パラメータの小さな Transformer 分類器を学習させ、25 以上の埋め込みモデルから 68 種類のモデルとタスクの組み合わせを特定できるようにしました。生の浮動小数点数のみを読み取ることで、87% の精度を達成しました。こちらの ライブデモ で実際に試すことができます。任意の埋め込みベクトルを貼り付けると、分類器がどのモデルとタスクによって生成されたかを推測します。
tagトークン化：数値をテキストとして扱う
1024 次元の埋め込みベクトルは、1024 個の浮動小数点数のシーケンスです。これを分類器に入力するには、値の構造について一切の仮定を置かない表現が必要になります。
私たちは大胆なアプローチを採用しました。各浮動小数点数を数字の文字列として扱い、文字ごとにトークン化（トークン）するのです。これは よりコンパクトな代替案 と比較すると無駄が多いように思えるかもしれませんが、結果的に適切なトレードオフであることがわかりました。例えば -0.1234 という値の場合、トークンシーケンスは次のようになります。
- 0 . 1 2 3 4各次元は [SEP] トークンで区切られます。シーケンス全体は [CLS] で始まります。語彙数は全部で 15 トークンです。
| Token ID | Meaning |
|---|---|
| 0-9 | Digits |
| 10 | Minus sign |
| 11 | Decimal point |
| 12 | [SEP] |
| 13 | [CLS] |
| 14 | [PAD] |
小数点以下 4 桁の精度で、1024 次元のベクトルは約 7,700 トークンを生成します。384 次元のベクトルは約 2,900 トークンになります。シーケンス長は埋め込みの次元数に応じて自然に変化し、次元間でのパディングや切り捨ては不要です。トークナイザーは学習コンポーネントのない直接的な整数マッピングであるため、非常に効率的です。
tagモデルアーキテクチャ
この分類器は、4 層、128 次元、RoPE を備えた 4 つのアテンションヘッド、SwiGLU FFN、および RMSNorm を備えた小規模なエンコーダーのみの Transformer です。CLS トークンがプーリングされ、68 クラスの出力空間に投影されます。総パラメータ数は約 800K です。
15 トークンという非常に小さな語彙数にもかかわらず、これは根本的にロングシーケンス（長文）タスクです。単一の 1024 次元埋め込みは 7,700 トークンのシーケンスになり、これは典型的な NLP 入力よりも長いです。モデルは数千の数字トークンにアテンションを払い、あるモデルの出力を別のモデルと区別するための統計的パターンを捉えなければなりません。このため、この小規模なスケールであっても効率的なアテンションと位置エンコーディング（RoPE）が不可欠となります。
tagデータ
私たちは 10,000 個の多言語テキストサンプルを使用し、それぞれを 25 以上のモデルで、retrieval.query、retrieval.document、classification、clustering などの様々なタスクプレフィックスを使用して埋め込み、68 の異なるクラスを作成しました。重要なのは、この 68 クラスには異なるモデルだけでなく、同じモデルに適用された異なるプロンプト（指示プロンプト）も含まれている点です。例えば、検索指示を与えた jina-embeddings-v5-text-small と、分類指示を与えた jina-embeddings-v5-text-small は別のクラスとして扱われます。目標は、生の出力のみからモデルの正体とタスク固有の動作の両方を検出することです。
各クラスは 7,000 個の訓練サンプルと 3,000 個の検証サンプルに分割されています。モデルは 5 つの出力次元にわたります。
| Dimension | Classes | Example Models |
|---|---|---|
| 384 | 8 | BGE-small, E5-small, MiniLM, GTE-small |
| 512 | 2 | BGE-small-zh |
| 768 | 24 | BGE-base, E5-base, jina-embeddings-v5-text-nano, Nomic, INSTRUCTOR, LaBSE |
| 1024 | 32 | BGE-M3, E5-large, jina-embeddings-v3, jina-embeddings-v5-text-small, Qwen3-0.6B, Snowflake, mxbai |
| 1536 | 2 | GTE-Qwen2-1.5B |
1024 次元のグループだけでも 32 のクラスを分離する必要があり、その中にはタスクプレフィックスが異なるだけの同じファミリーのモデルも含まれています。ここでは分類器はシーケンス長に頼ることはできず、純粋に数値パターンを学習しなければなりません。
tag訓練
訓練は A100 40GB 上で混合精度、長さバケット化されたバッチ処理、およびコサインスケジュールを用いた AdamW を使用して行われ、秒間約 340K トークン、1 エポックあたり 23,800 ステップに達しました。
tag実験結果
訓練と検証の差が小さく、改善が継続していることは、暗記ではなく汎用的な学習が行われていることを示唆しています。800K パラメータではモデルの容量限界に近づいており、より大きなモデルを使用すればさらに精度が向上する可能性があります。
tag混同行列
全体的な精度は 87.0% で、これはランダムな確率（1.5%）の 59 倍優れています。GTE-large、jina-embeddings-v3/jina-embeddings-v5-text-small の分類バリアント、LaBSE、Paraphrase MiniLM を含むいくつかのモデルは完璧に分類されました。最も困難なケースは、同じベースモデルのタスクプレフィックスによるバリアントです。Qwen3-0.6B は 4 つのタスクタイプ間でファミリー内での混同が最も多かった一方、jina-embeddings-v5-text-small は 5 つのタスクにわたって 92% のファミリー内精度を達成しました。同じモデルに対する異なるプロンプト（指示プロンプト）が、区別可能な出力パターンを生成するという事実は、それ自体が注目すべき発見です。これは、ベースの重みが同一であっても、タスクへの適応が測定可能な数値的痕跡を残すことを示唆しています。
異なるファミリーのモデル（BGE 対 Jina 対 E5 対 Nomic）は、同じモデルのタスクバリアントよりもはるかに簡単に分離できます。コアアーキテクチャとトレーニング手法は、タスク固有のアダプターよりも強いシグネチャーを残します。本当の課題は 1024 次元グループ（32 クラス）と 768 次元グループ（24 クラス）にあり、ここでは分類器はシーケンス長ではなく、純粋に数値パターンに頼る必要があります。
tag代替アプローチ
tagバケットトークナイザー
各次元を K 個のビン（例えば 256 個）のいずれかに量子化し、1 次元につき 1 トークン、長さ D のコンパクトなシーケンスを生成します。これは Embedding-Converter（ICLR 2025）で使用されている手法です。1024 次元のベクトルの場合、7,700 トークンの代わりに 1024 トークンになります。
バケット化は、値の分布に関する事前知識を強いることになります。データを見る前にビンの境界を決定しなければなりません。しかし、モデルが異なれば、値の分布方法も根本的に異なります。あるものはゼロ付近の狭い範囲に集中し、別のものは [-1, 1] 全体に一様に分布し、さらに単一のモデル内でも次元によって分布が異なります。固定されたビン化スキームは、値が集中する場所では解像度を無駄にし、分散する場所では解像度不足に陥ります。モデルごとに適応的なビン化を行うことは、事前にモデルの正体を知る必要があるため、本末転倒です。
tag固定長 MLP
生の埋め込みベクトルを直接 MLP 分類器に入力します。根本的な問題は、可変次元の問題（私たちのモデルは 384 から 1536 次元のベクトルを生成します）だけではありません。たとえすべてを固定長にパディングしたとしても、モデル間で次元のインデックスが意味的に揃っていること、つまり BGE-M3 の第 1 次元が jina-embeddings-v5-text-small の第 1 次元に対応していることを暗黙のうちに仮定していることになります。この仮定は誤りです。異なるアーキテクチャ、訓練データ、訓練目的は、全く異なる内部表現を生成します。
どちらの代替案も、モデルが回避しなければならない構造的な仮定を強いています。数字レベルのトークン化は、それらすべてを回避します。これは私たちが見つけることができた、最も仮定のない表現です。「各数値の正確な数字を、順番に、マーカーで区切って提示する。あとはモデル自身が解明する」というものです。
tag結論
埋め込みモデル（埋め込み）は、意味的に類似したテキストを近いベクトルにマッピングするように訓練されます。訓練の目的関数には、ベクトルを識別可能にすることや、モデルのシグネチャーをエンコードすることについては何も書かれていません。しかし、シグネチャーはそこに存在し、ごく小さな分類器で検出できるほど強力です。埋め込みモデルの「スタイル」、つまり意味を表現するために使用される特定の数値パターンは、筆跡のように独特です。プロンプト（指示プロンプト）の選択ですら、検出可能な痕跡を残します。
これは、ソースモデルが不明な場合のベクトルデータベースの監査、API が実際に主張通りのモデルを使用しているかの検証、およびモデルのバージョン変更の検出において実用的な価値があります。より根本的には、同じ次元のベクトルを生成している場合であっても、埋め込みモデルは構造的に異なる方法で意味をエンコードしているということを私たちに教えてくれます。
