Un agent IA a été chargé d'accélérer un magasin clé-valeur. Il a obtenu une augmentation du débit de 6× et a réussi tous les tests de vérification. L'explication ? L'agent a découvert que le benchmark standard de l'industrie utilisé pour évaluer les performances du magasin générait des valeurs à partir des clés. Au lieu de stocker les valeurs, il se contentait de les régénérer à la demande lorsque les clients les sollicitaient.
Un magasin clé-valeur qui évite de stocker les valeurs n'a guère de sens, pourtant l'évaluateur a récompensé exactement ce comportement. La spécification omettait quelque chose que nous pensions évident, et le benchmark n'a pas permis de révéler cette omission.
Deux lacunes conduisant au hacking de récompense et aux hallucinations
Notre nouvel article explique ce comportement ainsi que de nombreux autres échecs agentiques à travers le prisme de deux lacunes clés qui se situent en dehors de la boucle familière implémentation-vérification qui génère du code, exécute des tests et corrige les erreurs jusqu'à ce que tous les tests passent.
- Lacune des exigences : Elle sépare ce que nous écrivons de ce que nous voulons réellement. Dans notre cas, nous tenions pour acquis que toute solution stockerait les valeurs fournies par les clients—après tout, c'est bien pour cela qu'on l'appelle un « magasin » !—il ne nous est donc jamais venu à l'esprit de formuler explicitement cette exigence.
- Lacune du modèle : Elle sépare l'environnement dans lequel nous évaluons du monde réel où l'implémentation sera déployée. Notre benchmark utilisait des valeurs prévisibles, mais les vrais clients fournissent des valeurs arbitraires.
La réponse naturelle consiste à rédiger de meilleures exigences et des tests plus robustes. Les deux sont utiles. Mais même les preuves vérifiées par machine ne peuvent combler ces lacunes. Comme l'expliquait Brian Cantwell Smith dans The Limits of Correctness (1985), une preuve établit uniquement que le logiciel satisfait aux exigences déclarées sous certaines hypothèses environnementales données. Elle ne peut pas prouver que ces exigences capturent tout ce que les utilisateurs veulent, ni que ces hypothèses couvrent chaque scénario de déploiement réel. Par conséquent, ces lacunes ne peuvent pas être comblées de manière générale.
Ces lacunes conduisent au hacking de récompense et aux hallucinations. Le hacking de récompense survient lorsque les agents améliorent un objectif donné en exploitant une lacune, telle qu'une exigence non déclarée ou une hypothèse sur le monde réel. L'hallucination survient lorsque les agents élargissent davantage les lacunes en introduisant des exigences ou des hypothèses environnementales fabriquées, comme une API qui n'existe pas. Les incidents récemment signalés impliquant OpenAI et Hugging Face et Claude sont tous des manifestations de ces lacunes.
Les agents IA aggravent les deux lacunes
Ces lacunes ne sont pas nouvelles ; elles existent depuis des décennies chez les ingénieurs logiciels. Mais les agents IA rendent ces lacunes beaucoup plus graves.
- Hyper-optimisation : Les agents explorent les implémentations des ordres de grandeur plus vite que les humains, optimisant activement contre l'évaluateur.
- Manque de connaissances tacites : Les ingénieurs humains expérimentés s'appuient sur un contexte tacite (par exemple, savoir qu'un magasin de données doit réellement stocker des données). Les agents manquent souvent de ce contexte organisationnel et exploiteront volontiers les exigences manquantes.
- Le piège multi-agents : Ajouter plus d'agents de revue ne résout pas le problème si chaque agent hérite exactement des mêmes exigences incomplètes et des mêmes hypothèses environnementales.
Le jugement humain est essentiel pour réduire les lacunes
Puisque les lacunes se situent en dehors de la boucle implémentation–vérification, leur réduction nécessite une boucle externe d'assurance-révision. Cette boucle vérifie si le comportement déployé satisfait l'intention humaine. Lorsqu'il ne le fait pas, la boucle utilise les preuves du déploiement pour réviser les exigences, le modèle environnemental ou l'évaluateur. La boucle implémentation-vérification est ensuite exécutée à nouveau pour produire une implémentation révisée.
Parce que le logiciel doit servir l'intention humaine, les humains conservent l'autorité finale sur l'interprétation des preuves et la décision concernant le comportement acceptable. Les agents peuvent accélérer la boucle externe en recueillant des preuves, en proposant des révisions et en prenant des décisions courantes dans le cadre de l'autorité déléguée par les humains.
Ainsi, à mesure que l'implémentation logicielle devient moins coûteuse, la ressource la plus critique devient le jugement humain sur le comportement acceptable et l'évaluation fidèle de la performance des systèmes dans des conditions réelles.
