Chapitre 5 — Évaluer les applications LLM

Cinquième billet de la tournée chapitre par chapitre de LLM Primer V : Construire des applications LLM réelles. Le chapitre qui admet qu'assertEqual est mort pour les sorties LLM et reconstruit la discipline de test autour de juges ancrés, du Triangle RAG et des tests de trajectoire.

Pourquoi ce chapitre existe

Le test logiciel classique repose sur l'hypothèse qu'une sortie correcte est une sortie spécifique — la fonction renvoie 42, la chaîne vaut « Hello, world », le JSON correspond à la fixture. Les systèmes LLM produisent des paraphrases équivalentes en sens et différentes en caractères, et l'assertion d'égalité exacte qui a ancré le test logiciel pendant cinquante ans s'effondre à la première régénération. Les équipes tendent alors la main vers BLEU, ROUGE ou la similarité cosinus d'embedding, et découvrent que ces métriques corrèlent faiblement au jugement humain sur ce qui compte — la réponse est-elle correcte, est-elle ancrée, adresse-t-elle la question. Le Chapitre 5 reconstruit la discipline de test autour de ce qui fonctionne réellement : des rubriques LLM-juge ancrées, le Triangle RAG, des tests de trajectoire d'agent, et une boucle continue où les traces de production alimentent le jeu d'évaluation qui verrouille la prochaine version.

5.1 L'écart d'évaluation et le LLM-juge

L'écart d'évaluation est la distance entre ce qu'un test classique peut mesurer et ce qu'une sortie LLM a réellement besoin de voir mesuré. La correspondance exacte et les métriques à chaîne de référence n'attrapent aucune des défaillances intéressantes sur les tâches riches en paraphrase. Le LLM-juge est le cheval de bataille qui ferme cet écart, avec deux disciplines qui le distinguent d'un tour de foire. D'abord, la rubrique du juge est ancrée : chaque valeur de score a une définition écrite, idéalement avec un exemple, si bien que le juge n'associe pas librement un nombre. Ensuite, le juge produit son raisonnement avant le score, parce qu'un juge tenu d'écrire son raisonnement note plus régulièrement. Des vérifications programmatiques complètent le juge pour ce qui est déterministiquement vérifiable — le JSON s'analyse, les champs requis sont présents, aucune chaîne interdite n'apparaît, la longueur de réponse reste dans les bornes. Le juge n'est pas universel ; il couvre le terrain que les vérifications déterministes ne peuvent couvrir.

5.2 Le Triangle RAG — pertinence de contexte, ancrage, pertinence de réponse

Pour les systèmes de récupération, le motif qui s'est cristallisé consiste à noter indépendamment trois sommets. La pertinence de contexte demande si les segments récupérés sont réellement pertinents pour la requête, et isole les défaillances de récupération de celles de génération. L'ancrage demande si la réponse générée découle du contexte récupéré, et attrape les hallucinations qui passent la validation de forme. La pertinence de réponse demande si la réponse adresse la question réellement posée. Notés indépendamment, les trois sommets localisent les défaillances : un score de pertinence de contexte faible pointe vers la récupération, un score d'ancrage faible vers le générateur, un score de pertinence de réponse faible vers le routeur ou un système qui répond à une question voisine. RAGAS opérationnalise le triangle comme un pipeline par lots ; la qualité du modèle-juge domine la qualité des scores, si bien que le juge lui-même est un composant que l'équipe évalue.

5.3 Niches de frameworks et régression d'agent

Trois frameworks occupent des niches distinctes. RAGAS exécute le Triangle RAG par lots sur un jeu de paires question-réponse et est le bon outil pour l'évaluation périodique sur jeu de données. TruLens attache des fonctions de retour au trafic de production en direct et calcule le triangle sur les traces elles-mêmes, refermant la boucle entre production et évaluation. DeepEval exécute des tests LLM comme portes de CI de la façon dont pytest exécute des tests unitaires, avec un seuil par métrique. Les agents étendent tout cela dans trois directions : les tests d'instantané de trajectoire affirment la forme de la séquence d'appels d'outils pour une entrée fixe, attrapant la dérive structurelle ; les assertions d'invariant vérifient que l'agent n'a pas appelé un outil interdit ni omis une approbation requise ; les tests de rubrique notent la trajectoire elle-même pour savoir si le chemin était raisonnable. Un agent qui donne la bonne réponse par le mauvais chemin est à un changement de prompt d'en donner une mauvaise par le même chemin, et le test de trajectoire est la discipline qui attrape cela.

Ce que prépare le Chapitre 5

Les évaluations ont besoin de traces de production où puiser. Les portes de CI ont besoin de régressions réelles à surveiller. La boucle d'amélioration continue ne marche que s'il existe une couche d'observabilité capturant chaque étape de chaque invocation — les appels de modèle, les appels d'outil, les résultats de récupération, les sauts de sous-agent, le coût, la latence, les retours utilisateur. Le Chapitre 6 est cette couche. Il parcourt OpenTelemetry avec les conventions sémantiques GenAI, les métriques qui comptent vraiment pour les systèmes LLM, les choix de plateforme et — surtout — le pipeline d'export qui achemine les traces à faible score vers le jeu d'évaluation qui verrouille la prochaine version.

Prochaine étape — Chapitre 6 : Observabilité et traçage de l'IA. Le substrat qui rend possibles à la fois l'évaluation et le débogage — une trace imbriquée par invocation, avec coût et qualité attachés comme attributs de premier plan.