La limite de jetons est un budget, pas une simple restriction

Depuis plusieurs semaines, j'observe que Paperclip peut consommer mon quota hebdomadaire de jetons en une seule journée. Le problème ne réside pas dans la forte consommation en elle-même. Si elle entraînait des changements proportionnels et visibles dans les applications, on pourrait la considérer comme un coût lié au travail. Or, une part importante de l’activité du système est consacrée au développement et à la documentation du système, tandis que les projets que ce travail était censé soutenir évoluent beaucoup plus lentement.

J'ai donc configuré Paperclip pour qu'il s'arrête à 75 % de la limite. La limite restante vise à protéger les autres applications Codex, car Paperclip n'est pas mon seul domaine d'activité. Il s'agit d'une simple mesure de sécurité, mais elle révèle un problème plus important : les jetons ne sont pas un nombre abstrait affiché sur un tableau de bord. Il s'agit d'un budget de fonctionnement partagé, auquel se disputent les tâches, les projets et les agents.

Je préfère parler d'intelligence computationnelle plutôt que d'intelligence artificielle. Ce n'est pas qu'une question de style. Une bonne définition doit décrire la réalité aussi fidèlement que possible. Le terme « artificiel » peut suggérer quelque chose d'irréel, d'illusoire ou d'inférieur à l'intelligence humaine. « Computationnel », en revanche, désigne un mécanisme : algorithmes, mathématiques et exécution de calculs. Cela n'implique pas de supposer que l'intelligence humaine soit la seule forme véritable ou la plus aboutie de résolution de problèmes.

Un bon exemple des limites de cette vision anthropocentrique est Physarum polycephalum. Dans cette expérience, des points de nourriture ont été répartis à des emplacements correspondant à 20 grandes zones urbaines américaines. Ce myxomycète unicellulaire les a reliés par un réseau qui, sous forme de graphe simplifié, reproduisait 36 ​​des 41 connexions du réseau autoroutier inter-États américain (Adamatzky et Ilachinski, 2012). Cela ne signifie pas que le myxomycète possède une personnalité humaine ni qu'il a conçu des autoroutes parfaites. Cependant, cela démontre que le calcul utile et l'optimisation des réseaux ne sont pas l'apanage exclusif de l'esprit humain. De ce point de vue, une limite de jetons est comparable à une limite de temps humain, de bande passante d'équipe ou de puissance de calcul disponible. Elle ne détermine pas encore la valeur qui sera créée. Elle détermine plutôt la quantité de travail que le système peut tenter d'accomplir avant de ne plus pouvoir exécuter les tâches suivantes.

La consommation de ressources n'est pas une preuve de résultats

Il n'existe pas de nombre idéal de jetons à attribuer à chaque tâche. Écrire un court poème et préparer un tableau comparatif des coûts et des revenus requièrent des efforts différents. Par conséquent, il est impossible d'évaluer équitablement un système uniquement sur la base du ratio jetons/nombre de fichiers, de réponses ou de tâches générés.

Le point de départ doit être un problème. L'agent doit recevoir un objectif, un contexte et une description du résultat qui, une fois exécuté, sera utile à l'utilisateur ou à l'agent suivant. Ce n'est qu'alors que l'on peut se demander si le coût était justifié. Un artefact ne devient pas précieux simplement parce qu'il a nécessité une longue réflexion. La documentation est nécessaire si elle permet de débloquer le travail. Si elle remplace la modification qu'elle était censée permettre, elle consomme le budget sans que la tâche ne soit clôturée.

Paperclip laisse aujourd'hui deux diagnostics possibles. Le budget disponible est peut-être insuffisant pour l'envergure des projets assignés. Le problème réside peut-être dans l'organisation du travail : tâches trop vastes, contexte mal défini, activités répétitives ou critères d'acceptation privilégiant une documentation facilement accessible. Il est également possible que ces deux contraintes agissent simultanément. Le simple fait que la limite soit atteinte ne permet pas de les dissocier.

Un budget plus important ne résoudra pas un problème mal défini. Il permettra seulement de prolonger le travail de la même manière. Par ailleurs, un budget trop restreint peut perturber une séquence correctement planifiée avant même que ses composants ne soient combinés en un résultat. Par conséquent, la limite doit être analysée en lien avec la structure des tâches, et non comme un obstacle technique isolé.

Le plus petit contexte suffisant

La seconde ressource limitée est le contexte. L'agent a besoin d'informations pour comprendre le problème, les dépendances et les conditions d'acceptation. S'il reçoit trop peu d'informations, il doit faire des suppositions ou s'arrêter à une solution locale qui ne tient pas compte du reste du système. S'il reçoit toutes les données enregistrées concernant le projet, les informations nécessaires à une étape donnée peuvent se perdre dans le bruit.

Mon principe de travail est paradoxal : l’agent doit recevoir le maximum de données nécessaires, qui correspond également au minimum suffisant. Il ne s’agit pas de sauvegarder chaque jeton, mais de trouver le juste milieu. Le contexte doit inclure tout ce qui est nécessaire à la bonne réalisation d’une étape spécifique et ne doit pas contenir d’informations inutiles à la décision ou à l’action en cours.

L’étude « Lost in the Middle » a montré que, dans les tâches utilisant un contexte long, les performances du modèle dépendaient de l’emplacement de l’information pertinente et diminuaient souvent lorsque celle-ci se trouvait au milieu de l’entrée (Liu et al., 2024). Cela ne prouve pas que toute invite longue est néfaste. Cependant, cela montre que la simple acceptation d’une information par le modèle ne signifie pas nécessairement son utilisation efficace.

Le benchmark RULER a révélé une différence similaire. Les auteurs ont testé 17 modèles annoncés comme prenant en charge au moins 32 000 jetons ; Presque tous ces modèles ont perdu en efficacité avec l'augmentation de leur longueur et de leur complexité, et la moitié d'entre eux ont conservé le niveau de performance attendu à 32 000 jetons (Hsieh et al., 2024). La fenêtre déclarée constitue donc une limite technique pour les entrées, et non une garantie de raisonnement utile sur toute sa longueur.

Ceci corrige l'intuition selon laquelle il serait judicieux de remplir la fenêtre disponible par défaut. La remplir de données n'a de sens que si ces données sont nécessaires à la tâche et ont été organisées de manière à ce que l'agent puisse identifier les dépendances. L'espace vide dans le contexte n'est pas une ressource gaspillée. Il permet parfois de se prémunir contre les informations qui pourraient détourner l'attention du problème lui-même.

La tâche doit être compatible avec la bande passante de l'exécutant

Si la bonne exécution de la tâche requiert davantage de contexte, le système dispose de deux options raisonnables : ajouter des informations manquantes spécifiques ou diviser le problème en étapes plus petites et dépendantes. La division n'implique pas la production de tâches arbitrairement petites. Chaque étape requiert une entrée, un résultat attendu et un critère d'acceptation, et son résultat doit être exploitable à l'étape suivante.

L'étude LLM sur la planification d'agents mentionne la décomposition des tâches comme l'un des principaux mécanismes de planification, aux côtés de la sélection de plans, de la mémoire, de la réflexion et des modules externes. Elle met également en lumière des problèmes ouverts liés à la planification et à l'exécution (Huang et al., 2024). La division seule ne garantit pas le succès. Elle peut produire des parties localement correctes qui, une fois combinées, ne résolvent pas le problème initial.

Pour planifier mon propre travail, j'utilise une heuristique simple : je ne planifie pas les tâches qui durent moins de cinq minutes environ ; j'essaie de diviser celles qui durent plus de 25 minutes environ afin de maintenir ma concentration. Il ne s'agit pas d'une conversion du temps humain en jetons d'agent. L'analogie concerne la granularité. Une tâche doit être suffisamment grande pour que son résultat soit significatif, mais suffisamment petite pour que l'exécuteur puisse intégrer les dépendances nécessaires.

Dans un système multi-agents, chaque étape doit se terminer par un résultat intermédiaire contrôlé. Si l'agent a analysé les exigences, le résultat ne peut se limiter à la simple confirmation de la fin de l'analyse. Il doit fournir des exigences structurées et utiles au planificateur. Si le développeur a modifié une fonction, le résultat doit inclure le code et la preuve que les flux restent fonctionnels. Cela évite à l'agent suivant de devoir recréer l'intégralité du contexte précédent et de refaire le même travail.

Le budget doit garantir la création de valeur

Le seuil de 75 % est actuellement une contrainte manuelle, et non une prescription universelle. Dans d'autres systèmes, la réserve appropriée peut être supérieure ou inférieure. Le rôle de cette limite est important : aucun processus autonome ne doit accaparer sans contrôle la totalité de la ressource partagée et bloquer les tâches prioritaires.

Avant de lancer une séquence plus importante, il est donc essentiel de connaître le budget disponible, le résultat minimal et la condition d'arrêt. Après chaque étape importante, le système doit être capable de déterminer ce qui a réellement changé, le résultat transmis et si la poursuite de l'exécution présente toujours une valeur ajoutée par rapport à l'utilisation de la ressource pour une autre tâche. À l'approche de la limite, il convient d'abord de sécuriser l'état et la preuve, et seulement ensuite de réduire la portée ou d'arrêter les travaux.

L'objectif n'est pas de garantir que chaque agent consomme le moins de jetons possible. Une telle optimisation pourrait encourager des réponses superficielles et l'omission de dépendances. L'objectif est une consommation adéquate : le niveau de raisonnement et de contexte nécessaire pour fournir correctement le résultat convenu, sans financer une activité inutile qui ne fait pas progresser le système.

Le quota de l’abonnement est peut-être trop faible. Cependant, avant de l'envisager comme seule cause, je souhaite m'assurer que le système peut préserver son budget, associer le contexte à chaque étape, répartir le travail sans perte d'informations et distinguer le résultat de la trace d'activité. Ce n'est qu'à cette condition qu'un plus grand nombre de jetons se traduira par un débit accru. Sans ces mécanismes, il pourrait s'agir simplement d'un réservoir plus important que Paperclip videra de la même manière.

Bibliographie

✦Construire des systèmes pour plus d’autonomie.