Définir des outils clairs et sûrs

Une description d'outil, c'est de la documentation pour le modèle

Le modèle ne "devine" pas ce qu'un outil fait : il se base entièrement sur sa description textuelle et ses paramètres. Une description vague ou ambiguë conduit à des appels d'outils incorrects ou à un mauvais choix parmi plusieurs outils disponibles.

Faible : {
  "name": "recherche",
  "description": "recherche des trucs"
}

Meilleur : {
  "name": "rechercher_ticket_support",
  "description": "Recherche un ticket support existant par son numéro exact. Retourne le statut, la priorité et le résumé du ticket. N'utilise PAS cet outil pour créer un nouveau ticket.",
  "parameters": {
    "numero_ticket": "Numéro exact du ticket, format TICKET-1234"
  }
}

Limiter la portée de chaque outil

Un outil trop générique ("exécuter n'importe quelle requête SQL") est plus risqué qu'un ensemble d'outils spécifiques et bornés ("rechercher un client par email", "lister les commandes d'un client"). Des outils étroits et bien définis réduisent la surface d'erreur possible.

flowchart TD
    A[Outil generique\nexecuter_sql] --> B[Risque : le modele peut\ngenerer n'importe quelle requete]
    C[Outils specifiques\nrechercher_client,\nlister_commandes] --> D[Perimetre limite et\nprevisible par conception]

Documenter les cas limites et les non-usages

Une bonne description d'outil précise aussi ce qu'il ne faut pas faire avec, réduisant les mauvaises interprétations ("N'utilise pas cet outil pour supprimer un enregistrement, utilise supprimer_ticket à la place").

Cas concret

Un agent dispose d'un outil unique et générique executer_requete_base permettant d'exécuter n'importe quelle requête SQL. Une instruction ambiguë de l'utilisateur ("nettoie les vieux tickets") conduit le modèle à générer une requête DELETE trop large, supprimant des données non prévues. Remplacer cet outil unique par des outils spécifiques et bornés (archiver_tickets_anciens avec des paramètres stricts) aurait rendu ce type d'erreur structurellement impossible, quelle que soit l'ambiguïté de la demande initiale.

Erreurs fréquentes

• Créer un outil trop générique et puissant ("exécuter n'importe quelle commande") plutôt que plusieurs outils spécifiques et bornés, une décision de conception qui détermine directement le niveau de risque de l'agent.
• Rédiger des descriptions d'outils vagues, forçant le modèle à deviner leur usage exact et augmentant le risque d'appel incorrect.
• Ne jamais préciser les non-usages d'un outil dans sa description, alors que cette précision réduit efficacement les mauvaises interprétations sur des cas ambigus.

À retenir

• Le modèle se base entièrement sur la description textuelle d'un outil pour décider quand et comment l'appeler, une description vague augmente les erreurs.
• Des outils spécifiques et bornés sont plus sûrs qu'un outil générique et puissant, en réduisant la surface d'erreur possible par conception.
• Documenter explicitement les non-usages d'un outil réduit les mauvaises interprétations sur des demandes ambiguës.

Mini-exercice

Un agent dispose d'un seul outil générique permettant d'exécuter n'importe quelle requête sur une base de données. Quelle reconception réduirait structurellement le risque d'une action destructrice non désirée ?

Réponse : remplacer cet outil unique et générique par plusieurs outils spécifiques et bornés (ex. rechercher_client, archiver_ancien_ticket), chacun avec un périmètre d'action strictement limité à sa fonction précise, rendant structurellement impossible une action destructrice large non prévue par conception.