En résumé : définissez les critères d’une performance optimale pour votre cas d’utilisation, puis effectuez des tests avec des invites représentatives et versionnées, ainsi qu’avec des cas limites. Associez des métriques automatisées à une évaluation humaine, en intégrant des contrôles de sécurité contre les attaques adverses et l’injection d’invites. Si des contraintes de coût ou de latence s’avèrent contraignantes, comparez les modèles en fonction du taux de réussite des tâches par euro dépensé et des temps de réponse p95/p99.
Points clés à retenir :
Responsabilité : Désignez des responsables clairement identifiés, conservez les journaux de versions et relancez les évaluations après chaque modification d'invite ou de modèle.
Transparence : Notez les critères de réussite, les contraintes et les coûts d'échec avant de commencer à collecter les scores.
Auditabilité : Maintenir des suites de tests reproductibles, des ensembles de données étiquetés et des métriques de latence p95/p99 suivies.
Contestabilité : Utiliser des grilles d'évaluation humaine et une procédure d'appel définie pour les résultats contestés.
Résistance aux abus : injection de messages d’alerte par une équipe rouge, sujets sensibles et refus excessifs pour protéger les utilisateurs.
Si vous choisissez un modèle pour un produit, un projet de recherche ou même un outil interne, vous ne pouvez pas vous contenter de dire « ça a l'air intelligent » et de le déployer (voir le guide d'évaluation d'OpenAI et le NIST AI RMF 1.0 ). C'est comme ça qu'on se retrouve avec un chatbot qui explique avec assurance comment faire chauffer une fourchette au micro-ondes. 😬
Articles que vous pourriez aimer lire après celui-ci :
🔗 L'avenir de l'IA : les tendances qui façonneront la prochaine décennie.
Innovations clés, impact sur l'emploi et éthique à surveiller.
🔗 Modèles fondamentaux de l'IA générative expliqués aux débutants :
découvrez ce qu'ils sont, comment ils sont entraînés et pourquoi ils sont importants.
🔗 Comment l'IA affecte l'environnement et la consommation d'énergie :
découvrez les émissions, la demande en électricité et les moyens de réduire votre empreinte écologique.
🔗 Comment fonctionne la mise à l'échelle par IA pour des images plus nettes aujourd'hui ?
Découvrez comment les modèles ajoutent des détails, suppriment le bruit et agrandissent proprement.
1) Définir ce qui est « bon » (cela dépend, et c'est normal) 🎯
Avant toute évaluation, définissez ce que représente le succès. Sinon, vous mesurerez tout sans rien apprendre. C'est comme venir juger un concours de gâteaux avec un mètre ruban : vous obtiendrez des chiffres, certes, mais ils ne vous apprendront pas grand-chose 😅
Clarifier:
-
Objectif de l'utilisateur : résumé, recherche, rédaction, raisonnement, extraction de faits
-
Coût de l'échec : une mauvaise recommandation de film est drôle ; une mauvaise instruction médicale ne l'est pas (cadrage des risques : NIST AI RMF 1.0 ).
-
Environnement d'exécution : sur l'appareil, dans le cloud, derrière un pare-feu, dans un environnement réglementé
-
Contraintes principales : latence, coût par requête, confidentialité, explicabilité, prise en charge multilingue, contrôle du ton
Un mannequin qui excelle dans un domaine peut être un désastre dans un autre. Ce n'est pas une contradiction, c'est la réalité. 🙂
2) À quoi ressemble un cadre d'évaluation robuste pour les modèles d'IA 🧰
Oui, c'est l'étape que beaucoup négligent. Ils choisissent un benchmark, l'exécutent une fois et s'arrêtent là. Un cadre d'évaluation robuste présente quelques caractéristiques essentielles (exemples d'outils pratiques : OpenAI Evals / Guide OpenAI Evals ) :
-
Reproductible – vous pouvez le refaire la semaine prochaine et vous fier aux comparaisons.
-
Représentatif – il reflète vos utilisateurs et vos tâches réels (et pas seulement des détails insignifiants).
-
Multi-niveaux - combine des mesures automatisées, une vérification humaine et des tests contradictoires
-
Exploitable – les résultats vous indiquent ce qu’il faut corriger, et pas seulement « le score a baissé ».
-
Inviolable – évite les manipulations accidentelles et les fuites accidentelles
-
Soucieux des coûts – l’évaluation elle-même ne devrait pas vous ruiner (à moins que vous n’aimiez souffrir).
Si votre évaluation ne résiste pas à l'avis sceptique d'un collègue qui dit « D'accord, mais transposons cela en production », alors elle n'est pas encore terminée. C'est le test de validation.
3) Comment évaluer les modèles d'IA en commençant par des cas d'utilisation concrets 🍰
Voici une astuce qui permet de gagner énormément de temps : diviser le cas d’utilisation en tranches .
Au lieu de « évaluer le modèle », faites :
-
Compréhension de l'intention (le système obtient-il ce que l'utilisateur souhaite ?)
-
Utilisation du contexte ou de la récupération (utilise-t-elle correctement les informations fournies ?)
-
Raisonnement / tâches à plusieurs étapes (la cohérence se maintient-elle d'une étape à l'autre ?)
-
Mise en forme et structure (respecte-t-il les instructions ?)
-
Alignement entre sécurité et politique (évite-t-il les contenus non sécurisés ? Voir NIST AI RMF 1.0 )
-
Ton et identité de marque (le son correspond-il à ce que vous souhaitez)
Cela donne à « Comment évaluer les modèles d'IA » l'allure moins d'un seul et unique examen que d'une série de quiz ciblés. Les quiz sont agaçants, mais gérables. 😄
4) Principes de base de l'évaluation hors ligne : ensembles de tests, étiquettes et les détails peu attrayants mais importants 📦
L'évaluation hors ligne consiste à effectuer des tests contrôlés avant que les utilisateurs ne touchent à quoi que ce soit (modèles de flux de travail : OpenAI Evals ).
Constituez ou rassemblez un ensemble de tests qui vous soit véritablement propre
Un bon ensemble de tests comprend généralement :
-
Exemples en or : des résultats idéaux que vous seriez fiers de livrer
-
Cas particuliers : invites ambiguës, entrées mal structurées, formatage inattendu
-
Sondes de défaillance : incitations susceptibles de provoquer des hallucinations ou des réponses dangereuses (cadre de test des risques : NIST AI RMF 1.0 )
-
Couverture de la diversité : différents niveaux de compétences des utilisateurs, dialectes, langues, domaines
Si vous ne testez que sur des invites « propres », le modèle semblera parfait. Mais voilà, vos utilisateurs font des fautes de frappe, des phrases incomplètes et cliquent de manière frénétique. Bienvenue dans la réalité.
Choix d'étiquetage (ou : niveaux de rigueur)
Vous pouvez étiqueter les sorties comme suit :
-
Binaire : réussite/échec (rapide, brutal)
-
Ordinale : score de qualité de 1 à 5 (nuancé, subjectif)
-
Multi-attributs : exactitude, exhaustivité, ton, utilisation des citations, etc. (meilleur résultat, plus lent)
L'analyse multi-attributs est idéale pour de nombreuses équipes. C'est comme déguster un plat et juger le sel indépendamment de sa texture. Sinon, on se contente de dire « c'est bon » et on hausse les épaules.
5) Des indicateurs qui ne mentent pas – et des indicateurs qui, eux, mentent un peu 📊😅
Les indicateurs sont précieux… mais ils peuvent aussi être une véritable bombe à retardement. Brillants, omniprésents et difficiles à maîtriser.
Familles métriques communes
-
Précision / correspondance exacte : idéal pour l'extraction, la classification et les tâches structurées
-
F1 / précision / rappel : utile lorsque manquer quelque chose est pire que du bruit supplémentaire (définitions : scikit-learn précision/rappel/score F )
-
Chevauchement des styles BLEU et ROUGE : acceptable pour les tâches de résumé, souvent trompeur (métriques originales : BLEU et ROUGE )
-
Intégration de similarité : utile pour la correspondance sémantique, peut récompenser les réponses incorrectes mais similaires.
-
Taux de réussite des tâches : « L’utilisateur a-t-il obtenu ce dont il avait besoin ? » constitue la référence absolue lorsqu’il est bien défini.
-
Conformité aux contraintes : respect du format, de la longueur, de la validité JSON et du schéma.
Le point clé
Si votre tâche est ouverte (écriture, raisonnement, assistance par chat), les indicateurs numériques uniques peuvent être… peu fiables. Pas inutiles, juste peu fiables. Mesurer la créativité avec une règle est possible, mais vous vous sentirez ridicule. (Et vous risquez de vous crever un œil.)
Donc : utilisez des indicateurs, mais ancrez-les à une évaluation humaine et aux résultats réels des tâches (un exemple de discussion d'évaluation basée sur LLM + mises en garde : G-Eval ).
6) Tableau comparatif - meilleures options d'évaluation (avec ses particularités, car la vie est pleine de particularités) 🧾✨
Voici un éventail pratique de méthodes d'évaluation. Combinez-les à votre guise. La plupart des équipes le font.
| Outil / Méthode | Public | Prix | Pourquoi ça marche |
|---|---|---|---|
| Suite de tests d'invite de commande conçue à la main | Produit + ingénieur | $ | Très ciblé, détecte rapidement les régressions - mais vous devez le maintenir en permanence 🙃 (outils de démarrage : OpenAI Evals ) |
| panel d'évaluation humaine | Équipes pouvant se permettre de détacher des relecteurs | $$ | Idéal pour le ton, les nuances, la question de savoir si un être humain accepterait cela, avec un léger chaos selon les critiques |
| LLM en tant que juge (avec rubriques) | Boucles d'itération rapides | $-$$ | Rapide et évolutif, mais peut hériter de biais et parfois évaluer les impressions plutôt que les faits (recherche + problèmes de biais connus : G-Eval ). |
| sprint d'équipe rouge adverse | Sécurité et conformité | $$ | Détecte des modes de défaillance complexes, notamment l'injection de vulnérabilités – c'est comme un test de résistance à la salle de sport (aperçu des menaces : OWASP LLM01 Injection de vulnérabilités / OWASP Top 10 pour les applications LLM ). |
| génération de tests synthétiques | équipes légères en données | $ | Excellente couverture, mais les suggestions synthétiques sont parfois trop polies, trop convenues… or, les utilisateurs ne sont pas polis |
| Tests A/B avec de vrais utilisateurs | Produits matures | $$$ | Le signal le plus clair – et aussi le plus stressant émotionnellement – lorsque les indicateurs fluctuent (guide pratique classique : Kohavi et al., « Expériences contrôlées sur le Web » ). |
| Évaluation fondée sur la récupération (contrôles RAG) | Applications de recherche et de questions-réponses | $$ | Les mesures « utilisent correctement le contexte », réduisent l’inflation du score d’hallucination (aperçu de l’évaluation RAG : Évaluation de RAG : Une enquête ) |
| Surveillance et détection de dérive | Systèmes de production | $$-$$$ | Détecte la dégradation au fil du temps - discret jusqu'au jour où cela vous sauve la mise 😬 (aperçu de la dérive : étude conceptuelle de la dérive (PMC) ) |
Notez que les prix sont volontairement variables. Ils dépendent de l'échelle du projet, des outils utilisés et du nombre de réunions que vous générez accidentellement.
7) L'évaluation humaine : l'arme secrète que l'on sous-finance 👀🧑⚖️
Si vous vous contentez d'une évaluation automatisée, vous passerez à côté de :
-
Incohérence de ton (« pourquoi est-ce si sarcastique ? »)
-
Des erreurs factuelles subtiles qui paraissent fluides
-
Implications néfastes, stéréotypes ou formulations maladroites (cadrage risque + biais : NIST AI RMF 1.0 )
-
Des échecs dans le respect des consignes qui paraissent encore « intelligents »
Rendez les critères d'évaluation concrets (sinon les évaluateurs improviseront)
Mauvaise rubrique : « Serviabilité »
Meilleure rubrique :
-
Exactitude : factuellement exact compte tenu de la consigne et du contexte.
-
Exhaustivité : aborde les points essentiels sans digressions.
-
Clarté : lisible, structuré, confusion minimale
-
Politique / sécurité : évite les contenus restreints, gère bien les refus (cadre de sécurité : NIST AI RMF 1.0 )
-
Style : correspond à la voix, au ton et au niveau de lecture
-
Fidélité : ne s'appuie pas sur des sources ou des affirmations non étayées.
Il est également important de procéder régulièrement à des vérifications inter-évaluateurs. Si deux évaluateurs sont constamment en désaccord, il ne s'agit pas d'un problème humain, mais d'un problème lié à la grille d'évaluation. (Principes de base de la fiabilité inter-évaluateurs : McHugh sur le kappa de Cohen ).
8) Comment évaluer les modèles d'IA en termes de sécurité, de robustesse et, surtout, d'expérience utilisateur ? 🧯🧪
Voici la partie que vous effectuez avant le lancement – et que vous continuez à faire, car Internet ne dort jamais.
Des tests de robustesse à inclure
-
Fautes de frappe, argot, grammaire incorrecte
-
Des amorces très longues et des amorces très courtes
-
Instructions contradictoires (« soyez bref mais incluez tous les détails »)
-
Conversations à plusieurs tours où les utilisateurs modifient leurs objectifs
-
Tentatives d'injection de prompt (« ignorer les règles précédentes… ») (détails de la menace : OWASP LLM01 Injection de prompt )
-
Sujets sensibles nécessitant un refus prudent (cadrage des risques/de la sécurité : NIST AI RMF 1.0 )
L'évaluation de la sécurité ne se résume pas à « est-ce que ça refuse ? »
Un bon modèle devrait :
-
Refuser les demandes dangereuses de manière claire et calme (cadre de référence : NIST AI RMF 1.0 )
-
Proposez des solutions de rechange plus sûres lorsque cela est approprié
-
Évitez de refuser systématiquement les requêtes inoffensives (faux positifs)
-
Répondre aux demandes ambiguës en posant des questions de clarification (lorsque cela est autorisé)
Le refus excessif est un véritable problème pour les produits. Les utilisateurs n'aiment pas être traités comme des lutins suspects. 🧌 (Même s'ils le sont.)
9) Coût, latence et réalité opérationnelle - l'évaluation que tout le monde oublie 💸⏱️
Un modèle peut être « incroyable » et pourtant ne pas vous convenir s'il est lent, coûteux ou fragile sur le plan opérationnel.
Évaluer:
-
Distribution de la latence (pas seulement la moyenne - les percentiles 95 et 99 sont importants) (pourquoi les percentiles sont importants : Guide pratique Google SRE sur la surveillance )
-
Coût par tâche réussie (et non coût par jeton pris isolément)
-
Stabilité sous charge (délai d'attente, limites de débit, pics anormaux)
-
Fiabilité des appels d'outils (s'ils utilisent des fonctions, se comportent-ils correctement ?)
-
Tendances en matière de longueur des résultats (certains modèles sont verbeux, et les digressions coûtent cher)
Un modèle légèrement moins performant, mais deux fois plus rapide, peut s'avérer plus efficace en pratique. Cela paraît évident, et pourtant, on l'oublie souvent. C'est comme acheter une voiture de sport pour faire ses courses et se plaindre ensuite du volume du coffre.
10) Un flux de travail simple et complet que vous pouvez copier (et adapter) 🔁✅
Voici une méthode pratique pour évaluer les modèles d'IA sans se perdre dans des expériences sans fin :
-
Définir le succès : tâche, contraintes, coûts de l'échec
-
Créez un petit ensemble de tests « de base » : 50 à 200 exemples reflétant une utilisation réelle.
-
Ajouter des ensembles de vulnérabilités et d'adversaires : tentatives d'injection, invites ambiguës, sondes de sécurité (classe d'injection d'invite : OWASP LLM01 )
-
Effectuer des vérifications automatisées : formatage, validité JSON, exactitude de base lorsque cela est possible.
-
Effectuer une évaluation humaine : examiner les résultats par catégorie et les noter à l’aide d’une grille d’évaluation.
-
Comparer les compromis : qualité vs coût vs latence vs sécurité
-
Projet pilote à diffusion limitée : tests A/B ou déploiement progressif (guide des tests A/B : Kohavi et al. )
-
Surveillance en production : dérive, régressions, boucles de rétroaction des utilisateurs (aperçu de la dérive : enquête sur la dérive conceptuelle (PMC) )
-
Itérer : mettre à jour les invites, la récupération, le réglage fin, les garde-fous, puis relancer l’évaluation (modèles d’itération d’évaluation : guide des évaluations OpenAI )
Conservez des journaux versionnés. Non pas parce que c'est amusant, mais parce que votre futur vous remerciera en sirotant un café et en murmurant « qu'est-ce qui a changé… » ☕🙂
11) Pièges courants (ou comment les gens se trompent eux-mêmes sans le vouloir) 🪤
-
Formation axée sur le test : vous optimisez les invites jusqu’à ce que le résultat de référence soit excellent, mais les utilisateurs en pâtissent.
-
Fuite de données d'évaluation : les invites de test apparaissent dans les données d'entraînement ou de réglage fin (oups !).
-
Culte d'un seul indicateur : la poursuite d'un score unique qui ne reflète pas la valeur pour l'utilisateur
-
Ignorer le changement de distribution : le comportement des utilisateurs change et votre modèle se dégrade discrètement (cadrage des risques de production : enquête sur la dérive du concept (PMC) )
-
Survalorisation de l'« intelligence » : un raisonnement astucieux importe peu s'il enfreint la mise en page ou invente des faits.
-
Ne pas tester la qualité du refus : un « non » peut être justifié, mais l'expérience utilisateur reste déplorable.
Attention également aux démos. Les démos sont comme des bandes-annonces de films : elles montrent les moments forts, cachent les passages plus lents et parfois même mentent avec une musique dramatique. 🎬
12) Résumé final sur l'évaluation des modèles d'IA 🧠✨
L'évaluation des modèles d'IA ne se résume pas à une simple note, mais à un repas équilibré. Il faut des protéines (exactitude), des légumes (sécurité), des glucides (rapidité et coût), et parfois même un dessert (plaisir et satisfaction) 🍲🍰 (cadrage des risques : NIST AI RMF 1.0 )
Si vous ne retenez rien d'autre :
-
Définissez ce que signifie « bon » pour votre cas d'utilisation
-
Utilisez des ensembles de tests représentatifs, et pas seulement des benchmarks célèbres
-
Combiner les mesures automatisées avec une évaluation humaine par grille d'analyse
-
Tester la robustesse et la sécurité comme si les utilisateurs étaient hostiles (car parfois… ils le sont) (classe d'injection prompte : OWASP LLM01 )
-
Intégrez le coût et la latence dans l'évaluation, et non comme une simple réflexion après coup (pourquoi les percentiles sont importants : Google SRE Workbook ).
-
Suivi après lancement - dérive des modèles, évolution des applications, créativité humaine (aperçu de la dérive : enquête sur la dérive des concepts (PMC) )
Voici comment évaluer les modèles d'IA de manière à ce qu'ils restent pertinents lorsque votre produit est en production et que les utilisateurs commencent à adopter des comportements imprévisibles. Ce qui est toujours le cas. 🙂
FAQ
Quelle est la première étape pour évaluer les modèles d'IA pour un produit réel ?
Commencez par définir ce que signifie « bon » pour votre cas d'utilisation spécifique. Précisez l'objectif de l'utilisateur, le coût des échecs (faibles ou importants enjeux) et l'environnement d'exécution du modèle (cloud, appareil, environnement réglementé). Ensuite, listez les contraintes essentielles telles que la latence, le coût, la confidentialité et le contrôle du ton. Sans ces bases, vous risquez de multiplier les mesures et de prendre une mauvaise décision.
Comment puis-je constituer un ensemble de tests qui reflète véritablement mes utilisateurs ?
Créez un ensemble de tests qui vous soit propre, et non un simple référentiel public. Incluez des exemples de référence que vous seriez fier de déployer, ainsi que des requêtes complexes et réalistes, avec des fautes de frappe, des phrases incomplètes et des demandes ambiguës. Ajoutez des cas limites et des tests de défaillance susceptibles de provoquer des erreurs ou des réponses inappropriées. Veillez à couvrir la diversité des niveaux de compétence, des dialectes, des langages et des domaines afin d'éviter des résultats erronés en production.
Quels indicateurs dois-je utiliser, et lesquels peuvent être trompeurs ?
Adaptez les métriques au type de tâche. La correspondance exacte et la précision sont pertinentes pour l'extraction et les résultats structurés, tandis que la précision/le rappel et le score F1 sont utiles lorsque l'absence d'information est plus problématique que du bruit supplémentaire. Les métriques de chevauchement comme BLEU/ROUGE peuvent induire en erreur pour les tâches ouvertes, et l'intégration de la similarité peut valoriser les réponses « fausses mais similaires ». Pour la rédaction, le support ou le raisonnement, combinez les métriques avec la validation humaine et les taux de réussite des tâches.
Comment structurer les évaluations pour qu'elles soient reproductibles et utilisables en production ?
Un cadre d'évaluation robuste est reproductible, représentatif, multicouche et exploitable. Il combine des contrôles automatisés (format, validité JSON, exactitude de base) avec une évaluation humaine basée sur une grille d'évaluation et des tests contradictoires. Il garantit son intégrité en évitant les fuites de données et en optimisant l'apprentissage en fonction des tests. Veillez à ce que l'évaluation soit économique afin de pouvoir la réexécuter fréquemment, et pas seulement une fois avant le lancement.
Quelle est la meilleure façon de procéder à une évaluation humaine sans que cela ne dégénère en chaos ?
Utilisez une grille d'évaluation précise pour éviter que les évaluateurs n'improvisent. Évaluez des critères tels que l'exactitude, l'exhaustivité, la clarté, le respect des règles de sécurité et des politiques, la cohérence du style et du ton, et la fidélité (absence d'invention de sources ou d'affirmations). Vérifiez régulièrement la concordance entre les évaluateurs ; en cas de désaccords constants, la grille d'évaluation nécessite probablement d'être affinée. L'évaluation humaine est particulièrement précieuse pour détecter les incohérences de ton, les erreurs factuelles subtiles et les manquements au respect des consignes.
Comment évaluer la sécurité, la robustesse et les risques liés à l'injection rapide ?
Testez avec des entrées utilisateur problématiques : fautes de frappe, argot, instructions contradictoires, invites très longues ou très courtes, et modifications d’objectifs en plusieurs étapes. Intégrez des tentatives d’injection d’invites comme « ignorer les règles précédentes » et abordez les sujets sensibles nécessitant des refus prudents. Une bonne sécurité ne se limite pas à refuser : elle consiste à refuser clairement, à proposer des alternatives plus sûres le cas échéant et à éviter de refuser systématiquement les requêtes inoffensives, ce qui nuit à l’expérience utilisateur.
Comment évaluer le coût et la latence de manière à refléter la réalité ?
Ne vous contentez pas de mesurer des moyennes ; suivez la distribution de la latence, notamment les latences p95 et p99. Évaluez le coût par tâche réussie, et non le coût par jeton isolément, car les tentatives de reprise et les résultats incohérents peuvent annuler les économies réalisées. Testez la stabilité sous charge (délai d'attente, limites de débit, pics) et la fiabilité des appels d'outils et de fonctions. Un modèle légèrement moins performant, mais deux fois plus rapide ou plus stable, peut s'avérer un meilleur choix.
Quel est un flux de travail simple et complet pour évaluer les modèles d'IA ?
Définissez les critères de réussite et les contraintes, puis créez un petit ensemble de tests de base (environ 50 à 200 exemples) reflétant une utilisation réelle. Ajoutez des ensembles de tests de sécurité et des ensembles adverses pour simuler des tentatives d'injection. Exécutez des contrôles automatisés, puis échantillonnez les résultats pour une évaluation humaine. Comparez la qualité, le coût, la latence et la sécurité, effectuez un test pilote avec un déploiement limité ou un test A/B, et surveillez en production les dérives et les régressions.
Quelles sont les erreurs les plus fréquentes que commettent les équipes lors de l'évaluation de modèles ?
Parmi les pièges courants, citons l'optimisation des invites pour atteindre un score de référence élevé au détriment de l'expérience utilisateur, l'intégration d'invites d'évaluation dans les données d'entraînement ou de réglage fin, et le culte d'une seule métrique qui ne reflète pas la valeur ajoutée pour l'utilisateur. Les équipes négligent également les variations de distribution, privilégient l'« intelligence » au détriment du respect du format et de la fidélité, et omettent les tests de qualité liés au refus. Les démonstrations peuvent masquer ces problèmes ; il est donc préférable de privilégier les évaluations structurées aux présentations de performances exceptionnelles.
Références
-
OpenAI - Guide d'évaluation OpenAI - platform.openai.com
-
Institut national des normes et de la technologie (NIST) - Cadre de gestion des risques liés à l'IA (AI RMF 1.0) - nist.gov
-
OpenAI - openai/evals (dépôt GitHub) - github.com
-
scikit-learn - precision_recall_fscore_support - scikit-learn.org
-
Association for Computational Linguistics (ACL Anthology) - BLEU - aclanthology.org
-
Association for Computational Linguistics (ACL Anthology) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01 : Injection d'invite - owasp.org
-
OWASP - Top 10 OWASP pour les applications de modélisation de langage de grande taille - owasp.org
-
Université de Stanford - Kohavi et al., « Expériences contrôlées sur le Web » - stanford.edu
-
arXiv - Évaluation de RAG : une étude - arxiv.org
-
PubMed Central (PMC) - Enquête sur la dérive des concepts (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh sur le kappa de Cohen - nih.gov
-
Google - Cahier d'exercices SRE sur la surveillance - google.workbook