En 2016, notre équipe a créé un outil de recherche de domaines premium conçu pour trouver instantanément, au fil de la saisie, des domaines similaires sur le marché secondaire. Nous avons utilisé les embeddings fastText avec l’indexation Annoy de Spotify pour alimenter une recherche sémantique en moins de 10 ms.
Contrairement aux outils de recherche de domaines classiques qui vérifient simplement la disponibilité, le nôtre tentait de comprendre l’intention de l’utilisateur. Lorsqu’un utilisateur recherche « instantdomainsearch.com », notre index trouve des domaines sémantiquement similaires :
- domaininstant.com
- fastdomainsearch.com
- searchdomain.com
Les limites de fastText : le contexte propre aux domaines
fastText a appris sa compréhension sémantique à partir de milliards de mots issus de Common Crawl et de Wikipédia. Mais les domaines représentent des entreprises et des marques, qui adoptent souvent les mots différemment du texte général du Web.
Prenons « mint » comme exemple ci-dessous. Même si fastText reconnaît ses deux sens, il attribue des scores de similarité bien plus élevés aux termes liés aux plantes et aux herbes. Dans le monde des domaines et des entreprises, « mint » est plus couramment associé à l’argent (par exemple Mint.com). Ce schéma se répétait pour de nombreux termes (par exemple Cloud, Spark).
| Mot associé | Similarité fastText avec « mint » | Contexte |
|---|---|---|
peppermint | 0.64 (élevée) | Plante/herbe |
| herb | 0.49 | Plante/herbe |
money | 0.37 | Argent/finance |
finance | 0.29 | Argent/finance |
budget | 0.27 (faible) | Argent/finance |
Nous avons compris qu’il ne s’agissait pas d’une limite de fastText : les noms de domaine avaient plutôt développé leur propre sens sémantique.
Cela nous a posé un défi : comment donner à notre modèle un contexte propre aux domaines ?
Pourquoi ne pas simplement utiliser l’IA ?
Les LLM modernes comprennent remarquablement bien le contexte. Lorsque nous avons testé GPT-4 pour suggérer des domaines similaires, il saisissait clairement les sens attendus par les utilisateurs.
Avec un court prompt fournissant le contexte des domaines, il comprenait que « cloud » désigne aussi le cloud computing, que « mint » renvoie à la finance et que « spark » désigne l’analytique de données. Il suggérait des domaines correspondant à ce que les acheteurs veulent réellement, et pas seulement à des variations textuelles.
Mais un obstacle majeur subsistait : la latence. Notre système fastText renvoie les résultats en moins de 10 ms. GPT-4 atteignait 1,7 seconde en moyenne (85× plus lent). Pour un outil dont les utilisateurs attendent des résultats au fil de leur saisie, attendre plus d’une seconde à chaque frappe détruirait l’expérience utilisateur.
Les modèles d’embeddings : des mots aux concepts
Nous avons donc eu l’idée suivante : au lieu d’exécuter des LLM en temps réel, nous pouvions les utiliser hors ligne pour entraîner notre propre modèle d’embeddings rapide. Ainsi, son contexte ne serait pas celui du Web général, mais celui de notre cas d’usage : les domaines.
Voici les différences concrètes :
Approche fastText (compréhension sémantique générale) :
- Utilise 2 millions de vecteurs de mots entraînés sur Common Crawl (2017)
- Comprend les relations entre les mots selon leur usage dans le texte Web
- « searchengine » = signification sémantique issue de millions de phrases
- Excellent pour la compréhension générale du langage
Notre approche améliorée (sémantique propre aux domaines) :
- Traite chaque mot et expression comme un concept d’entreprise
- « searchengine » = « Une plateforme de recherche et de découverte sur le Web »
- Ajoute un contexte propre aux domaines que fastText n’a jamais vu
- S’appuie sur les fondations de fastText avec des techniques modernes
Pour y parvenir, nous avons utilisé sentence-transformers, une bibliothèque Python qui prend en charge des modèles d’embeddings plus modernes, conçus pour la recherche sémantique et ajustables à notre cas d’usage précis. Le paysage de l’IA a considérablement évolué depuis 2017, ce qui facilite beaucoup la création de modèles spécialisés. Nous avons utilisé GPT-4 pour générer par lots des millions d’exemples d’entraînement propres aux domaines. Nous avons ensuite ajusté ces nouveaux modèles afin qu’ils comprennent les domaines comme les domainers.
La mise en œuvre a nécessité cinq étapes : générer les données d’entraînement, calculer les similarités, structurer les données pour l’entraînement, ajuster le modèle, puis optimiser sa vitesse en production.
Étape 1 : utiliser GPT-4 pour générer des descriptions de domaines
Nous avons découvert que GPT-4 excelle à développer des mots isolés en descriptions contextuelles riches. À partir d’un simple nom de domaine, il pouvait déduire des cas d’usage potentiels, des secteurs associés et des liens sémantiques.
| Domaine | Description générée par GPT-4 | Mots-clés extraits |
|---|---|---|
| torontopancakes.com | Un nom charmant qui associe le caractère de Toronto à l’amour des pancakes, idéal pour les amateurs de petit-déjeuner et les explorateurs urbains. | food, breakfast, pancakes, maple syrup, Canada, Toronto, brunch, treats, sweet, delicious, local, community |
| matchupitchutours.com | Un nom orienté voyage inspiré de Machu Picchu, proposant des visites guidées et des aventures inoubliables dans les Andes. | travel, tours, adventure, Peru, Machu Picchu, history, culture, nature, explore, hiking, mountains, guide |
| frankenbergerschokolade.com | Un nom riche et gourmand mêlant le charme de l’héritage allemand à la douceur du chocolat, parfait pour les friandises et confiseries haut de gamme. | chocolate, gourmet, sweets, German, heritage, desserts, artisan, cocoa, indulgence, handmade, treats, premium |
La génération de descriptions pour une partie de notre inventaire nous a fourni des données d’entraînement étiquetées qui capturaient la sémantique des domaines.
Étape 2 : transformer les descriptions en scores de similarité
Avec une description pour chaque domaine, nous pouvions mesurer la similarité sémantique à l’aide de modèles d’embeddings existants. Cela nous a donné des données de référence sur les domaines qui devaient être considérés comme liés :
| Paire de domaines | Score de similarité | Type de relation |
|---|---|---|
| google.com ↔ searchengine.com | 0.68588746 | Même catégorie |
| cloudeous.com ↔ cloudivio.com | 0.82812774 | Concept similaire |
| omnigenics.com ↔ omniparent.com | 0.66224474 | Préfixe commun seulement |
| xaute.com ↔ paveup.com | 0.50881153 | Sans rapport |
Ces scores de similarité sont devenus nos cibles d’entraînement. Ils indiquaient à notre modèle quels domaines devaient être proches ou éloignés dans l’espace des embeddings.
Étape 3 : créer des triplets d’entraînement pour l’ajustement
L’entraînement avec la perte triplet exige des données en groupes de trois : un domaine d’ancrage, une correspondance positive (similaire) et une correspondance négative (différente). Nous avons généré des milliers de ces triplets à partir de nos calculs de similarité :
| Domaine d’ancrage | Correspondance positive (similaire) | Correspondance négative (différente) |
|---|---|---|
| google.com | searchengine.com (0.6858) | flowershop.com (0.2754) |
| uber.com | rideshare.com (0.7139) | cookbook.net (0.2201) |
| shopify.com | ecommerce.com (0.6064) | weatherapp.org (0.2656) |
Cette structure force le modèle à apprendre des similarités relatives plutôt que des classifications absolues.
Étape 4 : entraîner notre modèle d’embeddings propre aux domaines
Nous avons sélectionné all-MiniLM-L6-v2 comme modèle de base, en utilisant all-mpnet-base-v2 comme fournisseur d’embeddings initial. Il équilibre performances et taille. Avec la perte triplet, nous l’avons entraîné à reproduire la compréhension sémantique de GPT-4 :
| Indicateur d’entraînement | Valeur |
|---|---|
| Modèle de base | all-MiniLM-L6-v2 |
| Échantillons d’entraînement | 500,000 |
| Époques | 25 |
| Corrélation finale avec GPT-4 | ~0.87 |
La corrélation de 0,87 signifiait que notre modèle léger capturait l’essentiel de la compréhension sémantique de GPT-4 tout en s’exécutant plusieurs ordres de grandeur plus vite.
Étape 5 : optimiser de ~500 ms à 10 ms
La première version de cette nouvelle pile a été mise en œuvre en Python afin de tester certaines hypothèses. Nous avons utilisé des bibliothèques courantes comme usearch pour HNSW et SQLite pour refaire le lien avec le domaine. Cela a montré que nous allions dans la bonne direction, avec des résultats prometteurs autour de ~500 ms dans la plupart des cas. Entraîner un bon modèle ne résolvait que la moitié du problème. Il nous fallait encore une latence inférieure à 50 ms !
La plus grande partie de notre pile technique est déjà écrite en Rust. Nous avons donc décidé d’y porter aussi ces modèles plus récents. Pour éviter des dépendances lourdes et parce que Torch n’est pas le plus rapide pour l’inférence, nous avons choisi ONNX Runtime.
- Format du modèle : ONNX (3× plus rapide que PyTorch)
- Runtime : Rust + ort (surcharge minimale, excellentes performances CPU)
- Index : HNSW pour un ensemble limité d’environ 25 M de domaines du marché secondaire
- Matériel : CPU uniquement (pas de surcharge de coordination GPU)
- Optimisations : sortie optimisée quantifiée (optimum)
Résultat : une latence au 95e percentile de 10 ms, dans notre objectif de 25 ms. Cette vitesse est essentielle pour préserver l’expérience de recherche instantanée que nous avons optimisée grâce à notre infrastructure CDN.
L’IA en développement et en production
« Alimenté par l’IA » devient souvent un raccourci pour désigner l’intégration d’un LLM dans chaque chemin de requête, mais son emplacement est un choix de conception avec des compromis distincts.
- En développement : moins de contexte, vitesses supérieures
- En production : plus de contexte, vitesses inférieures
Notre recherche instantanée montre jusqu’où la première approche peut aller : nous avons distillé les connaissances de GPT‑4, qui compte mille milliards de paramètres, dans un modèle d’embeddings de 22,7 M de paramètres, qui renvoie des résultats sémantiques en moins de 10 ms (sans compter la distance entre l’utilisateur et nos serveurs).
À l’inverse, notre générateur de noms d’entreprise montre où un LLM en direct prend l’avantage : la recherche d’idées de marque demande un raisonnement frais et étendu ; nous échangeons donc la vitesse contre la profondeur et fournissons des suggestions qui nécessitent réellement le contexte de plus de mille milliards de paramètres.
Cela ne veut pas dire que les LLM en développement sont meilleurs que les LLM en production. Il s’agit d’adapter la profondeur de contexte au coût de la latence.
Nous prévoyons de déployer notre nouveau modèle au cours du mois prochain.