On a tous déjà vécu ça. Tu changes de modèle, tu changes de prompt, tu changes deux ou trois paramètres… et tu as l’impression que « c’est mieux ». Plus fluide. Plus confiant. Plus rapide.
Puis, deux jours après, tu tombes sur un cas réel. Une demande utilisateur un peu tordue, une contrainte métier, une edge case système. Et là… ça craque. Tu te rends compte que tu as surtout progressé en « sensation de qualité ». Pas forcément en qualité.
Le problème, c’est qu’un LLM peut donner une impression de progrès sans progresser là où ça compte pour toi. Et si tu bosses en productivité, en automatisation, en sysadmin, en growth, en contenu, ou même juste en « je veux que ça marche proprement »… tu as besoin de métriques qui coupent court à l’auto intoxication.
Dans cet article, je te propose 7 métriques. Pas les trucs de paper académique que personne ne déploie. Plutôt des métriques qui tiennent dans un Notion, un Google Sheet, un script Python, ou un petit banc de tests maison. Des métriques qui te disent vite si ton LLM améliore ton système… ou juste ton confort.
Petite note : sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), j’essaie de publier ce genre de méthodes « build, scale, sell » avec du concret. Si tu veux, tu peux garder le site en favori, je remets souvent à jour mes checklists et trackers.
1. Taux de réussite sur tâches critiques (task success rate)
Si tu ne gardes qu’une seule métrique, garde celle-là.
Le « taux de réussite » sur un set de tâches critiques, c’est juste : combien de fois le modèle fait ce que tu attends, sans bidouille humaine.
Mais attention, ce n’est pas « est-ce que la réponse est sympa ». C’est binaire, ou quasi binaire.
Exemples de tâches critiques selon ton contexte :
- Sysadmin : produire une commande
rsynccorrecte avec exclusions, sans détruire le répertoire cible. - Growth : générer 10 angles d’accroche non redondants, chacun avec une promesse et un mécanisme.
- Prompt engineering : respecter une structure de sortie JSON stricte, parseable, sans texte autour.
- Support interne : répondre en citant uniquement des sources autorisées, et refuser le reste.
Comment le mesurer sans te compliquer la vie :
- Tu prends 30 à 200 cas réels (pas des cas inventés au propre).
- Tu écris une « règle de réussite » claire.
- Tu notes succès / échec / partiel.
- Tu compares modèle A vs modèle B, ou prompt A vs prompt B.
Ce que ça évite : le faux progrès « ça sonne mieux ». Parce que parfois, le modèle te donne un texte plus agréable… mais il échoue plus souvent sur la contrainte.
2. Taux de conformité au format (format compliance rate)
Dans la vraie vie, on ne demande pas juste du texte. On demande du texte qui rentre dans un pipeline. Une automatisation. Un champ CRM. Un parseur. Une API. Un tableau.
Donc une métrique simple et ultra violente : est-ce que la sortie respecte le format demandé ?
Ça peut être :
- JSON valide (et qui respecte le schéma).
- Markdown avec sections attendues.
- Table CSV sans colonnes manquantes.
- Réponse en deux parties « résumé » puis « actions ».
- Langue, ton, longueur, etc.
Mesure minimale :
% de sorties parseables.% de sorties conformes au schéma.
Tu peux automatiser une partie : validation JSON, validation YAML, regex, JSON Schema. Et pour le reste, revue humaine rapide.
Ce que ça évite : le modèle qui « parle bien » mais qui casse ton automatisation une fois sur trois. Et toi tu te retrouves à patcher au lieu de scaler.
3. Taux d’hallucination vérifiable (verifiable hallucination rate)
Oui, les hallucinations, tout le monde en parle. Mais on les mesure rarement bien.
Je te propose une version praticable : hallucination vérifiable. Pas « je n’aime pas la réponse ». Plutôt : le modèle affirme un fait, un chiffre, une commande, une API, un endpoint, une option… qui est faux.
Exemples :
- Il invente une option
--fastsurtar. - Il cite une loi, une norme, un prix, une version, qui n’existe pas.
- Il prétend qu’une fonctionnalité est dispo dans un outil alors qu’elle ne l’est pas.
Méthode simple :
- Sur ton set de tests, tu marques les affirmations vérifiables.
- Tu en vérifies un échantillon (ou toutes sur les tâches critiques).
- Tu notes : faux / non vérifiable / vrai.
Et tu sors une métrique :
hallucination_rate = faux / (faux + vrai)sur les affirmations vérifiables.
Ce que ça évite : le modèle « très sûr de lui » qui te fait perdre une heure, ou qui te pousse à déployer une mauvaise config.
4. Robustesse au prompt (prompt sensitivity score)
Tu veux éviter un système fragile. Celui où, si tu changes une virgule, tout change. Celui où ton collègue copie colle le prompt, mais en retire une ligne, et ton agent part en freestyle.
Donc on mesure la robustesse : à quel point la performance varie quand le prompt change un peu.
Variables à faire varier sur une même tâche
- La formulation (synonymes).
- L'ordre des contraintes.
- La présence ou non d'un exemple.
- La longueur du contexte.
- Le style d'instruction (directif vs descriptif).
Ce que tu observes ensuite
- Variation du taux de réussite.
- Variation de conformité au format.
- Variation des erreurs.
Tu peux résumer en un score simple : robustesse = 1 - (écart-type des résultats) sur plusieurs variantes.
Ce que ça évite : croire que « ça marche » alors que ça marche uniquement avec ton prompt fétiche, dans ton chat, un mardi.
5. Taux de récupération après erreur (self-correction rate)
Une bonne partie de la valeur d'un LLM en production, ce n'est pas juste de réussir du premier coup. C'est de se corriger quand tu lui dis : « non, tu as cassé la contrainte ».
Tu peux tester ça de manière très concrète. Tu exécutes d'abord la tâche, puis tu forces une boucle de feedback standardisée, et enfin tu mesures en combien d'itérations le modèle revient dans les clous.
Exemples de feedback standardisé
- « La sortie n'est pas un JSON valide, corrige sans ajouter de texte. »
- « Tu as dépassé 120 mots, réécris en 120 mots max. »
- « Tu as inventé une source, retire tout ce qui n'est pas sourcé. »
Métriques possibles
% corrigé en 1 itération.% corrigé en ≤ 2 itérations.nombre moyen d'itérations.
Ce que ça évite : un modèle qui paraît fort, mais qui se défend au lieu de corriger. Ou qui corrige un point, puis casse un autre point.
6. Coût par succès (cost per successful task)
Celle-là, elle fait mal, mais elle te garde honnête.
Parce qu’un modèle peut être meilleur… mais tellement plus cher que ton ROI s’écroule. Ou il peut être moins bon, mais suffisamment moins cher pour que tu acceptes un petit taux d’échec.
Tu mesures donc :
- Coût tokens entrée + sortie.
- Coût des retries.
- Coût des appels outils (si agent).
- Coût humain de vérification, si tu peux l’estimer.
Et tu ramènes tout à une unité utile :
coût_par_succès = coût_total / nombre_de_succès.
Tu peux même faire deux versions :
- coût par succès strict (réussite parfaite).
- coût par succès utile (réussite « utilisable » avec retouche légère).
Ce que ça évite : te faire séduire par un modèle premium qui te donne 3 pour cent de qualité en plus, mais 5 fois le coût.
7. Stabilité inter-runs (variance) et reproductibilité
Tu lances exactement la même requête, même contexte, même prompt… et tu n’obtiens pas la même chose. Normal, il y a la génération stochastique. Mais en production, tu veux savoir à quel point ça bouge.
Donc on mesure la stabilité.
Tu fais par exemple 10 runs par cas, ou 5 runs si tu veux rester rapide, et tu mesures :
% de réussite moyen.% de conformité format moyen.- Variance du score.
Si tu as une évaluation automatique (regex, parse, tests), c’est facile. Sinon, tu fais une revue humaine sur un échantillon.
Ce que ça évite : un modèle qui « peut réussir », mais qui réussit 1 fois sur 5. Super en démo. Moins super quand tu automatises un process.
Comment assembler ces métriques sans te noyer
Je te donne une manière simple de tout combiner, que j’utilise quand je veux trancher vite.
Étape 1 : crée ton jeu de tests minimal
- 50 cas réels.
- 10 cas « pièges » (format strict, contradictions, données manquantes).
- 10 cas « dangereux » (commandes destructrices, sécurité, permissions, etc.).
Étape 2 : note 4 choses pour chaque cas
- Succès tâche : oui / non / partiel.
- Format ok : oui / non.
- Hallucination vérifiable : oui / non / NA.
- Nombre d’itérations pour corriger.
Étape 3 : ajoute le coût
- Tokens.
- Retries.
- Temps humain estimé.
Et là tu peux faire une petite synthèse type tableau de bord.
Le piège classique : optimiser une métrique et dégrader le reste
Un exemple très fréquent :
Tu pousses le modèle à être ultra strict sur le JSON. Super, le parse passe.
Mais il devient plus court, plus sec, et il perd en « réussite tâche » parce qu’il n’explique plus assez, ou qu’il oublie des détails utiles. Ou il respecte le format… avec des champs vides.
Donc, au lieu d’un score unique magique, garde une vision à 2 ou 3 axes :
- qualité utile (succès tâche).
- fiabilité (format, stabilité, correction).
- coût.
Tu peux même faire une règle brutale :
- Si conformité format < 98 % sur pipeline critique, rejet.
- Si hallucination vérifiable > X %, rejet.
- Sinon, arbitrage coût vs succès.
Mini checklist à copier coller (pour tes tests maison)
- « Est-ce que ça réussit les tâches critiques, oui ou non ? »
- « Est-ce que c’est parseable, à chaque fois ? »
- « Est-ce que ça invente des faits ou des options de commande ? »
- « Est-ce que ça casse si je reformule un peu le prompt ? »
- « Est-ce que ça se corrige vite quand je le recadre ? »
- « Combien ça me coûte par tâche réellement réussie ? »
- « Est-ce que ça varie trop d’un run à l’autre ? »
Si tu appliques ça, tu vas arrêter de « ressentir » le progrès. Tu vas le mesurer. Et en général, tu vas aussi simplifier tes systèmes, parce que tu vas voir où ça casse vraiment.
Conclusion : des métriques qui te protègent, pas qui t’impressionnent
Évaluer un LLM, ce n’est pas faire joli. C’est éviter de déployer une illusion.
Les 7 métriques ci-dessus ont un point commun : elles sont reliées à la réalité. À tes tâches. Tes contraintes. Ton budget. Ta prod. Ton temps.
Et si tu veux une suite logique à cet article, je peux publier sur Le Blog Tech Pro de Samyn-Antoy ABASSE un template de banc de tests (Google Sheet + structure de prompts + règles de scoring), version simple, sans usine à gaz. Tu peux passer sur https://monblog-sa-abasse.blogspot.com et jeter un œil aux pages ressources et méthodes, j’y ajoute souvent des outils prêts à l’emploi.
Parce qu’au final, le bon LLM… c’est celui qui te fait gagner du temps sans te créer un autre job : celui de réparer ses erreurs.
Questions fréquemment posées
Pourquoi la sensation de qualité d'un LLM peut être trompeuse ?
La sensation de qualité peut être trompeuse car un LLM peut sembler plus fluide, confiant ou rapide sans réellement améliorer la qualité là où cela compte, notamment face à des cas réels complexes ou des contraintes métier spécifiques.
Quelle est la métrique la plus importante pour évaluer un LLM selon l'article ?
Le taux de réussite sur tâches critiques est la métrique clé. Elle mesure combien de fois le modèle accomplit correctement une tâche spécifique sans intervention humaine, offrant une évaluation binaire ou quasi binaire de la performance réelle.
Comment mesurer efficacement le taux de réussite sur des tâches critiques ?
Il faut utiliser entre 30 et 200 cas réels, définir une règle claire de réussite, noter chaque résultat comme succès, échec ou partiel, puis comparer différentes versions du modèle ou prompts pour voir les progrès réels.
Qu'est-ce que le taux de conformité au format et pourquoi est-il important ?
Le taux de conformité au format mesure si la sortie du modèle respecte le format attendu (JSON valide, Markdown structuré, CSV complet, etc.), ce qui est crucial pour assurer l'intégration dans des pipelines automatisés et éviter les erreurs en production.
Comment peut-on automatiser la vérification du format des sorties d'un LLM ?
On peut automatiser cette vérification via des validations JSON ou YAML, l'utilisation de schémas JSON Schema, des expressions régulières (regex), et compléter par une revue humaine rapide pour s'assurer du respect total du format.
Qu'est-ce que le taux d'hallucination vérifiable dans le contexte des LLM ?
Le taux d'hallucination vérifiable correspond à la fréquence à laquelle un modèle affirme des informations incorrectes ou inventées qui peuvent être objectivement vérifiées comme fausses, ce qui aide à quantifier les erreurs factuelles plutôt que subjectives.
0 Commentaires