Google: Gemini Embedding 2

Gemini Embedding 2 est le modèle de plongement multimodal de Google pour la représentation numérique du texte, des images, de la vidéo, de l’audio et des PDF. Il projette les différents types de médias dans un espace partagé afin qu’une application puisse comparer leur sens entre modalités. Le résultat est un vecteur de nombres, utile pour la recherche sémantique, la recherche documentaire, la recommandation, la classification ou le regroupement ; ce n’est ni une réponse écrite ni un fichier multimédia généré. Google documente une couverture sémantique dans plus de 100 langues.

Pour une base de connaissances, créez des vecteurs pour les passages sources, comparez-leur une requête utilisateur et retrouvez les matériaux pertinents. Un modèle textuel distinct peut ensuite composer une réponse à partir de ces sources. Pour une collection de médias, une description textuelle peut rechercher des images ou des vidéos liées ; une image peut aussi constituer la requête. Préservez le lien de chaque vecteur avec le contenu d’origine, y compris une référence de page ou d’extrait, afin que le résultat retrouvé puisse être examiné et montré dans son contexte initial.

La limite d’entrée globale est de 8192 tokens. Le guide du modèle stable autorise jusqu’à six images PNG ou JPEG, jusqu’à 180 secondes d’audio MP3 ou WAV et jusqu’à 120 secondes de vidéo MP4 ou MOV. Les codecs vidéo documentés sont H264, H265, AV1 et VP9. Le traitement vidéo utilise au maximum 32 images : les extraits de 32 secondes au plus sont échantillonnés à une image par seconde, tandis que les extraits plus longs sont échantillonnés uniformément en 32 images. La piste audio d’une vidéo n’est pas traitée dans cette entrée vidéo ; encodez son son séparément lorsqu’il importe pour la recherche.

L’entrée PDF accepte un fichier de six pages au maximum. Google recommande une page par PDF pour la meilleure qualité. Divisez une source plus volumineuse en pages ou en sections porteuses de sens et conservez leur relation avec le document d’origine. Choisissez un extrait représentant ce qui doit pouvoir être retrouvé, plutôt que de combiner des matériaux sans rapport uniquement parce qu’ils tiennent dans la limite. La limite partagée en tokens s’applique toujours à une requête mêlant plusieurs médias. Chaque page PDF consomme 258 tokens visuels, en plus des tokens de son texte extrait. Dans le processus documenté de Google, le contenu dépassant la limite partagée de 8192 tokens est tronqué sans erreur.

La dimension de sortie est flexible de 128 à 3072, avec 3072 par défaut et 768, 1536 et 3072 comme tailles recommandées. Le modèle utilise Matryoshka Representation Learning ; les préfixes du vecteur restent donc utiles à des dimensions plus petites. Son guide documente une normalisation automatique des vecteurs par défaut comme des vecteurs raccourcis. Choisissez une dimension cohérente pour les enregistrements et les requêtes comparés par votre application ; la taille demandée modifie la représentation numérique, plutôt que le contenu source lui-même.

Pour les tâches exclusivement textuelles, incluez l’objectif dans le texte plutôt que d’utiliser l’ancien champ task_type. Google distingue la recherche asymétrique de la comparaison symétrique. Une requête de recherche utilise « task: search result | query: {content} », tandis qu’un document source utilise « title: {title} | text: {content} » ; utilisez « title: none » s’il n’a pas de titre. Les tâches de question-réponse, de vérification de faits et de recherche de code possèdent leurs propres préfixes de requête. Pour la classification, le regroupement ou la similarité entre phrases, utilisez le même format de tâche de manière cohérente des deux côtés. Le guide déconseille généralement d’ajouter un préfixe de tâche à la partie textuelle d’une représentation multimodale combinée.

La structure d’entrée détermine si le résultat représente un objet combiné ou des éléments séparés. Plusieurs parties fournies ensemble créent un plongement agrégé ; des objets Content séparés créent des plongements distincts pour chaque entrée. Pour une publication contenant du texte et une image, une représentation combinée peut capturer leur relation. Pour des enregistrements recherchables indépendamment, gardez-les séparés. Ce choix influe sur la granularité de recherche : un vecteur pour une publication entière diffère d’un vecteur pour chaque passage ou image.

Le guide indique que les vecteurs de Gemini Embedding 001 et de Gemini Embedding 2 occupent des espaces incompatibles et ne peuvent pas être comparés directement. Une collection migrée depuis l’ancien modèle doit être réencodée dans le nouvel espace. Gardez un choix de modèle et des dimensions cohérents avec les vecteurs comparés et conservez le texte et les médias d’origine séparément de l’index numérique. La similarité d’un plongement est un signal de recherche, plutôt qu’une explication factuelle de la raison pour laquelle un document répond à la question de l’utilisateur.

Pour un catalogue concret, encodez une photographie produit avec sa description approuvée lorsque la paire doit être retrouvée comme un seul objet. Pour une collection documentaire, encodez des passages ciblés et comparez-les à une requête mise en forme selon son objectif, puis présentez les passages sources avec le résultat de recherche. Pour l’audio ou la vidéo, choisissez la séquence décrivant l’événement à rechercher et conservez sa plage temporelle d’origine. Le livrable utile est une représentation numérique liée à des éléments sources pour l’étape suivante de recherche ou d’analyse de l’application.