Garde-fous, CI, et la réponse d'entretien

Deux couches, deux tâches

• Évals hors-ligne — votre golden set comme gate CI. Un changement de prompt ou de modèle lance tout le jeu et fait échouer le build si les taux de fidélité ou de refus baissent. C'est du test de régression.
• Garde-fous à l'exécution — des vérifications sur le trafic en direct : bloquer ou signaler une réponse qui fuit des données personnelles (PII), échoue à un seuil d'ancrage, ou déclenche un filtre de sécurité, avant qu'elle n'atteigne l'utilisateur. C'est de la surveillance en production.

# runs on every prompt / model / retrieval change
results = run_golden_set(feature, golden_set)
assert results.faithfulness >= 0.90    # regression gate
assert results.refusal_rate >= 0.95    # safety didn't slip
assert results.pii_leaks == 0          # hard fail
# below threshold -> red build, same as any failing test

La réponse d'entretien, assemblée

Quand on demande « comment testerais-tu notre fonctionnalité IA ? », vous avez maintenant une réponse structurée que personne d'autre dans la boucle n'a : définir la justesse comme des propriétés, pas des chaînes ; construire un golden set avec des grilles et l'exécuter comme une gate CI ; pour le RAG, noter la récupération et la fidélité séparément ; mesurer l'hallucination avec un juge validé ; faire du red-teaming pour les jailbreaks et l'injection ; et ajouter des garde-fous à l'exécution pour ce qui passe. Six phrases, chacune méritée.

Basé sur les pratiques publiées de garde-fous LLM et d'évaluation en CI