Évaluation : comment améliorer une solution à base d’IA générative sans dégrader ses performances (retour d’expérience)

Au début, dans la conception de nos solutions à base de modèles d’IA générative, on a fait comme tout le monde. 

On changeait un prompt.
 
On branchait un nouveau modèle. 
On modifiait une règle. 
Puis on testait sur 2–3 exemples. 

Et on se disait : “ok, ça a l’air mieux”. 

Finalement : ça ne l’était pas toujours. 

Dans cet article, on vous partage notre retour d’expérience sur la mise en place d’un workflow d’évaluation IA, conçu pour mesurer la qualité d’un modèle génératif (LLM) dans le temps. 

Pourquoi nos optimisations n’étaient pas toujours des améliorations 

Sur notre solution Product Assistant Manager (notre assistant de génération de descriptions produits), nous avons enchaîné les optimisations : 

  • améliorer le ton
  • éviter les hallucinations
  • mieux structurer les contenus 
  • ajouter des règles SEO  

Chaque itération améliorait un aspect… mais en dégradait parfois un autre. 
Un prompt plus précis → moins d’erreurs, mais un texte plus rigide 
Des « guardrails » plus stricts → moins d’hallucinations, mais moins de richesse 

Surtout, il nous était impossible de mesurer l’impact réel de nos changements ou la performance des modèles LLM utilisés. 
Nous restions sur des ressentis et des impressions. 

Se poser les bonnes questions 

À un moment, on s’est posé une question simple : Comment sait-on que la version générée par notre solution aujourd’hui est meilleure que celle d’hier ? 

Et la réponse honnête, c’était : “on ne sait pas vraiment”. 

C’est là qu’on a décidé de structurer un vrai workflow d’évaluation. 

Ce qu’on a mis en place 

L’objectif était simple : mettre en place un système de mesure de la qualité au fil de nos optimisations. 
Vérifier si l’on améliorait ou si l’on dégradait les résultats.

1. Un dataset de référence

Nous avons constitué un dataset de référence avec : 

  • de vraies données produits (inputs métier) 
  • des descriptions validées par le métier (outputs attendus)  

Et on a isolé un jeu de test qu’on ne touche jamais. 
C’est notre point de comparaison stable (la “ground truth”). 

2. Trois métriques pertinentes

On a choisi seulement 3 métriques, parce qu’elles couvrent efficacement notre besoin d’observer la qualité au fil des évolutions. 

Fidélité 

Est-ce que le modèle raconte n’importe quoi ?
Concrètement : chaque info générée est vérifiée, et si elle n’est pas dans la source (input) → alors c’est une hallucination (cela permet d’éviter les erreurs factuelles). 

Exemple d’hallucination :  
Attendu :Pantalon large” → Généré : Pantalon à pinces 

Similarité sémantique  

Est-ce que le texte généré “dit la même chose” que le résultat attendu ? 
Pas mot pour mot, mais dans le sens. Cela permet de garder de la flexibilité rédactionnelle sans perdre en qualité. 

Exemple de similarité sémantique :
Attendu : T-shirt en coton respirant, idéal pour les journées chaudes 
–> Généré : T-shirt léger en coton, parfait par temps chaud 

Pertinence

Est-ce que la description générée est vraiment pertinente par rapport aux données sources et aux caractéristiques du produit ? 
L’objectif est de vérifier qu’il ne manque pas d’éléments clés par rapport aux données sources. Parce qu’un texte peut être correct et bien écrit… mais incomplet, donc insuffisant pour décrire correctement le produit. 

 Exemple « non-pertinent » : 
Attendu : Veste imperméable respirante avec capuche, conçue pour la randonnée 
–> Généré : Veste imperméable avec capuche, idéale pour un usage quotidien 

Comparer pour décider 

À chaque modification (prompt, modèle, règle) de la solution, on lance le workflow d’évaluation pour vérifier si nos résultats générés sont stables. 
On compare version N vs version N+1 avec des métriques précises, et non plus au ressenti ou au feeling. 

Notre règle selon les résultats 

On a volontairement évité de complexifier. 

  • Si les 3 métriques montent → on valide nos modifications
  • Si ça baisse → on conserve les précédents paramétrages  
  • Si c’est mitigé → on regarde dans le détail  

Ce que nous avons observé 

Dans la pratique, ce framework nous a permis de mieux comprendre les effets réels de nos évolutions. 

Sur la similarité sémantique, nous avons observé une amélioration pouvant atteindre,+25% au fil des itérations
 
Concernant, la pertinence, les gains se situent généralement entre +10% et +15% 
En revanche, la fidélité a parfois légèrement baissé (-5%) par rapport au modèle de référence 

En effet un modèle très conservateur fait peu d’erreurs… mais produit aussi des contenus moins riches. 
Tout l’enjeu est donc de trouver le bon équilibre entre fidélité et créativité. 

Ce que ça a changé concrètement 

On a arrêté de juger au feeling → on mesure, on compare, on analyse 
On itère beaucoup plus vite → on teste sans stress, en sachant qu’on verra immédiatement si ça dégrade quelque chose 
On a industrialisé le process → chaque run génère des scores, des comparaisons et une trace exploitable 
On parle enfin le même langage que le métier → moins de ressenti, plus de qualité, de précision et de pertinence 
Et ça change clairement la prise de décision. 

La conviction Proxym

Le plus gros apprentissage : une solution à base d’IA qui s’améliore sans système d’évaluation… c’est une illusion. 

Intégrer de l’IA dans une solution ou un système n’est pas toujours le vrai challenge.
 
Ce qui fait la différence, c’est la capacité à mesurer la qualité dans le temps et à piloter les évolutions. 
Mettre en place un workflow d’évaluation, ce n’est pas un bonus. C’est ce qui permet de passer d’une démo… à un système fiable en production.

Erol KOSEOGLU
Lead Data & IA