Évaluation des LLM : Métriques, Frameworks et Ce Qui Fonctionne Vraiment en 2026

L'évaluation des LLM est la différence entre « ça semble correct » et « je peux prouver que ça fonctionne. » Si vous livrez des fonctionnalités alimentées par des LLM aux utilisateurs sans évaluation systématique, vous déployez essentiellement du code non testé — sauf que les modes d'échec sont des hallucinations, de la toxicité et des réponses silencieusement erronées plutôt que des stack traces.

Ce guide couvre tout : métriques, méthodes, frameworks, conception de pipeline et conformité à la loi européenne sur l'IA. Pas de biais vendeur, pas de remplissage.

En Un Coup d'Œil

Avant d'entrer dans les détails, voici l'image complète en un tableau.

Maintenant décomposons chaque élément.

Qu'est-ce que l'Évaluation des LLM (et Pourquoi est-ce Important en 2026) ?

L'évaluation des LLM est le processus systématique de mesure et de notation de la qualité des sorties des grands modèles de langage selon des critères définis — précision, pertinence, sécurité et fidélité aux données sources. Elle englobe les métriques automatisées, la notation LLM-as-a-judge et la révision humaine pour garantir que les applications alimentées par LLM fournissent des résultats fiables en production.

Pourquoi est-ce important maintenant ? Deux raisons. Premièrement, les LLM sont passés de prototypes à des fonctionnalités de production dont de vrais utilisateurs dépendent. Un chatbot qui hallucine une politique d'entreprise ou un système RAG qui cite des documents inexistants n'est plus un bug de démo amusant — c'est un ticket de support, un risque juridique ou un client perdu.

Deuxièmement, l'application de la loi européenne sur l'IA commence en août 2026. Si votre système d'IA sert des utilisateurs européens, vous aurez besoin de pratiques d'évaluation documentées, pas juste un message Slack disant « j'ai testé quelques prompts et ça avait l'air bien. »

La plupart des équipes font encore ce qu'on pourrait appeler une « évaluation intuitive » — vérifier en spot-check une poignée de sorties dans un playground et décider que ça semble assez bon. Ça fonctionnait quand les LLM étaient des expériences. Ça ne fonctionne pas quand ce sont des fonctionnalités.

L'évaluation répond à trois questions : Le résultat est-il correct ? Est-il sûr ? Est-il utile ? Le reste de ce guide vous montre comment répondre systématiquement aux trois.

Une distinction importante : ce guide couvre l'évaluation d'application — tester comment votre produit alimenté par LLM performe sur des tâches réelles. C'est différent de l'évaluation de modèle (benchmarks de pré-entraînement comme MMLU), qui vous dit comment un modèle de fondation performe en général mais ne dit presque rien sur comment il se comportera dans votre application spécifique.

Conclusion : Si vous livrez des fonctionnalités LLM sans évaluation systématique, vous volez à l'aveugle. La question n'est pas de savoir s'il faut évaluer — c'est comment.

Métriques d'Évaluation des LLM — Quoi Mesurer et Quand

Les métriques que vous suivez dépendent entièrement de ce que vous construisez. Un chatbot nécessite une évaluation différente d'un générateur de code. Voici une taxonomie pratique organisée par cas d'utilisation, pas alphabétiquement.

Métriques de Similarité de Texte (Quand Vous Avez des Réponses de Référence)

Ces métriques classiques comparent le texte généré à une référence connue correcte :

• BLEU mesure la précision des n-grammes — combien de séquences de mots dans la sortie correspondent à la référence. Conçu à l'origine pour la traduction automatique.
• ROUGE mesure le rappel — quelle quantité du contenu de référence apparaît dans la sortie. Courant pour les tâches de résumé.
• BERTScore utilise des embeddings contextuels pour mesurer la similarité sémantique, capturant les paraphrases que BLEU et ROUGE manquent.

Le problème ? Ces métriques ne fonctionnent que si vous avez des réponses de vérité terrain à comparer. Évitez BLEU pour la génération ouverte — il pénalise la reformulation créative, qui est exactement ce que vous voulez d'un bon chatbot.

Métriques d'Évaluation Sémantique (Quand Vous Avez Besoin de Sens, Pas de Correspondance Exacte)

Pour la génération ouverte, vous avez besoin de métriques qui évaluent le sens :

• Answer relevancy évalue si la réponse adresse réellement la question de l'utilisateur.
• Cohérence mesure à quel point logiquement la sortie s'écoule.
• Concision signale les réponses inutilement verbeuses.
• G-Eval est l'option flexible : vous définissez des critères d'évaluation personnalisés en langage naturel, et un juge LLM note les sorties en utilisant le raisonnement chain-of-thought. C'est là que la plupart des équipes passent leur temps en 2026.

Métriques Spécifiques au RAG

Si vous construisez de la génération augmentée par récupération, vous évaluez deux composants — le retriever et le générateur. Le framework Ragas définit quatre métriques clés :

• Faithfulness — La réponse est-elle ancrée dans le contexte récupéré ? Ça détecte les hallucinations.
• Context relevancy — Le retriever a-t-il récupéré les bons documents ?
• Context recall — Le retriever a-t-il trouvé TOUS les documents pertinents ?
• Answer relevancy — La réponse adresse-t-elle réellement la requête ?

Métriques de Sécurité et de Conformité

Ces métriques protègent vos utilisateurs et votre entreprise :

• Taux d'hallucination — exactitude factuelle par rapport aux sources connues
• Détection de toxicité — contenu nuisible, offensant ou inapproprié
• Mesure des biais — traitement disparate entre les groupes démographiques
• Détection de fuite PII — données personnelles apparaissant dans les sorties

Quelles Métriques pour Quelle Application ?

C'est le tableau qu'aucun guide vendeur ne vous donne. Au lieu de lister chaque métrique alphabétiquement, faites correspondre votre type d'application aux métriques qui comptent vraiment :

Conclusion : Ne mesurez pas tout. Choisissez 3-5 métriques qui correspondent à VOTRE type d'application et concentrez-vous là.

Comment Exécuter Vraiment les Évaluations ? (Les Trois Méthodes)

Il y a trois façons d'évaluer les sorties LLM. La plupart des équipes de production utilisent les trois, mais dans des proportions très différentes.

Métriques Automatisées (Rapides, Bon Marché, Limitées)

Notation basée sur des scripts utilisant des métriques comme BLEU, ROUGE, correspondance exacte ou des patterns regex. Vous écrivez un test, il s'exécute en millisecondes, et vous obtenez un succès/échec.

L'avantage : c'est rapide, reproductible et essentiellement gratuit. L'inconvénient : ces métriques ne peuvent pas juger la nuance, la créativité ou l'utilité dans le monde réel. Une réponse peut avoir un score parfait sur ROUGE et être quand même inutile pour l'utilisateur.

Utilisez les métriques automatisées pour les tests de régression, les gates CI/CD et le screening à haut volume où vous avez besoin de vitesse plutôt que de profondeur.

LLM-as-a-Judge (Le Standard de 2026)

C'est là où le secteur en est arrivé. Vous utilisez un LLM séparé — typiquement GPT-4o ou Claude — pour noter les sorties selon vos critères. Le pattern G-Eval fonctionne ainsi : définissez vos critères d'évaluation en langage naturel, donnez au juge le critère plus le cas de test, et il produit un raisonnement chain-of-thought plus un score.

Les recherches de Zheng et al. montrent environ 81% de corrélation avec les scores humains, ce qui est suffisant pour l'évaluation quotidienne quand vous comprenez les modes d'échec (plus à ce sujet dans la section suivante).

Utilisez LLM-as-a-judge pour la génération ouverte, l'évaluation de qualité subjective et les critères personnalisés qui ne peuvent pas être capturés par de simples métriques.

Évaluation Humaine (Étalon Or, Ne Scalent Pas)

Des évaluateurs experts notent les sorties en utilisant des rubriques, des échelles de Likert ou des tests A/B en aveugle. Rien ne bat un humain lisant une réponse et disant « c'est vraiment utile » ou « ça confondrait l'utilisateur. »

Le problème : ça coûte 5-50 € par évaluation, prend des minutes au lieu de millisecondes, et vous ne pouvez pas l'exécuter sur chaque requête. Utilisez l'évaluation humaine pour calibrer votre LLM-as-judge, les audits de conformité et la validation des edge cases.

Choisir Votre Méthode

Conclusion : Utilisez LLM-as-a-judge pour 80% de vos évaluations, les métriques automatisées pour les gates CI/CD, et la révision humaine pour la calibration et la conformité. C'est le playbook de 2026.

LLM-as-a-Judge : Comment Ça Fonctionne, Quand Ça Échoue

LLM-as-a-judge est devenu la méthode d'évaluation par défaut pour une bonne raison — c'est flexible, relativement bon marché et corrèle bien avec le jugement humain. Mais il a de vrais angles morts que les guides vendeurs sautent commodément.

Comment G-Eval Fonctionne

Le pattern est simple. Vous définissez ce que « bon » ressemble en langage naturel, le LLM juge lit vos critères avec la sortie évaluée, raisonne étape par étape, et produit un score.

Voici un exemple pratique utilisant l'implémentation G-Eval de DeepEval :

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

correctness_metric = GEval(
    name="Correctness",
    criteria="Determine if the output is factually correct based on the expected output.",
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.7,
)

test_case = LLMTestCase(
    input="What is the capital of France?",
    actual_output="Paris is the capital of France.",
    expected_output="The capital of France is Paris.",
)

correctness_metric.measure(test_case)
print(f"Score: {correctness_metric.score}")  # 0.0 à 1.0
print(f"Reason: {correctness_metric.reason}")

Vous pouvez définir n'importe quels critères — exactitude, utilité, professionnalisme, conformité à la voix de marque — et le LLM juge notera en conséquence.

Biais Connus (Ce que les Guides Vendeurs ne Vous Disent Pas)

C'est là où la plupart des guides d'évaluation s'arrêtent. Ils vous montrent la configuration et passent à autre chose. Mais les juges LLM ont des biais systématiques qui peuvent silencieusement corrompre vos résultats d'évaluation :

• Biais de position : Lors de la comparaison de deux sorties (test A/B), les juges LLM préfèrent systématiquement l'option présentée en premier. Inversez l'ordre et le « gagnant » change.
• Biais d'auto-préférence : GPT-4 note les sorties GPT-4 plus haut que Claude ne note ces mêmes sorties, et vice versa. Le juge favorise sa propre famille de modèles.
• Biais de verbosité : Les réponses plus longues obtiennent des scores plus élevés indépendamment de la qualité réelle. Une réponse de 500 mots score mieux qu'une réponse de 100 mots qui dit la même chose plus clairement.
• Biais d'ancrage : Si vous montrez au juge des scores ou exemples précédents, les évaluations suivantes sont attirées vers ces ancres.

Atténuer le Biais du Juge

Ces biais sont gérables une fois que vous les connaissez :

1. Aléatoiriser l'ordre des options dans les comparaisons A/B (corrige le biais de position)
2. Utiliser une famille de modèles différente comme juge de votre générateur (corrige l'auto-préférence)
3. Inclure des instructions de normalisation de longueur dans vos critères de notation (corrige le biais de verbosité)
4. Exécuter des panels multi-juges — utiliser 2-3 LLM différents et moyenner les scores pour les évaluations importantes

Conclusion : LLM-as-a-judge fonctionne étonnamment bien — mais seulement si vous connaissez ses angles morts. Validez toujours contre des scores humains sur votre cas d'utilisation spécifique avant de lui faire entièrement confiance.

Évaluer les Systèmes RAG : Faithfulness, Relevancy et Recall

L'évaluation RAG est le cas d'utilisation d'évaluation le plus courant de 2026, et c'est fondamentalement différent d'évaluer un LLM autonome. Vous testez deux composants — le retriever et le générateur — et un échec dans l'un ou l'autre produit de mauvaises sorties.

Les Quatre Métriques Clés

• Faithfulness — La réponse générée est-elle vraiment ancrée dans le contexte récupéré ? Une réponse qui semble correcte mais inclut des informations absentes des documents récupérés est une hallucination. C'est votre métrique la plus importante.
• Context relevancy — Le retriever a-t-il récupéré des documents vraiment pertinents pour la requête ? Garbage in, garbage out.
• Context recall — Le retriever a-t-il trouvé TOUS les documents pertinents, ou a-t-il manqué du contexte critique ?
• Answer relevancy — Même avec une récupération parfaite, la réponse finale adresse-t-elle vraiment ce que l'utilisateur a demandé ?

Exécuter des Évaluations RAG avec Ragas

Ragas est le framework dédié pour l'évaluation RAG. Voici le pattern central :

from ragas import evaluate
from ragas.metrics import faithfulness, context_relevancy, answer_relevancy
from datasets import Dataset

# Votre jeu de données d'évaluation
eval_data = {
    "question": ["Quelle est notre politique de remboursement ?"],
    "answer": ["Vous pouvez demander un remboursement dans les 30 jours suivant l'achat."],
    "contexts": [["Politique de remboursement : Les clients peuvent demander un remboursement complet dans les 30 jours."]],
    "ground_truth": ["Les clients peuvent obtenir un remboursement dans les 30 jours."],
}

eval_dataset = Dataset.from_dict(eval_data)

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, context_relevancy, answer_relevancy],
)
print(result)
# {'faithfulness': 0.95, 'context_relevancy': 0.88, 'answer_relevancy': 0.91}

Erreurs Courantes d'Évaluation RAG

Trois patterns qui font trébucher les équipes à répétition :

1. Évaluer uniquement le générateur et ignorer la qualité du retriever. Votre réponse pourrait être parfaitement générée à partir des mauvais documents.
2. Utiliser BLEU ou ROUGE pour le RAG — ces métriques ne peuvent pas détecter les hallucinations du tout. Une réponse peut scorer haut sur ROUGE tout en contenant des informations fabriquées.
3. Ne pas tester avec des requêtes adversariales — les edge cases qui cassent la récupération (requêtes ambiguës, questions hors champ, requêtes sans documents pertinents) sont là où les systèmes RAG échouent le plus durement.

Si vous choisissez la bonne stack pour votre application IA, assurez-vous que votre infrastructure supporte l'évaluation dès le départ — l'ajouter plus tard est toujours plus difficile.

Conclusion : L'évaluation RAG est non négociable. faithfulness et context_relevancy sont vos deux métriques indispensables. Tout le reste est secondaire.

Évaluer les Agents IA : Au-delà des Métriques Single-Call

L'évaluation d'agents est là où les choses deviennent vraiment difficiles. Contrairement à un chatbot ou un système RAG, un agent prend plusieurs étapes, utilise des outils, prend des décisions, et peut partir dans des directions inattendues. Les métriques single-call traditionnelles ne capturent pas ça.

Métriques Spécifiques aux Agents

• Taux de complétion des tâches — L'agent a-t-il complété l'objectif global ? C'est votre métrique étoile du nord.
• Correction de l'utilisation des outils — A-t-il appelé les bons outils avec les bons paramètres ? Un agent qui appelle une requête base de données avec les mauvais filtres pourrait « compléter » la tâche avec de mauvaises données.
• Rétention du contexte — L'agent maintient-il un contexte cohérent à travers un workflow multi-étapes, ou perd-il le fil ?
• Coût par tâche réussie — Les agents peuvent brûler des appels API. Un agent qui prend 47 appels LLM pour compléter une tâche qui devrait en prendre 5 est un problème de coût de production.
• Récupération d'erreur — Quand un appel d'outil échoue ou retourne des résultats inattendus, l'agent s'adapte-t-il ou reste-t-il coincé dans une boucle ?

Le Défi des Tests Statistiques

Voici ce qui rend l'évaluation d'agents fondamentalement différente : le comportement des agents est non-déterministe. Exécutez la même tâche dix fois et vous pourriez obtenir sept succès, deux complétions partielles et une boucle infinie. Vous avez besoin d'évaluation statistique — exécutez chaque cas de test N fois et rapportez les taux de complétion, pas succès/échec.

Les frameworks rattrapent. DeepEval inclut maintenant des métriques spécifiques aux agents, et AWS a publié des patterns d'évaluation agentique. Mais honnêtement, l'outillage est encore précoce. Si vous déployez des agents IA en production, attendez-vous à construire une logique d'évaluation personnalisée.

Conclusion : L'évaluation d'agents est encore précoce, mais le taux de complétion des tâches et le coût par tâche sont les deux métriques à suivre dès le premier jour.

Comparaison des Frameworks d'Évaluation LLM

Chaque comparaison de framework existante est écrite par un vendeur qui se classe lui-même en premier. Voici la version neutre.

Choisissez Ceci Si...

• Vous commencez juste : DeepEval ou Ragas — tous deux gratuits, bien documentés, rapides à configurer
• Vous utilisez LangChain : LangSmith — l'intégration profonde en fait la voie de moindre résistance
• Vous avez besoin de blocage CI/CD : Braintrust — le seul outil qui bloque nativement les déploiements en cas d'échec d'évaluation
• Vous voulez une observabilité auto-hébergée : Langfuse — la meilleure combinaison tracing + évaluation open source
• Vous avez besoin de surveillance de production : Arize Phoenix — analyse d'embeddings et détection de dérive les plus puissantes
• Vous évaluez uniquement le RAG : Ragas — dédié, léger, meilleures métriques RAG

Pour un regard plus approfondi sur chaque outil avec les détails de tarification et les guides de configuration, voir nos Best LLM Evaluation Tools [à venir].

Conclusion : Il n'y a pas de framework « meilleur » unique. DeepEval pour les métriques personnalisées, Ragas pour le RAG, Braintrust pour CI/CD, Langfuse pour l'observabilité auto-hébergée. Choisissez celui qui correspond à votre workflow.

Construire Votre Pipeline d'Évaluation : De l'Ad-hoc à l'Automatisé

La plupart des équipes construisant des fonctionnalités LLM sont bloquées à ce qu'on appelle le Niveau 1 — vérifier quelques sorties manuellement et espérer le meilleur. Voici comment progresser.

Le Modèle de Maturité d'Évaluation

Construire un Jeu de Données Doré

Votre évaluation n'est aussi bonne que vos données de test. Commencez avec 50-100 exemples curés à la main qui représentent de vraies requêtes utilisateurs, incluez des edge cases et des entrées adversariales, et couvrez la gamme complète des comportements attendus.

Versionnez vos jeux de données. Ils devraient évoluer au fur et à mesure que votre produit évolue — de nouvelles fonctionnalités signifient de nouveaux cas de test. Un jeu de données doré d'il y a six mois ne reflète probablement pas ce que vos utilisateurs font aujourd'hui.

La qualité de vos résultats d'évaluation est égale à la qualité de votre vérité terrain. Investissez le temps.

Intégration CI/CD

Une fois que vous avez un jeu de données doré, connectez-le à votre pipeline de déploiement. Exécutez des évaluations sur chaque PR qui touche des prompts, la logique de récupération ou la configuration du modèle. Chaque changement de prompt engineering devrait être validé par un score mesurable, et non livré à l'aveugle. Définissez des seuils de score — par exemple faithfulness >= 0.8 et hallucination_rate < 0.05 — et bloquez le déploiement s'ils échouent.

Voici une configuration minimale GitHub Actions comme point de départ :

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths: ['prompts/**', 'src/llm/**']
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install deepeval
      - run: deepeval test run tests/eval_suite.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Ceci déclenche une évaluation quand quelqu'un modifie un fichier de prompt ou du code lié aux LLM. Si une métrique tombe en dessous du seuil, la PR ne peut pas être fusionnée. C'est du test de régression pour les applications LLM.

Surveillance de Production

Une fois en production, échantillonnez et évaluez le trafic en direct — 1-5% est typique. Suivez la dérive des métriques dans le temps, car les mises à jour de modèles, les changements de données et l'évolution du comportement des utilisateurs peuvent tous dégrader la qualité sans que personne ne le remarque.

Configurez des alertes quand les métriques tombent sous les seuils. Journalisez toutes les évaluations pour les audits de conformité (vous vous en féliciterez quand l'audit de la loi IA de l'UE arrivera). Comme Gergely Orosz le note, l'évaluation doit être un processus continu, pas une case à cocher au lancement.

Conclusion : La plupart des équipes sont bloquées au Niveau 1 (intuition). Passer au Niveau 2 (jeux de données dorés) prend un jour et change dramatiquement votre confiance dans la livraison de fonctionnalités LLM.

Loi IA de l'UE et Évaluation LLM : Ce Dont Vous Avez Besoin pour la Conformité

C'est la section qu'aucun autre guide d'évaluation ne couvre — et avec l'application d'août 2026 qui approche, c'est la section qui compte le plus pour les responsables engineering et les CTO.

Ce que la Loi IA de l'UE Exige

La loi IA de l'UE (Règlement 2024/1689) classe les systèmes d'IA par niveau de risque et impose des exigences en conséquence. Les systèmes à haut risque ont besoin d'évaluation systématique, de documentation et d'une surveillance continue. Même les systèmes à « risque limité » (où tombent la plupart des applications LLM) ont des obligations de transparence et de documentation.

Le point clé : même si vous n'êtes pas basé dans l'UE, si votre système d'IA sert des utilisateurs européens, ces règles s'appliquent à vous. Le cadre de classification des risques de la Commission européenne vous aide à déterminer où tombe votre système.

Mapper les Pratiques d'Évaluation aux Exigences de Conformité

Voici comment vos métriques d'évaluation se connectent directement aux articles de la loi IA de l'UE :

Red Teaming pour la Conformité

La loi IA de l'UE exige des tests adversariaux pour les systèmes à haut risque. Le red teaming signifie essayer systématiquement de casser votre système :

• Injection de prompts — Les utilisateurs peuvent-ils manipuler les prompts système ?
• Tentatives de jailbreak — Les utilisateurs peuvent-ils contourner les directives de sécurité ?
• Sondage des biais — Le système traite-t-il différemment les groupes démographiques ?
• Extraction de données — Les utilisateurs peuvent-ils extraire des données d'entraînement ou des PII ?

Documentez tout : méthodologie, résultats, atténuations. Planifiez des exercices de red teaming trimestriels au minimum.

Étapes Pratiques pour la Préparation à Août 2026

1. Classifiez le niveau de risque de votre système d'IA (la plupart des applications LLM sont à « risque limité »)
2. Établissez des métriques et seuils d'évaluation maintenant
3. Implémentez l'évaluation automatisée en CI/CD
4. Configurez la surveillance de production avec journalisation d'audit
5. Documentez formellement votre méthodologie d'évaluation
6. Planifiez des exercices réguliers de red teaming
7. Préparez des procédures de réponse aux incidents

Conclusion : Même si vous n'êtes pas dans l'UE, la loi IA fixe le standard mondial. Construire des pratiques d'évaluation et de documentation maintenant vous évite une précipitation plus tard.

Erreurs Courantes d'Évaluation (et Comment les Éviter)

Après avoir aidé des équipes à construire des pipelines d'évaluation LLM, voici les erreurs que nous voyons sans cesse :

1. Évaluer avec vos données d'entraînement — Si vos cas de test se chevauchent avec ce que le modèle a vu pendant le fine-tuning, vos scores sont sans signification. Utilisez toujours des ensembles d'évaluation retenus.
2. Utiliser BLEU/ROUGE pour les tâches ouvertes — Ces métriques mesurent le chevauchement de texte de surface. Elles ne peuvent pas détecter les hallucinations, évaluer l'utilité ou juger la qualité créative.
3. Faire confiance aveuglément aux benchmarks — La contamination des benchmarks est réelle. Les modèles entraînés sur des questions MMLU scorent bien sur MMLU mais ça ne signifie pas qu'ils performeront bien sur votre tâche spécifique. Utilisez toujours des évaluations spécifiques à l'application.
4. Sauter la calibration humaine — LLM-as-judge nécessite une validation contre des scores humains sur VOS données avant de lui faire confiance. Exécutez au moins 50 exemples à travers des réviseurs humains et le juge LLM, puis vérifiez la corrélation.
5. Évaluation unique — L'évaluation n'est pas une case à cocher au lancement. Les modèles changent, le comportement des utilisateurs évolue, et la qualité de récupération se dégrade. Rendez-la continue.
6. Même modèle comme juge et générateur — Le biais d'auto-préférence gonfle les scores. Utilisez une famille de modèles différente pour juger.
7. Ne pas versionner vos jeux de données d'évaluation — Vos évaluations devraient évoluer avec votre produit. Suivez les changements, ajoutez de nouveaux edge cases, retirez les cas de test obsolètes.
8. Ignorer le coût — Exécuter LLM-as-judge sur chaque requête de production devient cher rapidement. Échantillonnez intelligemment — 1-5% du trafic est suffisant pour la surveillance.

Comment Techsy Aborde l'Évaluation des LLM

Nous avons construit des pipelines d'évaluation pour des équipes de startups livrant des fonctionnalités LLM à travers des chatbots, systèmes RAG et agents IA. Notre engagement typique suit un pattern :

1. Audit — Nous examinons vos sorties LLM actuelles, identifions les modes d'échec et cartographions votre position sur le modèle de maturité
2. Sélection des métriques — Basé sur votre type d'application, nous définissons les 3-5 métriques qui comptent vraiment (en utilisant le framework de ce guide)
3. Création du jeu de données doré — Nous construisons votre jeu de données d'évaluation initial, incluant les edge cases adversariaux que la plupart des équipes manquent
4. Configuration du pipeline — Intégration CI/CD avec notation automatisée et gates de déploiement
5. Passation — Votre équipe en devient propriétaire, avec documentation et runbooks

La plupart des équipes n'ont pas besoin d'un partenaire externe pour ça — si vous avez un ingénieur ML et une semaine de temps dédié, ce guide vous donne tout ce dont vous avez besoin. Mais si vous manquez de temps, faites face à une échéance de conformité, ou voulez un deuxième avis expérimenté sur votre stratégie d'évaluation, nous sommes heureux d'aider.

Besoin d'aide pour construire un pipeline d'évaluation pour votre application LLM ? Obtenez une consultation gratuite

FAQ

Comment évalue-t-on les performances d'un LLM ?

Commencez par définir vos critères de succès — précision, sécurité, pertinence, ou ce qui importe pour votre cas d'utilisation. Sélectionnez 3-5 métriques correspondant à votre type d'application (voir le tableau métrique-application ci-dessus), construisez un jeu de données doré avec au moins 50 cas de test, et exécutez des évaluations automatisées en utilisant des frameworks comme DeepEval ou Ragas. Validez vos scores automatisés contre le jugement humain sur un échantillon avant de leur faire confiance.

Quelles métriques sont utilisées pour évaluer les LLM ?

Les métriques clés incluent faithfulness, answer relevancy et taux d'hallucination pour les systèmes RAG ; BLEU et ROUGE pour la traduction et le résumé ; toxicité et biais pour la sécurité ; et taux de complétion des tâches pour les agents. Les bonnes métriques dépendent de votre type d'application — un chatbot nécessite une évaluation différente d'un générateur de code.

Qu'est-ce que LLM-as-a-judge ?

Une méthode où un LLM séparé (typiquement GPT-4o ou Claude) évalue la sortie d'un autre LLM selon les critères que vous définissez. G-Eval est l'implémentation la plus populaire, utilisant la notation chain-of-thought. Les recherches montrent environ 81% de corrélation avec les notes humaines, en faisant le standard pratique pour l'évaluation quotidienne en 2026.

Comment détecter les hallucinations dans les LLM ?

Utilisez des métriques faithfulness qui comparent le texte généré aux documents sources. DeepEval et Ragas offrent tous deux une détection d'hallucination intégrée qui vérifie si chaque affirmation dans la sortie est ancrée dans le contexte fourni. Pour les systèmes de production, combinez la détection automatisée avec des spot-checks humains sur les sorties signalées.

Quel est le meilleur framework d'évaluation LLM ?

Il n'y en a pas de meilleur unique. DeepEval pour les métriques personnalisées et l'évaluation complète, Ragas pour l'évaluation spécifique au RAG, Braintrust pour l'intégration CI/CD et le blocage de déploiement, LangSmith pour les équipes utilisant déjà LangChain, et Langfuse pour l'observabilité auto-hébergée. Choisissez celui qui correspond à votre workflow.

Comment évalue-t-on un système RAG ?

Mesurez quatre métriques : faithfulness (la réponse est-elle ancrée dans le contexte ?), context relevancy (bons docs récupérés ?), context recall (tous les docs pertinents trouvés ?), et answer relevancy (adresse la requête ?). Ragas et DeepEval sont les outils standard. Crucalement, évaluez à la fois le retriever et le générateur — la plupart des équipes ne testent que le générateur et manquent les échecs de récupération.

Qu'est-ce que G-Eval ?

G-Eval est un framework LLM-as-judge qui utilise le prompting chain-of-thought pour évaluer les sorties contre des critères personnalisés. Vous décrivez ce que « bon » ressemble en français simple, et le LLM juge raisonne à travers chaque sortie et attribue un score. Le papier original de Liu et al. a montré un fort alignement avec l'évaluation humaine sur plusieurs tâches NLG.

Comment la loi IA de l'UE affecte-t-elle l'évaluation LLM ?

La loi IA de l'UE exige une évaluation systématique, une documentation et une surveillance pour les systèmes d'IA servant des utilisateurs européens. Les systèmes à haut risque doivent démontrer précision, robustesse, transparence et non-discrimination à travers des pratiques d'évaluation formelles. Même les systèmes à risque limité ont des obligations de transparence. L'application commence en août 2026, et les exigences s'appliquent à toute entreprise servant des utilisateurs de l'UE, quel que soit l'endroit où vous êtes basé.

Comment évalue-t-on les agents IA ?

Suivez le taux de complétion des tâches, la correction de l'utilisation des outils, la rétention du contexte à travers les étapes, et le coût par tâche réussie. L'évaluation d'agents nécessite des approches statistiques — exécutez la même tâche plusieurs fois et rapportez les taux de complétion, pas les résultats succès/échec uniques. L'outillage est encore précoce, mais DeepEval et AWS offrent tous deux des frameworks d'évaluation d'agents émergents.

Qu'est-ce que la contamination des benchmarks ?

Quand les données d'entraînement LLM incluent des questions de test de benchmark, les scores sont artificiellement gonflés sans refléter une véritable capacité. C'est pourquoi les benchmarks publics comme MMLU ne devraient pas être votre seule méthode d'évaluation. Les modèles peuvent scorer de manière impressionnante sur des benchmarks contaminés tout en performant mal sur des tâches réelles. Complétez toujours les benchmarks avec une évaluation spécifique à l'application sur vos propres données.

Combien coûte l'évaluation LLM ?

Les outils open source comme DeepEval et Ragas sont gratuits. LLM-as-a-judge coûte environ 0,01-0,05 € par évaluation selon le modèle juge. Les plateformes commerciales comme Braintrust et LangSmith ont des niveaux gratuits pour les petites équipes et des plans payants pour l'utilisation en production. L'évaluation humaine coûte 5-50 € par évaluation. La plupart des équipes peuvent faire fonctionner un solide pipeline d'évaluation pour moins de 100 €/mois.

Sources

• Documentation DeepEval – Métriques
• Documentation Ragas – Métriques
• Documentation Braintrust – Évaluations
• Documentation LangSmith – Évaluation
• Documentation Langfuse – Scores et Évaluation
• Documentation Arize Phoenix
• Loi IA de l'UE – Texte Complet (Règlement 2024/1689)
• Loi IA de l'UE – Classification des Risques (Commission européenne)
• Judging LLM-as-a-Judge – Zheng et al., 2023
• G-Eval: NLG Evaluation using GPT-4 – Liu et al., 2023
• How to Build an LLM Evaluation Framework – The Pragmatic Engineer