WeChat passe en open source son modèle d'embedding multimodal, en tête du MMEB-v2

L'équipe Vision de WeChat, chez Tencent, a publié en open source WeMM-Embedding, une famille de modèles d'embedding multimodaux à usage général. Le code et les poids ont été mis en ligne simultanément sur GitHub et Hugging Face, le rapport technique porte la référence arXiv 2608.24053, et le code est distribué sous licence Apache 2.0.

Le travail d'un modèle d'embedding consiste à compresser un contenu en une suite de vecteurs, de sorte que des éléments similaires se retrouvent proches dans l'espace vectoriel — c'est sur cette base que reposent la recherche, la déduplication et la recommandation. La couverture de WeMM-Embedding est plus large que celle de la plupart de ses équivalents : texte, image, vidéo, documents visuels, ainsi que toute combinaison entrelacée de ces formats, passent tous par la même représentation. L'audio n'est pour l'instant pas pris en charge.

Trois tailles et résultats au classement

La série se décline en trois tailles : 2B, 4B et 9B. Sur les 78 jeux de données de MMEB-v2, la version 2B obtient un score global de 77,9 (image 79,6, vidéo 70,8, documents visuels 80,7), la version 4B atteint 79,2 et la version 9B 80,6, ce qui la place en tête du classement officiel, devant tous les modèles ouverts et propriétaires déjà répertoriés.

La comparaison directe éclaire encore mieux sa position. La version 2B devance Qwen3-VL-Embedding-2B de 4,7 points et DME-2B de 3,1 points, tout en dépassant légèrement Qwen3-VL-Embedding-8B, quatre fois plus grand en nombre de paramètres. Dans ce type de tâche, le poids de la recette d'entraînement et de la qualité des données l'emporte désormais sur la seule taille du modèle.

L'entraînement se déroule en deux temps : d'abord un alignement multimodal à grande échelle, puis un affinage sur des données sélectionnées. La phase d'affinage ajoute une supervision de la pertinence à grain fin ainsi qu'un transfert de connaissances entre échelles — ce qu'apprend le grand modèle est transmis au petit, ce qui explique en partie comment la version 2B parvient à dépasser des modèles plus grands.

Des dimensions que l'on peut réduire

Les trois tailles prennent en charge la représentation Matryoshka, dont la dimension de sortie peut être choisie entre 64 et jusqu'à 2048 ou 4096. Selon les chiffres officiels, avec 256 dimensions sur MMEB-v2, les tâches d'image et de vidéo conservent encore 98,7 % de la performance obtenue avec la dimension complète.

Ce point pèse plus lourd côté ingénierie que dans le classement. Le coût de stockage et de recherche d'une base vectorielle est à peu près proportionnel à la dimension : passer de 2048 à 256 dimensions réduit la taille de l'index à un huitième, et le calcul de distance lors de la phase de récupération diminue d'autant. Auparavant, il fallait pour cela entraîner à part un petit modèle dédié ou ajouter une couche de réduction de dimension ; il suffit désormais de prendre les premiers segments des mêmes poids. Sur le plan technique, l'embedding est extrait de l'état caché à la position du token dédié <embedding> de la dernière couche, puis normalisé en L2.

Déjà en production sur du trafic réel

Le rapport technique mentionne un jeu d'évaluation interne de 26 tâches, ainsi que 14 expériences A/B en production sur différents services de WeChat, toutes ayant montré des améliorations constantes. Ces chiffres ne peuvent pas être vérifiés de l'extérieur, mais ils montrent que le modèle ne s'arrête pas à la seule course au classement — la recherche Sou Yisou, les Channels (chaînes vidéo) et la recherche de contenu des Official Accounts de WeChat constituent, par leur seul volume, un véritable test de charge.

Les limites sont également clairement indiquées : pas de prise en charge de l'audio en entrée, et dans le code d'évaluation, les vidéos sont échantillonnées à 64 images. Pour traiter des vidéos longues ou des scénarios de recherche combinée audio-image, il faudra encore ajouter une couche supplémentaire.

Pour les équipes chinoises travaillant sur le RAG multimodal, l'utilisabilité de la version 2B pèse plus lourd que la première place obtenue par la 9B. Grossièrement calculé, le modèle 2B associé à une sortie de 256 dimensions permet de faire tourner un index image-texte de l'ordre de dizaines de millions d'entrées sur un seul GPU, avec une structure de coûts totalement différente du recours à des API propriétaires comme auparavant. La licence Apache 2.0 abaisse par ailleurs nettement le seuil d'entrée pour un usage commercial.

Sources : dépôt open source Tencent/WeMM-Embedding, rapport technique arXiv 2608.24053, page du modèle sur Hugging Face, CocoLoop ; les scores par taille sur MMEB-v2, la plage de dimensions Matryoshka et le nombre d'expériences A/B en production suivent le dépôt officiel et le rapport technique.