Le 20 mars 2025 s’est déroulée l’édition 2025 de Dataquitaine, un événement dédié à la Data et à l’IA sur Bordeaux. Cet article, écrit par la team Ippon Data Bordeaux, a pour but de vous présenter quelques conférences auxquelles nous avons assisté. 

Article co-écrit par Théophile Cathelineau, Mathis Le Gall, Mateo Lopez.

Sommaire

• Au coeur des moteurs de recherche et de recommandation : le pouvoir du ranking 
• Transformer vos métriques systèmes en indicateurs énergétiques avec le Rating-Operator
• Retour d’expérience d’une migration totale vers dbt : deux ans après

Au cœur des moteurs de recherche et de recommandation : le pouvoir du ranking

Présentateur : Pierre Legault, Senior Data Scientist chez Malt, leader européen du freelancing.

Durée de la conférence : 30 minutes.

TL,DR:

• détermination d’un système de ranking adapté,
• mode d’entraînement du modèle,
• amélioration de la qualité du jeu de données pour l'entraînement.

Au cours de cette demi-heure, Pierre nous démontre que Machine Learning ne rime pas uniquement avec classification et régression. En effet, il nous a présenté le sujet du Ranking, qui est un aspect du machine learning au cœur de la stratégie de Malt.

Malt étant le leader européen du freelancing, la qualité de son service repose en grande partie sur la pertinence de son ranking, qui est déterminant aussi bien pour les clients que les freelancers.

L’aspect très didactique de cette intervention repose sur le fait que, pour chaque étape du processus de détermination du modèle de ranking, un benchmark des solutions existantes était avancé, pour finalement justifier celles qui étaient conservées. 

Le premier point abordé a donc été le choix d’une métrique de ranking pertinente.

Pour évaluer la pertinence du modèle de ranking, Malt a comparé l’utilisation de 5 indicateurs :

• Mean Reciprocal Rank (MRR): position du premier élément pertinent dans la liste des résultats,
• Précision-based: proportion d'éléments pertinents dans le top 5 des résultats,
• Hit Rate: proportion de requêtes pour lesquelles au moins un freelance pertinent apparaît dans les résultats,
• Pertinence pondérée : pondération attribuée en fonction de la pertinence des profils, ce qui permet d’affiner le ranking en fonction de leur qualité,
• DCG (Discounted Cumulative Gain) et NDCG (Normalized DCG) : ordonnancement précis des résultats en prenant en compte leur position et pertinence.

Finalement, deux métriques ont été retenues :

• la Precision-based, qui se concentre sur la proportion d'éléments pertinents dans le top 5 des résultats,
• le Hit Rate, qui mesure sur la proportion de requêtes pour lesquelles au moins un freelance pertinent doit apparaître dans le top K des éléments en tête du ranking.

Une fois que les métrique de ranking ont été décidées, vient le sujet de l’entraînement des modèles.

Pour ce sujet, un compromis a dû être trouvé entre deux approches opposées :

• L’approche Pointwise, un modèle qui labellise les éléments. Cette dernière est économique mais manque de précision,
• Le modèle Listwise, lui, consiste à la construction de l'ordre “parfait” élément par élément et a contrario très précis mais très gourmand en ressource et nécessitant un data-set suffisamment qualitatif pour être entraîné efficacement.

C’est donc finalement une approche ‘Pairwise’, comparant un élément par élément et de complexité O(N²) qui va être conservé, un bon compromis entre performance et faisabilité.

Il a ensuite été abordé le sujet de la précision de l’étiquetage des données car, assez logiquement, la qualité du jeu de données est un grand facteur de réussite dans la détermination du système de ranking le plus adapté aux besoins de l’entreprise. Pour cela, Malt se repose sur une combinaison de données implicites, telles que les actions des utilisateurs (clic, temps passé sur les profils, etc….)  et synthétiques (par l’utilisation de LLM pour générer des données et annotations).

Enfin, il a aussi été ajouté des bad cases (ici, des profils hors scope de recherche) pour tester le système dans des situations limites et ses techniques de debiasing.

Puisque le sujet de l’utilisation d’un LLM a été abordé, l’architecture des modèles a aussi été discutée, notamment les sujets des avantages d’utilisation entre un réseau neural ou non-neural, ou bien encore les algorithmes utilisés (dans ce cas XGBoost et LightGBM).

Finalement, une nuance est apportée vis-à-vis du fait qu’une évaluation hors-ligne implique le risque de plusieurs biais pouvant altérer l'entraînement du modèle propre au cas d'usage de Malt (esthétique des profils, cas des profils non affichés, métriques manquantes etc…).

En résumé, cette présentation nous permet, au travers d’un contexte concret, de comprendre la méthodologie utilisée par une entreprise de grande envergure pour déterminer le meilleur système de ranking pour ses besoins. Trois enseignements clés semblent ressortir de ce retour d’expérience :

• Définir au préalable les moyens de mesures,
•  Déterminer le modèle LLM le plus adapté aux besoins de l’entreprise,
• Apporter un point d'intérêt, aux possibles biais lors de l'entraînement du modèle.

Le format de cette conférence m’a semblé particulièrement adapté à la diversité des profils présents. Grâce à différents benchmarks et slides épurées et pertinentes, chacun y trouve son compte.

Transformer vos métriques systèmes en indicateurs énergétiques (kWh, CO2…) avec le Rating-Operator

Dans cette conférence, Jonathan Rivalan responsable de R&D chez Smile, a présenté le Rating Operator, une solution développée pour répondre aux défis liés à la gestion et à l’exploitation des métriques système dans des environnements cloud et Kubernetes dans le cadre du projet européen 6Green. La présentation s’est déroulée en 3 parties : le contexte actuel, la solution proposée via une présentation concise de l’outil et l’analyse des indicateurs obtenus.

Le contexte est simple : la consommation énergétique des infrastructures IT génèrent une quantité massive de métriques provenant de différents niveaux :

• Serveurs physiques (CPU, mémoire…),
• Systèmes d’exploitation (OS),
• Machines virtuelles (VM),
• Microservices (composés de conteneurs, eux-mêmes hébergés sur des VM, etc.).

Et plusieurs problématiques émergent :

• Disponibilité et fiabilité des données : les métriques énergétiques ne sont pas toujours accessibles au niveau BIOS et peuvent être inexactes au niveau des microservices.
• Modélisation de l’équivalence énergétique :
  • Déterminer la bonne formule de calcul
  • Implémenter un langage de requêtage adapté
  • Prendre en compte les variations selon les types de serveurs, VM, etc.

Ce volume important de données pose des défis en matière de stockage, d’affichage et d’analyse. 

Pour gérer cette complexité, Smile propose le Rating Operator, un opérateur Kubernetes permettant :

• l’agrégation et la réconciliation des métriques hétérogènes issues de différentes sources,
• le lien entre les opérations IT et les enjeux business, notamment en facilitant l’analyse des coûts et de l’efficacité énergétique à travers des KPI.

L’outil propose alors une approche permettant de factoriser les données dans une base temporelle (TSDB) et d’adapter les calculs en fonction de la configuration des infrastructures :

• Les métriques sont collectées à partir de différentes sources :
  • Des sondes spécialisées comme Scaphandre ou Kepler,
  • Le BIOS des machines,
  • Des fournisseurs cloud (GCP, AWS…).
• L’outil ajuste simplement des variables spécifiques aux différents environnements pour estimer la consommation énergétique.

Il n’est pas complètement rentré dans les détails du développement et du fonctionnement de l’outil car celui-ci est disponible en open source (https://github.com/Smile-SA/rating-operator). 

Il a ensuite basculé sur la partie analyse et visualisation des résultats. Et pour celle-ci, Smile a développé X-BI, un dashboard permettant d’exploiter les métriques agrégées en indicateurs également disponible en open source (https://github.com/Smile-SA/x-bi). 

L’objectif final est de proposer notamment une corrélation entre les coûts d’infrastructure et la consommation énergétique en proposant un équivalent entre pricing et consommation énergétique, facilitant ainsi :

• Une meilleure optimisation des ressources,
• Une prise de décision éclairée pour les entreprises utilisant des services cloud.

En résumé, avec l’outil Rating Operator, Smile propose une solution innovante pour la gestion des métriques dans le cloud, permettant non seulement d’optimiser les performances IT, mais aussi de transformer ces métriques en KPI afin de répondre aux enjeux environnementaux liés à la consommation énergétique avec l’appui de leur propre solution de dashboarding X-BI pour l’analyse des indicateurs obtenus.

Retour d’expérience d’une migration totale vers dbt : deux ans après

Présentateur : Jean-Christophe Bianic, Head of Data chez Libon.

Durée de la conférence : 30 minutes.

TL;DR : 

• présentation de la migration des pipelines SQL historiques vers dbt,
• les raisons de cette transformation,
• état des lieux actuel post-migration.

Architecture historique :

• source : application, outil de support, outils marketing (10M lignes/jour),
• data loader : Airbyte,
• data warehouse : BigQuery,
• data transformation : Script Python (SQL) + Airflow,
• data visualisation : Tableau.

En utilisant des scripts Python, l’équipe devait gérer elle même le DML pour créer et mettre à jour les tables/vues, ce qui représentait plusieurs désavantages :

• reviews souvent longues et complexes,
• erreur la plus fréquente lors de problèmes dans les pipelines de données,
• investigations chronophages.

Ces étapes sont gérées nativement par dbt via la matérialisation dans la configuration des modèles et c’est donc la raison principale qui a décidé l’équipe pour la migration. Ceci a permis à l’équipe de gagner en simplicité et donc en vélocité lors des phases de développement de ses pipelines, en n’ayant plus qu’à se concentrer sur la partie transformation de données. De plus, l’équipe a profité des tests facilités par dbt afin de résoudre ses problèmes de fiabilité de la donnée et en assurer une meilleure qualité dans ses produits data finaux.

Pour cette migration, l’équipe a mis en place du double run sur leur existant ainsi que des tests d’équivalence qui, bien que chronophages, se sont améliorés et industrialisés au fur et à mesure de la transformation.

L’équipe a également intégré dbt avec Airflow, en développant un module qui crée une tâche par modèle dans leurs DAG afin de lancer des modèles unitairement, notamment lors de problèmes dans les flux de données. Cette intégration permet d’investiguer facilement le flux de données en cas d’erreurs, mais aussi de le relancer à partir du modèle bloquant après résolution du problème.

 Des tests ont pu être facilement mis en place grâce à dbt ; avec un choix de tester uniquement les features qui ont déjà posé problème, afin de limiter les coûts.

Néanmoins, il reste beaucoup de features dbt à mettre en place maintenant que leur transformation est terminée, comme par exemple les packages ou encore les exposures qui seraient intéressants afin de suivre facilement l’exposition des données qui est faite pour leur dashboards Tableau.

En ce qui concerne l’aspect finops, les coûts ont augmenté lors de la migration, ce qui peut paraître contre intuitif mais qui s’explique par le double run qui a multiplié les coûts. De plus, la facilité à développer des modèles a eu pour conséquence d’augmenter le nombre de tables dans le warehouse et a donc aussi augmenté les coûts; bien que pour moi celui-ci serait arrivé plus tard même sans migration et est donc un point positif finalement. Enfin, l’équipe a mis en place du monitoring, ce que dbt facilite (tag des requêtes, UID des jobs, artifacts, etc), afin d’évaluer les coûts et pouvoir trouver et optimiser les requêtes qui sont les plus coûteuses.

En conclusion, cette conférence est pour moi un bel exemple de pourquoi dbt fait partie de la modern data stack. En effet, à travers ce retour d’expérience, on constate que l’équipe a gagné en vélocité dans son développement de pipelines, tout en ajoutant facilement des tests, du monitoring et en supprimant un de ses pain points majeurs grâce aux possibilités offertes par dbt.