Aller au contenu principal
Essentiel10–16 heures

Quality Gate IA dans la CI

Construisez un regression gate pour une fonctionnalité LLM avec des vérifications déterministes, des model graders, des cas de sécurité et des seuils de release.

conception de testsdatasets d’évaluationmodel graderstests de sécuritégates CI

Scénario

Tâche

Une équipe modifie régulièrement les prompts et les modèles. Elle a besoin d’un gate automatisé qui bloque le release en cas de régression de qualité, de sécurité ou de stabilité des structured outputs.

Exécution pas à pas

1. Construire la taxonomie de tests

Résultat: Les risques produit sont couverts par des classes de tests explicites.

Tâches

  • Identifier les happy paths
  • Ajouter les edge cases
  • Ajouter des cas de prompt injection et d’hallucination
  • Attribuer une severity

Vérifications

  • Chaque risque critique possède un cas de test
  • Le dataset ne contient pas seulement des happy paths

2. Implémenter les graders

Résultat: Chaque propriété possède une méthode d’évaluation adaptée.

Tâches

  • Ajouter des schema checks
  • Ajouter des assertions exact/regex
  • Configurer un model grader
  • Calibrer le grader sur un échantillon revu manuellement

Vérifications

  • Les checks déterministes ne sont pas remplacés par un LLM judge
  • Le grader possède des preuves de calibration

3. Définir la politique de régression

Résultat: Les décisions de release suivent des règles enregistrées.

Tâches

  • Enregistrer le baseline
  • Définir les blocking thresholds
  • Séparer les quality et safety gates
  • Ajouter un processus d’exception

Vérifications

  • Une régression de sécurité bloque toujours le release
  • Les seuils sont stockés sous contrôle de version

4. Intégrer le rapport CI

Résultat: Chaque changement reçoit un verdict transparent.

Tâches

  • Exécuter les evals dans la CI
  • Publier un résumé
  • Conserver les résultats raw
  • Ajouter des exemples d’échecs

Vérifications

  • Un gate échoué fait échouer le job
  • Les résultats sont comparables entre les runs

Critères d’acceptation

  • Le dataset couvre les cas normaux, edge et adversariaux
  • Des graders déterministes et basés sur des modèles sont présents
  • Les régressions de sécurité bloquent le release
  • La CI conserve les preuves brutes
  • Le baseline et les seuils sont versionnés

Grille d’évaluation

Comment le résultat est évalué

Score de réussite: 75/100 · Distinction: 92/100

Couverture des risques

Le dataset couvre les scénarios normaux, edge et adversariaux.

25 points

Insuffisant

Les happy paths dominent.

Compétent

Les risques critiques sont couverts.

Solide

La couverture est liée aux incidents de production et au threat model.

Preuves requises

  • ✓ Lien vers le code ou l’artefact
  • ✓ README avec les décisions
  • ✓ Sortie des tests ou preuve runtime
  • ✓ Taxonomie de tests et carte de severity

Qualité des graders

Les checks déterministes et les model graders correspondent aux propriétés évaluées.

25 points

Insuffisant

Un seul LLM judge évalue tout.

Compétent

Les checks déterministes et model-based sont séparés.

Solide

La calibration et l’analyse des désaccords sont automatisées.

Preuves requises

  • ✓ Lien vers le code ou l’artefact
  • ✓ README avec les décisions
  • ✓ Sortie des tests ou preuve runtime
  • ✓ Échantillon de calibration

Politique de régression

Baseline, seuils et règles de blocage sont versionnés.

25 points

Insuffisant

Le verdict est subjectif.

Compétent

Les seuils et conditions bloquantes sont explicites.

Solide

Des exceptions fondées sur le risque et une analyse de tendance existent.

Preuves requises

  • ✓ Lien vers le code ou l’artefact
  • ✓ README avec les décisions
  • ✓ Sortie des tests ou preuve runtime
  • ✓ Politique de release

Intégration CI

Le gate bloque les releases faibles et conserve les preuves.

25 points

Insuffisant

Le rapport n’influence pas le release.

Compétent

Un échec fait échouer le job.

Solide

Artifacts, diff report et contrôle des flaky evals sont présents.

Preuves requises

  • ✓ Lien vers le code ou l’artefact
  • ✓ README avec les décisions
  • ✓ Sortie des tests ou preuve runtime
  • ✓ Run CI en échec et réussi