Fonctionnement de MakoBench : Présentation du benchmark pour les LLM ouverts

Aller à : CrucibleForge sur GitHub

Les exemples détaillés font référence au tableau de notation de la Suite 4.0, publié le 7 novembre 2026. La Suite 4.1 corrige les clés de réponse et renote tous les modèles, en appliquant les mêmes règles de scoring et de bonus ; ce qui a changé dans la Suite 4.1 présente les détails ainsi que les nouveaux scores.

Qu’est-ce que MakoBench ?

D’un modèle au classement final

1. Un modèleLocal sur notre poste de travail, ou via une API hébergée
2. Les cas d’utilisation standardLes mêmes questions pour chaque modèle
3. Ses réponsesEnregistrées afin de pouvoir être re-évaluées
4. L’évaluationPour le code : exécution contre des tests cachés et vérification de la sortie exacte. Pour les conversations : évaluation via un modèle de jugement sur notre poste de travail, selon des règles textuelles.
5. Les scoresScore du code + score des conversations = score total, avec une marge d’erreur ±
6. Le classement finalRang, catégorie et tendance globale du modèle

MakoBench est un classement public des modèles linguistiques, qu’ils soient locaux ou hébergés, tous évalués de la même manière. Il mesure deux capacités : l’aptitude à écrire du code fonctionnel, ainsi que la capacité à tenir une conversation en rôle-play ou en tant que compagnon virtuel. La page Ce que MakoBench teste et ce qu’il ne teste pas décrit tout le périmètre d’évaluation.

Le moteur utilisé est CrucibleForge, gratuit et open source (licence MIT-0). Vous pouvez l’utiliser sur vos propres modèles grâce au guide d’installation de CrucibleForge.

Comment est calculé le score

Un cas à la fois

Comment un cas rapporte des points

1. Le casUn chat de réservation comportant 11 étapes et divers pièges intégrés
2. La réponseCe que le modèle dit et les appels qu’il effectue
3. Les vérifications, étape par étapeBon outil ? Bons arguments ? Répondre à l’utilisateur plutôt que d’appeler un outil ?
4. 7 étapes réussies, 4 échouéesPoints obtenus : 7 / 11 = 0,64

Un cas correspond à une tâche : écrire une fonction, prédire la sortie d’un programme, effectuer un chat avec des outils, ou mener une longue séance de jeu de rôle. Chaque cas est évalué en petites parties – par exemple des groupes de tests cachés ou les étapes d’un chat – afin qu’une réponse presque correcte rapporte la plupart des points. Chaque cas standard est exécuté une seule fois.

Détails : la liste des cas d’évaluation et le code de notation (graders.py).

Comment le juge évalue les réponses du chat

Procédure d’évaluation d’une réponse par le juge

1. La réponseUn tour de la conversation
2. Une question« Le personnage a-t-il tenu sa promesse ? »
3. Le modèle jugeIl répond OUI ou NON
4. OUI + citation exacteLe code vérifie la citation : elle doit comporter au moins 12 caractères et apparaître mot pour mot dans la réponse.
5. Le résultatSi la citation est présente, le OUI est compté ; sinon, c’est un NON.
6. Règles textuelles, pas de jugeCompte des mots, phrases interdites, faits prédéfinis : tout est vérifié par le code. Un refus de tâche échoue aux contrôles.

Le code n’a jamais besoin d’opinion. Le chat, en revanche, en a besoin ; c’est pourquoi un modèle juge, autre modèle linguistique, répond par OUI ou NON à chaque réponse. Dans ce contexte, il s’agit de Gemma 4 31B (version « hérétique » non censurée, format Q8) exécuté sur notre propre matériel GPU ; le format Q8 désigne une copie des poids en 8 bits. Un OUI n’est valable que s’il est accompagné d’une citation identique mot pour mot, car les modèles juges ont tendance à répondre OUI trop facilement. Avant chaque lot de tests, le modèle juge doit valider une réponse connue comme correcte et détecter une réponse connue comme incorrecte ; sinon, le lot est annulé.

Lorsqu’une seule question peut faire échouer un cas, elle est posée trois fois. Elle est considérée comme validée uniquement si la majorité des réponses sont OUI ; en cas d’égalité, c’est un NON.

Détails : le code du juge (judge.py) et le fonctionnement des sessions de chat.

Le code et le chat se combinent pour former le total

Code : 10 points

• Fonctions56 programmes
• Prédiction + détection de bugs2,53 tâches
• Utilisation d’outils2,53 conversations

Chat : 10 points

• Jeu de rôle approfondi32 sessions
• Conversation32 sessions
• Personnages22 sessions
• Écriture créative22 sessions

Chaque composante obtient la part de points qui lui revient : par exemple, « Fonctions » représente 76 % du total, soit 3,8 sur 5 points. Ces composantes se cumulent pour former les scores « Code » et « Chat ». Le test destiné aux adultes possède sa propre section et n’est jamais inclus dans le calcul global.

Détails : le profil de test (bench.yaml) liste chaque composante, ses points attribués ainsi que les cas d’évaluation associés.

La marge ±

D’où provient la marge ?

1. Redessiner les cas1 000 fois, de manière aléatoire ; un cas peut apparaître deux fois ou pas du tout
2. Évaluer chaque redessin en détailCela donne 1 000 totaux différents
3. Prendre les 90 % centraux de ces 1 000 totauxCette zone est ensuite mise en évidence
4. ± = la moitié de cette largeurClaude Sonnet 4.5 : 12,8 ± 1,1

Un autre ensemble de cas donnerait un total légèrement différent. La marge indique cette variation. Deux modèles dont les valeurs sont plus proches que leurs marges respectives sont statistiquement considérés comme égaux. La marge ne tient pas compte des fluctuations d’une exécution à l’autre ; il convient donc de considérer comme égals aussi les écarts d’un ou deux points.

Détails : le code relatif à la marge (headline.py).

Lecture du tableau de notation

Catégories de classement

• Classe CMoins de 10La catégorie la plus basse
• Classe B10 et plusDe 10 à 13
• Classe A13 et plusDe 13 à 16
• Classe S16 et plusDe 16 à 20, et au-delà uniquement avec des ensembles de bonus

Total, sur une échelle de 0 à 20

• Claude Sonnet 4.512,8 ± 1,1classe B
• DeepSeek V4 Flash19,2 ± 0,8classe S

Les coûts d’exécution, la technologie utilisée et les autres colonnes sont décrits dans l’onglet Documentation de MakoBench ainsi que dans la section concernant les colonnes du tableau de notation dans le README.

Exemple : un modèle sur l’ensemble standard

Code : 6,1 sur 10

• Fonctions3,8sur 5
• Prédiction + recherche de bugs0,5sur 2,5
• Utilisation d’outils1,8sur 2,5

Chat : 6,7 sur 10

• Jeu de rôle approfondi2,0sur 3
• Conversation2,0sur 3
• Caractère1,3sur 2
• Écriture créative1,4sur 2

Claude Sonnet 4.5 s’est contenté de l’ensemble standard, rien d’autre. Voici comment les scores obtenus se transforment en points pour chaque catégorie.

Total : 6,1 + 6,7 = 12,8 ± 1,1, classe B. La meilleure catégorie, « Fonctions », a atteint 76 % ; ce chiffre reste en dessous du seuil de 90 % nécessaire pour débloquer les bonus. Par conséquent, aucun bonus n’a été attribué et le score reflète uniquement l’ensemble standard. La plupart des modèles figurant sur le tableau se trouvent dans la même situation.

Ensembles de bonus

Comment un ensemble se débloque

Mécanisme de déblocage des ensembles de bonus, pour une partie donnée

1. Questions standardesPar exemple, pour la partie « Fonctions »
2. 90 % ou plus ?Non : l’ensemble reste verrouillé, 0 point. La partie conserve ses points standards. Oui : les ensembles de niveau 1 se débloquent, chacun valant 1 point.
3. En attenteUn ensemble débloqué mais qui n’a pas encore été exécuté : compte pour 0 pour l’instant.
4. Chaque ensemble ajoute sa part de pointsLorsqu’il est exécuté, un ensemble ajoute entre 0 et 1 point.2 bonnes réponses sur 3 rapporte environ 0,67 point.
5. 90 % ou plus sur chaque ensemble de niveau 1 ?Non : on s’arrête, les points restent tels quels. Oui : les ensembles de niveau 2 se débloquent, et ainsi de suite, niveau par niveau.
6. Score final de la partiePoints standards + somme des points attribués par chaque ensemble exécuté

Un ensemble de bonus regroupe des questions plus difficiles, généralement au nombre de trois, pour une même partie. CrucibleForge les désigne sous le nom de « packs d’échelle ». Les règles sont les suivantes :

• Déblocage. Les ensembles d’un certain niveau ne sont attribués qu’après avoir obtenu 90 % ou plus aux questions standardes de cette partie ainsi qu’à tous les ensembles des niveaux inférieurs.
• Verrouillé, débloqué, en attente. Verrouillé : non acquis. Débloqué : acquis, donc exécutable. En attente : acquis mais pas encore exécuté ou évalué ; compte pour 0 pour l’instant.
• Jusqu’à 1 point par ensemble. Les questions d’un même ensemble se partagent ce point, avec attribution de points partiels : 2 bonnes réponses sur 3 rapporte environ 0,67 point. Si une question est exécutée deux fois, les résultats sont moyennés.
• Niveaux. Tous les ensembles d’un même niveau sont attribués en même temps, et chacun ajoute sa part de points à la partie concernée.

À partir de la suite 4.1, tous les ensembles sont de niveau 1. Code dispose de trois ensembles, un par partie ; Chat en a cinq (dont deux pour le jeu de rôle Deep). Ainsi, Code peut atteindre 13 points et Chat 15. Une partie ne débloque jamais ses ensembles si elle ne comporte pas encore de cas standard.

Plus de détails : les règles relatives aux ensembles de bonus, le code de déblocage (ladder.py) et les ensembles de bonus publics.

Exemple : un modèle qui débloque un ensemble

DeepSeek V4 Flash débloque un ensemble de bonus

1. Fonctions : 6 programmes standardTous réussis : 100 %, soit 5,0 points
2. 100 % dépasse les 90 % : déblocageEnsemble de bonus « Fonctions », niveau 1
3. 3 questions difficiles, chacune exécutée deux foisQuestion 1 : 0 et 0 → 0,00 ; Question 2 : 0 et 0 → 0,00 ; Question 3 : 4 bons résultats sur 6 essais, puis 0 → 0,33
4. Part de points attribuée : 0,33 / 3 = 0,11Fonctions : 5,0 + 0,1 = 5,1
5. Jeu de rôle Deep : 74 %En dessous de 90 %, donc ses ensembles de bonus restent verrouillés : 2,2 points sur 3
6. Score final Code : 11,2 = 5,1 + 2,7 + 3,3Seuls les ensembles de bonus permettent d’atteindre plus de 10 points.

DeepSeek V4 Flash a réussi les six programmes standard de la partie « Fonctions », ce qui a débloqué l’ensemble de bonus correspondant : trois programmes à créer de zéro, chacun exécuté deux fois. Le modèle en a résolu une partie : 4 bons résultats sur 6 essais pour l’une des questions, et aucun pour l’autre ; cela lui a valu 0,33 point. L’ensemble rapporte donc (0 + 0 + 0,33) ÷ 3 = 0,11 point. Les autres parties de Code ainsi que l’écriture créative ont également débloqué leurs ensembles respectifs. Le score final de Code s’est ainsi élevé à 11,2, dépassant les 10 points requis ; le score total atteint 19,2 ± 0,8.

En revanche, pour la partie « Jeu de rôle Deep », le modèle n’a obtenu que 74 %, si bien que ses ensembles de bonus sont restés verrouillés. Chaque partie se débloque indépendamment des autres.

Comment le test a été conçu

Garder les cas à jour

Ce qui se passe lors d’une modification du cas

• Si la question ou ses tests changentNouvelles réponsesChaque IA génère de nouvelles réponses
• Si une question d’évaluation changeRéévaluéL’évaluateur relit les réponses enregistrées
• Si une vérification de texte ou une réponse changeRe-notéLa note est recalculée, sans intervention de l’IA
• Si rien ne changeConservéLes réponses enregistrées restent valides

Chaque réponse enregistrée comporte une indication du cas auquel elle correspond. Lorsqu’un cas est modifié, seules les parties affectées par ce changement sont traitées à nouveau. Les réponses anciennes et nouvelles ne se mélangent jamais. Détails : les indications de version (version.py).

Examen de la clé de réponses de la suite 4.1

Examen de la clé de réponses de la suite 4.1

1. Chaque clé de réponses publique63 cas au total
2. Deux relecteursLe relecteur A examine chaque cas. Le relecteur B fait de même.
3. Vérification de chaque affirmationCode : exécution du code de référence et des tests. Chat et outils : comparaison avec les réponses enregistrées pour chaque modèle.
4. Tri des affirmations~190 affirmations confirmées, corrigées lorsque elles modifiaient le score. ~95 affirmations rejetées, chacune accompagnée d’une justification écrite.
5. Deuxième vérification de chaque correction« Refuser ne rapporte jamais de points ; les tâches difficiles restent difficiles. »
6. Réexécution, réévaluation ou re-calcul du scorePour chaque cas modifié

Une clé de réponses peut être erronée de deux manières : elle peut valider une mauvaise réponse, ou au contraire rejeter une bonne réponse en exigeant plus que ce que la tâche ne demandait. Pour la suite 4.1, deux relecteurs ont examiné chacune des clés de réponses publiques individuellement ; chaque affirmation a été comparée aux réponses enregistrées avant toute modification. Le crédit lié au refus a également été pris en compte : aucun cas ne rapporte de points pour un refus. Suite 4.1 : quels changements ? liste toutes les corrections apportées.

De la première suite aux nouveaux packs

La suite à ce jour

1. 3.0Note sur 100
2. 3.9Ajout de sets bonus
3. 4.0Code + Chat, 10 chacun
4. 4.1Vérification des réponses correctes

Un nouveau pack bonus

1. RédactionDes modèles de plusieurs familles rédigent des cas d’épreuve
2. AttaqueUn autre modèle tente de percer chaque clé
3. Vérification par le jugeUne bonne réponse est acceptée ; une mauvaise mais subtile, ainsi qu’une réponse affaiblie, sont rejetées
4. Test piloteQuelques modèles performants le testent
5. RenforcementCorrection des problèmes identifiés lors du test pilote
6. Mise en attenteLe pack reste en suspens jusqu’à révision

Les sets bonus sont apparus dans la version 3.9 afin d’empêcher que tous les meilleurs modèles obtiennent une note parfaite. Les anciens packs restent inchangés dans l’historique de la suite, et chaque nouvelle version du moteur est décrite dans le journal des modifications de CrucibleForge.

Lorsque les modèles atteignent la note maximale sur une partie donnée, il devient nécessaire de créer un set bonus plus difficile (un nouveau pack). Chaque nouveau pack suit donc le processus décrit ci-dessus. La vérification par le juge est cruciale : si celui-ci ne parvient pas à distinguer une bonne réponse d’une mauvaise mais subtile, le pack ne peut être évalué de manière équitable.

Pourquoi j’ai créé cela

J’en avais assez de ne pas pouvoir distinguer les différents modèles. Je voulais un benchmark simple que n’importe qui pourrait exécuter, sur n’importe quel modèle, avec des chiffres que chacun pourrait vérifier par lui-même. Je pensais que cela apporterait de la valeur.

Si vous trouvez cela utile, pensez à faire un don pour aider à le maintenir à jour. Vous pouvez également voter pour le prochain modèle que nous testerons.

Voir aussi : Comment fonctionne CrucibleForge.