text-embedding-3-small est le modèle d'embedding plus petit et moins coûteux d'OpenAI, sorti le 25 janvier 2024 aux côtés du plus grand text-embedding-3-large. Un modèle d'embedding transforme du texte en un vecteur de nombres de longueur fixe représentant son sens, plutôt que de générer du nouveau texte — 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é est à la base de la recherche sémantique, du clustering, de la déduplication, de la recommandation et de la génération augmentée par récupération (RAG), où un système doit classer des passages stockés par pertinence par rapport à une requête avant même qu'un modèle de langage ne les voie.
Ce pour quoi il est conçu
Par défaut, text-embedding-3-small produit un vecteur de 1 536 dimensions. Sur le propre benchmark MTEB d'OpenAI — une suite d'évaluation standard couvrant récupération, classification et clustering — il obtient 62,3, devançant l'ancien modèle text-embedding-ada-002 à 61,0, bien qu'ada-002 utilise les mêmes 1 536 dimensions. Autrement dit, cette génération a amélioré la qualité à taille de vecteur inchangée, ce qui représente une mise à niveau simple pour quiconque utilise encore la génération précédente.
La longueur maximale d'entrée est de 8 192 tokens par requête, comme pour le modèle plus grand. La sortie est uniquement de l'embedding : pas de chat, pas de génération, pas d'usage d'outils — un seul appel prend une chaîne de caractères et renvoie un tableau de flottants de taille fixe.
Le paramètre dimensions
Comme son grand frère, text-embedding-3-small prend en charge un paramètre dimensions qui raccourcit le vecteur de sortie à une longueur plus courte sans réencoder via un autre modèle. Raccourcir le vecteur réduit le stockage dans une base de données vectorielle et accélère les comparaisons de similarité au moment de la requête, ce qui est utile lorsque l'index est assez grand pour que le stockage et la latence de recherche commencent à dominer le coût — une situation courante une fois qu'un corpus atteint des millions de documents.
Là où il trouve sa place
La raison principale de choisir text-embedding-3-small est le volume : un grand nombre de documents, une réindexation fréquente, et un schéma de requêtes où les budgets de latence sont serrés. Son coût plus faible par appel et sa taille de vecteur par défaut plus petite s'accumulent à l'échelle — chaque document indexé et chaque requête encodée entraîne un coût de stockage et de calcul réel et continu, et pour de grands corpus, cela s'additionne quelle que soit la qualité de chaque embedding pris isolément.
C'est aussi un choix par défaut raisonnable pour les tâches de récupération non adversariales ou peu exigeantes en finesse : recherche documentaire générale, correspondance de FAQ, déduplication de contenu quasi identique, et pipelines RAG où l'étape de récupération doit être « suffisamment bonne » plutôt que maximalement précise, car le modèle de langage qui lit les passages récupérés peut tolérer un peu de bruit dans ce qui est retrouvé.
Là où les limites apparaissent
L'écart MTEB avec text-embedding-3-large est réel, quoique modeste, et il tend à s'élargir sur les tâches de récupération les plus difficiles — distinguer des passages étroitement liés, travailler dans des langues moins courantes, ou classer avec précision de nombreux candidats similaires. Pour un système RAG qui manque de façon mesurable des passages pertinents, ou une fonction de recherche qui renvoie des quasi-correspondances, la solution consiste souvent à passer au modèle plus grand plutôt qu'à continuer d'ajuster le plus petit.
Alternatives à comparer
text-embedding-3-large est la voie de mise à niveau naturelle lorsque la qualité de récupération, et non le coût, est le goulot d'étranglement. text-embedding-ada-002 reste disponible mais est dominé en qualité par ce modèle à taille de vecteur égale, donc il y a peu de raisons de le choisir pour un nouveau travail. En dehors d'OpenAI, plusieurs fournisseurs proposent des modèles d'embedding généralistes comparables ; tester la qualité de récupération sur un échantillon représentatif de votre propre corpus est un meilleur guide que les seuls scores de benchmark, car la performance des embeddings ne se transpose pas toujours uniformément d'un domaine à l'autre.