EmbeddingGemma 2 amplía la búsqueda semántica a imágenes, audio y vídeo

Un modelo multimodal para encontrar contenido

Google presentó EmbeddingGemma 2 como una ampliación multimodal del modelo de embeddings textual anterior. La nueva versión representa texto —incluido código—, imágenes, audio y vídeo en un espacio vectorial compartido. Su cometido es ayudar a recuperar contenido relacionado con una consulta; no es un modelo conversacional diseñado para redactar respuestas ni generar imágenes, audio o vídeo.

El modelo tiene 740 millones de parámetros y combina un componente de texto con codificadores de visión y audio que pueden cargarse selectivamente. Google indica que el componente de texto suma 270 millones de parámetros, el codificador de visión 170 millones y el de audio 300 millones. La suma y la configuración activa importan para estimar recursos: una implementación de texto solo no carga necesariamente todos los componentes del modelo multimodal.

EmbeddingGemma 2 produce vectores de 768 dimensiones y admite reducirlos a 512, 256 o 128 dimensiones mediante aprendizaje de representación Matryoshka. Los vectores más cortos pueden reducir el almacenamiento y acelerar ciertas búsquedas, pero la calidad puede variar con la dimensión y la tarea. Tras truncar un vector hay que normalizarlo para compararlo por coseno; además, las consultas y los documentos del índice deben usar la misma dimensión.

Google publica el modelo bajo la licencia Apache 2.0. Esa licencia no elimina los costes de ejecución ni determina por sí sola las obligaciones relacionadas con los datos de una aplicación. La ficha técnica describe un contexto compartido de 8.192 tokens para las modalidades; el límite efectivo depende de cómo se mezclen y preparen las entradas.

Cómo funciona la búsqueda multimodal

Un embedding es una representación numérica de un elemento, como una frase, una imagen o un fragmento de audio. El sistema compara los vectores para ordenar candidatos según su similitud. En la búsqueda de documentos, por ejemplo, una consulta sobre «calzado para la lluvia» podría recuperar una ficha de botas impermeables aunque no contenga exactamente la palabra «lluvia». Ese resultado es una coincidencia candidata, no una prueba de que el modelo haya entendido el uso previsto o de que la ficha sea correcta.

EmbeddingGemma 2 permite buscar entre modalidades distintas cuando la aplicación prepara los datos para esa tarea: por ejemplo, relacionar una consulta textual con imágenes de un catálogo. El modelo también admite entradas que combinan texto y medios. Para representar un producto, una aplicación podría incluir su descripción y sus imágenes; para una consulta de vídeo, podría aportar el texto de búsqueda junto con los fotogramas procesados según la configuración elegida.

Los prefijos de tarea ayudan a orientar las representaciones de texto. En una búsqueda asimétrica, la consulta y los documentos desempeñan funciones distintas: se prepara la consulta como pregunta de búsqueda y los elementos del corpus como documentos. En tareas simétricas, como agrupar textos o medir similitud entre frases, se usa el mismo tipo de instrucción para los elementos comparados. Los prefijos se aplican al texto, no a imágenes, audio o vídeo.

La configuración de entrada también influye en qué contenido cabe en el contexto. La ficha técnica establece un presupuesto común para las modalidades, por lo que mezclar texto, imágenes, audio y vídeo reduce la cantidad disponible para cada una. En vídeo, el muestreo de fotogramas y su frecuencia afectan a la información representada; en audio, el formato de entrada indicado es mono a 16 kHz. Estos parámetros describen el procesamiento, no garantizan que se recuperen todos los detalles relevantes.

Tamaño, contexto y configuración local

Los 740 millones de parámetros corresponden al conjunto multimodal. Según la ficha técnica, la configuración de texto solo utiliza 270 millones de parámetros; texto e imagen, 440 millones; texto y audio, 570 millones; y el modelo completo, 740 millones. Estas cifras describen las configuraciones de carga publicadas, no el consumo total de memoria de una aplicación en funcionamiento.

El tamaño de los pesos y el uso de memoria dependen de factores como la precisión numérica, la biblioteca, el hardware, la longitud de entrada y el tamaño del lote. Google recomienda usar bfloat16 cuando el hardware lo admite y float32 en otros casos; advierte que float16 puede producir valores no válidos o embeddings degradados. Por eso, una cifra de parámetros no basta para estimar el espacio de memoria ni la latencia de un despliegue concreto.

La reducción Matryoshka permite elegir entre vectores de 768, 512, 256 y 128 dimensiones. En los resultados publicados por Google, al pasar de 768 a 256 dimensiones se reduce el tamaño del vector a un tercio y se observan cambios en varias puntuaciones de benchmark. A 128 dimensiones, algunas puntuaciones multimodales bajan más. Estos resultados pertenecen a las pruebas y métricas indicadas por el proveedor; no establecen qué dimensión será mejor para un corpus o una aplicación particular.

Para usar los vectores truncados con similitud coseno, hay que normalizarlos después del truncamiento. El vector de una consulta y los de los elementos indexados deben tener la misma dimensión. Cambiar la dimensión implica volver a generar o adaptar el índice de manera coherente; comparar directamente un vector de 768 dimensiones con uno de 128 no es una operación válida.

Cómo evaluar si la recuperación funciona

Una comparación útil empieza por una tarea concreta y un criterio de relevancia definido antes de ejecutar la prueba. Un benchmark puede medir recuperación en un conjunto de datos específico, pero no garantiza el mismo resultado en otro idioma, dominio o tipo de contenido. La ficha técnica de Google publica puntuaciones para distintas pruebas de texto, código, imagen, documentos visuales, vídeo y audio; cada puntuación corresponde a una métrica y un conjunto de evaluación determinados.

Para evaluar una búsqueda texto-imagen, prepara consultas reales y un conjunto de imágenes con etiquetas de relevancia. Para buscar audio o vídeo, define qué significa un resultado pertinente: una grabación completa, un segmento o un fotograma. Si el sistema mezcla modalidades, especifica cómo se preparan y ponderan las entradas antes de interpretar las métricas.

Compara el modelo con una alternativa usando las mismas consultas, corpus, instrucciones, dimensión vectorial y reglas de ranking. Mide por separado la calidad de recuperación, la latencia y los recursos utilizados. Registra la precisión numérica, el hardware, la longitud de las entradas y la configuración de modalidades para que el resultado pueda interpretarse y repetirse.

La evaluación debe incluir los idiomas y las condiciones de uso previstas. La documentación del modelo señala que el rendimiento puede variar entre idiomas y que puede verse afectado por ambigüedades y matices del lenguaje. Una puntuación agregada no sustituye a la comprobación de las consultas que realmente recibirá la aplicación.

Qué muestran los resultados y cuáles son sus límites

Google informa de resultados de evaluación en varios benchmarks y compara algunas tareas de texto con EmbeddingGemma, el modelo anterior. En MTEB multilingual, la puntuación publicada para EmbeddingGemma 2 es 61,36 frente a 61,15 para el modelo anterior; en la prueba de código MTEB, la puntuación publicada es 78,68 frente a 68,76. Esas diferencias describen los resultados reportados para las pruebas indicadas, no una mejora garantizada en cualquier sistema de búsqueda.

La ficha también presenta resultados para imagen, documentos visuales, vídeo y audio. Esos valores proceden de benchmarks concretos y no prueban que el modelo comprenda de forma general una escena, una conversación o un evento. Una búsqueda que sitúa un vídeo relevante entre los primeros resultados no demuestra que el sistema identifique todos sus hechos, responda con exactitud a preguntas abiertas o explique por qué el vídeo es pertinente.

El modelo genera representaciones, no una respuesta conversacional. Una aplicación puede usar los resultados recuperados como contexto para otro componente generativo, pero la calidad final dependerá también de ese componente, del corpus y de las reglas de la aplicación. Conviene evaluar por separado la recuperación y la respuesta que se construya después.

Google indica que EmbeddingGemma 2 se distribuye bajo Apache 2.0 y ofrece pesos abiertos. La ficha técnica señala que los modelos de embeddings no reciben ajuste de seguridad posterior ni moderación de salida como los modelos generativos; las salvaguardas de la aplicación, como filtros de recuperación y pruebas de equidad, quedan a cargo de quienes la despliegan. La licencia abierta no convierte una búsqueda en verificación factual ni elimina la necesidad de revisar sesgos, privacidad y usos previstos.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.