Juger les preuves dans les expériences d’IA

Une note peut contenir dix liens et rester principalement une opinion. Pour la juger, il faut vérifier ce que soutient réellement chaque source.

Une spécification peut établir la définition d’une API. Elle ne prouve pas que toutes les implémentations fonctionnent. Un benchmark peut rapporter un résultat dans une configuration précise. Il ne choisit pas le meilleur outil pour tous les dépôts. Un test personnel peut guider mon propre travail, sans devenir un résultat général après une seule exécution.

Faire correspondre preuve et affirmation

Ce que la note affirme	Ce qu’elle devrait généralement fournir	Ce que cela ne prouve toujours pas
Un protocole ou une API se comporte d’une certaine façon	Une spécification versionnée ou une documentation officielle à jour	Que les implémentations sont complètes, sûres ou interopérables
Un modèle ou un produit accomplit une tâche	Une carte de modèle ou une documentation, plus un test ciblé	Une supériorité générale hors du cadre testé
Un résultat de benchmark	Les versions de la tâche et du harness, le modèle, la date, la configuration et le résultat	Le transfert vers un autre dépôt, une autre langue ou une autre machine
Une observation personnelle	Une exécution reproductible et les échecs conservés	Une performance valable pour toute une population
Une recommandation	Des critères, des alternatives, des coûts et un seuil d’échec	Un meilleur choix valable pour tout le monde
Une prévision	Des hypothèses, des scénarios et l’incertitude	Un fait futur déjà vérifié

La documentation officielle convient pour une interface et pour les déclarations du fournisseur sur son produit. Elle est moins neutre lorsqu’il s’agit de qualité. Les benchmarks indépendants réduisent ce biais, mais introduisent leurs propres choix de tâches, de configurations et de seuils de publication. Pour vérifier versions des tâches, configuration et écarts question par question en lisant un résultat de benchmark, voir les fiches et évaluations de modèles.

Les biais sont plus faciles à gérer lorsqu’ils ont un nom

Avant de croire une comparaison, je cherche ce qu’elle ne teste pas. Les omissions comptent souvent davantage que la dernière décimale.

Le biais temporel est le plus facile à illustrer : il transforme un instantané daté en classement durable. La comparaison des API gratuites publiée par OpenRouter en juin était dépassée sur deux points dès août (l’état actuel figure dans le radar des modèles et des API) : l’offre gratuite de Cerebras était devenue un essai de 30 jours avec 5 dollars de crédit, réservé aux comptes ayant enregistré un moyen de paiement, et GitHub Models avait été entièrement retiré le 30 juillet.

Les autres biais ont eux aussi une forme reconnaissable. Le biais de sélection exclut les modèles, langues, outils ou échecs gênants. Le biais fournisseur transforme le positionnement d’un produit en résultat mesuré. Le biais de benchmark comprend la contamination, les tâches étroites, le choix des métriques et la confusion entre qualité du modèle et qualité du harness.

Le biais matériel cache des hypothèses sur la mémoire, l’énergie, les accélérateurs ou le réseau. Le biais de langue et de domaine généralise des résultats anglais ou Python à des contextes jamais testés. Le biais d’automatisation prend une réponse fluide ou le message de fin d’un agent pour une preuve de correction. Le biais de méthode transforme une préférence personnelle pour le terminal, l’IDE ou l’automatisation en conseil universel.

Cette liste ne rend pas la note neutre. Elle expose simplement le point de vue restant afin qu’il puisse être contesté.

Écrire une recommandation comme une décision vérifiable

Un petit relevé d’affirmation suffit à rendre visibles les éléments manquants :

claim: MiniCPM5-2B is a usable local model for triage and simple tool steps
kind: recommendation
as_of: 2026-10-29
facts:
  - model card lists 2.5B parameters, a 131,072-token context and Apache-2.0
  - official GGUF, MLX and GPTQ builds exist
  - model card recommends SGLang with the minicpm5 parser for tool calls
vendor_claims:
  - LiveCodeBench v6 score of 69.1
assumptions:
  - my runtime parses its tool-call template correctly
  - the 4-bit build keeps enough triage quality
missing_evidence:
  - accepted-result rate on my triage tasks
  - tool-call validity outside SGLang
alternatives:
  - Qwen3-4B
  - hosted small model for escalation
falsifier: label or tool-call failures above the task threshold

Les faits de ce relevé viennent de la fiche du modèle MiniCPM5-2B. Le score annoncé par le fournisseur figure sur sa propre ligne, les hypothèses locales sur une autre, et la dernière ligne nomme le résultat qui renverserait la recommandation, ce qui fixe aussi la prochaine date de revue. C’est plus utile que de qualifier un modèle de « puissant » ou « prometteur ».

Mes lectures