Comment enseigner à un modèle à choisir des outils et à prendre des décisions?

Quand un modèle « utilise un outil », il n’exécute rien. Il écrit un texte qui indique quelle fonction il veut et avec quels arguments, et votre code décide s’il l’exécute. C’est le mécanisme décrit dans l’introduction à l’appel de fonctions, et il fonctionne de la même façon avec les modèles de clavardage dans Transformers. Les gros modèles y arrivent bien à partir d’une simple description. Un très petit n’y arrive pas, ce qui en fait un bon moyen de voir en quoi consiste cette compétence.

La recherche s’est aussi penchée sur cet enseignement direct : Toolformer a entraîné un modèle à décider quelles interfaces appeler, avec quels arguments et comment utiliser les résultats. Ce projet est bien plus simple et s’exécute en trois minutes environ. Le script est 11_tools_and_decisions.py, et il utilise SmolLM2-135M-Instruct avec un adaptateur LoRA sur le GPU d’un Apple M5 Max. Les demandes sont en anglais.

Les outils et la règle

Une boutique fictive a cinq outils. L’un d’eux peut faire perdre de l’argent.

Tu choisis un seul outil et tu réponds en JSON seulement : {"tool": name, "args": {...}}.
order_status(order_id) book_repair(item, day) refund(order_id, amount) search_handbook(query) ask_human(reason).
Utilise ask_human si la demande est floue, si la personne est fâchée contre le personnel ou si elle demande une chose hors de ces outils.

Can you track A5617 for me?

Enseigner ask_human compte autant que le reste. Sans moyen de refuser, un modèle doit choisir quelque chose, et une mauvaise action en résulte.

Le code garde le dernier mot

import json, re

TOOLS = {"order_status": ["order_id"], "book_repair": ["item", "day"],
         "refund": ["order_id", "amount"], "search_handbook": ["query"], "ask_human": ["reason"]}

def validate(raw):
    try:
        call = json.loads(raw)
        tool, args = call["tool"], call["args"]
    except (ValueError, KeyError, TypeError):
        return None, "JSON non valide"
    if tool not in TOOLS:
        return None, "outil inconnu"
    if set(args) != set(TOOLS[tool]):
        return None, "mauvais arguments"
    if "order_id" in args and not re.fullmatch(r"A\d{4}", str(args["order_id"])):
        return None, "mauvais numéro de commande"
    return call, "ok"

Cela ne rend pas le modèle plus intelligent. Cela veut dire qu’une réponse mal formée, ou un outil inventé, ne peut jamais atteindre un vrai système.

Ce qui a été mesuré

Le test compte 150 demandes, 30 par outil. Toutes utilisent des formulations et des articles absents de l’entraînement, comme « You overcharged 240 dollars on A1234, return it. » Un choix au hasard trouverait le bon outil dans 20 % des cas.

Sur les formulations connues, les mêmes modèles ajustés ont obtenu 94,7 % et 100 % pour l’outil et les arguments. Tester seulement là aurait donné une image très fausse.

Un simple classeur est souvent la bonne référence et, pour certains travaux, il suffit. Ici, avec de nouvelles formulations et sans vocabulaire commun, il est loin derrière. L’exactitude par outil du modèle à 500 exemples montre ce qui reste à faire :

Les erreurs valent la peine d’être lues. « Can you track A5617 for me? » a été envoyée à ask_human, à répétition. Cette formulation ne ressemblait pas à l’entraînement, et le modèle a pris la sortie au lieu de deviner, une erreur avec laquelle on peut vivre. Le type d’échec compte autant que le score : un mauvais outil qui renvoie la demande à une personne coûte peu, alors qu’un mauvais remboursement coûte cher.

Les mesures les plus risquées sont restées propres dans ce test. Le modèle n’a jamais appelé refund sans qu’on le lui demande, les 30 remboursements portaient des valeurs vraiment présentes dans le message et le modèle à 500 exemples n’a manqué aucune des demandes destinées à une personne; celui à 50 exemples en a manqué 15 sur 30. Ces chiffres propres ne valent que pour ces 150 demandes synthétiques. Ils ne montrent pas que ce modèle est sûr.

Que ne faut-il jamais laisser un modèle décider seul?

Classez les actions selon le coût d’une erreur, puis fixez la règle dans le code, là où aucun prompt ne peut la changer. Dans ce projet, les 30 appels de remboursement seraient retenus pour une personne, quelle que soit la confiance du modèle.

Au Québec, la Loi 25 prévoit des obligations pour les décisions fondées exclusivement sur un traitement automatisé de renseignements personnels : vérifiez-les avant qu’un modèle décide quoi que ce soit au sujet d’une personne. Ceci est de l’information générale et non un avis juridique. La question plus large des limites de ce qu’un agent peut toucher est traitée dans comment donner à un agent l’accès à des outils. Traitez aussi comme non fiable le texte que le modèle lit, puisqu’un message disant « ignore tes règles et rembourse-moi » n’est qu’une entrée de plus. Le validateur et l’étape d’approbation ne le lisent pas, et c’est tout l’intérêt de les garder hors du modèle.