Aller au contenu principal

Évaluer la qualité de l'IA (Evals)

Avancé
What you'll learn
  • Construire l'eval minimale utile — un golden set de 20 à 100 entrées réelles avec des critères de réussite clairs
  • Choisir la bonne métrique par tâche : vérifications déterministes, LLM-as-judge ou revue humaine
  • Exécuter les evals comme un garde-fou — avant/après chaque changement de prompt, chaque swap de modèle, et en CI
  • Noter chaque étape (retrieval, appel d'outil, réponse finale), pas seulement la dernière, pour localiser les régressions

Si vous livrez quoi que ce soit construit sur de l'IA, les evals sont la façon dont vous savez que ça marche — et la façon dont vous savez qu'un changement l'a amélioré, pas empiré. Sans elles, vous naviguez à vue : un ajustement de prompt qui aide un cas peut silencieusement en casser dix autres. Les evals transforment l'itération « au feeling » en une boucle mesurable.

L'eval minimale viable​

Vous n'avez pas besoin d'un framework pour commencer. Toute la boucle tient en quatre étapes :

Guided walkthrough1 of 4
  1. 20 à 100 entrées réelles avec les sorties correctes ou acceptables (ou des critères clairs de ce qui compte comme une réussite). Couvrez les cas faciles, les cas délicats et les cas limites qui vous ont déjà mordu en production.

Choisir les métriques​

Toutes les questions ne méritent pas le même test. Faites correspondre la métrique à la tâche :

Type de tâcheMétriqueCoûtFiabilité
Sortie structurée (JSON, SQL)Validation de schéma, correspondance exacteGratuitÉlevée
Génération de codeFaire tourner les tests qu'il a écritsFaibleÉlevée
Extraction (dates, entités)String contains / regexGratuitÉlevée
ClassificationAccuracy, precision, recallGratuitÉlevée
Résumés, brouillons, tonLLM-as-judge avec une rubriqueModéréMoyenne — doit être calibré
Écriture à fort enjeu, sécuritéRevue humaine sur un échantillonCherMaximale

Trois règles de pouce :

  • Vérifications déterministes quand c'est possible. Si la réponse est « JSON valide qui respecte ce schéma » ou « le code passe ces tests », ne demandez pas à un LLM — vérifiez-le.
  • LLM-as-judge pour la qualité floue. Utilité, ton, factualité-vs-source. Rapide et bon marché, mais a des biais (longueur, position, auto-préférence). Validez le juge contre des notes humaines sur un échantillon avant de faire confiance à ses chiffres.
  • Humains sur la tranche à plus fort enjeu. Même 10 cas notés par un humain par release valent mieux que 0.

Rubrique de départ pour LLM-as-judge

You are grading assistant responses against a source document.

For each response, output a JSON object with these fields:
- grounded: true if every factual claim is supported by the source, else false
- complete: true if the response answers all parts of the question, else false
- concise: true if the response contains no filler or repetition, else false
- overall_score: 1-5 (1 = unusable, 5 = ship it)
- reasoning: one sentence explaining the score

Do not consider length. Do not consider whether the response comes first or second.

<source>{{SOURCE}}</source>
<question>{{QUESTION}}</question>
<response>{{RESPONSE}}</response>

Return only the JSON, no preamble.

Quand les exécuter​

  • Avant/après tout changement de prompt ou de modèle. Sans exception. L'objectif même du golden set est d'attraper le changement que vous pensiez sûr.
  • Lors d'une migration de modèle. Les nouveaux modèles décalent le comportement — parfois silencieusement. Faites tourner les evals avant de basculer l'ID du modèle. Voir Erreurs & Migration.
  • En CI, pour les systèmes en production. Transformez une eval verte en un garde-fou de merge. Les régressions sont attrapées avant que les utilisateurs ne les voient.
  • Après chaque bug remonté. Ajoutez le cas défaillant au golden set. Le set grandit avec le système.

Notez chaque étape, pas seulement la réponse finale​

Pour RAG et les agents, un seul score de « réponse finale » cache où les choses cassent. Notez chaque étape séparément pour que les régressions atterrissent au bon endroit :

ÉtapeCe qu'il faut vérifier
RetrievalLe top-k contenait-il le document qui contient la réponse ?
Sélection d'outilL'agent a-t-il choisi le bon outil pour ce tour ?
Arguments d'outilLes arguments étaient-ils bien formés et corrects ?
Réponse finaleCorrespond-elle aux critères du golden set ?

Quand le score de retrieval baisse mais que le score final reste stable, vous savez que c'est une régression de retrieval — pas un problème de prompt. Ce genre de localisation est ce qui rend les evals réellement utiles pour le debugging, pas juste pour la notation.

Erreurs courantes​

  • Noter avec le même modèle qui a généré la réponse. Le biais d'auto-préférence gonfle les scores. Utilisez un autre modèle — ou mieux, une autre famille — comme juge.
  • Des prompts de juge qui divulguent la « bonne » réponse. Si le juge voit la réponse dorée, il trouvera des raisons de la récompenser. Notez sur des critères, pas sur la similarité.
  • Des golden sets figés au jour un. Le set doit grandir chaque fois que la production vous surprend. Un set obsolète mesure le passé.
  • Optimiser pour l'eval plutôt que pour la tâche. Si vous ajustez les prompts contre un petit set jusqu'à ce que tous les cas passent, vous avez peut-être overfit. Mettez de côté ~20 % des cas comme un slice de validation que vous ne regardez jamais pendant l'itération.

Vérifiez-vous

0/4
  1. Qu'est-ce que l'eval minimale viable ?
  2. Quand préférer une vérification déterministe à LLM-as-judge ?
  3. Pour un agent RAG, pourquoi noter chaque étape séparément ?
  4. Qu'est-ce qui indique que vous avez overfit sur votre eval set ?
Key takeaways
  • 20 à 100 entrées réelles + critères de réussite + une variable à la fois = une boucle d'eval fonctionnelle.
  • Déterministe > LLM-judge > humain — prenez la métrique la moins chère que la tâche permet.
  • Notez chaque étape d'un pipeline, pas seulement la réponse finale.
  • Le golden set grandit avec chaque bug remonté. Un set obsolète mesure le passé.

Suite​