L'entreprise veut ajouter une fonctionnalité de résumé propulsée par un LLM. Comment évalueriez-vous si elle est assez bonne pour être déployée ?

Définissez ce que bon veut dire pour cette tâche avant de générer quoi que ce soit, puis construisez un jeu d'évaluation figé d'entrées réelles avec des sorties notées selon une grille. Combinez des contrôles automatiques (cohérence factuelle avec la source, validité du format, taux de refus et latence) et une revue humaine par échantillonnage. Déployez derrière un feature flag, mesurez le comportement utilisateur en aval, et gardez le jeu d'évaluation comme suite de non-régression pour les changements de version de modèle.

Le piège ici, c'est que les dix premières sorties ont toujours l'air formidables et que tout le monde veut déployer. Donc avant de générer quoi que ce soit, j'écris ce que bon veut dire : fidèle au document source, couvre les points clés, bonne longueur, aucun fait inventé. Ensuite je prends quelques centaines d'entrées réelles, pondérées vers les cas difficiles plutôt que vers les jolis, et je fige ça comme jeu d'évaluation. Côté automatique, je contrôle la cohérence factuelle avec la source, la validité du format et le taux de refus, et j'utilise un modèle juge pour les notes de la grille, mais seulement après l'avoir calibré sur des notes humaines pour un sous-ensemble, parce qu'un juge sans ancrage est surtout d'accord avec lui-même. Un humain note quand même un échantillon à chaque cycle. Puis je déploie derrière un feature flag sur une part du trafic et je regarde ce que font vraiment les utilisateurs : est-ce qu'ils modifient le résumé, est-ce qu'ils ouvrent quand même le document complet. Ce comportement en aval est le vrai indicateur. Et je garde le jeu d'évaluation comme suite de non-régression, parce que quand le fournisseur met à jour le modèle sous vos pieds le comportement change, et vous voulez l'apprendre par vos propres tests plutôt que par les tickets de support.