Chapitre 10 — Les frameworks d'évaluation de référence

Dixième billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. Le chapitre où la triade reçoit une boîte à outils — huit frameworks en deux saveurs — et un aveu honnête sur la partie de l'évaluation qu'aucun d'eux ne résout encore.

Pourquoi ce chapitre existe

La triade du Chapitre 9 a dit quoi mesurer. Elle n'a rien dit sur la manière de lancer effectivement ces mesures en production. Les métriques sont des concepts. Leurs mises en œuvre sont des prompts pour le juge, une logique de décomposition pour les affirmations, des choix d'embedding pour la similarité, des stratégies d'échantillonnage pour le coût, des tableaux de bord, des alertes, et des boucles de revue humaine. Aucune équipe ne construit tout cela de zéro.

Les frameworks se sont divisés selon un axe reconnaissable. D'un côté, les bibliothèques centrées métrique — RAGAS, TruLens, DeepEval — qui calculent la triade avec une méthodologie documentée et reproductible. De l'autre, les plateformes d'observabilité — Braintrust, LangSmith, Phoenix, Galileo, Opik — qui partent des traces de production et intègrent l'évaluation comme une fonctionnalité dans un flux plus large. Choisir entre elles est moins une comparaison de fonctionnalités qu'une question de ce que l'équipe a besoin que le système fasse le lendemain de la mise en service.

10.1 Les bibliothèques centrées métrique — RAGAS, TruLens, DeepEval

RAGAS est ce qui se rapproche le plus, dans le domaine, d'une implémentation de référence de la triade. Ensemble de métriques conservateur, prompts documentés, chaque appel LLM exposé. Le pipeline de Fidélité est une chaîne en deux étapes — décomposer la réponse en affirmations, vérifier chaque affirmation contre le contexte — et la liste intermédiaire d'affirmations revient dans le résultat, donc un ingénieur peut pointer du doigt l'affirmation spécifique que le framework a décidée comme non soutenue. Pour la recherche, les industries réglementées, ou toute équipe qui a besoin de défendre sa méthodologie, RAGAS est le défaut. Le coût est qu'il a un côté académique. Il calcule des métriques ; il ne livre pas un tableau de bord.

TruLens se situe entre la bibliothèque de métriques et la plateforme d'observabilité. Son accent est sur l'instrumentation : le framework enveloppe l'application au niveau fonction, capture chaque appel de recherche et chaque réponse de modèle dans une trace structurée, puis fait tourner la triade contre les traces. Les métriques de la triade sont exposées comme des fonctions de feedback — petites unités composables, faciles à écrire les vôtres. TruLens est le bon choix quand les besoins d'évaluation de l'équipe vont au-delà de l'ensemble standard, ou quand le flux est centré sur l'inspection des échecs individuels plutôt que sur les tableaux de bord agrégés.

DeepEval prend une troisième posture : évaluation comme pytest. Les cas de test sont écrits et exécutés avec une CLI à la pytest ; les échecs bloquent la PR ; l'ensemble de métriques est le plus large des trois, incluant des vérifications de biais, de toxicité et d'hallucination aux côtés de la triade. Le compromis est que cette largeur s'accompagne d'une rigueur inégale. Choisissez une métrique au menu sans en lire l'implémentation et vous risquez de rapporter des nombres qui ne signifient pas ce que vous croyez. La bonne discipline est de choisir un petit ensemble, lire les prompts, calibrer contre des étiquettes manuelles, et traiter le reste comme inspiration.

10.2 Les plateformes d'observabilité — Braintrust, LangSmith, Phoenix, Galileo, Opik

Les bibliothèques centrées métrique répondent à « comment je calcule la triade ». Les plateformes d'observabilité répondent à « comment je fais tourner un système RAG en production ». Elles partent du principe que l'équipe écrira des prompts, comparera des versions de modèles, ingérera des traces et regardera des tableaux de bord dans un avenir prévisible. L'évaluation est une fonctionnalité ; le versionnement de prompts, l'exploration de traces, les tests A/B et l'alerting font tout aussi partie de la valeur.

Braintrust mène par l'expérience développeur — l'expérience, un enregistrement versionné du comportement d'un modèle sur un jeu de données, avec des diffs de scores côte à côte dans une UI véritablement agréable à utiliser. LangSmith est le choix naturel pour les équipes déjà profondément dans LangChain ; il s'attend à être au centre de l'instrumentation de l'application et récompense cet engagement par de la profondeur. Phoenix, d'Arize, est l'option open source, distinguée par l'analyse de dérive d'embedding et de clusters que les autres sous-jouent — viable pour les équipes qui ne peuvent pas envoyer leurs traces à un endpoint SaaS. Galileo est la plateforme orientée entreprise, avec un score propriétaire Correctness et un déploiement on-prem pour les industries réglementées. Opik, de Comet, est l'entrant le plus récent, open-source-first comme Phoenix, soigné comme Braintrust, avec l'avantage supplémentaire d'unifier l'observabilité LLM et ML classique sous une seule plateforme.

Le choix parmi les cinq porte moins sur les fonctionnalités que sur l'adéquation organisationnelle. Boutique LangChain : LangSmith. Équipe d'ingénierie produit en greenfield : Braintrust. Équipe open-source-first : Phoenix. Entreprise réglementée : Galileo. Boutique Comet : Opik. La qualité métrique à travers les cinq est globalement comparable — ils implémentent tous la triade, utilisent tous LLM-juge, portent tous les mêmes limites fondamentales que le Chapitre 9 a nommées. Les différences sont sur le flux, pas la mesure.

10.3 L'écart d'évaluation et le patron en trois boucles

Voici le fait gênant que le tour des frameworks vient de glisser. Presque tous les outils ci-dessus évaluent à la couche d'inférence : étant donné que la recherche a déjà eu lieu, le modèle a-t-il honoré les morceaux, la réponse correspondait-elle à la forme de la question, les morceaux étaient-ils sur le sujet. Aucun d'eux, en un sens profond, ne vous dit si la recherche a trouvé les bons morceaux au départ. La sortie du retrieveur est l'entrée de la couche d'inférence, et les métriques de la couche d'inférence mesurent la sortie mais pas l'entrée. Si la recherche manque systématiquement un document important, la Fidélité reste haute (le modèle a honoré ce qu'on lui a donné), la Pertinence de la Réponse reste haute (la réponse correspondait à la forme de la question), et les utilisateurs reçoivent la mauvaise réponse de toute façon.

C'est l'écart d'évaluation. La raison structurelle est que l'évaluation au niveau inférence est sans référence, alors qu'une évaluation rigoureuse de la couche contexte a besoin de savoir quels étaient les bons morceaux — ce qui exige soit un ensemble étiqueté, soit un ensemble synthétique. Les contournements — génération de questions synthétiques, sondes à l'aiguille dans la botte de foin, proxies d'impact en aval, audit de recherche conditionné par la requête, recherche-contre-soi — sont tous utiles et tous incomplets. Le résumé honnête est que l'évaluation de la couche contexte est la frontière ouverte et que les équipes devraient s'attendre à investir une partie de leur propre ingénierie directement dans la qualité de recherche. Les frameworks aident avec la boucle d'inférence ; ils laissent la boucle de recherche principalement à l'équipe.

Le patron sur lequel convergent les équipes mûres est trois boucles, pas une. Boucle interne : une bibliothèque centrée métrique (typiquement RAGAS ou DeepEval) fait tourner la triade sur un ensemble de régression fixe à chaque changement significatif, rapide et déterministe, orienté vers la capture des régressions. Boucle externe : une plateforme d'observabilité gère le stockage des traces de production, le calcul de métriques en ligne contre du trafic échantillonné, les tableaux de bord et les alertes — orientée vers la dérive que l'ensemble de régression manquera. Boucle lente : une petite fonction de revue humaine calibre les LLM-juges, audite les traces flagguées, et maintient l'ensemble de régression à mesure que le produit évolue. Une équipe avec seulement la boucle interne livre une production qui dérive. Une équipe avec seulement la boucle externe voit la dérive mais ne peut pas la déboguer. Une équipe avec les deux mais sans revue humaine fait confiance à des juges qui dérivent silencieusement. Les trois sont nécessaires, et la valeur des frameworks est dans la facilité avec laquelle ils rendent chaque boucle.

Ce que prépare le Chapitre 10

Entre la triade du Chapitre 9 et les frameworks du Chapitre 10, une équipe a ce qu'il lui faut pour mesurer un système RAG : un vocabulaire, une comptabilité honnête de ce que le vocabulaire manque, et un petit ensemble d'outils qui transforment les mesures en tableaux de bord. Le système sera lisible. Mais la mesure n'est que la moitié de l'histoire de production. Un système qui est mesuré mais non maintenu se dégradera quand même, parce que les documents changent, les utilisateurs changent, et les modèles sous-jacents changent. Savoir que la qualité a chuté n'est pas la même chose que pouvoir la restaurer.

Prochaine étape — Chapitre 11 : Mises à jour continues et optimisation du pipeline. CDC et indexation incrémentale, cache sémantique et tiering de modèles, et la boucle de feedback en quatre étapes qui transforme la télémétrie de production en le genre de système qui devient effectivement meilleur à mesure qu'il tourne.