Évaluer un LLM en CI consiste à exécuter, à chaque changement, un ensemble fixe de questions réalistes contre l’application, et à faire échouer le build quand la qualité baisse. Cet ensemble s’appelle un jeu de référence (golden set). Ce guide montre comment en construire un, quelles métriques choisir, comment contrôler les livraisons avec DeepEval et comment utiliser les traces de production de Langfuse pour garder le jeu honnête.

Pourquoi l’évaluation a sa place en CI

Le code ordinaire change quand quelqu’un le modifie. Une application LLM change quand un prompt est reformulé, quand un modèle est remplacé ou retiré, quand une taille de chunk est ajustée ou quand la description d’un outil est modifiée. Aucun de ces changements ne paraît risqué dans un diff, et tous peuvent modifier discrètement les réponses. Sans mesure à chaque changement, l’amélioration est une opinion et la régression est une surprise.

Construire un jeu de référence

Un jeu de référence est une collection versionnée de cas de test, gardée à côté du code. Chaque cas contient une question, les sources qui doivent étayer la réponse et, quand c’est utile, le comportement attendu : une réponse, un refus ou une escalade.

  • Partez de vraies questions, issues des utilisateurs ou des personnes qui connaissent le domaine, pas de questions inventées.
  • Incluez des refus. Un système qui doit s’abstenir quand il n’a pas de source a besoin de cas où s’abstenir est le bon résultat.
  • Ajoutez des cas difficiles et hostiles : questions ambiguës, documents quasi identiques, tentatives d’extraction de données personnelles.
  • Gardez-le relisible. Quelques dizaines de cas bien choisis valent mieux que des milliers que personne n’a lus.
  • Donnez-lui un responsable. Le jeu évolue par revue, comme du code.

Choisir des métriques qui correspondent à l’échec que vous redoutez

Mesurez chaque couche séparément, pour qu’un échec désigne sa cause.

  • Recherche : la source attendue figure-t-elle parmi les passages retrouvés ? DeepEval propose la précision et le rappel contextuels pour cela.
  • Ancrage : la réponse est-elle étayée par les passages retrouvés, et ses citations y correspondent-elles ? Les métriques de fidélité (faithfulness) couvrent la première moitié, un contrôle déterministe des citations couvre la seconde.
  • Pertinence : la réponse traite-t-elle la question ? La pertinence de la réponse (answer relevancy) est la métrique habituelle.
  • Comportement : le système s’abstient-il quand il le doit, et masque-t-il les données personnelles quand il le faut ? Utilisez des contrôles exacts, pas un juge.
  • Budgets : la latence et le coût par requête, suivis eux aussi comme des seuils.

Contrôler les livraisons

DeepEval permet d’écrire les évaluations comme des tests, qui s’exécutent dans la même pipeline que le reste de votre suite. Exécutez le jeu de référence dès que quelque chose qui affecte le comportement change : un prompt, un modèle, des réglages de recherche, un manifeste d’outil.

  • Fixez des seuils par métrique, et commencez par enregistrer les scores actuels pour que le premier contrôle soit « pas pire qu’aujourd’hui ».
  • Attendez-vous à du bruit. La sortie des modèles varie : comparez avec une tolérance, ou répétez un cas et prenez la moyenne, au lieu d’exiger des scores identiques.
  • Découpez la suite. Un petit jeu rapide s’exécute à chaque pull request, le jeu complet avant la livraison.
  • Échouez bruyamment. Un contrôle en échec doit nommer les cas et les métriques qui ont baissé.

Utiliser les juges avec prudence

Beaucoup de métriques utilisent un modèle comme juge. C’est pratique, et cela a des limites : un juge peut dériver quand son propre modèle change, et il peut être indulgent avec des réponses fluides mais fausses. Figez le modèle et la version du juge, calibrez-le sur un petit ensemble de cas annotés par des humains, et gardez des contrôles déterministes pour tout ce qui peut être vérifié exactement.

Boucler avec les traces de production

L’évaluation hors ligne ne couvre que les cas auxquels vous avez pensé. Langfuse enregistre les traces d’appels réels, gère les versions de prompts et porte des jeux de données, ce qu’il faut pour apprendre de la production. Quand une trace montre une mauvaise réponse, reproduisez-la, corrigez la cause et ajoutez le cas au jeu de référence, pour que le même échec ne puisse pas revenir inaperçu. Reliez chaque trace à la version de prompt qui l’a produite, afin de remonter d’une régression à un changement.

En pratique

Sur la plateforme d’ENSO, j’ai spécifié des contrôles d’évaluation en CI fondés sur DeepEval, des jeux de référence et le traçage Langfuse, comme une couche d’une plateforme qui comprend aussi une passerelle, la recherche et des actions d’agents gouvernées. L’architecture d’ensemble est décrite dans le guide de référence de la plateforme IA d’entreprise et dans l’étude de cas ENSO.

Compromis et limites

L’évaluation a un coût : exécuter un modèle juge sur chaque cas prend du temps et de l’argent, il faut donc dimensionner les suites. Les jeux de référence vieillissent quand les produits et les documents changent, et une équipe peut sur-ajuster son propre jeu : rafraîchissez-le à partir de la production. Un contrôle qui passe montre que les cas connus fonctionnent toujours, pas que le système est correct en général, et c’est pourquoi la relecture humaine de vraies conversations reste dans la boucle.