Google: Gemini Embedding 2

Gemini Embedding 2 es el modelo de embeddings multimodales de Google para representar numéricamente texto, imágenes, vídeo, audio y PDF. Asigna los distintos tipos de medios a un espacio compartido para que una aplicación pueda comparar su significado. El resultado es un vector de números, útil para búsqueda semántica, recuperación documental, recomendaciones, clasificación o agrupación; no es una respuesta escrita ni un archivo multimedia generado. Google documenta cobertura semántica en más de 100 idiomas.

Para una base de conocimiento, crea vectores de los pasajes de origen, compara una consulta del usuario con ellos y recupera el material pertinente. Un modelo textual separado puede redactar después una respuesta utilizando esas fuentes. Para una colección multimedia, una descripción textual puede buscar imágenes o vídeos relacionados; una imagen también puede aportar la consulta. Conserva la conexión de cada vector con el contenido original, incluida una referencia de página o clip, para que el resultado recuperado pueda examinarse y mostrarse en su contexto original.

El límite global de entrada es de 8192 tokens. La guía del modelo estable permite hasta seis imágenes PNG o JPEG, hasta 180 segundos de audio MP3 o WAV y hasta 120 segundos de vídeo MP4 o MOV. Los códecs de vídeo documentados son H264, H265, AV1 y VP9. El procesamiento de vídeo utiliza como máximo 32 fotogramas: los clips de hasta 32 segundos se muestrean a un fotograma por segundo, mientras que los clips más largos se muestrean uniformemente hasta obtener 32 fotogramas. La pista de audio de un vídeo no se procesa en esa entrada de vídeo; genera el embedding de su sonido por separado cuando importe para la recuperación.

La entrada PDF acepta un archivo con un máximo de seis páginas. Google recomienda una página por PDF para la mejor calidad. Divide una fuente más grande en páginas o secciones significativas y conserva su relación con el documento original. Elige un extracto que represente lo que debe poder recuperarse, en lugar de combinar materiales sin relación solo porque quepan en el límite. El límite compartido de tokens sigue aplicándose a una solicitud de medios mixtos. Cada página PDF consume 258 tokens visuales además de los tokens de su texto extraído. En el flujo documentado de Google, el contenido que supera el límite compartido de 8192 tokens se trunca sin error.

La dimensionalidad de salida es flexible entre 128 y 3072, con 3072 como valor predeterminado y 768, 1536 y 3072 como tamaños recomendados. El modelo utiliza Matryoshka Representation Learning, por lo que los prefijos del vector siguen siendo útiles con dimensiones menores. Su guía documenta normalización automática tanto para los vectores predeterminados como para los acortados. Elige una dimensión coherente para los registros y consultas que compare tu aplicación; el tamaño solicitado cambia la representación numérica, no el propio contenido de origen.

Para tareas exclusivamente textuales, incluye el propósito en el texto, en lugar de utilizar el campo antiguo task_type. Google distingue la recuperación asimétrica de la comparación simétrica. Una consulta de búsqueda utiliza «task: search result | query: {content}», mientras que un documento de origen utiliza «title: {title} | text: {content}»; utiliza «title: none» si no tiene título. Las tareas de pregunta-respuesta, verificación de hechos y recuperación de código tienen sus propios prefijos de consulta. Para clasificación, agrupación o similaridad entre frases, utiliza el mismo formato de tarea de forma coherente en ambos lados. La guía desaconseja en general añadir un prefijo de tarea a la parte textual de una representación multimodal combinada.

La estructura de entrada determina si el resultado representa un objeto combinado o elementos separados. Varias partes proporcionadas juntas crean un embedding agregado; objetos Content separados crean embeddings separados para cada entrada. Para una publicación con texto e imagen, una representación combinada puede captar su relación. Para registros que deban buscarse de forma independiente, mantenlos separados. Esta elección afecta a la granularidad de recuperación: un vector para una publicación entera es distinto de uno para cada pasaje o imagen.

La guía afirma que los vectores de Gemini Embedding 001 y Gemini Embedding 2 ocupan espacios incompatibles y no pueden compararse directamente. Una colección migrada del modelo anterior necesita nuevos embeddings para el espacio nuevo. Mantén la elección de modelo y las dimensiones coherentes con los vectores que se comparan y conserva el texto y los medios originales por separado del índice numérico. La similaridad de un embedding es una señal de recuperación, en lugar de una explicación factual de por qué un documento responde a la pregunta del usuario.

Para un catálogo práctico, genera un embedding combinado de una fotografía de producto y su descripción aprobada cuando el par deba recuperarse como un objeto. Para una colección documental, genera embeddings de pasajes específicos y compáralos con una consulta formateada según su propósito, y después presenta los pasajes de origen junto al resultado de búsqueda. Para audio o vídeo, elige el episodio que describe el evento que se quiere buscar y conserva su intervalo temporal original. El entregable útil es una representación numérica vinculada a evidencia de origen para el siguiente paso de búsqueda o análisis de la aplicación.