Il y a des modèles qui ne font pas beaucoup de bruit, mais qui structurent des pans entiers de l’infrastructure IA. text-embedding-ada-002 fait partie de ceux-là. Lancé par OpenAI fin 2022, il a accompagné l’essor de la recherche sémantique, des bases vectorielles et du RAG en offrant une interface simple, économique et polyvalente. En 2026, il n’est plus le choix le plus moderne, mais il reste présent dans de nombreux systèmes en production. Son intérêt tient désormais autant à son héritage qu’à sa compatibilité opérationnelle.
Le modèle qui a remis de l’ordre dans les embeddings OpenAI
Avant text-embedding-ada-002, l’écosystème d’embeddings d’OpenAI était plus fragmenté. Il fallait distinguer les modèles de similarité textuelle, les modèles de recherche avec variantes pour les requêtes et les documents, ainsi que les modèles dédiés à la recherche de code. Cette granularité avait du sens techniquement, mais elle compliquait le travail des équipes produit et data.
Avec text-embedding-ada-002, OpenAI a proposé un modèle unique capable de couvrir plusieurs familles d’usages : similarité, recherche documentaire, recherche de code, classification, clustering et recommandations. Ce choix a eu un impact concret. Les développeurs pouvaient vectoriser une requête et un document avec le même modèle, sans jongler entre plusieurs endpoints ni maintenir plusieurs espaces vectoriels.
À son lancement, OpenAI présentait ce modèle comme plus performant que les anciennes familles spécialisées sur la recherche texte, la recherche code et la similarité de phrases. Il apportait aussi deux avantages pratiques : une fenêtre d’entrée portée à environ 8 192 tokens et des vecteurs de 1 536 dimensions, beaucoup plus compacts que certains prédécesseurs. Pour les architectures de recherche sémantique, c’était un compromis particulièrement attractif.
Ce qu’un embedding fait au texte
Un embedding transforme un contenu textuel en vecteur numérique. L’objectif n’est pas de représenter les mots un par un, mais de capturer des proximités de sens. Deux formulations différentes peuvent ainsi se retrouver proches dans l’espace vectoriel si elles portent une intention similaire.
Par exemple, une requête comme “SUV électrique pour famille” peut être rapprochée d’un document parlant de “voiture électrique familiale”, même si les mots ne correspondent pas parfaitement. C’est précisément ce qui rend les embeddings utiles dans les moteurs de recherche internes, les assistants documentaires, les FAQ augmentées ou les systèmes de recommandation. Le modèle ne cherche pas seulement des chaînes de caractères, il produit une représentation exploitable par calcul de similarité.
Dans une architecture classique, les documents sont découpés en passages, chaque passage est transformé en vecteur, puis ces vecteurs sont stockés dans une base spécialisée. Lorsqu’un utilisateur pose une question, celle-ci est elle aussi vectorisée. Le système compare ensuite le vecteur de la requête aux vecteurs indexés afin d’identifier les passages les plus proches.
| Étape | Rôle dans la chaîne vectorielle |
|---|---|
| Découpage du corpus | Segmenter les documents en passages exploitables |
| Embedding | Convertir chaque passage en vecteur numérique |
| Indexation | Stocker les vecteurs dans une base vectorielle |
| Requête utilisateur | Transformer la question en vecteur comparable |
| Similarité | Identifier les passages les plus proches |
| Récupération | Fournir les extraits pertinents au système applicatif ou au LLM |
La fiche technique, sans enjoliver
text-embedding-ada-002 est un modèle d’embedding textuel. Il ne génère pas de réponse conversationnelle, ne résume pas un document et ne raisonne pas au sens d’un modèle génératif. Sa sortie est un vecteur dense de 1 536 valeurs numériques, utilisable ensuite par une application, une base vectorielle ou un pipeline de ranking.
| Caractéristique | Valeur |
|---|---|
| Nom du modèle | text-embedding-ada-002 |
| Fournisseur | OpenAI |
| Date de lancement | Décembre 2022 |
| Type | Embedding texte |
| Dimensions | 1 536 |
| Longueur maximale d’entrée | Environ 8 192 tokens |
| Modalité | Texte uniquement |
| Paramètre dimensions | Non supporté |
| Statut en 2026 | Disponible, mais désormais considéré comme un modèle ancien |
| Prix OpenAI standard | 0,10 dollar par million de tokens |
Un point mérite d’être souligné : le modèle impose sa dimension de sortie. Contrairement à text-embedding-3-small et text-embedding-3-large, il ne permet pas de réduire nativement la taille des vecteurs via un paramètre dimensions. À grande échelle, cette rigidité a des conséquences sur le stockage, les temps de recherche et les coûts d’infrastructure.
Pourquoi 1 536 dimensions comptent vraiment
Une dimension vectorielle n’est pas directement interprétable comme une colonne métier. On ne peut pas dire que la dimension 127 représente la fiscalité, la 482 l’intention d’achat ou la 901 le ton émotionnel. Le vecteur doit être lu comme une représentation distribuée, où l’information sémantique est répartie dans l’ensemble de l’espace.
Dans le cas de text-embedding-ada-002, chaque fragment de texte devient un vecteur de 1 536 nombres. En stockage brut float32, cela représente environ 6 144 octets par vecteur, soit près de 6 Ko avant même d’ajouter les métadonnées, l’index ANN, la réplication, les snapshots ou le texte source. À petite échelle, ce chiffre paraît anodin. À plusieurs millions de passages, il devient un vrai sujet d’architecture.
| Volume indexé | Stockage brut des vecteurs 1 536D |
|---|---|
| 100 000 chunks | Environ 614 Mo |
| 1 million de chunks | Environ 6,1 Go |
| 10 millions de chunks | Environ 61 Go |
Ces valeurs ne représentent que le plancher théorique. Dans une base comme Pinecone, Weaviate, Qdrant, Milvus, pgvector ou une solution maison, le coût réel dépend aussi de l’algorithme d’indexation, du niveau de réplication, du filtrage par métadonnées, du nombre d’environnements et des exigences de latence. Le prix de génération des embeddings n’est donc qu’une partie de l’équation.
Le RAG lui doit une partie de sa popularité
Le succès de text-embedding-ada-002 est difficile à séparer de la montée du RAG. Dans un système de génération augmentée par récupération, les embeddings servent à retrouver les passages pertinents avant de les injecter dans le contexte d’un modèle génératif. Le LLM ne répond plus uniquement depuis ses paramètres internes : il s’appuie sur une base documentaire externe, potentiellement plus fraîche, plus spécialisée et mieux contrôlée.
Ce modèle a donc été massivement utilisé pour construire des assistants documentaires, des moteurs de recherche internes et des outils d’aide à la décision. Sa simplicité d’usage a permis de prototyper rapidement des systèmes où l’on indexe des documents, des tickets support, des pages de documentation, des contrats, des fiches produits ou des articles scientifiques.
Dans ce type d’architecture, la qualité du modèle d’embedding compte, mais elle ne suffit pas. Le découpage des documents, la qualité des métadonnées, le choix du top-k, le reranking, les filtres hybrides et l’évaluation humaine pèsent fortement sur le résultat final. Un embedding performant ne compense pas un corpus mal segmenté ou des passages trop longs qui diluent l’information utile.
Le coût : cinq fois plus cher que son successeur direct
Sur le plan économique, text-embedding-ada-002 a longtemps été attractif. Mais la comparaison avec les modèles de troisième génération change le diagnostic. OpenAI affiche text-embedding-3-small à 0,02 dollar par million de tokens, contre 0,10 dollar par million de tokens pour text-embedding-ada-002.
Sur 100 millions de tokens indexés, la génération des embeddings coûte donc environ 10 dollars avec text-embedding-ada-002, contre environ 2 dollars avec text-embedding-3-small. Cette différence peut sembler modeste sur un corpus unique. Elle devient beaucoup plus sensible lorsque l’on réindexe régulièrement, que l’on maintient plusieurs environnements, que l’on gère des corpus clients séparés ou que l’on reconstruit l’index après chaque changement de découpage.
| Volume de tokens | Coût avec text-embedding-ada-002 | Coût avec text-embedding-3-small |
|---|---|---|
| 10 millions | Environ 1 dollar | Environ 0,20 dollar |
| 100 millions | Environ 10 dollars | Environ 2 dollars |
| 1 milliard | Environ 100 dollars | Environ 20 dollars |
Le coût de génération reste souvent inférieur au coût total d’exploitation d’un système vectoriel. Cependant, le différentiel de prix renforce une idée simple : pour un nouveau projet, choisir text-embedding-ada-002 demande aujourd’hui une justification sérieuse, généralement liée à la compatibilité avec un existant.
Face à text-embedding-3-small et text-embedding-3-large
Depuis janvier 2024, OpenAI propose deux modèles plus récents : text-embedding-3-small et text-embedding-3-large. Le premier vise le meilleur compromis coût-performance. Le second vise une qualité supérieure, notamment pour les corpus complexes, multilingues ou fortement ambigus.
Les benchmarks publiés par OpenAI donnent une lecture nette. text-embedding-3-small dépasse text-embedding-ada-002 sur MTEB et surtout sur MIRACL, un benchmark de recherche multilingue. text-embedding-3-large va plus loin, avec une dimension par défaut plus élevée et une meilleure qualité annoncée.
| Modèle | Dimensions par défaut | MTEB | MIRACL | Prix standard |
|---|---|---|---|---|
| text-embedding-ada-002 | 1 536 | 61,0 % | 31,4 % | 0,10 dollar / 1M tokens |
| text-embedding-3-small | 1 536 | 62,3 % | 44,0 % | 0,02 dollar / 1M tokens |
| text-embedding-3-large | 3 072 | 64,6 % | 54,9 % | 0,13 dollar / 1M tokens |
La progression la plus visible concerne le multilingue. Pour un corpus français, européen ou international, text-embedding-3-small apparaît souvent comme une option plus rationnelle que text-embedding-ada-002. Il conserve la même dimension par défaut, coûte cinq fois moins cher et améliore les scores publiés. Pour des cas exigeants, text-embedding-3-large apporte davantage de marge qualitative, au prix d’un vecteur plus grand et d’un coût token supérieur.
Ce que le modèle fait bien, encore aujourd’hui
Malgré son ancienneté, text-embedding-ada-002 reste parfaitement exploitable dans de nombreux scénarios. Il est stable, largement documenté, intégré dans de nombreux frameworks et compatible avec la plupart des bases vectorielles du marché. Pour des systèmes déjà en production, cette stabilité peut peser plus lourd qu’un gain de benchmark.
Recherche sémantique interne
Dans une base de connaissance, une documentation produit ou un historique de tickets support, le modèle permet de retrouver des passages proches d’une requête même lorsque les termes exacts divergent. L’intérêt est particulièrement net lorsque les utilisateurs formulent leurs questions avec leur propre vocabulaire, loin de la terminologie officielle de l’entreprise.
Classification légère et routage
Les embeddings peuvent servir à comparer un texte entrant à des exemples représentatifs. Un ticket peut être rapproché d’une catégorie, un e-mail d’une intention, un commentaire client d’un thème. Ce type d’approche est souvent plus souple qu’un classifieur supervisé lorsque les labels évoluent vite ou que les données annotées sont limitées.
Clustering et analyse de corpus
En regroupant les vecteurs proches, on peut faire émerger des familles de documents, des sujets récurrents ou des anomalies. Les équipes support, produit, juridique ou recherche peuvent ainsi explorer de grands volumes de textes sans définir à l’avance toutes les catégories pertinentes.
Recommandations et rapprochements documentaires
Un article, un produit, une vidéo, une fiche profil ou un document métier peut être représenté par un embedding. Les éléments voisins deviennent alors des candidats naturels pour une recommandation, une suggestion de lecture ou une mise en relation. text-embedding-ada-002 reste utilisable pour ces cas si l’exigence de précision n’est pas extrême.
Ses limites ne sont plus anecdotiques
Le principal problème de text-embedding-ada-002 n’est pas qu’il serait devenu mauvais. C’est qu’il existe désormais mieux, souvent moins cher et parfois plus flexible. Pour un acteur qui conçoit une nouvelle pile RAG ou un moteur de recherche sémantique en 2026, ce simple constat change la grille de décision.
- Qualité relative en retrait : les modèles text-embedding-3 affichent de meilleurs scores sur les benchmarks communiqués par OpenAI, notamment en multilingue.
- Absence de dimension ajustable : text-embedding-ada-002 produit toujours des vecteurs de 1 536 dimensions, sans réduction native paramétrable.
- Coût token moins favorable : text-embedding-3-small est annoncé à un prix cinq fois inférieur.
- Migration non directe : les vecteurs issus de différents modèles ne sont pas interchangeables dans un même espace vectoriel.
- Seuils à recalibrer : les scores de similarité, les top-k et les seuils métier ne se transfèrent pas mécaniquement d’un modèle à l’autre.
La compatibilité vectorielle est un point souvent sous-estimé. Un index construit avec text-embedding-ada-002 ne peut pas être enrichi directement avec des vecteurs text-embedding-3-small comme si rien ne changeait. Les espaces vectoriels sont propres aux modèles. Mélanger les deux dans le même index revient généralement à dégrader la cohérence de la recherche.
Migrer sans perdre le contrôle de la pertinence
La migration vers un modèle récent doit être traitée comme une reconstruction d’espace vectoriel, pas comme un simple changement de paramètre. Le risque n’est pas seulement technique. Il touche aussi les métriques produit, les seuils de décision, les habitudes utilisateurs et parfois les engagements contractuels de qualité.
Une bonne migration commence par un échantillon représentatif. Il faut ré-embedder une partie du corpus avec le nouveau modèle, comparer les résultats sur des requêtes réelles, mesurer le recall@k, le MRR, le nDCG ou des métriques métier, puis analyser les écarts qualitatifs. Les requêtes difficiles sont les plus utiles : synonymes rares, ambiguïtés, formulations longues, documents proches mais non pertinents, contenu multilingue.
- Conserver l’index existant en text-embedding-ada-002 pendant toute la phase de test.
- Créer un second index avec le modèle cible, le plus souvent text-embedding-3-small ou text-embedding-3-large.
- Rejouer un jeu de requêtes représentatif, idéalement issu de logs réels et annoté.
- Comparer les résultats à l’aide de métriques automatiques et d’une revue humaine.
- Recalibrer les seuils de similarité, le nombre de passages récupérés et les filtres hybrides.
- Tester le nouvel index en shadow mode ou en A/B test.
- Basculer progressivement, avec possibilité de retour arrière.
- Supprimer l’ancien index uniquement après validation opérationnelle.
Dans beaucoup de cas, text-embedding-3-small sera le candidat naturel. Il conserve la même dimension par défaut que text-embedding-ada-002, réduit le coût de génération et améliore les scores de référence. text-embedding-3-large devient plus pertinent lorsque la précision documentaire est critique : corpus juridiques, scientifiques, médicaux, techniques, multilingues ou fortement spécialisés.
Le choix raisonnable dépend surtout de l’existant
Pour un nouveau projet, le choix de text-embedding-ada-002 est difficile à défendre, sauf contrainte très particulière. text-embedding-3-small offre un meilleur rapport coût-performance et s’inscrit dans la génération de modèles désormais recommandée par OpenAI. Pour une qualité maximale, text-embedding-3-large mérite d’être évalué, même si son coût et sa dimension par défaut imposent une réflexion d’infrastructure.
Pour un système existant, la réponse est moins tranchée. Si l’index est massif, les performances satisfaisantes et les seuils métier finement calibrés, rester sur text-embedding-ada-002 peut être parfaitement rationnel. OpenAI n’a pas annoncé sa dépréciation, ce qui laisse de la marge aux équipes qui privilégient la stabilité.
| Situation | Choix le plus probable |
|---|---|
| Nouveau projet RAG standard | text-embedding-3-small |
| Index historique en production | Maintien temporaire de text-embedding-ada-002 ou migration progressive |
| Corpus multilingue | text-embedding-3-small ou text-embedding-3-large |
| Budget de génération très contraint | text-embedding-3-small |
| Qualité documentaire prioritaire | text-embedding-3-large |
| Compatibilité avec un ancien espace vectoriel | text-embedding-ada-002 |
| Besoin de réduire les dimensions nativement | text-embedding-3-small ou text-embedding-3-large |
Un ancien standard qui garde sa place
text-embedding-ada-002 a marqué une étape importante dans l’industrialisation des embeddings. Il a simplifié l’offre d’OpenAI, réduit les coûts de l’époque, rendu la recherche sémantique plus accessible et contribué à installer le RAG comme architecture de référence pour exploiter des corpus privés.
Son rôle a toutefois changé. Il n’est plus le modèle à choisir spontanément pour construire une nouvelle application. Il est devenu un modèle de continuité, précieux lorsque l’on doit maintenir un index existant, préserver des seuils calibrés ou éviter une migration risquée. La règle pratique est assez nette : garder text-embedding-ada-002 pour la stabilité, partir sur text-embedding-3-small pour bâtir aujourd’hui, tester text-embedding-3-large lorsque la précision justifie l’investissement. C’est moins une question de nostalgie technologique qu’un arbitrage entre compatibilité, coût et qualité de récupération.