Arrêtez d’évaluer les LLM avec les « Vibe Checks »

directeur. Votre équipe vient de passer trois semaines à refactoriser la chaîne d’invites pour l’agent de recherche interne en IA de votre entreprise. Ils déploient la nouvelle version dans un environnement de test, exécutent quelques requêtes et rendent compte : « Cela se sent beaucoup mieux. Les réponses sont plus détaillées. »

Si vous approuvez ce déploiement sur la base d’un « contrôle vibratoire », vous volez à l’aveugle.

Dans le génie logiciel traditionnel, nous n’accepterions jamais « ça fait du mieux » comme note de réussite à un test. Nous exigeons des tests unitaires, des tests d’intégration et des assertions déterministes. Pourtant, lorsqu’il s’agit de grands modèles linguistiques (LLM) et de systèmes agents, de nombreuses équipes abandonnent la rigueur technique et reviennent à une évaluation humaine subjective.

C’est l’une des principales raisons pour lesquelles les projets d’IA d’entreprise ne parviennent pas à évoluer. Vous ne pouvez pas optimiser ce que vous ne pouvez pas mesurer, et vous ne pouvez pas itérer en toute sécurité sur un système si vous ne savez pas quand il tombe en panne.

Pour faire passer un système d’IA d’une démonstration fragile à un actif de production robuste, vous devez créer une carte de pointage d’évaluation décisionnelle.

Le piège de la précision

L’erreur la plus courante que commettent les équipes est d’optimiser uniquement pour la précision.

La précision est nécessaire, mais elle est totalement insuffisante pour la production. Un système qui donne systématiquement la mauvaise réponse est inexact mais fiable. Un système qui donne la réponse parfaite 9 fois sur 10, mais qui fait planter le pipeline d’orchestration au 10ème essai, est précis mais peu fiable.

De plus, l’exactitude ne rend pas compte des réalités opérationnelles de l’entreprise. Un agent qui coûte 50 $ par exécution parce qu’il appelle GPT-4o de manière récursive vingt fois n’est pas prêt pour la production, quelle que soit sa précision. Un agent qui met cinq minutes pour répondre à une requête d’assistance client en temps réel a déjà échoué, même si la réponse finale est impeccable. Comme indiqué lors de récentes discussions sur latence et coût de l’IA agentiqueces mesures opérationnelles sont tout aussi critiques que l’intelligence du modèle.

Lorsque vous optimisez uniquement pour la précision, vous dégradez souvent par inadvertance la latence et les coûts. Une invite plus complexe peut donner une réponse légèrement meilleure, mais si elle double le nombre de jetons et ajoute trois secondes au temps de réponse, l’expérience utilisateur globale peut en réalité être pire. Ce compromis constitue un défi fondamental dans évaluer les agents d’IAoù l’équilibre entre intelligence et efficacité opérationnelle est essentiel.

Les 5 dimensions de la qualité décisionnelle

Un cadre d’évaluation robuste doit mesurer cinq dimensions distinctes. Lorsque vous créez vos suites de tests automatisés, vous devez définir des métriques spécifiques et quantifiables pour chacun d’entre eux :

1. Précision : le résultat est-il factuellement exact et fondé sur les données sources fournies ? (Mesure : comparaison automatisée avec un ensemble de données dorées à l’aide d’un LLM en tant que juge pour vérifier les entités hallucinées).
2. Fiabilité : le système produit-il systématiquement un résultat valide sans faire planter le pipeline ? (Mesure : taux de réussite de la validation du schéma. Le taux de JSONDecodeError doit être de 0 %).
3. Latence : le système est-il suffisamment rapide pour le flux de travail spécifique qu’il dessert ? (Mesure : temps de réponse P90 et P99 mesurés en millisecondes ou secondes). Le coûts cachés de l’IA agentique se manifestent souvent par des pics de latence inacceptables lorsque les agents restent bloqués dans des boucles récursives.
4. Coût : l’utilisation des jetons et le coût de calcul sont-ils durables à grande échelle ? (Mesure : coût moyen par exécution réussie, suivi via les métriques de facturation de l’API).
5. Décisions : le résultat aide-t-il réellement l’utilisateur à prendre une meilleure décision commerciale ? (Mesure : mesures commerciales en aval, telles que la réduction du temps de révision manuelle ou l’augmentation du taux d’achèvement des tâches).

Construire l’ensemble de données d’or

Vous ne pouvez pas automatiser l’évaluation sans base de référence. Il s’agit de votre « ensemble de données en or ».

Un ensemble de données doré est une collection organisée d’entrées diverses associées à leurs résultats idéaux et attendus. Il ne doit pas se limiter au « chemin du bonheur » ; il doit inclure les cas extrêmes, les entrées mal formées et les invites contradictoires. Comme détaillé dans les guides sur créer des ensembles de données dorés pour l’évaluation de l’IAcet ensemble de données constitue la base de toute votre stratégie de test.

La création d’un ensemble de données doré demande beaucoup de main-d’œuvre. Cela nécessite que des experts du domaine examinent et annotent manuellement des centaines ou des milliers d’exemples. Cependant, cet investissement initial rapporte d’énormes dividendes sur toute la ligne. Une fois que vous disposez d’un ensemble de données robuste et fiable, vous pouvez évaluer de nouveaux modèles ou provoquer des modifications en quelques minutes plutôt qu’en quelques jours.

Lorsque vous mettez à jour l’invite de votre agent ou remplacez le modèle de base sous-jacent, vous exécutez la nouvelle version sur l’intégralité de l’ensemble de données de référence. Vous utilisez ensuite un pipeline d’évaluation automatisé (utilisant souvent un LLM distinct et hautement performant comme évaluateur) pour comparer les nouveaux résultats aux résultats en or dans les cinq dimensions.

Si la nouvelle version améliore la précision mais augmente la latence au-delà de votre seuil acceptable, le déploiement échoue. Si cela réduit les coûts mais introduit des erreurs de validation de schéma, le déploiement échoue. Cette approche rigoureuse est essentielle pour applications d’IA réglementéesoù les échecs peuvent avoir de graves conséquences juridiques et financières.

La pyramide d’évaluation

Construire ce tableau de bord nécessite de réfléchir à l’évaluation à quatre niveaux distincts :

• Unité : l’invite ou la fonction spécifique fonctionne-t-elle de manière isolée ?
• Intégration : les différents agents ou outils de la chaîne se transmettent-ils correctement les données ?
• Système : L’ensemble du pipeline fonctionne-t-il de bout en bout dans des conditions de charge réalistes ?
• Décision : le résultat final détermine-t-il le résultat commercial escompté ?

La plupart des équipes ne quittent jamais le niveau Unité. Ils testent une invite dans un environnement de terrain de jeu et supposent que le système est prêt. Mais les systèmes agents sont des composants complexes et interactifs. Une invite qui fonctionne parfaitement de manière isolée peut échouer de manière catastrophique lorsque sa sortie est transmise à un outil en aval qui attend un format différent.

Pour véritablement évaluer un système agent, vous devez tester l’ensemble du pipeline. Cela signifie simuler les interactions des utilisateurs du monde réel et mesurer les performances du système dans les cinq dimensions. Cela nécessite de créer une infrastructure capable de démarrer automatiquement des environnements de test, d’exécuter l’ensemble de données de référence et de regrouper les résultats dans un tableau de bord complet.

Le rôle du LLM en tant que juge

L’un des outils les plus puissants de l’évaluation moderne de l’IA est le modèle « LLM-as-a-Judge ». Au lieu de vous fier à une correspondance de chaînes fragile ou à des expressions régulières pour évaluer le résultat d’un agent, vous utilisez un LLM distinct et hautement performant (comme GPT-4) pour évaluer le résultat par rapport à une rubrique spécifique.

Par exemple, vous pourriez demander au juge LLM : « La réponse de l’agent résume-t-elle avec précision le document fourni sans introduire de faits externes ? Notez de 1 à 5 et fournissez une justification. »

Cette approche vous permet d’automatiser l’évaluation de résultats complexes et nuancés qui nécessiteraient autrement un examen humain. Cependant, il est crucial de rappeler que le juge LLM lui-même doit être évalué. Vous devez vous assurer que sa notation est cohérente et conforme au jugement humain. Cela se fait souvent en demandant périodiquement à des experts humains d’examiner un échantillon des scores du juge LLM pour garantir l’étalonnage.

Évaluation continue en production

L’évaluation ne s’arrête pas une fois le modèle déployé. En fait, c’est à ce moment-là que le véritable travail commence.

Les modèles se dégradent avec le temps. La distribution des données change. Les API en amont changent de comportement. Pour détecter ces problèmes avant qu’ils n’affectent les utilisateurs, vous devez mettre en œuvre une évaluation continue en production.

Cela implique d’échantillonner un pourcentage du trafic en direct, de le faire passer par votre pipeline d’évaluation et de suivre les résultats sur un tableau de bord. Si le score de précision descend en dessous d’un certain seuil ou si la latence augmente, le système doit automatiquement déclencher une alerte.

L’évaluation continue vous permet également de créer une boucle de rétroaction. Lorsqu’un utilisateur signale une réponse comme incorrecte, cette interaction doit être automatiquement ajoutée à votre ensemble de données privilégiées, garantissant ainsi que le système tire les leçons de ses erreurs et s’améliore au fil du temps.

Ingénierie pour la confiance

L’objectif d’une carte de pointage d’évaluation décisionnelle n’est pas seulement de détecter les bogues. Il s’agit d’instaurer la confiance.

Lorsque vous pouvez prouver définitivement à vos parties prenantes (avec des données concrètes) que votre système d’IA est fiable à 99,5 %, fonctionne dans le cadre d’un budget de latence strict et coûte exactement 0,04 $ par exécution, la conversation change. Vous ne leur demandez plus de faire confiance à une « ambiance ». Vous leur demandez de faire confiance à l’ingénierie.

Ce niveau de rigueur est ce qui différencie les projets d’expo-sciences des systèmes d’entreprise. C’est le seul moyen de créer une IA qui tienne réellement ses promesses.