J'ai arrêté d'évaluer mes modèles IA « au feeling » — voici ce que les chiffres m'ont appris

Pendant des mois, j'ai fait confiance à mon instinct pour choisir mes modèles LLM locaux.

Un modèle répondait vite ? Bon signe. Il donnait des réponses qui « paraissaient cohérentes » ? Encore mieux. J'avais même demandé à Claude de les évaluer pour moi — quelques tests ad hoc, une appréciation globale, et on passait à autre chose.

Le résultat : j'avais des modèles qui tournaient à 150 tokens par seconde avec une qualité de 30 %. Des sprinters qui couraient dans la mauvaise direction.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le contexte : une infrastructure d'IA locale pour tout faire

Depuis plus d'un an, je fais tourner plusieurs modèles LLM locaux via Ollama sur un GPU de 6 Go. Ces modèles servent de cerveau pour des tâches automatisées dans mon système :

Ces tâches ne sont pas anodines. Si un modèle rate une anomalie critique, c'est un bug en production qui passe inaperçu. Si le scoring de qualité est biaisé, les décisions de routing deviennent fausses.

Du coup, la question n'était pas « quel modèle est sympa ? » mais « quel modèle est fiable sur ces tâches précises ? »

Le problème : l'évaluation empirique est trompeuse

Ma première approche était simple — peut-être trop. Je donnais 5 ou 10 exemples à un modèle, je regardais les réponses, et je tranchais. Claude m'aidait à formuler le verdict : « ce modèle semble bien s'en sortir sur les tâches de classification. »

Il existe même un terme pour ce type d'évaluation dans la littérature académique : le vibes-based evaluation. Amazon Web Services a publié un article intitulé « Beyond Vibes : How to properly select the right LLM for the right task » — ce qui confirme que ce n'est pas un problème isolé, c'est la norme dans l'industrie.

Cette méthode a trois défauts majeurs.

Premier défaut : le biais de sélection. Les exemples qu'on choisit à la main sont rarement représentatifs. On prend les cas « intéressants », ceux où l'on sent une différence. On évite inconsciemment les cas banals — qui sont pourtant les 80 % de la charge réelle.

Deuxième défaut : la variance cachée. Un modèle peut donner une réponse juste à température 0,1 et une réponse complètement différente à 0,7. Sans tester plusieurs runs, on ne sait pas si le modèle est fiable ou juste chanceux sur ce test précis.

Troisième défaut : la métrique binaire. « Correct ou faux » efface trop d'information. Si j'attends une sévérité de 3 (anomalie critique) et que le modèle répond 2 (warning), c'est très différent de répondre 0 (normal). Le premier cas est un modèle « proche » ; le second est un modèle « dangereux ». La recherche académique sur le scoring automatisé (essay scoring) montre que le Quadratic Weighted Kappa — une métrique ordinale — est nettement plus discriminant que l'accuracy binaire pour ce type de tâche.

La solution : un protocole de benchmark statistique

J'ai conçu un système de benchmarking sérieux autour d'une tâche concrète : la détection d'anomalies dans des métriques quotidiennes.

La tâche de test

Chaque cas présente au modèle :
- Une métrique avec sa valeur du jour
- Les statistiques de référence sur 7 jours (moyenne, écart-type, min, max)
- La tendance sur 14 jours

La question posée au modèle est simple : quelle est la sévérité de cette situation ? (0 = normal, 4 = critique)

Six domaines sont couverts : coûts, santé système, appels LLM, qualité, utilisation, workflows — soit 600 cas de test au total (6 suites × 100 cas).

Le protocole Option A : multi-run avec analyse de variance

Chaque cas est exécuté 3 fois à température 0,7 (stochastique). On mesure quatre indicateurs :

Le partial score mérite une explication. La pénalité n'est pas binaire :

Distance 0 → 100 %  (exact)
Distance 1 →  50 %  (proche — acceptable)
Distance 2 →  10 %  (lointain — mauvais)
Distance 3+ →  0 %  (raté — dangereux)

Cela réduit le score aléatoire de référence de ~52 % à ~38 % sur un jeu de données équilibré — une différence qui rend le benchmark discriminant là où une mesure binaire ne verrait rien.

Les résultats : le choc des données

Voici les résultats consolidés sur les 6 suites métriques, protocole Option A (3 runs, échantillon stratifié de 45 cas/suite) :

Taux de succès (Binary Pass %)

Stabilité (Consistency %)

La lecture est sans appel. Le qwen2.5-coder 1.5b — mon modèle de formatage rapide, 148 tokens/seconde — obtient 42,8 % de pass sur les tâches de raisonnement. À peine mieux que de lancer un dé. C'est cohérent avec ce qu'on observe dans la recherche : des agents qui affichent 60 % de pass sur un benchmark mono-run tombent souvent à ~25 % de consistency quand on répète les tests en conditions stochastiques.

Et sa consistency à 50,8 % signifie que sur la moitié des cas, il donne des réponses différentes selon le run. Ce n'est pas un modèle lent qui réfléchit — c'est un modèle qui improvise.

La révélation : un seul modèle fiable bat trois modèles rapides

J'avais en tête l'idée reçue classique : diversifier les modèles selon les tâches, utiliser les petits modèles rapides pour les tâches simples et réserver les gros pour le raisonnement.

En pratique, cette stratégie a trois problèmes.

Le problème de la classification. Pour savoir qu'une tâche est « simple », il faut déjà la comprendre. Du coup, on se retrouve à utiliser un modèle capable pour décider si on peut déléguer à un modèle incapable. Le gain en vitesse s'évapore dans la logique de routing.

Le problème de la VRAM. Charger trois modèles en permanence sur un GPU de 6 Go n'est pas gratuit. Mon ancien stack occupait 5 299 Mo : qwen3:4b (3 298 Mo) + qwen2.5-coder:0.5b (720 Mo) + bge-m3 (655 Mo) + overhead runtime (~626 Mo). Ollama évinçait régulièrement un des modèles, créant des délais de rechargement de 2 à 5 secondes.

Le problème de la qualité à 30 %. Si un modèle de formatage rapide gère les tâches de scoring à 30 % de qualité, l'économie de temps est illusoire. Le coût réel se paie en bugs silencieux, en anomalies ratées, en décisions prises sur de mauvaises données.

La stack consolidée

Du coup, j'ai abandonné l'approche multi-modèle pour les tâches de raisonnement. La nouvelle stack :

1 347 Mo libérés. Plus d'évincements. Le modèle est toujours en mémoire, le KV cache est persistant (keep_alive: 24h), et les appels séquentiels profitent du cache de contexte.

La latence par appel est plus élevée — 155 ms vs 125 ms pour le qwen2.5-coder — mais la fiabilité passe de 34,8 % à 79,2 %. Ce n'est pas un compromis : c'est un gain net sur tous les axes qui comptent en production.

Ce que j'aurais dû mesurer dès le début

En rétrospective, les erreurs de mon approche initiale étaient prévisibles. Je mesurais la mauvaise chose.

La vitesse en tokens/seconde est séduisante à regarder — elle se mesure en 5 minutes avec une commande Ollama. Mais c'est une métrique de débit, pas de qualité. Un modèle qui produit 200 tokens de réponses incorrectes par seconde est moins utile qu'un modèle qui produit 62 tokens de réponses correctes.

La qualité perçue sur quelques exemples manuels est encore pire. Elle est biaisée par le choix des exemples, par l'ordre de présentation, par l'humeur du moment. C'est de l'anecdotique habillé en évaluation.

Ce qu'il faut mesurer :
1. La précision sur une distribution représentative — pas 5 exemples, mais 45 cas stratifiés sur toutes les classes de difficulté
2. La variance entre runs — un modèle fiable doit être consistent, pas seulement correct en moyenne
3. Le score ordinal — être « légèrement faux » est fondamentalement différent d'être « complètement à côté »
4. Le coût système — la VRAM occupée par un modèle intermédiaire n'est pas gratuite

Et maintenant ?

Le système de benchmarking tourne maintenant en continu. Chaque nouveau modèle que je veux intégrer passe les 6 suites en mode Option A avant d'être promu en production. Les résultats sont persistés dans PostgreSQL et consultables depuis mon tableau de bord de monitoring.

Ce n'est pas de l'over-engineering. C'est simplement appliquer à l'évaluation des modèles ce qu'on applique à n'importe quel système en production : des tests automatisés, des métriques objectives, et pas de décision sans données.

La prochaine étape ? Étendre les suites pour couvrir la traduction et la synthèse — les deux tâches où j'ai encore des modèles qui « semblent bien fonctionner » sans que je l'aie vraiment mesuré.

Pour aller plus loin

Articles liés sur ce blog :
- J'ai testé 7 modèles IA locaux. J'en ai gardé 1. — le benchmark généraliste qui a précédé cette approche statistique
- 920 appels LLM par jour à votre insu : l'architecture silencieuse qui mesure tout dans Claude Code — le système de métriques qui tire parti des modèles benchmarkés
- Gemma 4 e2b et e4b : ce que j'ai appris après des heures de benchmark — les mêmes suites appliquées aux modèles Gemma 4
- Gemma 4 ne rentrait pas dans mon GPU — jusqu'à ce que je supprime ce qu'il n'utilisait pas — optimisation VRAM, contexte de la contrainte GPU 6 Go

Sources externes :
- Beyond Vibes: How to properly select the right LLM for the right task — AWS Machine Learning Blog
- ReliabilityBench: Evaluating LLM Agent Reliability (arXiv) — données sur la chute de consistency entre benchmark et production

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Je documente en public ce que je construis en privé. Abonnez-vous pour ne pas manquer les prochains articles sur l'IA locale, les agents autonomes et l'architecture de systèmes LLM.

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.