text-embedding-3-large est le modèle d'embedding de qualité supérieure d'OpenAI, sorti le 25 janvier 2024 aux côtés du plus petit text-embedding-3-small. Un modèle d'embedding ne génère pas de texte — il convertit un passage de texte en un vecteur de nombres de longueur fixe capturant son sens, de sorte que deux passages de sens proche produisent des vecteurs qui se retrouvent proches l'un de l'autre dans cet espace numérique. Cette propriété rend les embeddings utiles pour la recherche sémantique, le clustering, la déduplication, la recommandation et la génération augmentée par récupération (RAG), où un système doit trouver les passages les plus pertinents avant de les transmettre à un modèle de langage.
Ce qu'apporte « large » par rapport à « small »
Par défaut, text-embedding-3-large produit un vecteur de 3 072 dimensions, contre 1 536 pour text-embedding-3-small. Sur le propre benchmark MTEB d'OpenAI, une suite standard pour évaluer la qualité des embeddings sur des tâches de récupération, de classification et de clustering, large obtient 64,6 contre 62,3 pour small — un écart de qualité réel mais pas énorme. Le modèle plus grand capture davantage de nuances par embedding, ce qui compte surtout sur les tâches de récupération les plus difficiles : distinguer des documents étroitement liés, travailler dans des domaines ou des langues moins courants, ou classer de nombreux candidats similaires les uns par rapport aux autres.
Le paramètre dimensions
Les deux modèles prennent en charge un paramètre dimensions qui raccourcit le vecteur de sortie par troncature, sans avoir besoin de réencoder le texte via un autre modèle. Selon OpenAI, un vecteur text-embedding-3-large raccourci à 256 dimensions surpasse encore l'ancien modèle text-embedding-ada-002 non raccourci à ses 1 536 dimensions natives. C'est important sur le plan opérationnel : un vecteur plus court occupe moins de stockage dans une base de données vectorielle et se compare plus rapidement et à moindre coût au moment de la requête ; le paramètre dimensions est donc un véritable levier pour échanger une petite quantité de qualité de récupération contre une taille d'index et une latence de recherche nettement réduites — sans changer de modèle ni repenser le pipeline.
Sous le capot
La longueur maximale d'entrée est de 8 192 tokens par requête. La sortie est uniquement de l'embedding — il n'y a ni génération de texte, ni interface de chat, ni usage d'outils. Le modèle prend du texte en entrée et renvoie un vecteur, rien d'autre, ce qui garde sa surface d'intégration réduite : un seul appel API prend une chaîne de caractères et renvoie un tableau de flottants de taille fixe.
Quand choisir large plutôt que small
Tournez-vous vers text-embedding-3-large lorsque la qualité de récupération est le goulot d'étranglement : un système RAG qui manque des passages pertinents, une fonction de recherche qui renvoie des quasi-correspondances plutôt que le bon résultat, ou une tâche de clustering où des distinctions fines entre éléments similaires comptent. C'est aussi le choix par défaut le plus défendable lorsqu'on travaille dans des langues moins courantes ou des domaines spécialisés, où un espace d'embedding plus petit a moins de marge pour représenter les nuances.
Pour l'indexation à très fort volume — des millions de documents, ou un workload où la latence des requêtes et le coût de stockage dominent la conception — text-embedding-3-small, ou un embedding large tronqué via le paramètre dimensions, est généralement le point de départ le plus pratique. L'écart MTEB entre les deux modèles est réel mais modeste, donc il vaut la peine de tester les deux sur un échantillon représentatif de vos propres données plutôt que de choisir large par défaut sur la seule hypothèse que plus grand est meilleur.
Alternatives à comparer
text-embedding-ada-002 reste disponible en tant que modèle d'embedding de génération précédente d'OpenAI, mais il est dominé en qualité par les deux modèles actuels, même à une fraction de leur dimensionnalité, donc il y a peu de raisons de le choisir pour un nouveau travail. En dehors de la propre gamme d'OpenAI, plusieurs autres fournisseurs proposent des modèles d'embedding de texte généralistes au positionnement comparable ; le bon choix se résume généralement à tester la qualité de récupération sur votre propre corpus plutôt qu'aux seuls scores de benchmark, car la performance MTEB ne se transpose pas toujours proprement à un domaine spécifique.