Toolformer : Utilisation d'outils auto-supervisée et ses limites pour l'IA financière

Toolformer (Schick et al., 2023, Meta AI) est l'article de référence pour enseigner aux modèles de langage comment appeler des API externes via un entraînement auto-supervisé. J'ai repoussé une lecture attentive car l'« utilisation d'outils » est devenue un tel mot à la mode que les affirmations originales s'en trouvent brouillées. Avant de concevoir un agent d'écriture capable d'appeler des outils de comptabilité, je dois comprendre ce que Toolformer a réellement démontré — et là où il échoue discrètement.

L'article

Timo Schick et sept co-auteurs de Meta AI présentent une méthode pour entraîner un modèle de langage à décider quand appeler des API externes, quels arguments transmettre et comment incorporer les résultats dans ses propres prédictions — sans nécessiter de données d'entraînement étiquetées manuellement pour chaque outil. L'approche est auto-supervisée : le modèle génère des candidats d'appels d'API à des positions plausibles dans le texte, exécute ces appels et ne conserve que les exemples où le résultat de l'API réduit véritablement la perplexité du modèle sur les jetons environnants. Cet ensemble de données filtré est ensuite utilisé pour le réglage fin (fine-tuning). Les outils testés incluent une calculatrice, deux moteurs de recherche (récupération BM25 et recherche Wikipedia), un modèle de questions-réponses, un traducteur et un calendrier.

Le modèle entraîné est un modèle basé sur GPT-J de 6,7 milliards de paramètres qu'ils nomment Toolformer. L'article a été accepté à NeurIPS 2023.

Idées clés

• Sur les problèmes mathématiques textuels (SVAMP), Toolformer 6.7B obtient un score de 29,4 % — contre 5,2 % pour la base de référence GPT-J, 4,9 % pour OPT 66B et 10,0 % pour GPT-3 175B. L'utilisation d'outils réduit efficacement la courbe de mise à l'échelle habituelle pour l'arithmétique.
• Sur les mathématiques ASDiv, Toolformer atteint 40,4 % contre 7,5 % pour GPT-J et 14,0 % pour GPT-3 ; sur MAWPS, 44,0 % contre 9,9 % pour GPT-J et 19,8 % pour GPT-3.
• Sur les tâches de questions-réponses factuelles, la situation s'inverse : GPT-3 surpasse toujours Toolformer sur les trois bancs d'essai de questions-réponses (TriviaQA, WebQuestions, Natural Questions) malgré l'utilisation d'outils de recherche par Toolformer. Toolformer TriviaQA : 53,5 % contre 31,9 % pour la base GPT-J, mais GPT-3 sans outils reste supérieur.
• Le pipeline de génération de données auto-supervisé produit des exemples d'entraînement où le modèle apprend à ne pas appeler une API lorsqu'elle n'est pas utile — l'étape de filtrage utilise l'amélioration de la perplexité comme signal pour déterminer si « cet appel d'outil a réellement aidé ».
• La capacité d'utiliser des outils n'émerge qu'avec le passage à l'échelle : les modèles inférieurs à environ 775 millions de paramètres n'apprennent pas de manière fiable quand invoquer les outils, même avec le même signal d'entraînement.
• L'outil calendrier n'est appelé que 0,2 % du temps dans les tâches de raisonnement temporel ; le modèle oriente principalement les questions temporelles vers l'outil de recherche wiki à la place.

Ce qui tient la route — et ce qui ne tient pas

L'idée centrale est durable : l'astuce du filtrage basé sur la perplexité est élégante car elle ne nécessite aucun étiquetage humain ni aucun oracle connaissant la bonne réponse — seulement si le résultat de l'API inséré a rendu le texte environnant plus prévisible. C'est une véritable contribution, et les résultats en mathématiques sont frappants. Un modèle de 6,7B battant GPT-3 sur ASDiv n'est pas un artifice d'évaluation ; c'est une démonstration claire qu'un appel d'outil approprié vaut environ 26 fois plus de paramètres sur les tâches arithmétiques.

Ce que je trouve moins convaincant, c'est la partie sur les questions-réponses. L'article présente Toolformer comme améliorant globalement les performances, mais les résultats en QA montrent qu'il ne bat pas GPT-3 — un modèle beaucoup plus grand sans aucun outil. Les auteurs le reconnaissent, mais le cadrage narratif (« souvent compétitif avec des modèles beaucoup plus grands ») minimise à quel point la victoire est sélective : le modèle gagne sur des tâches qui se décomposent proprement en un seul appel de calculatrice ou de recherche, et perd ou fait match nul sur des tâches nécessitant un véritable raisonnement sur le contenu récupéré.

Le problème méthodologique plus profond est que le pipeline auto-supervisé suppose que le modèle est déjà assez bon pour générer des appels d'API plausibles avant d'avoir été entraîné à le faire. C'est un problème d'auto-amorçage (bootstrapping). Pour des outils bien structurés comme une calculatrice avec un format d'entrée clair, cela fonctionne. Pour des outils avec des schémas d'arguments plus complexes — exactement le genre que l'on voudrait pour une API d'écriture de comptabilité réelle — la qualité des appels échantillonnés se dégraderait rapidement.

L'article évalue également chaque outil de manière isolée, et non en combinaison. Il n'y a aucune démonstration d'un pipeline multi-étapes où, par exemple, un résultat de recherche alimenterait une calculatrice. Les auteurs signalent cela comme une limite, mais elle est significative : les flux de travail comptables réels nécessitent presque toujours des appels d'outils en chaîne.

Enfin, l'évaluation est en « zero-shot ». Il n'y a pas de comparaison avec GPT-3 ou GPT-4 utilisant le « few-shot prompting » avec des outils fournis en contexte, ce qui est devenu le paradigme dominant quelques mois après cet article. La date de publication à NeurIPS 2023 signifie que les expériences précèdent l'adoption généralisée des API d'appel de fonctions (function-calling), ce qui rend l'ensemble de comparaison quelque peu daté au moment de la publication.

Pourquoi cela compte pour l'IA financière

L'article Toolformer répond à une question qui m'importe pour Bean Labs : un modèle peut-il apprendre à appeler une API d'écriture de manière fiable, et à quel coût ? La réponse des résultats mathématiques est « oui, si l'interface de l'outil est propre et que la tâche se décompose en un seul appel ». Cependant, les modes d'échec correspondent directement aux parties les plus difficiles du problème de la comptabilité.

Les actions d'écriture Beancount — classifier une transaction, inférer les correspondances de comptes, générer une écriture de journal — ne sont pas des appels de calculatrice en une seule étape. Elles impliquent la récupération de contexte (entrées précédentes, plan comptable), l'application de règles (règles d'imputation, contraintes de devises) et la production d'une sortie structurée qui doit être syntaxiquement valide. Cela représente au moins trois appels d'outils en chaîne, et l'architecture Toolformer ne peut explicitement pas enchaîner les outils. Le signal d'entraînement basé sur la perplexité serait également difficile à appliquer ici : on ne sait pas ce que signifie une « perplexité plus faible sur le texte de comptabilité environnant » lorsque la sortie est un fichier .beancount structuré plutôt qu'une suite en langage naturel.

La leçon la plus utile de Toolformer pour nos besoins réside dans l'espace en creux : un agent d'écriture ne peut pas être simplement un modèle de langage ajusté ayant mémorisé quand appeler l'API de comptabilité. Il a besoin d'une couche de raisonnement explicite (ReAct ou similaire) capable de planifier, d'exécuter et de vérifier les résultats intermédiaires avant de valider une écriture. Toolformer démontre que l'utilisation d'outils fonctionne ; il ne démontre pas qu'elle fonctionne de manière sûre sur des opérations structurées à effets de bord.

Que lire ensuite

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — ajoute des étapes de raisonnement explicites par chaîne de pensée entrelacées avec des appels d'outils ; l'architecture qui répond à la limitation du chaînage de Toolformer et sert de base à la plupart des agents modernes.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — porte l'utilisation d'outils à plus de 16 000 API réelles via l'ensemble de données ToolBench ; ce qui se rapproche le plus d'un test de résistance pour l'appel d'outils au niveau de complexité auquel un véritable agent comptable serait confronté.
• FinMaster (arXiv:2505.13533) — évalue les flux de travail comptables de bout en bout, y compris les écritures de journal et le rapprochement ; montrera si les gains démontrés par Toolformer en arithmétique se généralisent aux tâches multi-étapes et contraintes par un schéma qui comptent pour Beancount.