Andy Garcia · dev freelance
FRENES
Volver al blog
IA y Privacidad

El nuevo modelo de embeddings abierto de Google lleva la búsqueda multimodal al teléfono. Antes de indexar PDF escaneados con él, revisa el presupuesto de imagen

7 de octubre de 2026 6 min de lectura

El 6 de octubre, Google DeepMind publicó EmbeddingGemma 2, un modelo de embeddings abierto que proyecta texto, código, imágenes, vídeo y audio en un mismo espacio compartido de 768 dimensiones. Tiene 740 millones de parámetros, está construido sobre Gemma 4 y se distribuye con licencia Apache 2.0. La ficha del modelo dice que está pensado para hardware de consumo como teléfonos y portátiles, y la ficha on-device de Google incluye tiempos medidos en un iPhone.

Leí el anuncio, la ficha del modelo y la ficha on-device esa misma tarde, con una pregunta en mente. Construyo una LegalTech que maneja documentos de patentes, y publico apps de iOS por mi cuenta. En ambos mundos, la primera pregunta sobre un modelo de embeddings rara vez es "¿qué tan bueno es?". Es "¿adónde va el documento cuando lo indexo?".

Lo que Google realmente lanzó

El modelo es modular. La base de texto tiene 270M de parámetros (130M de transformer, 140M de tabla de embeddings). Un codificador de visión de 170M y un codificador de audio de 300M son opcionales. Texto más visión suman 440M; todo, 740M. Todas las configuraciones comparten un único espacio vectorial, así que una consulta codificada con la configuración solo de texto puede compararse con páginas codificadas con el modelo completo.

La ventana de contexto es de 8192 tokens, cuatro veces la del primer EmbeddingGemma. Una imagen cuesta 280 tokens por defecto, así que caben unas 29 imágenes en una entrada. La ficha afirma más de 100 idiomas. La salida está entrenada con Matryoshka Representation Learning: puedes conservar solo las primeras 512, 256 o 128 dimensiones, con hasta seis veces menos almacenamiento.

La licencia también cambió. El primer EmbeddingGemma está en Hugging Face bajo la licencia "gemma", tras un acceso restringido donde aceptas los términos de uso de Google. La versión 2 está etiquetada apache-2.0, sin restricción de acceso. La ficha del modelo sigue diciendo que los despliegues deben cumplir la Gemma Prohibited Use Policy, que un equipo jurídico querrá leer junto a la licencia.

Las cifras, y con qué se comparan

La ficha del modelo compara EmbeddingGemma 2 con exactamente un modelo: su predecesor. El texto multilingüe queda plano (61,36 frente a 61,15 en MTEB multilingual v2). El código salta de 68,76 a 78,68 en MTEB Code, los 9,92 puntos del titular. Todo lo demás es nuevo, así que no tiene con qué compararse: 64,64 en MIEB lite para imágenes, 50,67 en MMEB v2 vídeo, 69,54 en MSEB para recuperación de audio.

El anuncio añade tres gráficos que lo sitúan por tamaño frente a modelos abiertos: Qwen3-Embedding 0.6B y 8B para código, jina-embeddings-v5-omni y LCO-Embedding-Omni para imágenes y audio, entre otros. La parte alta de cada gráfico pertenece a un modelo mucho más grande, Qwen3-Embedding-8B para código y LCO-Embedding-Omni (3B, luego 7B) para imágenes y audio. La afirmación es calidad por parámetro, y los gráficos están dibujados para mostrar justo eso. El modelo alojado de Google, Gemini Embedding 2, no aparece en ninguno.

La cifra que me importa es otra: MMEB v2 VisDoc, recuperación de documentos visuales, 67,84 de NDCG@5. Es lo más parecido en la ficha a "encontrar la página escaneada correcta". No tiene nada al lado.

Por qué un embedder multimodal local importa para los documentos

La mayoría de los documentos con los que trabajo no son texto limpio. Los expedientes de patentes mezclan reivindicaciones con dibujos. El estado de la técnica llega en PDF escaneados. Una figura con números de referencia lleva un significado que el OCR aplana o pierde. El pipeline habitual encadena OCR, a veces un modelo de subtitulado, y luego un embedder de texto, y cada eslabón es un lugar donde algo se rompe o sale de tu máquina. El equipo edge de Google describe el mismo problema para los medios: un solo modelo "reduces the latency and memory overhead of chaining separate image captioning, speech-to-text, and text-embedding models" (reduce la latencia y la sobrecarga de memoria de encadenar modelos separados de subtitulado de imágenes, voz a texto y embeddings de texto).

Un embedding tampoco es anónimo en el momento de crearse. Para calcularlo, un servicio alojado tiene que recibir el documento entero. Cuando la pregunta es "¿quién ve esta invención antes de que se presente?", "un gran proveedor cloud, bajo contrato" es una respuesta. "Nadie, se ejecuta en nuestra máquina" es una mejor. Un modelo de 740M con Apache 2.0 puede correr en tu propio servidor, en la región que elegiste, con sentence-transformers, vLLM, llama.cpp u Ollama, que Google lista como compatibles.

El argumento del coste es más débil de lo que parece

Revisé el equivalente alojado de Google ese mismo día. Gemini Embedding 2 admite texto, imágenes, vídeo, audio y PDF. En el nivel de pago, una imagen cuesta 0,00012 $, o 0,00006 $ en batch. Cien mil páginas escaneadas salen en unos 12 $, o 6 $ en batch. Nadie debería cambiar de arquitectura para ahorrar 12 $.

Otras dos líneas de esa página de precios importan más. El nivel gratuito está marcado "Used to improve our products: Yes" (usado para mejorar nuestros productos: sí). El de pago está marcado "No". Mis proyectos personales suelen empezar en niveles gratuitos, y esa es la línea que hay que leer antes de indexar algo que te entregó un usuario.

El coste real es el que Simon Willison planteó en Hacker News el día del lanzamiento. Los embeddings se calculan por miles o por millones y se almacenan. Si un proveedor retira su modelo, pagas para volver a calcularlo todo. Su matiz merece conservarse: preferiría pagar a un proveedor para que lo aloje, sabiendo que los pesos abiertos están ahí si el proveedor deja de hacerlo. Los pesos abiertos no te obligan a autoalojar. Te dan una salida.

Lo que cede la versión para teléfono

Para iOS, la ficha LiteRT de Google publica tiempos reales. En la GPU de un iPhone 18 Pro, un embedding de texto tarda 11,6 ms y texto más una imagen 69,8 ms, con 85 MB y 196 MB de memoria. El paquete de texto y visión pesa 388 MB de descarga, y tu ficha de la App Store lo notará.

Ahora lee las notas al pie. Esos tiempos usan una entrada de texto de 128 tokens y una imagen de 70 tokens. Los paquetes LiteRT solo aceptan presupuestos de imagen de 70 o 140 tokens. El valor por defecto de la ficha del modelo es 280 y llega hasta 1120, y dice que un presupuesto mayor mejora la "fine-grained visual understanding" (comprensión visual fina). Una foto de vacaciones puede sobrevivir con 70 tokens. Una página densa de reivindicaciones con pequeños números de referencia, quizá no. Los benchmarks se ejecutaron con el checkpoint de precisión completa, y ninguna de las dos fichas da una puntuación de recuperación de documentos para la configuración del teléfono.

Así que mi reparto sería: documentos codificados en el servidor con el presupuesto por defecto o mayor, y el teléfono encargándose de las consultas y de la búsqueda ligera de medios. Ambos acaban en el mismo espacio vectorial, que es lo que hace posible el reparto.

Qué haría el lunes

Construir un pequeño conjunto de evaluación con tus propios documentos antes de elegir nada: cincuenta consultas reales y las páginas que deberían volver. Ejecutarlo a 768, 512 y 256 dimensiones, y con dos presupuestos de imagen. La guía para desarrolladores de Google recomienda 768 o 512 para recuperación de documentos visuales, y dice que 128 baja la recuperación de imágenes y voz a cerca del 75 % de la calidad completa.

Guardar la configuración con cada vector: modelo, dimensión, presupuesto de imagen, prefijo de tarea. Los vectores de ajustes distintos no son comparables, y un día necesitarás saber cuáles rehacer.

Ojo con las tres trampas que detalla la ficha del modelo. Nunca ejecutarlo en float16: sus activaciones superan el rango del formato, y obtienes NaN o embeddings degradados en silencio en lugar de un error. Renormalizar tras truncar, o la calidad del ranking se degrada "silently" (en silencio). Y usar los prefijos de tarea: SearchQuery para consultas, "title: {title} | text: {content}" para documentos.

La API en sí es pequeña. Este es el patrón de la guía para desarrolladores con sentence-transformers 6.1 o posterior, cargando solo texto y visión:

from sentence_transformers import SentenceTransformer

# Text, images, and video (440M parameters)
model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"audio_config": None},
)
page_emb = model.encode({"image": "scan_page_017.png"})
query_emb = model.encode("hinged lid with a magnetic latch", prompt_name="SearchQuery")
print(model.similarity(query_emb, page_emb))

Última regla, la que sobrevive a este modelo: conserva las páginas de origen, no solo los vectores. Son tu única protección real contra el próximo modelo, abierto o no.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos