Aller au contenu
Chapitre 04 · 11 min

Outils et appel de fonctions

Un modèle capable d'appeler des outils est une classe de système différente de celui qui ne peut que parler. Les outils transforment le modèle d'une chose qui devine en une chose qui agit sur de vrais systèmes — et c'est ainsi que vous corrigez les pires faiblesses du modèle (arithmétique, données récentes, effets de bord) sans rien réentraîner.

A model calling a deterministic toolThe model emits a structured tool call instead of guessing. The tool — a calculator, database, or API — runs deterministically and returns a result, which the model reads before producing its final answer.modeltoolcalc · db · api{ tool, args }resultthe model decides; the tool is the source of truth

“Arrêtez de demander au modèle de faire de l'arithmétique dans sa tête. Donnez-lui une calculatrice et laissez-le appuyer sur les touches.”

Ce que signifie réellement l'« appel de fonctions »

Vous décrivez un ensemble de fonctions au modèle — leurs noms, ce qu'elles font et leurs paramètres. Quand le modèle décide qu'il en a besoin, au lieu de répondre il émet une requête structurée : « appeler get_order_status avec order_id=4471 ». Votre code exécute la vraie fonction, retourne le résultat, et le modèle continue avec ce résultat en main.

Le modèle n'exécute jamais rien lui-même. Il ne fait que proposer un appel sous forme structurée ; votre code décide de l'exécuter ou non, et comment. Cette frontière est toute la sécurité, et nous nous y appuyons fortement dans le cours sur la sécurité.

A model calling a deterministic toolThe model emits a structured tool call instead of guessing. The tool — a calculator, database, or API — runs deterministically and returns a result, which the model reads before producing its final answer.modeltoolcalc · db · api{ tool, args }resultthe model decides; the tool is the source of truth
Le modèle propose un appel structuré ; votre code exécute le vrai outil et retourne le résultat. L'outil, pas le modèle, est la source de vérité.

Pourquoi les outils corrigent les pires faiblesses du modèle

Rappelez-vous les choses pour lesquelles les modèles sont mauvais : l'arithmétique, les faits récents, et tout ce qui a une bonne réponse déterministe. Les outils règlent les trois en confiant le travail à des systèmes qui y excellent.

  • Calculatrice / interpréteur de code — le modèle arrête de confabuler des nombres et les calcule.
  • Requête base de données / API — le modèle arrête d'inventer des données et les récupère.
  • Recherche — le modèle arrête de s'appuyer sur des connaissances d'entraînement périmées et cherche.
  • Validateurs (vérificateur de types, analyseur de code, schéma) — le modèle peut vérifier sa propre sortie contre la vérité.

Concevoir de bons outils

Le modèle utilise un outil comme un nouveau collaborateur utilise une API inconnue : à partir du nom et de la description seulement. La conception d'outils est donc de la conception d'API pour un lecteur qui ne lira pas le code source. Les noms doivent être sans ambiguïté, les descriptions doivent expliquer quand utiliser l'outil (pas seulement ce qu'il fait), et les paramètres doivent être difficiles à mal utiliser.

Retournez des erreurs sur lesquelles le modèle peut agir. « Erreur 400 » est inutile ; « order_id doit comporter 6 chiffres ; vous avez passé 4471 (4 chiffres) » permet au modèle de se corriger et de réessayer. Traitez le modèle comme le consommateur de vos messages d'erreur, et écrivez-les pour ce lecteur.

Les outils de lecture et les outils d'écriture sont des animaux différents

Un outil qui lit (consulter une commande, chercher dans des docs) est à faible risque : le pire cas est une mauvaise réponse. Un outil qui écrit (envoyer un e-mail, débiter une carte, supprimer un enregistrement) peut causer des dommages réels que le modèle ne peut pas annuler. Ces cas méritent un traitement complètement différent.

Rendez les outils d'écriture idempotents quand c'est possible, pour qu'un réessai soit sûr. Placez une étape d'approbation humaine devant les actions à enjeux élevés. Donnez au modèle un mode simulation pour qu'il puisse tester avant de valider. Et journalisez chaque appel. Le modèle appellera éventuellement un outil d'écriture avec de mauvais arguments ; concevez pour que ce soit survivable, pas catastrophique.

En une ligne chacun

  • Appel de fonctions : le modèle propose un appel structuré ; votre code exécute le vrai outil et retourne le résultat.
  • Les outils corrigent les pires faiblesses du modèle — arithmétique, faits récents, effets de bord — en déléguant à des systèmes qui y excellent.
  • La conception d'outils est de la conception d'API pour un lecteur qui ne lira pas le code source : noms clairs, erreurs instructives, sortie compacte.
  • Les outils de lecture sont à faible risque ; les outils d'écriture ont besoin d'idempotence, de simulations, de bornes, de portes d'approbation et de journalisation.

Où aller ensuite