Évaluer et fiabiliser un système LLM : évals et garde-fous

Un système LLM qui « a l'air de marcher » en démo échoue souvent en production, sur les cas que vous n'aviez pas testés. La différence entre un prototype et un produit fiable tient à deux choses : une évaluation rigoureuse et des garde-fous d'exécution. Voici comment mettre les deux en place.

Pourquoi l'éval est non négociable

Les LLM sont non déterministes : la même entrée peut donner des sorties différentes. « Je l'ai testé trois fois, c'était bon » ne prouve rien. Sans mesure systématique, chaque changement de prompt ou de modèle est un pari. Une suite d'évals transforme ces paris en décisions chiffrées.

Construire un jeu d'évaluation

Commencez tôt, même petit :

1. Rassemblez des cas réels : 30 à 100 entrées représentatives, incluant les cas limites et ceux qui ont déjà échoué.
2. Définissez le résultat attendu pour chacun (réponse de référence, ou critères de réussite).
3. Versionnez ce dataset : il devient votre référence pour comparer modèles, prompts et versions.

Un dataset de 50 cas bien choisis vaut mieux que 1000 cas génériques.

Trois niveaux de mesure

1. Vérifications automatiques (rapides, gratuites). Pour tout ce qui est objectif : format JSON valide, présence d'un champ, longueur, absence de mots interdits, correspondance exacte quand elle s'applique.

2. LLM-as-judge (souple, pour le subjectif). Un second LLM note la sortie selon une grille : pertinence, fidélité aux sources, ton. Pratique pour évaluer à grande échelle ce qu'une règle ne peut juger — mais le juge a ses biais, calibrez-le sur quelques cas notés à la main.

3. Revue humaine (l'étalon-or, coûteux). Sur un échantillon, un humain tranche. À réserver aux décisions importantes et au calibrage du juge automatique.

Les garde-fous à l'exécution

L'éval mesure avant le déploiement ; les garde-fous protègent en direct :

• Validation de sortie : rejetez ou réessayez si la réponse ne respecte pas le format attendu.
• Détection d'hallucination : en RAG, vérifiez que la réponse s'appuie sur les sources fournies ; sinon, signalez ou refusez.
• Filtres d'entrée et de sortie : bloquez les contenus interdits dans les deux sens.
• Fallback : prévoyez un comportement sûr quand le modèle échoue (réponse par défaut, escalade humaine) plutôt qu'un plantage.
• Limites : timeout, nombre de tentatives, budget de tokens.

Boucler avec la production

Les vrais cas limites viennent des utilisateurs. Journalisez les échecs et les retours négatifs, et réinjectez-les dans votre dataset d'éval. Votre suite de tests s'enrichit ainsi des cas qui comptent vraiment, et chaque incident renforce le système.

À retenir

« Ça a l'air de marcher » n'est pas une métrique. Construisez tôt un jeu d'évaluation de cas réels, mesurez à trois niveaux (vérifs automatiques, LLM-juge calibré, revue humaine), et doublez l'éval de garde-fous d'exécution : validation des sorties, détection d'hallucination, fallback sûr. Enfin, bouclez : chaque échec en production devient un nouveau cas de test. C'est cette discipline qui rend un système LLM fiable.