Décrire des outils

Un agent d'analytique dispose de deux outils : get_data et query. Le premier lit une table, le second exécute du SQL. Les deux descriptions font quatre mots. En production, le modèle appelle query pour lire une table entière, tombe sur un délai dépassé à 30 secondes, puis rappelle query avec la même requête, puis tente get_data avec un nom de table inventé. Aucune ligne de la boucle n'est fautive. Le modèle a fait ce qu'on pouvait attendre de lui : deviner, faute d'avoir été informé.

La description d'un outil n'est pas de la documentation, c'est la spécification que le modèle utilise pour décider. Elle joue le rôle d'une signature de fonction, d'une docstring et d'un contrat d'erreur, tout à la fois. Un schéma imprécis produit des appels invalides ; un nom ambigu produit des appels au mauvais outil ; une valeur de retour mal formée produit des tours de boucle inutiles. Ce sont les trois causes dominantes de dérive dans un agent, très loin devant le choix du modèle, et elles se corrigent toutes dans le fichier où vous déclarez vos outils.

Le schéma d'un outil, au complet

Voici la forme complète d'une déclaration exploitable. Comparez la densité d'information avec get_data.