Création de pipelines d'évaluation LLM de niveau production : des vibrations aux métriques

Comment nous avons remplacé « ça me semble bien » par une évaluation automatisée détectant 92 % des hallucinations avant le déploiement

Le problème : pourquoi les « vibe checks » échouent en production

Il y a trois mois, notre équipe a livré un assistant de support client basé sur RAG. Cela a très bien fonctionné lors des tests : nous lui posions des questions, lisions les réponses et disions "oui, ça a l'air bien".

Puis cela a frappé la production.

Un client a posé des questions sur son cycle de facturation. L'assistant a cité avec assurance une politique qui n'existait pas. Un autre a posé des questions sur les limites de débit de l'API et a obtenu des chiffres provenant de la documentation d'un concurrent. Au moment où nous l’avons détecté, plus de 500 utilisateurs avaient vu des réponses hallucinées.

L’autopsie a été brutale : nous n’avons eu aucune évaluation automatisée. Notre processus de test consistait littéralement à « poser 5 questions, lire les réponses, bravo ».

Ce dont l’évaluation de la production a réellement besoin

Les benchmarks académiques (MMLU, HellaSwag) ne vous disent pas si votre système fonctionne pour votre cas d'utilisation. Besoins en évaluation de la production :

1. Juges spécifiques à un domaine — Vos critères, pas une « serviabilité » générique
2. Vitesse – L'évaluation doit s'exécuter en CI/CD, pas du jour au lendemain
3. Détection de régression – Sachez immédiatement quand un changement rapide interrompt les choses
4. Intégration CI/CD — Bloquer les fusions qui dégradent la qualité
5. Gestion des ensembles de données Golden – Cas de test versionnés, stratifiés et croissants

Architecture : le pipeline d'évaluation