Alors, vous tombez sur des trucs avec lesquels je me bats depuis environ 5 ans. Des métriques auxquelles les gens ne pensent pas, mais devraient.
Les régimes de tokens ne sont pas la solution, parce que le problème ne vient pas du nombre de tokens. C’est la complexité cyclomatique de l’opération et la clarté des instructions qui comptent. Un nombre élevé de tokens peut ne pas créer de confusion si la complexité cyclomatique est faible. Par contre, un petit nombre de tokens avec une complexité cyclomatique élevée, ça peut coincer.
Ensuite, une observation. Vous avez déjà remarqué que parfois, un modèle 4b peut faire tourner en bourrique un 20b ou un 60b ? C’est parce que le nombre de paramètres n’est pas l’élément important. Ici, la métrique à surveiller, c’est la bande passante de raisonnement, ou la profondeur récursive. Jusqu’où peut-on pousser un agent avant qu’il ne s’effondre sur lui-même et boucle ?
Il faut vraiment aborder les deux au cas par cas. Il n’y a pas de règle absolue qui fonctionne sur tous les systèmes.
La métaphore du nettoyage de chambre me donne une idée. Et si un agent avait un outil pour passer en revue son propre contexte et supprimer tout ce qu’il juge inutile pour faire le job ? On pourrait probablement intégrer ça à la gestion de session. Juste réviser entre chaque tour, de la même manière qu’on tronquerait dans un client personnalisé ? J’ai l’impression que ça marcherait partout, sauf sur Gpt-oss.
Tant pis.
C’est juste mon avis.
Allez voir le papier !
Je vous adore !