EmbeddingGemma 2 de Google junta texto, código, imágenes y audio en un modelo abierto de embeddings de 740M

Google DeepMind lanzó el 6 de octubre EmbeddingGemma 2, un modelo abierto de embeddings que lleva texto, código, imágenes, video y audio a un mismo espacio vectorial de 768 dimensiones. Tiene 740 millones de parámetros, está construido sobre la arquitectura de Gemma 4 y se distribuye con licencia Apache 2.0. Los pesos están en Hugging Face y Kaggle, según el anuncio de Google; la disponibilidad en el Model Garden de Google figura como próxima.

No es un modelo de chat. Un modelo de embeddings convierte contenido en vectores para que el software encuentre cosas parecidas: el paso de recuperación en un pipeline RAG, la búsqueda semántica sobre un repositorio o el ruteo de un pedido hacia la herramienta correcta. Es una parte del stack que casi no se lleva atención, pero define qué termina leyendo el modelo de lenguaje.

Qué trae el lanzamiento

• Tamaño modular. El núcleo de texto tiene 270M de parámetros (130M de transformer más 140M de embedder). El encoder de visión (170M) y el de audio (300M) son opcionales y podés no cargarlos, así que quedan cuatro configuraciones: 270M solo texto, 440M texto e imágenes, 570M texto y audio, 740M con todo.
• Contexto de 8.192 tokens, cuatro veces el del primer EmbeddingGemma. Todas las modalidades comparten ese presupuesto a tasas fijas, según la ficha del modelo: 280 tokens por imagen, 140 por cuadro de video y 25 por segundo de audio. Google ubica el techo en unos 5,5 minutos de audio, 29 imágenes o 58 cuadros de video.
• Truncado Matryoshka. Los vectores se pueden recortar de 768 a 512, 256 o 128 dimensiones, con hasta 6 veces menos almacenamiento.
• Memoria en el dispositivo. Google dice que, cuantizado, en un Pixel 11 Pro necesita unos 191MB de RAM activa para los pesos de solo texto y unos 567MB para el modelo multimodal completo.
• Herramientas desde el primer día: sentence-transformers, transformers, vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX, transformers.js, LiteRT y MediaPipe, con una guía de fine-tuning de Unsloth.

Los números, y lo que no muestran

Todas las cifras de benchmarks salen de las pruebas de la propia Google, publicadas en la ficha del modelo sobre el checkpoint en precisión completa. Al momento de publicar no había evaluación independiente disponible.

La mejora principal está en código. En MTEB Code, EmbeddingGemma 2 marca 78,68 contra 68,76 de su antecesor: 9,92 puntos más, lo que Google describe como alrededor de un 14%. En texto multilingüe el cambio es mínimo: 61,36 en MTEB multilingual v2, contra 61,15 de la primera versión. En la práctica, la calidad de recuperación de texto quedó más o menos donde estaba; lo nuevo es el código y el soporte de imagen, video y audio en el mismo modelo.

Para las modalidades nuevas no hay versión anterior con la cual comparar. La ficha informa 64,64 en MIEB lite (imágenes), 50,67 en MMEB v2 video, 69,54 en MSEB de recuperación de audio y 49,39 en MAEB. Google dice que son los mejores puntajes entre los embedders multimodales de menos de 1B de parámetros y que supera a algunos modelos especializados de más del doble de tamaño, pero el anuncio no nombra a esos rivales.

Truncar tiene un costo, y la ficha lo dice sin vueltas. A 256 dimensiones las pérdidas son moderadas: texto multilingüe baja de 61,36 a 60,41 y código de 78,68 a 76,18. A 128 dimensiones la calidad multimodal cae mucho más: el puntaje general de MMEB v2 pasa de 59,01 a 45,65 y la recuperación de audio de 69,54 a 56,71. Google recomienda 128 dimensiones sobre todo para cargas de solo texto, y probándolo antes con tus propios datos.

Qué cambia para quien desarrolla

Hay tres puntos prácticos para cualquiera que arme sistemas de recuperación o agentes de código.

Los prefijos de tarea importan. Igual que su antecesor, el modelo está entrenado con instrucciones cortas delante de las entradas de texto; por ejemplo, task: code retrieval | query: ... para una consulta de búsqueda de código y title: <archivo> | text: <código> para el archivo indexado. La ficha advierte que sin el prefijo funciona igual, pero con menos precisión. Imágenes, audio y video van sin prefijo. Si cambiás de modelo de embeddings y los resultados empeoran, revisá esto primero.

La recuperación de código local se abarata. Un embedder de texto y código de 270M que marca 78,68 en MTEB Code es lo bastante chico para indexar un repositorio en una notebook. Eso lo vuelve un candidato razonable para agentes de código que no quieren mandar el código fuente a APIs de terceros. Si le gana o no a la API de embeddings que ya usás es algo para medir con tu propio set de evaluación, no con la tabla del proveedor.

Trampas de precisión y normalización. La ficha dice que float16 puede devolver NaN o resultados degradados; usá bfloat16 o float32. Después de truncar hay que volver a normalizar los vectores, y consultas y documentos tienen que usar la misma dimensión. Si te salteás la normalización no salta ningún error: simplemente obtenés rankings que parecen razonables pero son peores. Según la guía para desarrolladores, un millón de vectores de 768 dimensiones ocupa alrededor de 1,5GB, contra unos 250MB a 128 dimensiones.

El modelo además comparte el tokenizer de texto y el encoder de audio con Gemma 4, así que Google dice que los dos pueden correr juntos en un mismo pipeline en el dispositivo con menos memoria combinada. Eso importa sobre todo para apps móviles y de edge que quieren RAG local sin servidor.