EN
IntroductionGenèse du projetArchitecture globaleIdentification des objetsLLM en productionDétection des contrefaçons
← DealTracker

DealTracker - Enrichissement des annonces

Cette page décrit le composant que j'ai mis en place qui est responsable de l'enrichissement des annonces. Ce que j'appelle "enrichissement", c'est le fait d'ajouter aux annonces de nouvelles informations issues de l'intelligence de notre système.

Voici les opérations réalisées par ce système:

Schéma du pipeline d'enrichissement : les annonces non enrichies traversent six étapes — téléchargement et normalisation des images (récupérées en parallèle), classification du produit par les modèles de vision du labo (une annonce à la fois), détection de contrefaçon sur quelques produits suivis (tri par un LLM puis modèle supervisé), filtrage des annonces non pertinentes par règles puis par LLM, calcul de l'attractivité en comparant le prix demandé au prix usuel, écriture en base lue par l'API — puis ressortent enrichies ; chaque source d'intelligence a sa couleur et son symbole : les modèles du labo IA (bleu), le LLM multimodal (ambre), les prix usuels par produit (violet)

Après avoir optimisé la structure de ce pipeline et son usage de ressources hardware, le débit du pipeline est d'environs 450 annonces par minutes sur une RTX 5060 Ti.

Le pipeline

Le pipeline d'inférence traite les annonces en continu via une architecture asynchrone à plusieurs étapes:

J'ai voulu m'assurer que DealTracker soit en mesure de gérer n'importe quelle volumétrie. J'ai donc optimisé ce process en maximisant son débit de traitement, et en m'assurant qu'il soit scalable.

Concernant le débit de traitement, le plus important est de mettre en place un pipeline de traitement asynchrone. C'est à dire que les tâches ne sont pas traitées séquentiellement, elles sont orchestrées par Taskiq (un équivalent de Celery/Dramatiq avec asyncio). Le bottleneck du système c'est le modèle PyTorch, qui occupe 4Go de VRAM, et est capable de traiter environs 450 annonces par minutes sur ma RTX 3060Ti.

Concernant la scalabilité de ce pipeline, cela est naturellement permis par taskiq, puisque les tâches ne gardent pas d'état, et sont découplées. Il est possible de rajouter des capacités hardware pour gérer chacune des tâches, ce qui signifie que le système est aussi capable que le hardware sur lequel il est déployé.

Le filtrage des annonces non-pertinentes via LLM

Il y a beaucoup d'annonces qui montrent un objet dans leurs images, mais ne le vendent pas, ou pas seul. Voici la liste de tous les scénarios que j'ai identifiés:

  • La personne vend une sous-partie de l'objet (comme par exemple un accoudoir de chaise)
  • La personne vend un objet lié (comme par exemple un livre de recettes "Thermomix" ou une boîte vide)
  • La personne loue l'objet ou un service associé
  • La personne recherche l'objet
  • La personne vend une copie
  • La personne n'a pas mis le vrai prix attendu, et demande à ce que l'acheteur fasse une offre
  • La personne vend bien l'objet, mais en lot avec d'autres objets (par exemple une chaise vendue avec un bureau)

Au départ, je détectais ces scénarios en identifiant des mots-clés dans les noms des annonces et leurs descriptions. Cela fonctionnait d'une manière correcte, mais il y avait toujours des annonces qui passaient entre les mailles du filet et ça demandait un certain effort à maintenir.

Par la suite, les LLMs se sont montrés tout à fait capables pour cette tâche, et depuis quelques temps il est devenu possible d'héberger des LLMs chez soi sur son propre matériel. J'ai donc fait évoluer ma logique et commencé à utiliser un LLM pour cette détection: Gemma 4 26BA4B hébergé sur ma RTX 3090.