Mesures en ingénierie de l’IA : coût contextuel, preuves des agents et interopérabilité

Les commentaires sur l’ingénierie de l’IA expriment souvent une opinion sans aller plus loin. Une pratique plus rigoureuse consiste à reprendre une affirmation populaire, à mener l’expérience qui lui manque, et à publier les résultats accompagnés de la date, de la taille de l’échantillon, des versions logicielles ainsi que des données brutes archivées.

Les chiffres affichés sur cette carte proviennent uniquement des expériences qui ont abouti. Une vérification infructueuse entraînait l’abandon du résultat, avec mention de cet échec.

Considérez les sections ci-dessous comme un index qui s’enrichit au fur et à mesure que de nouvelles expériences sont terminées.

Ce que couvrent ces mesures, et pourquoi trois piliers

Pilier 1 — Économie du contexte : quel est le véritable coût du contexte

Les équipes achètent des tokens qu’elles n’ont jamais créés ; peu publient des données sur ces coûts supplémentaires.

Un étude sur les serveurs d’outils MCP est résumée ici : une étude mesurant le contexte des serveurs d’outils MCP. L’examen de 116 outils via stdio a consommé 38 900 tokens avant que quiconque n’entre quoi que ce soit — soit 19,4 % d’une fenêtre de 200 k tokens. Un seul serveur était responsable de 45 % de cette consommation, et JSON Schema à lui seul représentait 93,6 % de la part de ce serveur.

Par ailleurs, 96 versions publiées sur neuf serveurs ont été comparées. Au cours de 87 transitions de version, 42 ont réécrit le bloc d’outils ; parmi ces réécritures, 31 n’ont ajouté ni supprimé d’outil. Les caches de prompts se sont corrompus dans 48 % de ces versions. La plus petite rupture textuelle, touchant 34 tokens, a invalidé 36 320 tokens en cache.

La capacité de la fenêtre dépend également du type de contenu. Une fenêtre de un million de tokens peut contenir environ 4 MB de texte documentaire, mais seulement environ 1,8 MB de journaux, car les journaux consomment du contexte environ 2,2 fois plus rapidement — d’où un coût plus clairement exprimé en dollars par mégaoctet plutôt qu’en tokens seuls.

Les calculs de routage montrent qu’un modèle peu coûteux n’a besoin que d’un taux de réussite d’environ 4 % pour être moins cher qu’une solution basée sur un modèle avancé. Des études similaires sur la dégradation du contexte expliquent pourquoi même une fenêtre de 2 millions de tokens ne permet pas de conserver l’intégralité des informations dans des prompts longs.

Pilier 2 — Preuves fournies par les agents : ce que les agents enregistrent et ce que l’on peut prouver

Lorsqu’un agent dépense de l’argent pendant la nuit, sa reconstruction est souvent impossible.

Dans six frameworks différents, les journaux d’audit contenaient en moyenne cinq champs, bien que douze aient été jugés nécessaires. Aucun ne stockait de niveau de confiance ni de chaîne de hachage (de sorte que les modifications ne laissent aucune trace), et aucun ne conservait de raison d’arrêt.

Parmi les fichiers CLAUDE.md des 592 meilleurs répertoires, 57 % ne contenaient aucune connaissance réelle — seulement des redirections. HEAD a été vérifié pour chaque répertoire ; les cas limites ont été examinés manuellement dans les deux sens, et l’estimation a changé à deux reprises avant de se stabiliser.

Un recensement de survie basé sur du code d’IA a été effectué 50 fois sur 43 600 modifications dans onze dépôts ; 21 exécutions ont inversé la conclusion. En se basant sur un échantillon de 200 des 5 237 fichiers de vllm au lieu du ensemble complet, l’écart de survie de +12,2 points disparaît. Un outil précédent conçu pour répondre à la même question n’a pas passé la vérification et a été abandonné.

Le comptage des lignes d’un grand artefact de preuve formelle figure dans un rapport publié concernant l’artefact de preuve Fermat d’Anthropic : environ 13 millions de lignes au total, dont 88,5 % correspondent aux corps des preuves, avec une longueur moyenne par étape de 8 lignes contre 4 pour Mathlib.

Des « guerres de territoire » entre agents multiples dans un même dépôt ont été reproduites sans aucune utilisation d’IA — il s’agissait en réalité de verrous de fichiers présentés comme des conflits entre agents. Une autre faille réside dans l’absence de signalement : un agent a continué à donner des réponses incorrectes sur une tâche pendant neuf jours sur quatorze, sans aucun avertissement dans le tableau de bord.

Pilier 3 — Interopérabilité et coût de changement : passer d’un modèle, protocole ou outil à un autre

Le marketing qualifie les modèles et protocoles de compatibles immédiats. Les différences persistent cependant.

Les commutateurs de modèle de production ne sont pas des routeurs simples : seuls trois paramètres présentent des orthographes identiques entre les différentes surfaces comparées. Les spécifications des protocoles MCP et A2A ne comprennent que deux noms de méthodes correspondants. Le sandboxing seul échoue également face au schéma d’intrusion du « trio mortel » ; l’isolation sans contrôles complémentaires n’est pas suffisante.

L’article le plus lu publié

Un guide sur l’intelligence artificielle locale concernant le premier chip 2 nm d’Apple se demande si un Mac peut héberger un modèle de 70 milliards de paramètres. Avec 512 Go de mémoire unifiée, la réponse est oui, et l’article compare ce setup aux solutions cloud.

Comment se déroule la mesure, en quatre règles

1. Seules les étapes exécutées sont prises en compte. Les publications indiquent la méthode, la date, la taille de l’échantillon et les versions ; les résultats bruts sont archivés.

Attaquez d’abord le nombre. Les vérifications manuelles bidirectionnelles ainsi qu’une exécution déterministe ont toutes deux ruiné des titres prometteurs.

Identifiez les points aveugles. Neuf serveurs ne forment pas un écosystème ; l’analyse statique n’est pas une trace en temps réel.

Aucune publication en cas de mesure échouée. Les tentatives infructueuses sont enregistrées afin d’éviter de répéter la même erreur.

Que vient ensuite ?

Le rythme de publication correspond à une mesure par semaine. Le travail actuel cherche à savoir à quelle vitesse un ensemble d’évaluation se dégrade au fur et à mesure que le modèle testé s’améliore : combien de cas deviennent silencieux parce que les capacités ont réellement augmenté, par rapport au nombre de cas qui deviennent silencieux parce que le test lui-même est devenu inutilisable.