Identificación de modelos de embeddings a partir de valores numéricos brutos

Los modelos de embeddings son cajas negras. Envías texto y obtienes un vector. Una lista de números de coma flotante sin etiqueta, sin marca de agua, sin metadatos que indiquen de dónde provienen. Si alguien le entrega un vector de 1024 dimensiones, ¿puede saber si fue producido por BGE-M3, jina-embeddings-v5-text-small o Qwen3-Embedding? E incluso si dos vectores provienen del mismo modelo, ¿puede saber si fueron generados con una instrucción de recuperación o de clasificación?

Resulta que sí se puede. Los patrones numéricos en un vector de embeddings llevan una huella digital sorprendentemente fuerte del modelo que lo produjo, e incluso del prompt de instrucción utilizado durante la inferencia. Entrenamos un pequeño clasificador transformer (800 000 parámetros) para identificar 68 combinaciones diferentes de modelo-tarea de más de 25 modelos de embeddings, logrando una precisión del 87 % leyendo nada más que los dígitos puros de coma flotante. Puede probar la demo en vivo usted mismo: pegue cualquier vector de embeddings y vea qué modelo y tarea cree el clasificador que lo produjo.

tagTokenización: tratando los números como texto

Un vector de embeddings de 1024 dimensiones es una secuencia de 1024 números de coma flotante. Para introducirlo en un clasificador, necesitamos una representación que no haga suposiciones sobre la estructura de los valores.

Adoptamos un enfoque audaz: tratar cada número de coma flotante como una cadena de caracteres numéricos y tokenizarlo carácter por carácter. Esto puede parecer un desperdicio en comparación con otras alternativas más compactas, pero resulta ser el equilibrio adecuado. Para un valor como -0.1234, la secuencia de tokens es:

- 0 . 1 2 3 4
Copiar

Las dimensiones están separadas por un token [SEP]. La secuencia completa comienza con [CLS]. El vocabulario completo tiene 15 tokens:

Con una precisión de 4 decimales, un vector de 1024 dimensiones produce aproximadamente 7 700 tokens. Un vector de 384 dimensiones produce unos 2 900 tokens. La longitud de la secuencia varía de forma natural con la dimensión del embedding, y no es necesario realizar rellenos (padding) ni truncamientos entre dimensiones. Dado que el tokenizador es un mapeo directo de enteros sin componentes aprendidos, es extremadamente eficiente.

tagArquitectura del modelo

El clasificador es un pequeño transformer solo de codificación (encoder-only) con 4 capas, 128 dimensiones, 4 cabezales de atención con RoPE, SwiGLU FFN y RMSNorm. El token CLS se agrupa y se proyecta en el espacio de salida de 68 clases. El total de parámetros es de aproximadamente 800 000.

A pesar del diminuto vocabulario de 15 tokens, esta es fundamentalmente una tarea de secuencia larga. Un solo embedding de 1024 dimensiones se convierte en una secuencia de 7 700 tokens, más larga que las entradas típicas de procesamiento de lenguaje natural (NLP). El modelo debe prestar atención a miles de tokens de dígitos para detectar patrones estadísticos que distingan la salida de un modelo de otro. Esto hace que la atención eficiente y la codificación posicional (RoPE) sean esenciales incluso a esta pequeña escala.

tagDatos

Utilizamos 10 000 muestras de texto multilingüe, cada una procesada por más de 25 modelos con varios prefijos de tarea como retrieval.query, retrieval.document, classification y clustering, produciendo 68 clases distintas. Es importante destacar que las 68 clases incluyen no solo diferentes modelos, sino también diferentes prompts de instrucción aplicados al mismo modelo. Por ejemplo, jina-embeddings-v5-text-small con una instrucción de recuperación y jina-embeddings-v5-text-small con una instrucción de clasificación se tratan como clases separadas. El objetivo es detectar tanto la identidad del modelo como el comportamiento específico de la tarea basándose únicamente en la salida bruta.

Cada clase se divide en 7 000 muestras de entrenamiento y 3 000 de validación. Los modelos abarcan cinco dimensiones de salida.

Solo dentro del grupo de 1024 dimensiones, hay 32 clases que separar, incluyendo modelos de la misma familia con diferentes prefijos de tarea. El clasificador no puede confiar en la longitud de la secuencia aquí; debe aprender puramente patrones numéricos.

tagEntrenamiento

El entrenamiento se ejecutó en una A100 de 40 GB con precisión mixta, procesamiento por lotes agrupado por longitud y AdamW con programación de coseno, alcanzando unos 340 000 tokens por segundo y 23 800 pasos por época.

tagResultados experimentales

La estrecha brecha entre entrenamiento y validación y la mejora continua sugieren un aprendizaje generalizable en lugar de memorización. Con 800 000 parámetros, el modelo se acerca a su límite de capacidad, y un modelo más grande probablemente aumentaría la precisión.

tagMatriz de confusión

La precisión global es del 87,0 %, es decir, 59 veces mejor que el azar (1,5 %). Varios modelos se clasifican perfectamente, incluyendo GTE-large, las variantes de clasificación de jina-embeddings-v3/jina-embeddings-v5-text-small, LaBSE y Paraphrase MiniLM. Los casos más difíciles son las variantes de prefijo de tarea del mismo modelo base. Qwen3-0.6B presenta la mayor confusión dentro de su familia en sus 4 tipos de tareas, mientras que jina-embeddings-v5-text-small logra una precisión del 92 % dentro de su familia en 5 tareas. El hecho de que diferentes prompts de instrucción en el mismo modelo produzcan patrones de salida distinguibles es, de por sí, un hallazgo digno de mención, lo que sugiere que la adaptación a la tarea deja un rastro numérico medible incluso cuando los pesos base son idénticos.

Los modelos de familias diferentes (BGE frente a Jina frente a E5 frente a Nomic) son mucho más fáciles de separar que las variantes de tarea del mismo modelo. La arquitectura principal y la metodología de entrenamiento dejan una firma más fuerte que los adaptadores específicos de la tarea. El verdadero desafío reside en el grupo de 1024 dimensiones (32 clases) y el grupo de 768 dimensiones (24 clases), donde el clasificador debe confiar puramente en patrones numéricos en lugar de en la longitud de la secuencia.

tagEnfoques alternativos

tagTokenizador de cubetas (Bucket Tokenizer)

Cuantiza cada dimensión en uno de K contenedores (por ejemplo, 256), produciendo una secuencia compacta de longitud D, con un token por dimensión. Este es el enfoque utilizado por Embedding-Converter (ICLR 2025). Para un vector de 1024 dimensiones, se obtienen 1024 tokens en lugar de 7 700.

La creación de cubetas impone una prioridad sobre la distribución de los valores. Se deben decidir los límites de los contenedores antes de ver los datos. Pero los diferentes modelos distribuyen sus valores de formas fundamentalmente distintas. Algunos concentran la masa en un rango estrecho alrededor de cero, otros distribuyen los valores en [-1, 1] uniformemente, y la distribución varía según la dimensión dentro de un solo modelo. Cualquier esquema de división fija desperdicia resolución donde los valores se agrupan o no resuelve lo suficiente donde se dispersan. La división adaptativa por modelo anula el propósito, ya que requiere conocer la identidad del modelo de antemano.

tagMLP de longitud fija

Introducir el vector de embeddings bruto directamente en un clasificador MLP. El problema fundamental va más allá de la cuestión de la dimensión variable (nuestros modelos producen vectores de 384 a 1536 dimensiones). Incluso si se rellena todo a una longitud fija, se está asumiendo implícitamente que los índices de las dimensiones están alineados semánticamente entre los modelos, que la dimensión 1 de BGE-M3 corresponde a la dimensión 1 de jina-embeddings-v5-text-small. Esta suposición es falsa. Diferentes arquitecturas, datos de entrenamiento y objetivos de entrenamiento producen representaciones internas completamente diferentes.

Ambas alternativas imponen suposiciones estructurales que el modelo debe sortear. La tokenización a nivel de dígitos las evita todas. Es la representación con menos suposiciones que pudimos encontrar: aquí están los dígitos exactos de cada número, en orden, separados por marcadores. Averigüe el resto usted mismo.

tagConclusión

Los modelos de embeddings se entrenan para mapear textos semánticamente similares a vectores cercanos. El objetivo del entrenamiento no dice nada sobre hacer que los vectores sean identificables, nada sobre codificar una firma del modelo. Sin embargo, la firma está ahí, lo suficientemente fuerte como para que un diminuto clasificador la detecte. El "estilo" de un modelo de embeddings, los patrones numéricos específicos que utiliza para representar el significado, es tan distintivo como la escritura a mano. Incluso la elección del prompt de instrucción deja un rastro detectable.

Esto tiene un valor práctico para auditar bases de datos vectoriales cuando se desconoce el modelo de origen, verificar que una API realmente utiliza el modelo que afirma y detectar cambios de versión del modelo. Fundamentalmente, nos indica que los modelos de embeddings codifican el significado de formas estructuralmente distintas, incluso cuando producen vectores de la misma dimensionalidad.