Ton agent IA réussit une fois, mais l'autre ? Résoudre l'instabilité

Le problème que les benchmarks cachent

Tu as probablement vu des classements d'IA : « GPT-4 obtient 77 % de réussite ». Ce chiffre vient d'une moyenne : lance la tâche plusieurs fois, additionne les succès, divise par le nombre d'essais. C'est le Mean@k.

Mais voici le piège : cela répond à une question qu'un utilisateur réel ne se pose pas. Un utilisateur veut savoir : si je pose exactement la même question deux fois, ça marchera à chaque coup ? C'est le Pass^k — la fraction de tâches où l'agent réussit à chaque exécution.

Dans l'étude, sur AppWorld :

• ▸Mean@5 : 77,4 % (ce qu'on lit partout)
• ▸Pass^5 : 53,0 % (la vraie fiabilité)
• ▸L'écart de cohérence : 24,4 points

Traduction : près d'un quart des tâches sont instables. L'agent oscille entre succès et échec sans que rien ne change côté utilisateur.

Pourquoi les agents « flippent » ?

Quand un LLM choisit une action — appeler une API, passer un argument, rejouer une étape — ce choix sort d'une distribution de probabilités. La forme de cette distribution décide tout.

Une distribution concentrée : la majorité du poids repose sur un token. Les alternatives sont loin derrière. Même résultat à chaque exécution, stable.

Une distribution plate : le poids se répartit entre plusieurs tokens quasi-équivalents. C'est une pièce de monnaie. Comme une trajectoire enchaîne des dizaines de décisions, cette fragilité se compose : une petite variation dans le calcul en virgule flottante (traitement par lot, optimisation GPU, aller-retour réseau) peut faire basculer une décision sur une tâche difficile.

Et c'est vrai même à température 0, même avec décodage greedy et seed fixée. Les probabilités changent légèrement d'un appel à l'autre : une quasi-égalité peut se résoudre différemment.

La solution : Consistency Analyzer

IBM Research a construit deux étapes :

1. Détecter les points instables

Le Consistency Analyzer rejoue chaque étape de décision d'une trajectoire enregistrée, sans ré-exécuter la tâche. Une seule passe : pour chaque décision, on fait un appel modèle supplémentaire en demandant k complétions (5 par défaut) sur le contexte déjà noté. Cela génère une « fiche de risque » des points critiques.

C'est entièrement boîte noire : zéro accès aux logits, zéro instrumentation.

2. Générer des directives ciblées

Chaque point instable devient une recommandation injectée dans le contexte. Exemple réel (tâche AppWorld, compter des coches) :

Directive 1 : Utilise une regex ancrée à la ligne pour compter les marqueurs checkbox, pas une simple recherche de chaîne — les titres de notes répètent souvent le symbole dans une légende.

Directive 2 : Vérifie toujours les résultats de recherche en consultant plusieurs correspondances et en confirmant la bonne note avant de continuer.

Ces directives ne sont pas propres à une tâche isolée. Ce sont des instabilités qui resurgiront partout.

Les résultats

Sur AppWorld (168 tâches, agent ReAct / GPT-4.1) :

• ▸Pass^5 : 53,0 % → 69,0 % (+16pp)
• ▸Mean@5 : 77,4 % → 81,0 % (+3,6pp)
• ▸L'écart de cohérence : 24,4pp → 12,0pp (réduit de moitié)

Zéro perte de capacité moyenne. Les tâches difficiles gagnent ~22pp en cohérence.

Pourquoi ça compte

Pour du prototypage, 77% est acceptable. Pour la production — valider un contrat sans relecture, réconcilier une transaction financière, workflow critique — tu as besoin d'une pièce fiable. Cet outil adresse enfin une question que les classements ignorent volontairement.