Cessez d’acheter des benchmarks : construisez un banc d’évaluation LLM honnête

Chaque jour, un nouveau classement proclame un modèle numéro un. Un post affirme que GLM bat Claude chez eux. Un autre dev montre son CV oscillant de 90 à 74 puis 88 quand il passe dans un ATS open source. Ce ne sont pas des contradictions ; c’est un rappel : sans un banc d’évaluation fidèle au workload, vous achetez du marketing. En tant que CTO, vous avez besoin d’un benchmark qui réponde à une seule question : quel modèle gagne pour votre mix exact de tâches, de latences et de coûts ?

Ce que les classements des fournisseurs ignorent (et pourquoi vous le payez)

Les classements publics optimisent le spectacle, pas vos SLO. Ils capturent rarement :

• Décalage de distribution : Vos prompts ne sont pas des questions de trivia en 3 phrases. Vous tournez avec des contextes de 300–2000 tokens, des appels d’outils mêlés et des retours JSON stricts. Les classements moyennent sur des tâches qui ne ressemblent pas aux vôtres.
• Safety et taux de refus : Le modèle le plus rapide ne vaut rien s’il refuse 7 % de vos prompts de support client ou s’il omet silencieusement des champs requis.
• Latence de queue sous charge : les p95 et p99 explosent en premier. Vos clients ressentent la queue, pas la moyenne.
• Fragilité de l’évaluateur : Le modèle « juge » inverse ses verdicts avec de minuscules changements de prompt (cf. anecdotes de scoring ATS en yo-yo). Si votre scoreur n’est pas robuste, vos classements ne le sont pas non plus.
• Réalités opérationnelles : Limites de débit, pics transitoires 429/5xx, instabilité du routage API et bugs SDK (rappelez-vous le bug récent dans une bibliothèque HTTP populaire) faussent les résultats si vous ne mettez pas de garde-fous.

Cessez de louer les hypothèses des autres. Construisez un benchmark petit, honnête et répétable qui reflète votre monde.

Les cinq éléments à mesurer (dans cet ordre)

1. Taux de réussite des tâches (qualité) : Correspondance exacte pour les sorties structurées ; validation programmatique pour le code ou l’extraction ; jugement pair-à-pair calibré pour les réponses ouvertes.
2. Latence p95 au RPS cible : Sous votre concurrence et votre région. Les préchauffages mentent ; mesurez l’état stable.
3. Coût par élément résolu : Tokens entrants + tokens sortants + retries, divisé par les complétions réussies. C’est le chiffre dont la finance se souvient.
4. Taux d’échec/refus : Ruptures de schéma JSON, appels d’outils manqués, refus de politique et erreurs réseau/API.
5. Variance/dérive : Écarts run/replay et dérive hebdomadaire. Ne couronnez pas un champion qui n’est bon que le mardi.

Votre benchmark LLM minimal viable (MVB)

1) Constituer un dataset conforme à la production

• Taille : 1 000–2 000 éléments suffisent pour départager les prétendants sans vous ruiner.
• Mix : Reflétez vos 3–5 principaux use cases. Exemple : 40 % classification/extraction (JSON), 40 % agents/appels d’outils, 20 % raisonnement longue forme. Incluez des plages de longueur : court (≤128 tokens), moyen (129–512), long (513–2048+).
• Langues/régions : Si vous servez les Amériques, incluez l’anglais, l’espagnol et le portugais du Brazil. Même les modèles de pointe peuvent perdre 5–15 % sur des tâches non anglophones.
• Évitez la contamination : Pas de benchmarks publics sur lesquels les modèles ont probablement été entraînés. Utilisez des tickets internes, des variantes synthétiques mais validées, ou des données découpées dans le temps capturées après le cutoff connu du modèle.

2) Construire un scoreur fiable

• Tâches structurées : Validez le JSON avec un schéma strict ; utilisez des regex pour les identifiants ; exécutez des tests de code pour la génération. Pas besoin d’humain dans la boucle.
• Tâches ouvertes : Utilisez un ELO pair-à-pair avec trois modèles juges indépendants et des tie-breakers. Ne laissez jamais un candidat se juger lui-même. Figez le prompt de jugement et enregistrez son hash. Rejouez 10 % des éléments chaque semaine pour détecter la dérive du juge.
• Calibration humaine : Échantillonnez 100 éléments et faites les noter à l’aveugle par deux experts métier. Calculez l’accord inter-annotateurs (kappa de Cohen). Votre juge doit être ≥0,6 d’accord avec les humains, sinon vous notez du bruit.

3) Instrumenter la latence et la charge

• Balayages de concurrence : Testez à 1, 4, 16 et 64 requêtes concurrentes. Isolez des instances client par modèle pour éviter l’interférence inter‑modèles.
• Préchauffage, sans tricher : Envoyez une rafale de 30–60 s, puis enregistrez au moins 10 minutes à RPS stable. Vos clients ne vivent pas dans votre fenêtre de préchauffage.
• Mesurez la queue et la stabilité : Relevez p50/p95/p99, % de timeouts et nombre de retries. La queue vous dit d’où viennent les pagers.

4) Rendre le tout reproductible

• Environnement hermétique : Containerisez le harnais. Verrouillez les dépendances. Si vous êtes sur Python, lockez avec uv ; si vous êtes sur Node, lockez avec un installeur reproductible. N’expédiez pas du “latest”.
• Requêtes idempotentes : Hashez (modèle, template de prompt, inputs, temperature, outils) pour créer une clé de cache. Cachez les réponses brutes avec les en‑têtes. Lors des relances, détectez les hits de cache mais re‑mesurez la latence avec une branche “no‑op” afin de rejouer la qualité à bas coût et la latence honnêtement.
• Observabilité : Émettez des traces OpenTelemetry avec des attributs pour le modèle, le template, les comptes de tokens, les tentatives de retry et la classe d’erreur. Conservez les traces au moins 30 jours.
• Durcissement HTTP : Utilisez backoff exponentiel, jitter et coupe‑circuits. Implémentez une dead-letter queue pour les éléments pathologiques afin qu’un prompt problématique ne bloque pas l’exécution. Et oui — des bugs dans des clients HTTP populaires arrivent ; figez les versions et surveillez les régressions.

5) Contrôler la non‑déterminisme

• Paramètres d’échantillonnage : Figez temperature, top_p et presence penalties. Si l’API supporte un seed, définissez‑le ; sinon, utilisez n=3 échantillons et prenez la majorité pour la classification ou le best‑of selon le juge pour la génération.
• Discipline des templates : Figez les templates de prompts et les schémas d’outils. Enregistrez leur SHA‑256 dans les résultats. Un ajustement de deux mots peut déplacer votre taux de victoire de 3–7 % — logguez‑le.

Plan d’exécution : comparer 4–6 modèles en une semaine

1. Jour 1–2 : Finalisez dataset et scoreur ; figez templates et schémas. Dry run avec un modèle baseline peu coûteux pour valider métriques et budget.
2. Jour 3 : Calibration de concurrence. Pour chaque modèle, balayez la concurrence pour trouver le RPS le plus élevé qui maintient la p95 sous votre SLO (p. ex., 700 ms pour classification, 2–6 s pour longue forme). Enregistrez le point de coude où apparaissent les timeouts.
3. Jour 4–5 : Évaluation complète. 1 500 éléments × 4 modèles × 3 échantillons = 18 000 appels. Échelonnez les modèles selon un planning en carré latin pour éviter les effets d’heure de la journée. Utilisez des clés API et des régions séparées par modèle quand c’est possible.
4. Jour 6 : Analyse et ablations. Relancez les deux meilleurs modèles sur 300 cas limites et avec un second modèle juge pour confirmer la stabilité du classement.

La mécanique des coûts qui ne surprendra pas la finance

Ne devinez pas ; budgétez avec une formule simple :

• Tokens totaux = éléments × échantillons × (moyenne tokens prompt + moyenne tokens complétion)
• Coût brut = (tokens d’entrée × $/M d’entrée) + (tokens de sortie × $/M de sortie)
• Coût effectif par élément résolu = coût brut ÷ éléments réussis

Exemple : 1 500 éléments, 3 échantillons, prompts de 800 tokens, sorties de 300 tokens ⇒ 1 500 × 3 × (800 + 300) = 4,95 M tokens. À $2/M en entrée et $8/M en sortie (illustratif), split 800:300 ≈ 72 %:28 % ⇒ coût ≈ (3,56 M × $2) + (1,39 M × $8) ≈ $7.1K + $11.1K ≈ $18.2K pour un modèle. Si ça pique, réduisez à n=2 et 1 000 éléments pour la première passe, puis élargissez pour les finalistes.

Le sujet n’est pas le montant absolu ; c’est la discipline. Connaissez vos tokens, connaissez votre exposition, et ne tournez jamais à l’aveugle.

Lire les résultats : comment choisir des gagnants prêts à livrer

Segmentez par tâche, pas à l’intuition

• Tâches JSON strictes : Préférez les modèles avec le taux de rupture de schéma le plus bas même s’ils sont 10–15 % plus lents. Du JSON cassé entraîne des retries et des blocages d’agents.
• Agents à forte utilisation d’outils : Mesurez la précision des appels d’outils et le nombre d’étapes de chaîne. Un modèle qui prend en moyenne 1,2 étape de moins bat souvent un concurrent à tokens plus rapides.
• Raisonnement/contexte long : Classez par taux de victoire du juge à latence fixée et par coût par réponse validée. Si un plus petit modèle atteint 92 % de qualité pour 40 % du coût, c’est le choix de prod aujourd’hui, avec une voie d’upgrade plus tard.

Des lignes de coupe acceptables

• SLO de latence : p95 ≤ 700 ms pour la classification, ≤ 2,5 s pour l’extraction/les tours d’outil, ≤ 6 s pour la longue forme. Adaptez à votre UX.
• Stabilité : Dérive hebdomadaire du taux de victoire ≤ 3 % et delta de rupture de schéma ≤ 1 %. Si la p95 d’un fournisseur dérive de 15 % semaine après semaine, double‑sourcez ou stoppez.
• Plafond de coût : Fixez un $ max par 1 000 éléments par type de tâche. Rétro‑calculez des budgets de tokens par appel pour éviter les paniques produit plus tard.

Pièges qui invalident 60 % des benchmarks internes

• Faire juger par le modèle candidat : Il se flatte lui‑même. Isolez toujours le juge ; faites‑le tourner trimestriellement.
• Exécutions uniques : La non‑déterminisme plus la variance transitoire de l’API réordonneront votre classement. Rejouez 20 % des éléments et rapportez des intervalles de confiance.
• Illusions de préchauffage : Mesurer juste après les warm‑ups de cache donne des p95 fantaisistes. Maintenez une charge stable pendant des minutes, pas des secondes.
• Churn de template : Si le produit édite le prompt en cours de run, vous mesurez le template, pas le modèle.
• Consommation de jetons cachée en préambule : Les runtimes d’agents et les setups de type MCP peuvent brûler des dizaines de milliers de tokens avant le premier token utilisateur. Instrumentez explicitement préambules et system prompts, sinon vous sous‑compterez de 10–30 %.

Gouvernance : logs, confidentialité et répétabilité

• Journaux à valeur probante : Conservez les empreintes des requêtes/réponses, les comptes de tokens et les décisions du juge pendant 90 jours. Vous en aurez besoin quand le produit demandera pourquoi vous avez changé de modèle — ou quand le juridique demandera ce que l’IA a réellement fait.
• Hygiène PII : Si vous utilisez des données de prod, nettoyez ou synthétisez. Évitez les fuites de secrets clients vers des API tierces. Nous avons publié ailleurs sur la construction de patterns d’IA éphémères ; appliquez‑les ici aussi.
• Artefact de release : Traitez le gagnant comme un package versionné : nom du modèle, région API, hash du template de prompt, version du schéma d’outils et paramètres d’échantillonnage. C’est votre unité de rollback.

Une chaîne d’outils pragmatique

• Harnais : Python + uv ou Go pour la déterminisme. Évitez les notebooks tentaculaires.
• Données/métriques : Parquet pour les résultats, DuckDB ou SQLite pour l’analyse. Gardez ça requêtable sur un laptop.
• Jugement : Un unique prompt de juge stocké dans Git. Optionnellement, ajoutez un second juge pour les finalistes.
• Orchestration : Une simple file de travaux (Celery, Sidekiq ou un worker Go léger) vaut mieux que des pipelines sur‑ingéniérés. Ajoutez un topic dead‑letter.
• Observabilité : Spans OpenTelemetry avec attributs : model, template_hash, tokens_in, tokens_out, retries, status, latency_ms.

Quand (et comment) distiller ou fine‑tuner après votre benchmark

Une fois que votre banc montre un gagnant stable pour une tâche, envisagez une trajectoire de réduction des coûts :

• Optimisation du prompt uniquement : En général +5–15 % de qualité et 10–20 % de tokens en moins si vous raffinez instructions, exemples et indices de schéma. Re‑benchmarkez pour confirmer.
• Fine‑tuner de petits modèles : Si vos données sont propriétaires et étroites, un modèle 7–14B de paramètres fine‑tuné sur quelques milliers d’items labellisés peut atteindre 80–90 % d’un modèle de pointe pour une fraction du coût et de la latence. Votre banc vous dira si c’est suffisamment proche.
• Distillation de connaissances : Utilisez votre meilleur modèle comme enseignant pour labelliser des données pour un élève plus petit. Gardez un œil sur le juridique et la conformité ; benchmarkez l’élève avec le même banc pour éviter d’expédier des régressions.

Pourquoi c’est clé pour des équipes nearshore et hybrides

Si vous opérez des pods distribués (onshore + nearshore), votre benchmark devient la lingua franca. Il encode les décisions en code et en chiffres, pas dans des threads Slack. Un pod basé au Brazil peut faire tourner le même harnais pendant la nuit, rapporter les deltas le matin, et vous vous mettez d’accord sur une promotion ou un rollback avec des preuves. Prévoyez 6–8 heures de recouvrement quotidien pour la discussion, et des runs asynchrones à grande échelle pendant votre sommeil.

À quoi ressemble le “bon” en pratique

• Revue hebdomadaire de 30 minutes : Topline du dernier run : taux de victoire par tâche, p95 par palier de RPS, coût par élément résolu, dérive depuis la semaine passée, régressions notables.
• Critères de promotion : Un modèle est promu quand il dépasse la prod actuelle de ≥5 % sur le taux de réussite, respecte les SLO p95 et réduit le coût par élément résolu de ≥10 % — pendant deux runs consécutifs.
• Discipline de rollback : Si la dérive dépasse 3 % ou si la p95 dépasse le SLO pendant 2 heures, revenez automatiquement au gagnant précédent. La version de votre artefact rend cela trivial.

La vérité impopulaire

Le modèle “meilleur” sur le graphique de quelqu’un d’autre peut finir troisième chez vous. C’est très bien. Vos clients n’utilisent pas des benchmarks ; ils utilisent votre produit. Construisez le banc une fois, et vous cesserez d’argumenter sur des feelings, vous arrêterez de surpayer des tokens inutiles, et vous commencerez à livrer des upgrades en confiance.

À retenir

• Les classements publics reflètent rarement vos prompts, vos latences ou vos coûts — construisez un benchmark fidèle au workload.
• Mesurez cinq choses : taux de réussite, p95 au RPS cible, coût par élément résolu, taux d’échec/refus et dérive.
• Utilisez des schémas stricts pour les tâches structurées et un ELO multi‑juges pair‑à‑pair pour l’ouvert ; calibrez avec des humains.
• Faites des balayages de concurrence, des charges en régime établi, et rejouez 20 % des éléments pour contrôler la non‑déterminisme.
• Versionnez tout : modèle, région, hash du prompt, schéma d’outils et paramètres d’échantillonnage — c’est votre unité de rollback.
• Servez‑vous du banc pour justifier l’ops de prompts, le fine‑tune de petits modèles ou la distillation quand ils battent les modèles de pointe sur le coût par élément résolu.