Comment choisir et comparer un LLM ?
Apprenez à lire les classements publics et à tester les modèles sur vos usages, vos langues, votre budget et vos exigences de qualité.
Objectifs de la leçon
Choisir un modèle à partir des exigences de la tâche plutôt que de sa réputation.
Comprendre ce que mesurent des benchmarks publics comme LiveBench, Arena, SWE-bench, IrokoBench et AfroBench.
Créer un benchmark représentant les langues africaines et les conditions locales réelles.
Comparer la qualité avec la rapidité, le coût, la régularité et le taux d’échec.
Commencer par la tâche, pas par le classement
Il n’existe pas de modèle meilleur pour tous les usages. Un modèle peut être excellent en code et moyen en service client, performant en anglais et faible dans une autre langue, ou très précis mais trop lent et trop coûteux pour des milliers de demandes quotidiennes.
Avant de comparer les noms des modèles, décrivez le travail : les données reçues, le résultat attendu, les langues, le délai acceptable, le budget, les outils nécessaires et les conséquences d’une erreur.
Le meilleur choix pratique est généralement le modèle le moins coûteux qui atteint régulièrement la qualité demandée. Un modèle plus puissant devient utile seulement si son amélioration justifie réellement le temps et le coût supplémentaires.
Seuil de qualité Le résultat minimum qu’un modèle doit atteindre pour être utilisable.
Au moins 95 % des messages de paiement doivent être classés dans la bonne catégorie.
Latence Le temps entre l’envoi de la demande et la réception de la réponse.
Un chatbot peut avoir besoin d’une réponse en quelques secondes.
Coût par tâche réussie Le coût réel des réponses qui atteignent le seuil de qualité.
Un modèle peu cher qui échoue souvent peut coûter plus cher après les nouvelles tentatives et les corrections.
Taux d’échec La part des demandes incorrectes, inutilisables, mal formatées ou refusées sans raison attendue.
JSON invalide, mauvaise langue, montant inventé ou champ manquant.| Tâche réelle | Priorité | Ce qu’il faut tester |
|---|---|---|
| Classer 50 000 messages courts de support | Rapidité, prix et stabilité des catégories. | Exactitude par catégorie, latence, sorties invalides et coût total. |
| Résumer un contrat de 70 pages | Contexte long et fidélité au document. | Clauses oubliées, affirmations inventées, citations et temps de relecture. |
| Répondre aux clients en français et en wolof | Qualité linguistique et mélange des langues. | Sens, grammaire, politesse, termes locaux et transmission à un humain. |
| Modifier un dépôt logiciel | Code, outils et raisonnement sur plusieurs fichiers. | Tests réussis, régressions, durée d’exécution et corrections humaines. |
| Répondre avec une information officielle du jour | Utilisation d’outils et qualité des sources. | Bonne source, date de publication, citation et affirmations non justifiées. |
Tester la langue réellement utilisée par les clients
Une équipe de service client au Sénégal reçoit des messages en français, en wolof, avec des abréviations et une orthographe informelle. Un modèle peut être très bien classé en anglais et pourtant mal comprendre ces demandes. L’équipe prépare donc un jeu de test à partir des messages qu’elle reçoit réellement.
Le classement général permet de présélectionner les modèles ; la langue des clients permet de choisir le bon.
Choisir le modèle qui atteint l’objectif au meilleur coût
Une entreprise exige au moins 95 % d’exactitude pour classer ses demandes de support. Un grand modèle atteint 97 %. Un modèle plus rapide atteint 96 % et coûte quatre fois moins cher. Les deux respectent l’exigence, mais le second peut traiter le volume quotidien avec un budget bien inférieur.
Une fois le seuil de qualité atteint, le coût, la rapidité et la régularité peuvent départager les modèles.
Ce que change le réglage de thinking
Certains modèles proposent un réglage de thinking, ou effort de raisonnement. Ce réglage donne au modèle plus ou moins de capacité de traitement pour analyser le problème avant de produire la réponse finale.
Davantage de thinking devient utile lorsque plusieurs contraintes dépendent les unes des autres, lorsqu’un plan doit être vérifié ou lorsque la réponse demande plusieurs étapes de raisonnement. Il est généralement inutile pour une extraction directe, une reformulation, une traduction ou une classification simple.
Le thinking n’ajoute pas à lui seul des faits absents, un accès au web, la maîtrise d’une langue locale ou un calcul fiable. Il peut aussi augmenter la latence et le coût. Il doit donc être évalué comme n’importe quel autre réglage.
| Niveau | Tâches adaptées | Exemple |
|---|---|---|
| Faible | Transformation directe avec des consignes claires. | Extraire le montant et la référence de transaction d’un message. |
| Moyen | Analyse comportant quelques règles ou comparaisons. | Comparer trois offres de fournisseurs selon le prix, le délai et la garantie. |
| Élevé | Décisions en plusieurs étapes avec des contraintes liées. | Planifier des livraisons dans plusieurs quartiers en respectant la capacité, le carburant, les délais et les clients prioritaires. |
Impossible d’optimiser un trajet sans les données nécessaires
Une entreprise de livraison demande au modèle de trouver le trajet le moins coûteux, mais ne fournit ni les distances ni le prix du carburant. Augmenter le niveau de thinking oblige seulement le modèle à réfléchir plus longtemps avec des informations incomplètes.
Commencez par fournir les données nécessaires, puis vérifiez si davantage de raisonnement améliore réellement le résultat.
Vérifier si le thinking élevé vaut son coût
Avec un thinking moyen, un modèle réussit 48 cas de planification sur 50 en quatre secondes. Avec un thinking élevé, il en réussit 49, mais prend quinze secondes et coûte trois fois plus cher. L’entreprise doit déterminer si ce cas supplémentaire justifie la différence.
Mesurez ensemble le gain de qualité, le temps de réponse et le coût ; un thinking plus élevé n’est pas automatiquement préférable.
Comprendre les benchmarks et classements publics
Un benchmark est un examen composé de tâches précises et de règles de notation. Un leaderboard, ou classement, affiche les résultats obtenus par les modèles à cet examen. Les benchmarks publics permettent de repérer de bons candidats, mais ne remplacent pas les tests réalisés sur votre propre travail.
Chaque benchmark mesure un ensemble limité de capacités. Un score de code ne mesure pas la rédaction en wolof. Un score de préférence humaine ne garantit pas l’exactitude des faits. Un score multilingue ne prouve pas que le modèle comprend le vocabulaire de votre entreprise.
Vérifiez également la version du benchmark. Avec le temps, les questions d’un test fixe peuvent apparaître dans les données d’entraînement des modèles : c’est la contamination. Des évaluations comme LiveBench renouvellent leurs questions afin de réduire ce risque.
Benchmark Un ensemble de tâches, de réponses attendues et de règles de notation.
Cent questions corrigées automatiquement.
Leaderboard Un classement construit à partir des résultats d’un benchmark.
Modèles classés par score général ou par catégorie.
Métrique La règle utilisée pour transformer un résultat en score.
Réponse exacte, pourcentage de tâches réussies ou préférence humaine.
Contamination Les questions du benchmark se retrouvent dans les données d’entraînement du modèle.
Le modèle peut mémoriser une réponse au lieu de démontrer la capacité recherchée.| Benchmark | Ce qu’il évalue | Comment l’interpréter |
|---|---|---|
| LiveBench | Mathématiques, raisonnement, code, langage, respect des instructions et analyse de données avec des questions renouvelées et une notation objective. | Utile pour comparer les capacités générales tout en réduisant la contamination ; il faut malgré tout regarder la catégorie liée à votre usage. |
| Arena | Comparaisons anonymes entre deux réponses, puis vote des utilisateurs pour celle qu’ils préfèrent. | Utile pour la qualité conversationnelle et l’utilité perçue ; la préférence ne garantit ni la vérité ni le respect d’une règle métier. |
| MMLU-Pro | Questions difficiles à choix multiple dans de nombreuses disciplines, avec une place importante accordée au raisonnement. | Utile comme indicateur général de connaissances et de raisonnement ; ce n’est pas un test de vos documents, de vos langues ou de votre workflow. |
| SWE-bench Verified | Véritables problèmes issus de dépôts GitHub que le système doit résoudre en produisant une correction fonctionnelle. | Utile pour les agents de code et le travail sur des dépôts ; peu pertinent pour la rédaction marketing ou le support client. |
| IrokoBench | Compréhension logique, raisonnement mathématique et questions de connaissances traduits par des humains dans 17 langues africaines. | Utile pour comparer les performances au-delà des langues très dotées ; il ne couvre pas toutes les langues africaines ni tous les usages locaux. |
| AfroBench | Un ensemble étendu couvrant 64 langues africaines, 15 tâches et 22 jeux de données de compréhension et de génération. | Utile pour une vue multilingue étendue ; vérifiez la langue, la tâche et le jeu de données correspondant réellement à votre besoin. |
Utiliser LiveBench pour établir une présélection
Deux modèles obtiennent des scores généraux proches sur LiveBench. L’entreprise conserve donc les deux pour la suite. Sur son propre test Mobile Money, l’un produit plus régulièrement un JSON valide et respecte mieux la procédure de transmission.
Un benchmark public aide à trouver les candidats ; le benchmark métier permet de prendre la décision finale.
La réponse la plus agréable n’est pas toujours la plus fiable
Pendant une comparaison anonyme, les évaluateurs préfèrent une réponse détaillée et rassurante. Pourtant, cette réponse promet un remboursement interdit par la procédure. La réponse plus courte paraît moins impressionnante, mais elle est correcte.
La préférence humaine doit être complétée par une vérification des faits et des règles métier.
Construire un benchmark adapté à un usage africain
Un benchmark local doit reproduire les conditions dans lesquelles le modèle sera réellement utilisé. Il faut tenir compte des pays, des langues, des accents, des monnaies, des moyens de paiement, des habitudes d’écriture, des appareils, de la qualité des documents et des règles métier du service.
Ne traduisez pas mécaniquement un test anglais en supposant qu’il représente le marché. Collectez des exemples réels ou réécrits de manière réaliste, retirez les informations personnelles, faites vérifier les langues par des locuteurs compétents et conservez aussi les cas difficiles.
Par exemple, un benchmark de support Mobile Money au Bénin peut contenir du français formel, du français familier, des messages avec des expressions en fon, des accents manquants, des transcriptions de notes vocales, des montants en FCFA, des références de transaction incomplètes, des tentatives de fraude et des demandes à transmettre à une personne.
- Écrire précisément la décision que le benchmark doit permettre de prendre.
- Collecter des cas représentatifs des utilisateurs et des canaux visés.
- Préparer les réponses attendues ou les règles de notation avant de tester les modèles.
- Conserver un ensemble de test caché qui ne sert pas à améliorer le prompt.
- Faire vérifier les cas ambigus par des locuteurs compétents et des spécialistes du métier.
- Mesurer séparément chaque groupe important au lieu de cacher les échecs dans une seule moyenne.
| Groupe | Nombre de cas | Ce qui est testé |
|---|---|---|
| Classification de la demande | 20 | Transfert échoué, réception retardée, frais, code, accès au compte et fraude. |
| Extraction d’informations | 15 | Montant, date, référence, expéditeur, destinataire et champs manquants. |
| Réponse conforme à la procédure | 15 | Aucun remboursement inventé, bonnes étapes de vérification et transmission adaptée. |
| Variations de langue | 15 | Français formel, français familier, fautes, expressions en fon et mélange de langues. |
| Sécurité et confidentialité | 10 | Demandes de codes secrets, données d’identité, fraude, menaces et clients vulnérables. |
| Entrées longues ou bruitées | 10 | Transcriptions vocales, répétitions, détails inutiles et plusieurs problèmes à la fois. |
Une moyenne générale peut cacher une faiblesse importante
Un modèle obtient une moyenne de 82 % sur le français, l’anglais, le wolof et le fon. Le détail révèle pourtant 95 % en français contre seulement 49 % en fon. Pour un service qui doit fonctionner en fon, la moyenne générale est trompeuse.
Présentez les résultats par langue et par tâche, surtout pour les langues indispensables au service.
Tester les formats réellement envoyés par les clients
Le modèle fonctionne bien avec des messages soigneusement rédigés. Mais le support reçoit aussi des transcriptions vocales avec des répétitions, des mots coupés, des noms et plusieurs problèmes dans le même message. Les résultats baissent lorsque ces cas sont ajoutés au benchmark.
Un benchmark réaliste doit reproduire les canaux et la qualité des messages rencontrés en production.
Exécuter la comparaison de manière équitable
Chaque modèle doit recevoir la même tâche, les mêmes données, la même instruction système, les mêmes outils, le même contexte, la même limite de sortie et le même nombre d’essais. Si un modèle utilise le web et l’autre non, le test compare deux systèmes, pas seulement deux modèles.
Automatisez les vérifications objectives lorsque cela est possible : catégorie exacte, JSON valide, champs obligatoires, montant correct, tests logiciels réussis ou présence d’une source. Une évaluation humaine reste nécessaire pour le ton, la clarté, la traduction, l’adaptation culturelle et l’utilité.
N’évaluez pas uniquement la moyenne. Enregistrez les erreurs graves, les variations entre plusieurs essais, les temps de réponse, le coût par requête et la quantité de correction humaine nécessaire. Un modèle parfois excellent mais souvent imprévisible peut être inadapté à la production.
| Critère | Poids | Question de notation |
|---|---|---|
| Exactitude factuelle et métier | 30 % | La réponse utilise-t-elle uniquement les faits fournis et respecte-t-elle la procédure ? |
| Exactitude de la catégorie et des champs | 20 % | La catégorie, le montant, la date et la référence sont-ils corrects ? |
| Qualité linguistique | 15 % | La réponse est-elle compréhensible, polie et adaptée à la langue demandée ? |
| Sécurité et transmission | 15 % | Protège-t-elle les données privées et transmet-elle les bons cas ? |
| Fiabilité du format | 10 % | Le JSON ou la structure demandée est-il toujours valide ? |
| Rapidité et coût | 10 % | Quels sont le temps et le coût d’une réponse acceptable ? |
Noter les réponses sans afficher le nom du modèle
Les évaluateurs reçoivent « Réponse A » et « Réponse B » avec la même grille de notation. Ils découvrent le nom des modèles seulement après avoir envoyé leurs notes.
L’évaluation à l’aveugle réduit l’influence de la réputation, du prix ou de la préférence pour une marque.
Exécuter plusieurs fois le même cas
On demande trois fois au modèle de renvoyer le même résultat en JSON. Les deux premières sorties sont valides ; la troisième oublie un champ obligatoire. Un seul essai réussi aurait masqué cette instabilité.
La qualité en production se mesure par la régularité entre les essais, pas par la meilleure réponse obtenue.
Utilisez les benchmarks publics pour présélectionner les modèles. Utilisez votre propre benchmark pour choisir celui qui entrera en production.