Ozon : un transformeur dans les suggestions de recherche — honnêtes fractions de pour cent à l'échelle du billion de roubles

• Ozon Tech: генеративный трансформер в поисковых подсказках (архитектура, обучение на событиях, RPS, лимит 300 мс, итерации, риски генерации) — Habr (блог Ozon Tech), n/a
• Как Ozon ускорил расчёт факторов ранжирования динамической компиляцией (трёхуровневый поиск, CPU 15%+ → 5–6%, −10 мс) — Habr (блог Ozon Tech), n/a
• Ozon открыто рассказал об алгоритмах рекомендаций (пресс-брифинг о прозрачности, Алексей Минаев; >1000 признаков, вес персонализации ≈10%) — Телеспутник, 2022-04
• Принцип работы поиска на Ozon (5 шагов ранжирования, до 2000 кандидатов, нейросеть вероятности покупки) — SellerMoon, n/a
• Ozon задумался о создании ИИ-ассистента для помощи в поиске товаров (оценка +3–5% GMV за 1–2 года) — Forbes Russia, n/a
• GMV Ozon по годам (2024 ≈ 2,9 трлн ₽) — Smart-Lab (по отчётности компании), n/a

Contexte

Ozon est l'une des deux plus grandes places de marché de Russie, avec un GMV d'environ 2,9 milliards de roubles en 2024. À cette échelle, la barre de recherche n'est pas une « fonctionnalité du site » mais le principal canal de distribution : une grande part des commandes commence par une requête, et chaque fraction de pour cent de conversion de recherche se mesure en milliards de roubles de chiffre d'affaires.

L'équipe Ozon Tech gère un blog d'ingénierie détaillé sur Habr et — rare pour ce marché — publie non seulement ses architectures de système ML mais aussi les gains de métriques réels, y compris les gains modestes. L'entreprise est inhabituellement ouverte sur les algorithmes en général : en avril 2022, lors d'une conférence de presse sur la transparence des services de recommandation, le vice-directeur général d'Ozon Alexey Minaev a expliqué publiquement le fonctionnement de la recherche et des recommandations de la place de marché — sur fond d'un projet de loi de la Douma d'État sur la réglementation des algorithmes de recommandation. Selon la description officielle de l'entreprise, la sélection des offres et le tri passent par cinq étapes en fractions de seconde (Telesputnik).

Pour l'industrie, cette transparence n'est pas cosmétique. Le marché des cas d'IA au détail est inondé de présentations de fournisseurs vantant des gains de « conversion » à deux chiffres sans méthodologie ; un blog d'ingénierie qui divulgue l'architecture, les contraintes et les gains exacts d'A/B par itération est presque le seul genre par rapport auquel on peut étalonner ses propres attentes.

La recherche d'Ozon est un système multi-niveaux complexe : la couche de base exécute une récupération de texte intégral sur des millions de produits, la couche intermédiaire classe précisément des milliers de candidats sélectionnés, et la couche supérieure applique la personnalisation (Habr, blog Ozon Tech). Plus de mille fonctionnalités participent au classement ; selon le compte public de l'entreprise, la personnalisation pèse environ 10 % (popularité des articles 29 %, ventes 17 %, prix 5 %), les poids étant révisés régulièrement. Ce cas est assemblé à partir de telles sources primaires : il couvre un transformeur génératif dans les suggestions de recherche — et à quoi ressemblent les véritables chiffres d'impact des recommandations lorsque l'équipe d'ingénierie, et non le département marketing, les publie.

Problème

La recherche est le point d'entrée d'achat sur une place de marché. De faibles suggestions signifient un chemin plus long vers le produit et des pages de résultats vides qui tuent la conversion : un utilisateur qui rencontre « rien trouvé » deux fois part chez un concurrent. L'économie des suggestions est simple : la plupart des acheteurs tapent des requêtes sur un téléphone, où chaque caractère supplémentaire est une friction et chaque typo risque une page vide ; une bonne suggestion réduit la frappe à quelques caractères tout en orientant l'utilisateur vers une requête dont les résultats sont garantis non vides.

Les suggestions classiques assemblées à partir d'un dictionnaire de requêtes populaires gèrent mal les spécificités des places de marché : des millions de produits, des noms de marques et des codes SKU, les typos, la translittération (« xiaomi » en trois orthographes), et une longue traîne de requêtes rares où un dictionnaire reste simplement silencieux. C'est exactement la spécificité qu'Ozon Tech cite comme raison du passage à un modèle génératif entraîné sur les données de domaine de la place de marché (Habr).

Les contraintes d'ingénierie sont strictes : les suggestions doivent être servies à des dizaines de milliers de requêtes par seconde dans un budget de 300 millisecondes — sinon l'utilisateur tape la requête plus vite que le système ne peut la suggérer, et toute la valeur de la fonctionnalité s'effondre. Cette contrainte élimine immédiatement les grands modèles de langage avec des milliards de paramètres : à ce trafic, leur inférence dépasse soit le budget de latence, soit exige une flotte GPU inabordable.

Enfin, l'approche générative ajoute sa propre classe de risques que les suggestions de dictionnaire n'ont jamais eu : le modèle peut produire une phrase grammaticalement cassée, un doublon sémantique d'une suggestion voisine, une requête menant à une page de résultats vide, une formulation toxique des données d'entraînement — ou une marque franchement inventée et un produit inexistant. Chacun de ces modes de défaillance devait être fermé par sa propre boucle de post-traitement.

Solution

Ozon Tech a construit un transformeur décoder seul génératif de plusieurs centaines de millions de paramètres, entraîné non pas sur du texte ordinaire mais sur des jetons des actions des utilisateurs.

L'entraînement s'est déroulé en deux étapes. D'abord, le pré-entraînement sur des chaînes d'événements utilisateur — requêtes, clics, filtres, vues de produits ; une seule séquence peut s'étendre sur des mois d'interactions d'un utilisateur avec la place de marché. Ensuite, l'ajustement sur la tâche cible : générer une suggestion à partir du contexte de session et du préfixe tapé. Cette approche permet au modèle de « connaître » les marques, les SKU, les typos et la translittération à partir du comportement réel des acheteurs plutôt que d'un corpus externe (Habr, blog Ozon Tech).

L'inférence s'exécute sur un cluster GPU via TensorRT-LLM, sustaining dizaines de milliers de requêtes par seconde dans le budget de 300 ms. Les candidats sont générés avec une recherche par faisceau — le modèle suit plusieurs variantes de continuation simultanément et choisit la meilleure, ce qui donne une liste de suggestions diverse plutôt qu'une réponse « la plus probable ». Les candidats sont ensuite post-traités : déduplication, filtrage des formulations interdites, et vérification que la suggestion ne mène pas à une page de résultats vide. Cette « tuyauterie ennuyeuse » est ce qui ferme les risques spécifiques de l'approche générative — des erreurs de grammaire aux marques inventées : un produit généré mais inexistant est coupé à la vérification des résultats non vides avant d'atteindre l'utilisateur.

Le chemin de la requête est également documenté. La suggestion choisie entre dans le pipeline de recherche : le système recueille des candidats par mots-clés et synonymes, sélectionne jusqu'à 2 000 éléments pertinents, un réseau neuronal évalue la probabilité d'achat de chacun de 0 à 1, puis des boosts et des de-boosts s'appliquent — et ce n'est qu'alors que l'utilisateur voit les résultats ; selon les écrits de l'industrie, tout le pipeline tient en fractions de seconde (SellerMoon). La suggestion est ainsi le premier filtre d'un immense entonnoir, et sa qualité définit la qualité des données entrantes pour chaque étape suivante.

Le déploiement s'est déroulé en itérations avec mesure A/B à chacune — et la séquence elle-même est instructive. Itération un — génération de base de courtes suggestions : +10% CTR de suggestion ; le modèle a simplement commencé à couvrir les requêtes où le suggester de dictionnaire restait silencieux. Itération deux — suggestions multi-mots avec des fragments plus longs : encore +10% ; les utilisateurs ont commencé à voir une requête complètement formée plutôt que simplement « TV ». Itération trois — traitement des typos : encore +3% CTR, une baisse de 3% des pages de résultats vides, et +0,3% dans la part des utilisateurs terminant une session avec une commande — la première fois que l'effet a atteint la métrique commerciale finale. L'équipe énonce l'observation clé de ces itérations directement : la CTR croît plus facilement que les métriques commerciales — la cliquabilité des suggestions peut être soulevée rapidement, tandis que transporter l'effet jusqu'à une commande est beaucoup plus difficile.

Les suggestions ne sont que la partie visible de la pile de recherche. Dans le même blog, Ozon Tech décrit la machinerie de classement : un système à trois niveaux (récupération de texte intégral sur des millions de produits → classement précis de milliers de candidats → personnalisation) avec des milliers de facteurs de classement profondément imbriqués. Lorsque l'interprétation récursive des formules de facteurs a commencé à consommer plus de 15 % du CPU de l'ensemble du service, l'équipe a écrit un compilateur générant du bytecode JVM au moment de l'exécution : la consommation de CPU a chuté à 5–6 % et le temps total de requête a diminué de 10 millisecondes. Les écrits de l'industrie complètent le tableau : jusqu'à 2 000 éléments candidats sont sélectionnés, un réseau neuronal évalue la probabilité d'achat de chacun de 0 à 1, puis des boosts et des de-boosts s'appliquent (SellerMoon). Gardez cela à l'esprit lors de la lecture du « +10% CTR » : derrière chaque pour cent se trouve une infrastructure où 10 millisecondes est une victoire visible.

Résultat

Gains publiés par itération : CTR de suggestion de recherche +10%, puis encore +10% et +3% ; la part des pages de résultats vides a chuté de 3% ; la part des utilisateurs terminant une session avec une commande a augmenté de 0,3%. Chaque chiffre provient d'une expérience A/B sur le trafic en direct et a été publié par l'équipe elle-même dans son blog d'ingénierie — avec l'admission honnête que la cliquabilité croît plus facilement que la conversion des commandes.

Modeste à première vue — mais à des milliards de roubles en GMV, les fractions de pour cent représentent un effet commercial matériel, et voilà à quoi ressemblent les véritables chiffres des systèmes de recommandation. Un résultat supplémentaire, moins visible, est l'infrastructure : la compilation dynamique des formules de classement a réduit de près d'un tiers la consommation de CPU du service de recherche (de 15%+ à 5–6%) et a économisé 10 ms du temps de requête — à des dizaines de milliers de RPS, c'est à la fois une économie de matériel et une contribution directe à la vitesse des résultats.

Encadrage de crédibilité : tous les chiffres sont des chiffres auto-déclarés de l'entreprise sans audit indépendant. Mais il s'agit d'une auto-déclaration d'un type particulier — publiée par des ingénieurs avec la méthodologie A/B décrite et les points faibles admis (rendements décroissants, l'écart CTR-commande), ce qui réduit considérablement le risque d'embellissement marketing. Séparément (une prévision, pas un résultat) : selon une estimation citée par Forbes, un futur assistant de recherche IA pourrait ajouter 3–5% GMV pour Ozon dans un à deux ans. Cette estimation ne doit pas être confondue avec le +0,3% mesuré — ce sont des genres de chiffres différents.

À notre avis, la principale valeur du cas est l'étalonnage. Il établit un repère pour le marché d'un rapport honnête : la séquence +10% → +10% → +3% montre non seulement l'effet mais aussi sa décroissance, et la métrique « +0,3% utilisateurs avec une commande » montre combien est coûteuse chaque fraction de pour cent sur un produit mature. Quand un fournisseur ou un intégrateur promet « +15% conversion d'IA en recherche », ce cas est un mètre-étalon prêt à l'emploi : l'une des plus fortes équipes ML du pays, avec son propre cluster GPU et un GMV de milliards de roubles, documente un effet d'un ordre de magnitude plus modeste.

La deuxième observation est architecturale : à notre avis, choisir un modèle de centaines de millions de paramètres plutôt qu'un « multi-billion LLM » à la mode, c'est exactement ce qu'est la maturité d'ingénierie. Ozon a choisi l'architecture minimale qui résout la tâche dans un budget de latence dur, plutôt que celle maximale qui la résoudrait dans un diaporama.

Leçons

1. Les véritables gains des recommandeurs se mesurent en fractions et en pour cents simples : +0,3% utilisateurs avec une commande à l'échelle d'Ozon est une victoire, tandis que « +14% GMV de personnalisation » est un signal d'alerte de fabrication.
2. La latence dicte l'architecture : un budget de 300 ms à des dizaines de milliers de RPS impose à la fois la taille du modèle (centaines de millions de paramètres, pas des milliards) et la pile d'inférence (TensorRT-LLM).
3. Le déploiement itératif avec mesure à chaque étape (+10% → +10% → +3%) est plus honnête qu'une seule grande sortie : vous voyez à la fois l'effet et ses rendements décroissants.
4. La CTR croît plus facilement que les métriques commerciales : la cliquabilité des suggestions augmente rapidement, tandis que transporter l'effet jusqu'à une commande est un travail séparé et plus difficile (observation propre d'Ozon Tech).
5. Les suggestions génératives apportent de nouvelles classes de risques — grammaire cassée, doublons, formulations toxiques, marques inventées, suggestions dans les résultats vides — et ne doivent pas être livrées sans une boucle de post-traitement.
6. La personnalisation ne représente que ≈10% du poids de classement d'Ozon : les signaux de base (popularité, ventes, prix) décident toujours plus.
7. Publier des chiffres modestes signale la maturité de la culture d'ingénierie : on peut faire confiance à ces sources pour le reste aussi.

Questions fréquentes