Comprendre vos apprenants et leur fournir les bons outils
Langue étrangère 101
Ceux qui ont suivi des cours de langue étrangère s’en souviennent : les enseignants vous mettaient en situation pour simuler différentes interactions sociales (au restaurant, en conversation informelle, en réunion formelle, lors d’un rendez-vous romantique). Dans chaque scénario, ils vous donnaient un contexte et évaluaient à quel point vous vous en sortiriez. Mais vous n’étiez pas vraiment dans la situation ; vous jouiez un rôle. L’objectif était clair : pratiquer dans un environnement sans risque, recevoir des retours, progresser et gagner en confiance avant d’affronter ces situations dans la vraie vie. L’enseignant pouvait ainsi estimer votre niveau réel. Si ça ne se passait pas bien, vous receviez des retours et des pistes d’amélioration. Peut-être que ce n’était pas vous le problème, mais la méthode. Une autre approche aurait peut-être mieux fonctionné.
C’est une analogie très parlante pour comprendre Arcade.dev Evals. Tout comme les apprenants en langue ont besoin de s’entraîner et de gagner en confiance avant de vraies conversations, nous avions besoin d’un moyen de tester la qualité des définitions d’outils et d’en augmenter la fiabilité avant de les déployer en production. Avec Arcade Evals, on peut construire un scénario de jeu de rôle où le LLM joue l’apprenant, ajouter un contexte de conversation simulée, lui donner connaissance des définitions d’outils, puis envoyer un message utilisateur avec le résultat attendu à valider. Ce qui est fondamental : cela teste la sélection d’outils sans exécution réelle. Pas d’appels API, pas d’effets de bord, pas d’infrastructure nécessaire. Le modèle est notre constante ; les outils sont ce que l’on évalue. Les rubriques notent si les définitions d’outils étaient suffisamment claires pour que le modèle sélectionne le bon outil et renseigne correctement les arguments.
Dans cette analogie, nous sommes les enseignants qui fournissons aux apprenants des outils qui, bien utilisés, leur permettent d’exceller dans des situations réelles. Si notre apprenant ne performe pas bien, on envisage aussi que le problème vient peut-être des outils fournis. Tout le processus est pédagogique : on cherche à améliorer les outils pour qu’ils soient intuitifs à utiliser, en tenant compte des capacités cognitives de l’apprenant. On peut construire des outils formidables qui font des choses incroyables, mais s’ils ne fonctionnent que pour les modèles les plus avancés alors qu’on déploie sur un éventail de capacités, ils ne valent pratiquement rien.
Petit vocabulaire
Avant d’aller plus loin sur Arcade Evals, voici quelques termes clés à connaître :
- Définition d’outil / schéma : le schéma JSON et les descriptions que le modèle reçoit pour un outil (noms, paramètres, formats, enums).
- Cas d’éval : une requête utilisateur + contexte optionnel + le ou les appels d’outil attendus.
- Critics : des évaluateurs pour les arguments d’outil (correspondance exacte vs similarité).
- Rubric : des seuils pass/warn/fail appliqués à l’ensemble des critics.
- Tracks : des ensembles d’outils parallèles (ex. : « vague » vs « descriptif ») évalués sur les mêmes cas.
Affiner nos compétences pédagogiques avec Arcade Evals
La qualité des outils a un impact direct sur la fiabilité des agents. Un outil bien conçu possède des descriptions claires, des noms de paramètres intuitifs et des schémas non ambigus qui permettent au LLM de le sélectionner au bon moment et de renseigner correctement les arguments. Quand les outils sont mal conçus, les agents échouent silencieusement ou de façon imprévisible en production : mauvais outil choisi, arguments mal formés, ou bonne action manquée. C’est pourquoi une évaluation systématique est indispensable. Il faut mesurer si les outils sont compréhensibles pour le modèle avant que les utilisateurs ne se heurtent à des échecs.
L’idée de base est simple : créer un ensemble de situations réalistes, demander au modèle de les résoudre avec les outils fournis, et noter si le bon outil et les bons arguments ont été utilisés. Arcade Evals organise tout cela en suites de cas, où chaque cas comporte un message utilisateur, un contexte optionnel, les appels d’outils attendus et des critics qui notent les arguments. Les rubriques transforment ensuite ces scores en résultat lisible (pass, warn ou fail) pour savoir si un outil est prêt à être utilisé en conditions réelles.
Regardez l’extrait de code ci-dessous. Il représente un cas d’éval entièrement exécutable :
"""Minimal Arcade Evals example – a complete, runnable evaluation suite."""
from arcade_evals import (
BinaryCritic, # Exact match validator
SimilarityCritic, # Fuzzy text matching (cosine similarity)
EvalRubric, # Pass/warn/fail thresholds
EvalSuite, # Container for test cases
ExpectedMCPToolCall, # What we expect the LLM to call
FuzzyWeight, # Enum for qualitative weight assignment
MCPToolDefinition, # Tool schema definition
tool_eval, # Decorator to register eval functions
)
# ---------------------------------------------------------------------------
# 1. Define your MCP tools (the interface the LLM sees)
# ---------------------------------------------------------------------------
TOOLS: list[MCPToolDefinition] = [
{
"name": "schedule_meeting",
"description": "Book a calendar meeting with one attendee.",
"inputSchema": {
"type": "object",
"properties": {
"title": {"type": "string", "description": "Meeting title"},
"attendee": {"type": "string", "description": "Email of attendee"},
"datetime": {
"type": "string",
"description": "ISO 8601 datetime (e.g., 2026-02-04T14:00)",
},
"location": {
"type": "string",
"description": "Meeting platform",
"enum": ["Zoom", "Google Meet", "Teams"],
},
},
"required": ["title", "attendee", "datetime", "location"],
},
},
]
# ---------------------------------------------------------------------------
# 2. Create an evaluation suite with test cases
# ---------------------------------------------------------------------------
@tool_eval() # Registers this function with the eval runner
async def eval_scheduling_tools() -> EvalSuite:
suite = EvalSuite(
name="Scheduling Tools Evaluation",
system_message="You are a scheduling assistant. Use the provided tools.",
rubric=EvalRubric(fail_threshold=0.8, warn_threshold=0.9),
tools=TOOLS,
)
suite.add_case(
name="Book team sync",
user_message="Schedule a team sync with alice@acme.com tomorrow at 3pm on Zoom",
expected_tool_calls=[
ExpectedMCPToolCall(
name="schedule_meeting",
arguments={
"title": "Team sync",
"attendee": "alice@acme.com",
"datetime": "2026-01-23T15:00",
"location": "Zoom",
},
)
],
critics=[
SimilarityCritic(
critic_field="title",
weight=FuzzyWeight.HIGH,
similarity_threshold=0.8,
),
BinaryCritic(
critic_field="attendee",
weight=FuzzyWeight.CRITICAL,
),
BinaryCritic(
critic_field="datetime",
weight=FuzzyWeight.CRITICAL,
),
BinaryCritic(
critic_field="location",
weight=FuzzyWeight.MEDIUM,
),
],
)
return suiteVous obtenez ainsi une boucle de feedback à utiliser comme n’importe quelle autre pratique artisanale : capturez le comportement du modèle, définissez des attentes, et itérez sur les descriptions et schémas d’outils jusqu’à ce que le modèle fasse systématiquement ce qu’on attend de lui.
Ce qu’Arcade Evals peut révéler
Arcade Evals a été conçu pour aider les créateurs d’outils MCP et d’agents à obtenir des résultats objectifs simulant le comportement des LLM face à une demande d’action. Les définitions d’outils peuvent être chargées depuis le code source Python d’outils Arcade, des Arcade MCP Gateways, des serveurs MCP distants ou locaux, ou des définitions d’outils basées sur des dictionnaires. Quelques exemples concrets :
- Évaluer le comportement d’un ensemble d’outils sur différents modèles et fournisseurs.
- Vérifier si l’intention d’un outil est clairement communiquée ; ajuster les noms d’outils, de paramètres et les descriptions si ce n’est pas le cas.
- Tester itérativement des définitions d’outils avec des dicts sans s’engager dans du code de production.
- Comparer différents serveurs MCP ou versions en utilisant le même contexte et les mêmes attentes.
- Valider la qualité de serveurs MCP tiers à l’aide d’interactions utilisateur simulées réalistes.
- Vérifier la cohérence de l’Arcade MCP Gateway au fil de l’ajout de toolkits de différents fournisseurs.
- Utiliser les evals comme tests de régression lors de modifications de schémas ou d’ajouts d’outils.
Ce qu’Arcade Evals n’évalue pas (et pourquoi c’est très bien ainsi)
Arcade Evals est délibérément limité à la sélection d’outils et à la qualité des argumentssans exécuter l’outil. Cela signifie qu’il ne valide pas :
- Si l’appel API en aval réussit
- Si la sortie de l’outil est correcte ou utile
- La planification multi-étapes et les nouvelles tentatives (sauf si vous choisissez d’évaluer explicitement ces patterns)
- La latence, les limites de débit, l’authentification ou les effets de bord
C’est une fonctionnalité, pas un bug : cela vous permet d’itérer sur les schémas d’outils tôt, à moindre coût et en toute sécurité.
Démarrer avec Arcade Evals
Prêt à tester vos outils MCP avant qu’ils arrivent en production ? Arcade Evals est intégré à l’Arcade CLI.
pip install 'arcade-mcp[evals]'
arcade evalsPour une checklist pratique de ce qui rend les définitions d’outils efficaces (avec des exemples avant/après), lisez Building High-Quality MCP Tools with Arcade Evals.
Pour les données de benchmark complètes derrière cette approche, consultez le rapport technique.
