Cohere Embed 4 : migrer un index multimodal sans mélanger les espaces vectoriels

L’unité d’analyse est le modèle avec l’index qui en dépend

Changer de modèle d’embeddings ne revient pas à remplacer une pièce interchangeable du moteur de recherche. Le modèle transforme les documents et les requêtes en vecteurs ; l’index organise ces vecteurs et permet de les comparer. La récupération dépend donc de la compatibilité des représentations produites de part et d’autre, ainsi que d’un traitement adapté des requêtes. Pour évaluer Cohere Embed 4 — désigné `embed-v4.0` dans la documentation du fournisseur —, l’unité d’analyse doit être l’ensemble formé par le modèle, la configuration d’entrée, les vecteurs, l’index et la règle de comparaison.

La conséquence opérationnelle est importante : sans validation, les vecteurs produits par un modèle antérieur ne doivent pas être ajoutés au même espace de recherche que ceux générés par Embed 4. Le fait que les deux modèles produisent des vecteurs de même longueur ne prouve pas que leurs coordonnées aient la même signification. Modifier uniquement la dimension de sortie dans le système de stockage ne suffit pas non plus. En cas de remplacement du modèle, la démarche prudente consiste à recalculer les représentations des documents et des requêtes avec une configuration compatible, tout en gardant l’ancien index disponible pendant l’évaluation.

Ce guide propose une méthode pour décider s’il vaut mieux migrer, ajouter un parcours multimodal ou conserver la solution actuelle. Il ne part pas du principe qu’Embed 4 surpasse le système en place : les spécifications décrivent les capacités déclarées et les modalités d’utilisation documentées, mais l’effet sur la pertinence dépend du corpus, des requêtes et de l’implémentation. L’analyse porte sur la récupération, et non sur la comparaison de modèles génératifs ou l’attribution d’une qualité à la réponse finale d’un système RAG.

Ce que Cohere déclare au sujet d’Embed 4

Cohere présente Embed 4 comme un modèle multimodal capable de générer des représentations à partir de texte, d’images et d’entrées mixtes. Les exemples d’entrées mixtes documentés comprennent des pages PDF contenant du texte et des images. Cela ouvre la voie à des cas qui ne se limitent pas à rechercher du texte extrait de fichiers : une page peut apporter à la représentation des informations textuelles et visuelles. Toutefois, le fait qu’une modalité soit prise en charge ne garantit ni que tous les documents de cette modalité seront correctement interprétés ni que la récupération s’améliorera pour une tâche donnée.

Les informations publiées par Cohere indiquent des dimensions de sortie de 256, 512, 1024 et 1536, ainsi qu’un contexte de 128k. Il s’agit de spécifications du fournisseur, et non d’une promesse que tous les canaux d’accès accepteront les mêmes formats, limites ou paramètres. L’API de Cohere, Amazon Bedrock et Oracle Cloud Infrastructure sont, par exemple, des interfaces distinctes. Avant de concevoir une migration, vérifiez la documentation du service réellement utilisé et consignez le nom exact du modèle, la région ou le service le cas échéant, les limites en vigueur et le format des requêtes.

La dimension fait partie du contrat entre le générateur d’embeddings et l’index : elle détermine la taille de chaque vecteur et influe donc sur la compatibilité, le stockage et les opérations de recherche. Une dimension plus faible peut réduire le volume occupé par les vecteurs, mais il ne faut pas en déduire que la qualité de récupération sera préservée. De même, une dimension plus élevée ne garantit pas de meilleures performances sur le corpus. Il faut comparer les options avec les mêmes requêtes, les mêmes jugements de pertinence et les mêmes conditions opérationnelles.

Embed 4 dispose d’un paramètre `input_type` associé à l’usage de l’entrée. Dans la documentation de Cohere sur les embeddings, `search_document` désigne les entrées de documents et `search_query` les requêtes de recherche. Dans un flux de récupération, utiliser le type approprié de chaque côté fait partie de la configuration à maintenir cohérente entre l’indexation et la requête. Ce paramètre ne doit pas être traité comme une étiquette facultative : le processus doit respecter les valeurs admises par le point de terminaison choisi et vérifier leur application au texte, aux images ou aux entrées mixtes.

Pourquoi éviter de mélanger les vecteurs de modèles différents

Un vecteur est une représentation numérique produite par un modèle selon une configuration donnée. La recherche vectorielle classe généralement les candidats à l’aide d’une mesure de similarité ou de distance. Pour que la comparaison soit pertinente, les vecteurs des documents et des requêtes doivent être générés de manière compatible avec la méthode de récupération employée. Une dimension identique indique seulement que les listes numériques ont la même longueur ; elle n’établit pas que leurs positions soient comparables entre deux modèles.

La métrique de distance fait également partie de la configuration de l’index. Lors d’une migration, ne changez pas de métrique de comparaison sans en vérifier l’effet sur les résultats. La documentation de Cohere décrit des mesures de similarité pour les embeddings, mais le choix précis dépend de l’intégration et de l’index. L’équipe doit consigner la mesure utilisée par le système actuel, celle prévue pour le système candidat, ainsi que toute normalisation des vecteurs ou transformation supplémentaire appliquée par le moteur de recherche.

La séparation doit être maintenue dans le stockage comme dans l’évaluation. Étiqueter chaque vecteur avec le modèle, la dimension, la modalité traitée et la version de configuration permet de retracer sa production. Si les anciens et les nouveaux index coexistent, chaque requête doit être représentée dans l’espace correspondant à l’index visé. N’envoyez pas un vecteur de requête produit par un modèle à l’index d’un autre modèle dans le seul but de simplifier le routage, sauf si un test délibéré démontre la validité de cette combinaison pour le cas d’usage.

Une erreur fréquente consiste à évaluer uniquement la réponse générée par une application RAG. Une réponse convaincante peut masquer l’absence des documents pertinents parmi les premiers résultats ; elle peut aussi s’appuyer sur les connaissances préalables du générateur. Pour évaluer la couche d’embeddings, il faut examiner les éléments récupérés par le moteur et les confronter à des jugements de pertinence établis indépendamment du texte ensuite produit par le modèle génératif.

Migrer documents et requêtes en gardant une traçabilité

Une migration contrôlée commence par l’inventaire de l’index existant. Consignez le modèle et son identifiant, la dimension, la méthode de distance, la stratégie de segmentation, les transformations préalables, le type d’entrée, les langues couvertes et les métadonnées conservées. Pour les usages multimodaux, indiquez également les modalités extraites ou envoyées, la manière d’identifier les pages et le lien entre chaque vecteur et son fragment source. Sans cet inventaire, une variation des résultats pourrait provenir du modèle, de la segmentation ou d’un changement de prétraitement passé inaperçu.

Construisez ensuite l’index candidat comme une nouvelle version. Recalculez les embeddings des documents, conservez des clés stables permettant de relier chaque vecteur à sa source et consignez les éléments qui n’ont pas pu être traités. Ne remplacez pas les anciennes représentations pendant le test. Pour chaque exécution, stockez la combinaison du modèle, de la dimension, du type d’entrée, de la date et de la version du processus. Vous pourrez ainsi reproduire une comparaison et détecter si deux tests apparemment identiques ont en réalité utilisé des configurations différentes.

La requête doit suivre un parcours équivalent. Le service de recherche détermine l’index à interroger et utilise le type d’entrée prévu pour les requêtes. Pendant la période de coexistence, la même requête logique peut être envoyée au parcours existant et au parcours candidat, mais chacun doit générer son propre embedding. Si une étape ultérieure fusionne les résultats, ses effets doivent être mesurés séparément ; sinon, il sera difficile d’attribuer une amélioration ou une régression à Embed 4.

Pour intégrer des images et des pages PDF, documentez le traitement des fichiers propre au canal choisi. La documentation de Cohere présente un flux de recherche sémantique avec des pages PDF et du contenu mixte, mais les formats et limites exacts doivent être vérifiés dans l’API ou la plateforme sélectionnée. Ne transposez pas automatiquement les règles de Cohere à Bedrock ou à OCI, ni l’inverse. N’interprétez pas non plus le contexte déclaré comme une autorisation d’envoyer n’importe quel fichier sans tenir compte des restrictions de taille, de structure ou de format.

Protocole de test : corpus, requêtes et pertinence

Avant de comparer les modèles, fixez un corpus d’évaluation et ne le modifiez pas entre les exécutions. Incluez des documents fréquemment consultés, difficiles à traiter et rarement interrogés ; si la recherche couvre plusieurs langues, intégrez des exemples de chacune. Pour évaluer le multimodal, quelques images ne suffisent pas : identifiez les tâches pour lesquelles l’information visuelle est nécessaire, les documents mêlant texte et image, les pages contenant des tableaux et les situations où le contenu extrait par OCR risque d’être incomplet. L’objectif est de représenter les usages visés, et non de construire un échantillon qui favorise d’emblée un modèle.

Préparez des requêtes réelles ou formulées à partir de besoins observables, puis consignez les documents ou fragments qui devraient être considérés comme pertinents. Les jugements peuvent être binaires ou gradués, mais les règles doivent rester identiques pour la comparaison entre le système actuel et le candidat. Il est utile d’inclure des requêtes directes, ambiguës, contenant des termes rares ou des noms propres, ainsi que des questions dont la réponse dépend d’une image ou d’un tableau. Ne considérez pas une requête comme correctement évaluée simplement parce que le système actuel la résout : définissez au préalable ce qu’il est attendu de récupérer.

L’analyse doit porter sur les positions et les ensembles de résultats. Recall@k indique si les éléments pertinents figurent parmi les k premiers résultats ; precision@k, quelle proportion des premiers résultats est jugée pertinente ; nDCG@k peut être utile lorsque les jugements distinguent plusieurs degrés de pertinence. Ce sont des métriques possibles, et non la garantie qu’un indicateur unique résumera l’utilité du système. Convenez à l’avance des valeurs de k et des critères de promotion importants pour l’expérience réelle.

Ventilez les résultats par langue, modalité et type de requête. Une amélioration globale peut masquer une baisse pour une langue minoritaire ou pour des documents contenant des images. De même, une moyenne satisfaisante n’efface pas les cas d’échec critiques. Gardez des exemples de requêtes pour lesquelles le nouveau modèle récupère des résultats différents, examinez-les avec des spécialistes du domaine et distinguez les erreurs d’indexation, de segmentation, de configuration et de pertinence propres à l’embedding.

Métriques opérationnelles et effets de la dimension

La qualité de récupération n’est pas le seul critère de décision. Mesurez la latence dans des conditions comparables, tant pour la génération des embeddings que pour la recherche, et consignez les ressources nécessaires au traitement du corpus et à la maintenance de l’index. Distinguez le coût de création ou de reconstruction des embeddings de celui du traitement des requêtes habituelles. Les montants et les durées dépendent du fournisseur, du canal d’accès, de la taille des entrées, de la dimension sélectionnée et de la charge ; la fiche du modèle ne suffit pas à les déduire.

Comparez les dimensions disponibles dans un test où les autres facteurs restent constants. Vérifiez la taille réellement occupée dans l’index, les effets sur le transfert et le comportement de la récupération. Si le fournisseur décrit une stratégie Matryoshka ou la possibilité de choisir plusieurs dimensions, traitez-la comme une option de configuration à mesurer, et non comme la preuve d’une équivalence automatique entre tailles. Réduire la dimension peut alléger certaines charges opérationnelles, mais aussi modifier l’ordre des documents récupérés.

Consignez également la proportion d’entrées rejetées, tronquées ou traitées différemment de ce qui était attendu. Dans un test multimodal, la part de documents qui n’atteignent pas l’index peut modifier les métriques de récupération et donner une image trompeuse du modèle. Présentez séparément la couverture du traitement, la qualité de récupération sur les cas valides et les résultats globaux qui tiennent compte des échecs. Une comparaison équitable ne doit pas exclure silencieusement les documents difficiles pour l’une des configurations.

Promotion, retour arrière et documentation

Définissez avant le test les résultats nécessaires pour promouvoir l’index candidat. Les critères peuvent combiner des seuils de récupération par segment, l’absence de régressions sur les requêtes critiques, des limites acceptables de latence et de coût, ainsi qu’un niveau minimal de couverture du traitement. Il n’existe pas de seuil universel : tout dépend de l’importance des différents cas, du niveau de service et du coût des erreurs. La décision doit s’appuyer sur des éléments observables, et non sur l’impression que les réponses de démonstration semblent meilleures.

Le retour arrière doit faire partie de la conception de la migration. Conservez l’ancien index, sa configuration et le lien entre les identifiants des documents et leurs vecteurs. Si la promotion échoue, le parcours des requêtes doit pouvoir revenir à la version précédente sans ajouter à l’ancien index des vecteurs du candidat ni perdre la traçabilité. Pendant une transition progressive, identifiez chaque résultat avec l’index et la configuration qui l’ont produit ; ne fusionnez pas les sorties des deux versions sans politique de fusion préalablement testée.

Documentez les résultats et leurs limites : langues peu représentées dans l’échantillon, modalités non évaluées, entrées refusées par le canal et différences entre fournisseurs. Si l’équipe utilise Cohere directement, Amazon Bedrock ou OCI, précisez la documentation consultée et les limites applicables à cette intégration. La fiche d’un modèle proposé par une plateforme ne doit pas devenir une affirmation générale sur tous les points de terminaison qui utilisent le nom Embed 4.

Une migration est défendable si une autre personne peut reconstituer le corpus testé, le modèle et ses paramètres, les requêtes et les jugements utilisés, les métriques calculées et la décision qui en a résulté. La documentation publique de Cohere aide à définir les capacités et paramètres déclarés ; la validation des performances de récupération dans l’environnement propre à l’équipe reste de sa responsabilité.

Ce que l’on peut conclure et ce qui nécessite une évaluation propre

La documentation de Cohere déclare qu’Embed 4 prend en charge le texte, les images et les entrées mixtes, propose plusieurs dimensions et dispose d’un contexte étendu ; les exemples incluent la recherche dans des pages PDF. L’API et les guides du fournisseur décrivent des paramètres importants pour la récupération, comme `input_type`. Ces informations permettent de préparer un test et de comprendre quelles configurations vérifier. Elles ne prouvent pas qu’un index créé avec un autre modèle peut être réutilisé directement, qu’une dimension particulière est optimale ou que la récupération s’améliorera sur un ensemble de documents donné.

La question utile n’est pas de savoir si Embed 4 est meilleur dans l’absolu, mais si une configuration définie de `embed-v4.0` fournit des résultats de récupération satisfaisants pour les documents, les langues, les modalités et les contraintes opérationnelles de l’équipe. Pour y répondre, il faut construire un index candidat distinct, recalculer documents et requêtes de façon compatible, évaluer les résultats à l’aide de jugements de pertinence et consigner coût et latence. Ce n’est qu’après cette comparaison qu’il est pertinent de décider si le système en place doit être remplacé ou complété par un parcours multimodal.

Pour les équipes qui explorent des modèles et des outils dans la rubrique de découverte d’Inferama, cette démarche fournit un critère de comparaison qui va au-delà d’une fiche technique. La page consacrée à Cohere Embed 4 et les informations relatives à Cohere en tant qu’organisation peuvent aider à localiser le modèle et sa documentation ; le choix opérationnel, lui, doit être justifié par des résultats reproductibles obtenus sur l’index et les requêtes réels.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.