Quels LLM locaux savent réellement appeler des outils ?
Un agent ne devient pas fiable parce qu’un modèle sait produire un joli bloc JSON. Pour effectuer une action, il doit sélectionner le bon outil, respecter son schéma, fournir des paramètres utiles et savoir quand ne pas appeler d’outil. C’est une compétence distincte de la conversation générale.
Ce qu’un benchmark doit tester
Un jeu d’évaluation utile couvre au moins trois familles de cas :
- Sélection d’outil : retrouver une information, lire un document public ou préparer une action avec l’outil approprié.
- Réponse sans outil : répondre directement lorsqu’aucune action externe n’est nécessaire.
- Opérations composées : enchaîner plusieurs étapes tout en conservant les contraintes du schéma.
Le score doit séparer le choix de l’outil, la validité des arguments et les appels inventés. Sans cette séparation, un modèle qui choisit bien mais sérialise mal et un modèle qui hallucine des capacités peuvent sembler équivalents.
Le protocole compte autant que le modèle
L’appel d’outils dépend de la compatibilité entre le modèle, son modèle de conversation, le serveur et le format de requête. Deux empaquetages d’un même modèle peuvent se comporter différemment s’ils n’intègrent pas les mêmes métadonnées de template. Avant de conclure qu’une architecture est incapable, il faut vérifier le format de chat et l’exposition correcte des définitions d’outils.
Cette précaution vaut aussi pour les modèles entraînés à imiter une sortie conversationnelle. Une réponse qui ressemble à un appel de fonction n’est pas forcément compatible avec le protocole structuré attendu par le client.
Ce que les scores ne montrent pas
Un taux de réussite sur un petit ensemble de tests est un signal, pas une garantie. Les cas importants à ajouter sont : arguments ambigus, valeurs manquantes, outils aux noms proches, refus d’actions non autorisées et récupération après erreur. Les tests doivent également distinguer une réponse plausible d’un appel qui passe effectivement la validation du schéma.
Choisir pour un agent local
Pour un usage agentique, privilégier un modèle et un moteur qui documentent explicitement l’appel d’outils. Tester ensuite le flux réel avec des outils inoffensifs et des schémas stricts. Un modèle légèrement moins impressionnant en discussion peut être beaucoup plus utile s’il respecte systématiquement les contrats structurés.
L’objectif n’est pas de couronner un gagnant universel. C’est de mesurer la fiabilité de l’interface entre un modèle et les actions qu’on lui autorise.