Juger les preuves dans les expériences d’IA

Cette note examine la force d’une affirmation après lecture des méthodes et résultats. Les fiches et évaluations de modèles identifient les artefacts ; données et évaluation organise l’expérience. Ici, il s’agit du passage des preuves à la conclusion.

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 banc, 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.

Regarder d’abord ce que la comparaison oublie

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 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 banc.
• Le biais temporel transforme un instantané daté en classement durable.
• 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: gpt-oss-20b can be a practical local agent model on a 16 GB machine
kind: recommendation
as_of: 2026-08-10
facts:
  - provider says the MXFP4 model runs within 16 GB of memory
assumptions:
  - runtime supports Harmony and the exact quantization
  - context and KV cache stay within the remaining budget
missing_evidence:
  - accepted-result rate on my coding tasks
  - latency and peak memory on my hardware
alternatives:
  - smaller dense model
  - larger model on 24 GB
  - hosted model for escalation
falsifier: repeated tool-call or patch failures above the task threshold

Ce format sépare la déclaration du fournisseur des hypothèses locales et nomme le test qui changerait la recommandation. Il est plus utile que de qualifier un modèle de « puissant » ou « prometteur ».

Une empreinte prouve moins qu’il n’y paraît

Conserver une copie adressée par son contenu rend une vérification ultérieure reproductible. Une correspondance exacte peut prouver que les caractères cités figurent dans le fichier enregistré.

Elle ne prouve pas que le fichier vient de l’éditeur annoncé, qu’il est encore à jour, que le contexte préserve le sens ou que la citation soutient la conclusion. Ces questions exigent encore une vérification de la source et une lecture du sens.

Je sépare quatre étiquettes :

• un fait possède une source identifiée et un passage qui le soutient ;
• une piste mérite une enquête, mais reste non vérifiée ;
• une hypothèse est une explication ou une prévision testable ;
• une préférence dépend des objectifs et des compromis.

Toutes les notes n’ont pas besoin d’archiver chaque page. Une chaîne de conservation solide devient surtout utile lorsqu’une affirmation change vite, reste contestée, coûte cher à reproduire ou peut causer un dommage réel.

Garder une revue assez petite pour être utilisée

Extrayez les affirmations avant de polir le texte. Classez chacune d’elles, puis demandez si sa preuve suffit pour la décision qui en dépend. Cherchez un contre-exemple crédible, conservez les échecs avec les réussites et séparez les idées durables des instantanés de produit datés.

Enfin, notez ce qui changerait la conclusion et fixez la prochaine date de revue à partir de ce critère. À la fin, les faits, les tests et les jugements personnels doivent rester faciles à distinguer.

Mes lectures · Les notes ouvertes sont mémorisées dans ce navigateur.