Meilleurs modèles d'embedding multimodaux en 2026 : texte, image, vidéo et audio

L'embedding multimodal est la couche qui permet à une seule requête d'atteindre tous les types de contenus que vous possédez. Si vous vous trompez dans le choix du modèle, la facture le rappelle vite : les vecteurs d'un modèle n'ont aucun sens pour un autre, donc changer de modèle implique de réencoder l'intégralité de votre corpus.

La catégorie a changé de forme au cours des douze derniers mois. Jusqu'à récemment, « embedding multimodal » signifiait en pratique CLIP : une tour texte et une tour image, alignées au niveau de la couche de sortie, sans rien pour la vidéo ni l'audio. En 2026, trois architectures distinctes se disputent le terrain, la vidéo et l'audio sont des entrées de premier plan plutôt qu'une ligne sur une feuille de route, et les modèles les plus performants réunissent cinq modalités dans un seul espace vectoriel.

Nous avons comparé 16 modèles, APIs managées et poids ouverts, sur la qualité de la recherche cross-modale, la couverture des modalités, le coût à grande échelle, la latence et les contraintes de déploiement. Vous trouverez ci-dessous le tableau comparatif complet, la distinction d'architecture qui détermine la plupart des présélections, ce que les benchmarks mesurent (et ce qu'ils ne mesurent pas), ainsi qu'une méthode en cinq étapes pour réduire votre choix à deux ou trois candidats que vous pourrez tester sur vos propres données.

Les modèles d'embedding multimodaux comparés en un coup d'œil

Qu'est-ce qu'un modèle d'embedding multimodal ?

Un modèle d'embedding multimodal convertit différents types de contenus (un paragraphe, une photographie, un extrait vidéo, un mémo vocal) en vecteurs qui vivent dans le même espace. La similarité entre deux d'entre eux devient alors une simple question de géométrie, en général une similarité cosinus.

C'est cette seule propriété qui rend possible la recherche cross-modale. Vous tapez une phrase, vous récupérez une vidéo. Vous téléversez une capture d'écran, vous récupérez le paragraphe qui la décrit. Vous lancez un extrait audio, vous retrouvez le moment dont il provient. Sans espace partagé, il vous faudrait un modèle distinct par modalité, sans aucun moyen pertinent de comparer leurs sorties, car les vecteurs de deux modèles différents n'ont aucun lien entre eux, même lorsqu'ils ont une dimensionnalité identique.

La conséquence pratique est que le modèle détermine le plafond de qualité de tout ce qui est construit au-dessus, et que le coût du changement correspond à une réindexation complète.

Une remarque sur le périmètre : si votre corpus se compose d'images et uniquement d'images, les compromis sont différents. Les modèles purement visuels surpassent souvent les modèles cross-modaux sur la correspondance image-image pure. Cette comparaison se trouve dans notre guide des modèles d'embedding d'images. Le présent article porte sur la couverture de plusieurs modalités.

Cross-modal, any-to-any et omni : la distinction qui détermine votre présélection

Presque toutes les comparaisons traitent ces modèles comme une seule catégorie. Ils n'en forment pas une, et la différence d'architecture limite ce que vous pouvez construire.

Dual-encoder cross-modal (CLIP, SigLIP 2, JinaCLIP v2, Nomic Embed Vision)

Deux encodeurs séparés : un pour le texte, un pour les images, entraînés de façon contrastive afin que leurs sorties s'alignent. C'est peu coûteux, rapide et extrêmement bien documenté. La limite est structurelle : ces modèles gèrent le texte ↔ image et rien d'autre. Une entrée qui mélange texte et image dans un même document doit être découpée, encodée séparément, puis recombinée à la main.

Any-to-any avec backbone VLM (Jina v4, GME, Qwen3-VL-Embedding, Voyage Multimodal 3.5)

Un modèle vision-langage reconverti en encodeur. Du texte, une image ou un mélange entrelacé de texte et d'images passent tous par le même chemin et sont regroupés en un seul vecteur. C'est ce qui vous permet d'encoder une diapositive, une facture ou une capture d'écran telle qu'elle apparaît, en préservant la mise en page et les figures plutôt qu'en les passant d'abord par un OCR pour en faire une chaîne de texte.

L'argument de Voyage en faveur de cette conception mérite d'être compris : des tours séparées créent un écart entre modalités (modality gap), où une requête textuelle attribue systématiquement un meilleur score aux documents textuels qu'à des images tout aussi pertinentes, simplement parce qu'ils proviennent du même encodeur. Un encodeur unique supprime cet écart.

Omni (Gemini Embedding 2, Nova 2, Marengo 3.0, jina-v5-omni, ImageBind)

Quatre modalités ou plus dans un même espace, avec l'audio et la vidéo comme entrées natives plutôt que comme images échantillonnées. C'est la nouveauté de 2026. Cela compte lorsque votre corpus est véritablement multimédia : un service support avec des articles, des captures d'écran et des enregistrements d'appels, ou un diffuseur avec des rushes, des transcriptions et des photos.

Règle générale : texte et images uniquement, à grande échelle, avec un budget serré → dual encoder. Des documents où la mise en page porte du sens → any-to-any. De l'audio ou de la vidéo dans le corpus → omni. La plupart des équipes surinvestissent sur ce point ; la plupart des autres découvrent le manque au bout de dix-huit mois.

Comment nous avons évalué les meilleurs modèles d'embedding multimodaux en 2026

Cinq critères pondérés, appliqués de manière cohérente :

Modèle	Fournisseur	Modalités	Dimensions	Contexte	Auto-hébergement	Tarif	Idéal pour
Gemini Embedding 2	Google	Texte, image, vidéo, audio, PDF	3 072 (MRL → 128)	8 192 tokens	Non	~0,20 $ / 1M tokens de texte	L'éventail de modalités natives le plus large
Voyage Multimodal 3.5	Voyage AI (MongoDB)	Texte, image, vidéo	2 048 / 1 024 / 512 / 256	32 000 tokens	Non	~0,60 $ / 1 Md de pixels + tarif au token	Documents entremêlés et vidéo
Cohere Embed v4	Cohere	Texte, image, documents	Jusqu'à 1 536 (MRL)	128 K tokens	Licence requise	~0,47 $ / 1M tokens d'image	Documents multilingues désordonnés
Nova 2 Multimodal Embeddings	Amazon	Texte, image, vidéo, audio, documents	3 072 / 1 024 / 384 / 256	~8 192 tokens	Non	~0,14 $ / 1M tokens	Stacks nativement AWS
Marengo 3.0	TwelveLabs	Vidéo, audio, image, texte	512	Vidéo jusqu'à ~4 heures	Non	À l'usage via Bedrock	Archives vidéo et médias
multimodalembedding@001	Google Vertex AI	Texte, image, vidéo	1 408	Court	Non	~0,80 $ / 1M tokens	Pipelines GCP existants
Titan Multimodal G1	Amazon	Texte, image	1 024 / 384 / 256	~128 tokens de texte	Non

Critère	Pondération	Ce que nous avons examiné
Qualité de la recherche cross-modale	30 %	Rappel texte→image, texte→vidéo et any-to-any sur les benchmarks publics, ainsi que sur des documents visuellement denses
Couverture des modalités	20 %	Quelles entrées sont natives et lesquelles sont approximées par échantillonnage d'images ou OCR
Coût à grande échelle	20 %	Prix normalisé pour des corpus multimédias réalistes, y compris l'impact du nombre de dimensions sur le stockage
Latence et empreinte	15 %	Vitesse d'inférence via une API en production, et matériel nécessaire à l'auto-hébergement
Déploiement et licence	15 %	API uniquement, poids ouverts, licence commerciale requise, disponibilité régionale

Les meilleures APIs d'embedding multimodal en 2026

1. Google Gemini Embedding 2

Ce que c'est. Le premier modèle d'embedding de Google DeepMind construit nativement sur l'architecture Gemini, en preview publique depuis mars 2026 via l'API Gemini et Vertex AI. Il projette texte, images, vidéo, audio et PDF dans un unique espace à 3 072 dimensions.

Ce qui le distingue. Aucun autre modèle n'ingère actuellement autant de modalités nativement depuis un seul endpoint. L'alternative consiste à assembler CLIP pour les images, un modèle de reconnaissance vocale pour l'audio et un modèle d'embedding textuel, puis à découvrir que leurs espaces vectoriels ne s'alignent pas. Les limites d'entrée publiées par Google sont de 8 192 tokens de texte, jusqu'à six images par requête, environ deux minutes de vidéo, de l'audio natif et des PDF jusqu'à six pages, sans conversion de format.

Points forts

• Véritablement natif sur cinq modalités, et non des approximations par échantillonnage d'images
• Troncature Matryoshka de 128 à 3 072 dimensions ; Google recommande 768 comme meilleur rapport qualité/octet
• Des instructions de tâche personnalisées permettent d'optimiser les embeddings pour un objectif de recherche précis
• De solides résultats publiés en recherche vidéo face à Nova et Voyage

Limites

• En preview publique, pas en disponibilité générale : vérifiez le statut et le SLA avant tout engagement en production
• L'espace vectoriel est incompatible avec gemini-embedding-001 ; migrer implique de réencoder
• La tarification de l'audio et de la vidéo est nettement plus élevée que celle du texte, ces entrées se tokenisant fortement
• Le support multimodal a été déployé de façon inégale entre l'API Gemini et Vertex AI

Choisissez ce modèle si votre corpus couvre plus de deux modalités et que vous voulez un seul endpoint plutôt qu'un chantier d'alignement. Passez votre tour s'il vous faut dès aujourd'hui des garanties de stabilité en disponibilité générale, ou si votre charge de travail est uniquement textuelle : des modèles moins chers l'emportent là-dessus.

Tarifs : environ 0,20 $ par million de tokens de texte ; tarifs distincts pour l'image, l'audio et la vidéo.

2. Voyage Multimodal 3.5

Ce que c'est. Sorti en janvier 2026, le modèle multimodal de nouvelle génération de Voyage, désormais rattaché à MongoDB, conçu pour la recherche sur du texte, des images et de la vidéo, y compris des contenus qui entrelacent les trois.

Ce qui le distingue. Un encodeur transformer unique pour toutes les modalités, au lieu de tours séparées. La raison invoquée par Voyage est l'écart entre modalités : avec des encodeurs doubles, une requête textuelle dérive vers des résultats textuels même lorsqu'une image constitue la meilleure réponse. C'est aussi l'un des premiers modèles d'embedding vidéo en production à prendre en charge les dimensions Matryoshka, ce qui compte énormément quand votre index est constitué d'images de vidéo.

Points forts

• Gère nativement les entrées entrelacées : captures de PDF, diapositives, tableaux, figures, séquences d'images vidéo
• Matryoshka en 2 048 / 1 024 / 512 / 256, plus quantification float32, int8, uint8 et binaire
• 32 000 tokens de contexte, généreux pour un modèle d'embedding
• Un palier gratuit important avant tout début de facturation

Limites

• Uniquement en API, sans poids auto-hébergeables, ce qui l'exclut des déploiements isolés du réseau ou soumis à des exigences strictes de résidence des données
• La tarification à la quantité de pixels pour les entrées visuelles demande un travail de modélisation pour être anticipée
• Pas de modalité audio

Choisissez ce modèle si vos documents sont visuellement riches et que votre exigence de qualité de recherche est élevée. Passez votre tour si la résidence des données ou l'auto-hébergement est une contrainte absolue.

Tarifs : environ 0,60 $ par milliard de pixels pour les entrées visuelles, plus une tarification au token pour le texte ; les 200 premiers millions de tokens de texte et les 150 premiers milliards de pixels sont gratuits par compte.

3. Cohere Embed v4

Ce que c'est. L'option managée la plus solide pour les corpus documentaires d'entreprise : texte, images et contenus mixtes traités par un seul modèle avec une fenêtre de contexte de 128 000 tokens.

Ce qui le distingue. Sa robustesse sur du matériel professionnel réel. Tableaux, graphiques, diagrammes, code et notes manuscrites sont traités sans pipeline de prétraitement, et le modèle tolère les fautes d'orthographe et les mises en forme incohérentes. La couverture s'étend à plus de 100 langues, avec un ajustement pour la finance, la santé et l'industrie.

Points forts

• 128 K de contexte : les longs documents ne nécessitent souvent aucun découpage
• Troncature Matryoshka, plus quantification en octets et binaire pour des compromis de stockage économiques
• Disponible en direct, sur Amazon Bedrock, sur Azure AI Foundry et en déploiement privé
• Une qualité multilingue réellement solide, et non une considération secondaire

Limites

• Ni vidéo ni audio
• Les poids auto-hébergeables exigent une licence commerciale distincte ; ils ne sont pas librement redistribuables
• Un coût au token plus élevé que les alternatives ouvertes

Choisissez ce modèle si votre corpus se compose de documents et d'images, multilingue ou réglementé, et que vous préférez acheter la qualité plutôt que la régler vous-même. Passez votre tour s'il vous faut de la vidéo ou de l'audio dans le même espace.

4. Amazon Nova 2 Multimodal Embeddings

Ce que c'est. Le modèle d'embedding unifié d'AWS sur Bedrock, couvrant texte, documents, images, vidéo et audio dans un seul modèle.

Ce qui le distingue. Quatre dimensions de sortie Matryoshka : 3 072, 1 024, 384 et 256, issues d'un seul embedding, si bien qu'un même modèle sert quatre points d'équilibre coût-précision différents sans réencodage. Le contexte atteint environ 8 192 tokens sur près de 200 langues, avec des APIs synchrones et asynchrones et une segmentation intégrée pour les longs textes, vidéos ou fichiers audio.

Points forts

• Cinq modalités sous une seule API nativement intégrée à Bedrock, avec IAM, quotas et intégration S3
• Une flexibilité de dimensions qui s'articule proprement avec une cascade de recherche en deux étapes
• Une tarification au token compétitive
• Un chemin asynchrone pour les vidéos volumineuses, synchrone pour les petites entrées

Limites

• Les plafonds de segments impliquent votre propre stratégie de découpage et d'agrégation pour les médias longs
• La disponibilité régionale est plus restreinte que celle des modèles textuels établis : vérifiez-la avant de concevoir votre architecture autour
• Poids fermés, réservé à AWS
• Les résultats de benchmarks annoncés par l'éditeur sont contestés par les chiffres publiés par ses concurrents

Choisissez ce modèle si vous êtes déjà sur AWS et souhaitez un seul modèle managé pour toutes les modalités que vous détenez. Passez votre tour si la compréhension de vidéos longues est le cœur du travail, ou s'il vous faut des poids ouverts.

5. TwelveLabs Marengo 3.0

Ce que c'est. Un modèle d'embedding nativement vidéo, en disponibilité générale depuis décembre 2025 sur l'API TwelveLabs comme sur Amazon Bedrock. Un espace unique à 512 dimensions couvre vidéo, audio, images et texte, avec une prise en charge des vidéos jusqu'à quatre heures.

Ce qui le distingue. Une compréhension temporelle plutôt qu'un moyennage d'images. Dans cette catégorie, le « support vidéo » consiste le plus souvent à échantillonner des images et à agréger des embeddings d'images, ce qui fait disparaître le mouvement. Marengo encode la structure temporelle, et le fait en 512 dimensions, suffisamment peu pour maintenir toute une archive média interrogeable.

Points forts

• Un véritable encodage nativement vidéo, pas une approximation par images
• Un embedding compact de 512 dimensions : une fraction du coût de stockage des alternatives à 3 072 dimensions
• Recherche audio native dans le même espace : parole, musique, effets sonores
• Disponible sur Bedrock avec inférence régionale aux États-Unis et dans l'UE

Limites

• Les chiffres de benchmarks mis en avant proviennent de l'éditeur ; la vérification indépendante reste mince
• Poids fermés, uniquement en API, et l'invocation via Bedrock est asynchrone plutôt qu'un appel d'embedding synchrone
• La tarification à la minute de vidéo s'accumule vite sur de grandes archives

Choisissez ce modèle si la vidéo est votre modalité principale et que le mouvement compte. Passez votre tour si vos contenus sont majoritairement du texte et des documents, ou s'il vous faut un embedding synchrone à faible latence.

6. Google Vertex AI multimodalembedding@001

Ce que c'est. Le modèle Vertex historique, qui produit des vecteurs à 1 408 dimensions à partir d'images, de texte ou de vidéo.

Solide, bien documenté, et le chemin le plus court entre une image et un vecteur indexé si votre stack vit déjà sur Google Cloud, aux côtés de Vertex AI Vector Search, sans friction d'egress ni d'authentification. Il est toutefois en voie de remplacement : pas de troncature Matryoshka, une couverture multilingue plus restreinte et un éventail de modalités plus étroit que Gemini Embedding 2.

Choisissez ce modèle si vous êtes sur GCP avec un pipeline existant et aucune envie de réencoder. Passez votre tour si vous démarrez de zéro : évaluez d'abord Gemini Embedding 2.

7. Amazon Titan Multimodal Embeddings G1

Ce que c'est. Le modèle multimodal de première génération d'Amazon, qui convertit des images et de courts textes en anglais dans un espace partagé pour la recherche par texte, par image ou par combinaison des deux.

La contrainte à anticiper est le plafond de texte, environ 128 tokens. C'est suffisant pour des titres de produits et de courtes légendes, et insuffisant pour tout ce qui ressemble à un document. La sortie prend en charge 1 024, 384 ou 256 dimensions. Anglais uniquement.

Choisissez ce modèle si vous êtes sur AWS avec un catalogue de contenus courts et une intégration Titan existante. Passez votre tour si votre partie textuelle dépasse la longueur d'une légende, ou s'il vous faut d'autres langues que l'anglais : Nova 2 le remplace sur ces deux points.

8. Azure AI Vision multimodal embeddings

Ce que c'est. Vectorise images et requêtes textuelles dans un espace partagé à 1 024 dimensions, ce qui permet de fouiller un ensemble d'images avec du texte, sans tags ni métadonnées.

Compétent et sans surprise. Son intérêt réside dans l'intégration nativement Azure, en particulier avec Azure AI Search, plutôt que dans un leadership sur les benchmarks.

Choisissez ce modèle si vous êtes engagé sur Azure et voulez un support natif. Passez votre tour si la qualité de recherche est le critère décisif.

Les meilleurs modèles d'embedding multimodaux open source en 2026

L'auto-hébergement supprime le coût à la requête et résout la question de la résidence des données, au prix de l'exploitation d'une infrastructure GPU. Le point de bascule est plus élevé que la plupart des équipes ne l'imaginent : en dessous d'environ 200 à 300 millions de tokens par mois, une API est généralement moins chère dès lors que le temps d'ingénierie et la capacité GPU inutilisée sont comptés honnêtement. Au-dessus, le calcul s'inverse nettement.

9. jina-embeddings-v5-omni

9. jina-embeddings-v5-omni

Annoncée en mai 2026, c'est la famille omni en poids ouverts la plus performante disponible : texte, images, vidéo et audio dans un même espace partagé, en deux tailles (small, environ 1,6 milliard de paramètres, et nano, environ 0,9 milliard).

Le choix de conception qui la rend intéressante est la compatibilité. Les modèles omni partagent un espace vectoriel avec les modèles jina-embeddings-v5-text uniquement textuels : un index textuel existant peut donc rester en place pendant que vous commencez à y écrire des vecteurs d'images, d'audio et de vidéo. La recherche multimodale devient une amélioration plutôt qu'une migration. La troncature Matryoshka descend jusqu'à 32 dimensions, la vidéo est traitée sous forme d'images échantillonnées uniformément, et la variante nano tourne sur du matériel grand public sans GPU.

Le hic : les poids sont distribués sous licence CC BY-NC 4.0. Un usage commercial requiert un accord distinct. Prévoyez cette discussion avant de construire dessus.

10. Jina Embeddings v4

Construit sur un backbone Qwen2.5-VL, il traite texte et images par un chemin partagé avec des adaptateurs LoRA spécifiques à chaque tâche : recherche, correspondance de texte et code. Deux modes de sortie comptent en pratique : vecteur unique à 2 048 dimensions, tronquable à 128, et multi-vecteur à 128 dimensions par token pour une recherche en late interaction, nettement plus performante sur les documents visuellement complexes. Il accepte directement texte, images et PDF, et est disponible à la fois en API avec un palier gratuit et en poids ouverts.

Choisissez ce modèle si vous voulez la commodité d'une API maintenant et la possibilité d'auto-héberger plus tard.

11. Qwen3-VL-Embedding et GME

La gamme d'encodeurs dérivés de VLM signée Alibaba. GME transforme Qwen2-VL-2B en un encodeur any-to-any à vecteur unique : une diapositive, une facture scannée ou une page chargée de graphiques est encodée comme une image, ce qui capture la mise en page sans étape d'OCR préalable. Dans au moins un benchmark indépendant de 2026, un modèle Qwen3-VL de 2 milliards de paramètres a dépassé plusieurs APIs commerciales en recherche cross-modale, utile rappel que poids ouverts ne signifie plus seconde catégorie.

Choisissez ce modèle si vous pouvez auto-héberger un VLM de 2 milliards de paramètres et que votre corpus est visuellement riche. Passez votre tour s'il vous faut de l'audio ou de la vidéo, ou la plus faible latence possible par élément.

12. ColPali / ColQwen2

Une architecture différente pour un travail précis. Au lieu de la chaîne OCR → découpage → embedding, ColPali encode directement les images de pages via une recherche multi-vecteur en late interaction, en préservant la mise en page, les tableaux et les figures que l'OCR détruit. Si vous construisez du RAG sur des PDF, des présentations ou des rapports scannés, cette classe de modèles est la réponse actuelle : voyez la section sur la recherche multi-vecteur ci-dessous pour les compromis.

13. SigLIP 2

La référence par défaut en poids ouverts pour la similarité texte-image. La fonction de perte sigmoïde produit des scores par paire indépendants et bien calibrés plutôt que des classements softmax, et la recette SigLIP 2 ajoute une couverture multilingue sur 109 langues, ainsi que de l'auto-distillation et de la prédiction masquée, améliorant la localisation et les caractéristiques denses par rapport au SigLIP original comme à CLIP. Poids ouverts sur Hugging Face, de ViT-B jusqu'à So400m, avec une variante à 1 milliard de paramètres.

Choisissez ce modèle si vous auto-hébergez un modèle cross-modal et que texte + image suffit.

14. JinaCLIP v2

Il ajoute deux choses qui manquent à CLIP : un véritable support multilingue et des embeddings Matryoshka réductibles à 64 dimensions, pour des économies de stockage spectaculaires. Son contexte de 8 192 tokens est le plus long de tous les modèles de type CLIP, ce qui le rend viable pour encoder des documents entiers aux côtés d'images sans découpage agressif.

Choisissez-le plutôt que SigLIP 2 si votre corpus contient une part importante de texte non anglophone.

15. Nomic Embed Vision

Des modèles texte et vision sous licence Apache 2.0, d'une qualité compétitive face aux APIs propriétaires, avec en plus une option hébergée dotée d'un palier gratuit. Le choix évident quand vous voulez une licence ouverte pour des raisons de résidence des données ou de coût, sans avoir à monter une infrastructure dès le premier jour. Centré sur l'anglais ; ni vidéo ni audio.

16. ImageBind

Le modèle à six modalités de Meta : vision, texte, audio, profondeur, thermique et IMU dans un même espace. D'une capacité unique, et honnêtement positionné comme un outil de recherche et de prototypage plutôt qu'un modèle de recherche en production ; sa précision par modalité reste derrière celle des spécialistes. Tournez-vous vers lui quand vous avez besoin d'une combinaison de modalités que rien d'autre ne prend en charge, comme la fusion de capteurs en robotique.

Modèles vidéo natifs ouverts à surveiller

Pas des entrées à part entière, mais cités parce qu'ils changent le champ du possible : V-JEPA 2, VideoPrism et InternVideo2 encodent des extraits avec leur structure temporelle plutôt qu'en moyennant des images. Si vous auto-hébergez pour de la vidéo et que les poids fermés de Marengo sont un point bloquant, c'est là qu'il faut regarder.

Vecteur unique ou multi-vecteur : quand la late interaction l'emporte

Un modèle à vecteur unique compresse une image, une page ou un extrait entier en un seul vecteur. La recherche se réduit à un produit scalaire : peu coûteux, et parfaitement suffisant pour les requêtes du type « ce concept est-il présent ? ».

Un modèle multi-vecteur en late interaction comme ColPali ou ColQwen conserve un vecteur par patch ou par token et note une requête en additionnant, pour chaque token de la requête, sa meilleure correspondance parmi tous les vecteurs du document, une opération généralement appelée MaxSim. Rien de spatial ni de temporel n'est effacé par un moyennage, et c'est pourquoi le multi-vecteur l'emporte nettement sur les documents, les captures d'écran, le texte dense dans l'image et la recherche d'un instant précis.

Le prix à payer se situe dans le stockage et la complexité des requêtes. Une page qui tenait dans un vecteur en devient des centaines, et toutes les bases de données vectorielles ne gèrent pas bien la late interaction.

La règle pratique : vecteur unique pour un rappel sémantique large ; multi-vecteur lorsque le système doit désigner la région, la page ou le moment exact qui répond à la question. Beaucoup de stacks en production font tourner les deux : une première passe économique en vecteur unique, puis un reclassement multi-vecteur sur les meilleurs candidats.

Ce que les benchmarks mesurent réellement

Trois familles de benchmarks comptent ici, et elles ne mesurent pas la même chose.

MMEB (Massive Multimodal Embedding Benchmark), y compris MMEB-v2 avec ses tâches vidéo, est le classement à consulter pour du travail cross-modal. Sa faiblesse connue concerne les négatifs difficiles : la suite ne met pas fortement à l'épreuve les distinctions subtiles, si bien qu'un modèle peut bien y figurer sans démontrer qu'il sépare les cas limites.

ViDoRe (Visual Document Retrieval) est celui qui compte si vos documents sont visuels : PDF, présentations, rapports avec tableaux et graphiques. C'est le benchmark face auquel la famille ColPali a été conçue, et il corrèle bien mieux avec les performances réelles en RAG multimodal que les classements généralistes.

MTEB / MMTEB est le classement le plus cité et le moins pertinent ici. La suite principale porte majoritairement sur la recherche textuelle. Un score MTEB élevé ne vous dit presque rien des performances cross-modales.

Des évaluations indépendantes de 2026 ont également mis en avant des dimensions que nul classement public ne couvre correctement : la recherche translingue, la précision sur les documents longs et le maintien de la qualité en cas de troncature des dimensions. Un benchmark mené par un éditeur et construit spécifiquement autour de ces angles morts a conclu qu'aucun modèle ne gagne sur tous les tableaux.

La position honnête : si l'un de ces points décrit votre charge de travail, les scores publiés vous induiront en erreur. Constituez un petit jeu d'évaluation à partir de vos propres données. Deux cents paires annotées suffisent à départager les meilleurs candidats et ne coûtent qu'un après-midi.

Comparatif des tarifs d'embedding multimodal

Dans cette catégorie, les tarifs sont exprimés dans des unités incompatibles : au token de texte, à l'image, au pixel, à la minute de vidéo, à la transaction, ce qui rend la comparaison directe réellement difficile. Trois exemples chiffrés, à partir des tarifs du tableau ci-dessus :

Scénario A : 500 000 documents professionnels mixtes (texte et figures intégrées). Les 128 K de contexte de Cohere Embed v4 font que la plupart des documents sont encodés entiers plutôt que découpés, et c'est là que se situe l'économie. Modélisez ce cas sur le nombre de documents, pas sur le nombre de pages.

Scénario B : 1 000 heures d'archives vidéo. La tarification à la minute de Marengo domine le calcul, mais sa sortie à 512 dimensions maintient le stockage à un niveau modeste. Comparez avec une approche par échantillonnage d'images sur Nova 2 ou Voyage 3.5, où vous payez chaque image comme une image fixe et stockez six fois plus de volume vectoriel.

Scénario C : 10 millions de requêtes textuelles courtes par mois sur un index mixte. L'indexation est un coût unique ; les requêtes, elles, durent toujours. Le texte des requêtes est court et peu coûteux sur tous les modèles présentés ici. Modélisez votre volume de requêtes, pas la taille de votre corpus : c'est le chiffre que les équipes inversent systématiquement.

Et le chiffre que personne ne mentionne : le stockage. Un milliard de vecteurs float32 à 3 072 dimensions représente environ 12 To avant surcoût d'index. À 768 dimensions, c'est 3 To. Voilà pourquoi la prise en charge de Matryoshka constitue un avantage de coût structurel que la tarification au token masque totalement, et pourquoi Gemini Embedding 2, Nova 2, Voyage 3.5 et la famille Jina disposent d'un atout qui n'apparaît pas dans un tableau de prix au token.

Embeddings vidéo et audio : le coin qui bouge le plus vite

Jusqu'à fin 2025, encoder une vidéo signifiait échantillonner des images, faire tourner un modèle d'image sur chacune, puis moyenner. Cela fonctionne pour « y a-t-il une voiture dans cet extrait ? » et échoue complètement dès qu'il s'agit de mouvement, de séquence ou de causalité.

Trois approches existent désormais :‍

1. ‍Les encodeurs nativement vidéo (Marengo 3.0, V-JEPA 2, VideoPrism, InternVideo2) modélisent directement la structure temporelle. Meilleure qualité, coût le plus élevé.‍
2. Les modèles omni avec entrée vidéo (Gemini Embedding 2, Nova 2, jina-v5-omni, Voyage 3.5) acceptent la vidéo mais la traitent généralement comme des séquences d'images ordonnées, avec des plafonds de segments. Suffisant pour la plupart des cas de recherche, et cela garde tout dans un seul espace.‍
3. L'échantillonnage d'images avec un modèle d'image reste viable pour de courts extraits où rien ne bouge de façon significative.

L'audio est moins mature. Gemini Embedding 2, Nova 2, Marengo et jina-v5-omni placent la parole et l'audio non verbal dans l'espace partagé ; la plupart des autres modèles n'y touchent pas. Si la recherche audio compte pour vous (enregistrements d'appels, podcasts, bibliothèques d'effets sonores), cette seule exigence réduit la présélection à quatre modèles.

Comment choisir un modèle d'embedding multimodal

Déroulez ces étapes dans l'ordre. Chaque réponse élimine des options avant d'arriver aux questions plus difficiles.

1. Quelles modalités possédez-vous réellement ? Texte et images uniquement → tous les modèles présentés ici. Ajoutez la vidéo → Gemini Embedding 2, Nova 2, Voyage 3.5, Marengo, jina-v5-omni. Ajoutez l'audio → Gemini Embedding 2, Nova 2, Marengo, jina-v5-omni, ImageBind. Documents visuellement complexes → Cohere Embed v4, Jina v4, famille ColPali.

2. Avez-vous une contrainte de résidence des données ou d'auto-hébergement ? Si les données ne peuvent pas quitter votre infrastructure : éliminez entièrement Voyage, Marengo et les modèles Azure / Vertex / Bedrock, puis vérifiez soigneusement les licences de ce qui reste. Cohere exige une licence commerciale pour ses poids, jina-v5-omni est non commercial par défaut.

3. Vecteur unique ou multi-vecteur ? Si la recherche doit identifier une page, une région ou un moment exact, il vous faut de la late interaction, et cela détermine à la fois le modèle et la base de données vectorielle.

4. Quel est votre budget de stockage à l'échelle visée ? Grands corpus → privilégiez la troncature Matryoshka et la quantification. À l'échelle du milliard de vecteurs, ce point contraint la présélection plus fortement que les écarts de précision.

5. Puis évaluez sur vos propres données les deux ou trois modèles restants. Deux cents paires annotées issues de votre corpus réel vous en diront plus que n'importe quel classement de cette page.

Les embeddings multimodaux avec Eden AI

Choisir un modèle est une décision. Pouvoir en changer est une tout autre affaire, et comme changer implique de réencoder votre corpus, le coût d'un mauvais choix s'aggrave à chaque vecteur écrit.

Eden AI propose une API unique couvrant plusieurs fournisseurs d'embedding multimodal, avec un format de réponse JSON standardisé : changer de fournisseur devient un changement de paramètre plutôt qu'une réécriture de l'intégration.

import requests

url = "https://api.edenai.run/v3/embeddings"
headers = {
    "Authorization": "Bearer <your-api-key>",
    "Content-Type": "application/json",
}
payload = {
    "model": "vertex/gemini-embedding-001",
    "input": "a technician inspecting a wind turbine",
}

response = requests.post(url, headers=headers, json=payload)
print(response.json()["data"][0]["embedding"])

‍

En pratique, cela vous apporte une facturation centralisée entre fournisseurs, la comparaison côte à côte de la précision, de la latence et du coût sur vos propres données, un basculement automatique en cas de panne d'un fournisseur, et aucune conservation des données, avec la possibilité de filtrer pour ne retenir que les moteurs conformes au RGPD. Pour les équipes européennes, l'endpoint UE maintient les requêtes et les données au sein de l'Europe.

FAQ – Modèles et APIs d'embedding multimodal