Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

Le Centre d’Évaluation vous permet de vérifier la qualité des agents avant le déploiement en production. Créez un ensemble de données de cas de test, exécutez-les sur n’importe quel agent publié, et obtenez un rapport quantitatif avec des verdicts réussi/échoué par cas, la latence et l’utilisation des jetons.
Conçu pour l’examen d’approvisionnement en entreprise — chaque résultat est vérifiable, reproductible et stocké de manière persistante.

​
Fonctionnement

Chaque exécution d’évaluation exécute un pipeline à trois étapes pour chaque cas de test :
1

Exécution de l'agent

Un vrai ReActAgent exécute le prompt du cas de test. Même moteur que le chat : même modèle, mêmes outils, mêmes instructions. Pas de simulation, pas de raccourcis.Produit : réponse, latence, utilisation des tokens.
2

Notation par LLM

Un LLM “évaluateur” séparé (modèle rapide) juge la réponse par rapport au comportement attendu et aux assertions.Entrée : prompt + comportement attendu + assertions + réponse. Sortie : { verdict: "pass"|"fail", reasoning: "..." }.
3

Persistance et agrégation

Chaque résultat de cas est sauvegardé dans la base de données. Après que tous les cas soient terminés : taux de réussite, latence moyenne, tokens totaux sont calculés et attachés à l’exécution.

​
Décisions de conception clés

DécisionRaison
ReActAgent réel (pas de simulation)Teste le comportement réel de l’agent, y compris les appels d’outils et le raisonnement multi-étapes
LLM évaluateur séparé (modèle rapide)Bon marché et rapide ; le LLM de l’agent a déjà consommé des jetons lors de l’exécution
asyncio.Semaphore(5)Limite la concurrence à 5 pour éviter de surcharger le fournisseur LLM avec des erreurs de limite de débit
Chaque cas est indépendantPas d’historique de conversation entre les cas ; chacun obtient une nouvelle instance d’agent
Exécution en arrière-planL’exécution se déclenche en tant que tâche asynchrone — l’API retourne immédiatement, le frontend interroge toutes les 3 secondes

​
Flux de travail

​
1. Créer un ensemble de données

Accédez à Eval Center → Datasets et cliquez sur New Dataset. Un ensemble de données est une collection nommée de cas de test. Donnez-lui un nom descriptif (par exemple, « Support client — Questions de niveau 1 ») et une description facultative.

​
2. Ajouter des cas de test

Cliquez dans votre ensemble de données et ajoutez des cas de test. Chaque cas a trois champs :
ChampObligatoireDescription
PromptOuiLa question ou l’instruction exacte envoyée à l’agent
Expected BehaviorOuiUne description en langage naturel de ce qu’une réponse correcte ressemble
AssertionsNonUne liste de vérifications spécifiques (par exemple, « La réponse mentionne la politique de remboursement », « La réponse fait moins de 200 mots »)
Rédiger de bons cas de test :
  • Prompt : Soyez précis. « Quelle est notre politique de remboursement pour les plans d’entreprise ? » est mieux que « Parlez-moi des remboursements. »
  • Expected Behavior : Décrivez le résultat, pas la formulation exacte. « Explique la fenêtre de remboursement de 30 jours et mentionne l’exception pour les plans annuels. »
  • Assertions : Utilisez-les pour les exigences strictes. L’évaluateur vérifiera explicitement chaque assertion.

​
3. Démarrer une Évaluation

Allez à l’onglet Eval Runs et cliquez sur New Evaluation. Sélectionnez :
  1. Agent — n’importe quel agent que vous possédez
  2. Dataset — n’importe quel dataset avec au moins un cas de test
Cliquez sur Start Evaluation. Vous serez redirigé vers la page des résultats.

​
4. Lire les résultats

La page des résultats affiche :
  • En-tête : Nom de l’agent, nom du dataset, badge de statut, taux de réussite, latence moyenne, nombre total de tokens
  • Barre de progression : Se remplit au fur et à mesure que les cas se complètent (vert = proportion de réussite)
  • Tableau des résultats : Une ligne par cas de test avec :
    • Prompt (tronqué — cliquez pour développer)
    • Verdict : Pass (vert), Fail (rouge), ou Error (orange)
    • Réponse de l’agent (tronquée — cliquez pour développer)
    • Raisonnement de l’évaluateur (pourquoi c’est passé ou échoué)
    • Latence (ms) et nombre de tokens
Pendant qu’une exécution est en cours (statut pending ou running), la page se rafraîchit automatiquement toutes les 3 secondes. Ne naviguez pas ailleurs si vous souhaitez voir les résultats apparaître en temps réel.

​
Ce qui est testé

​
Inclus

  • Outils intégrés : calculatrice, web_search, web_fetch, python_exec, file_ops, etc.
  • Instructions de l’agent : Le champ extra_instructions de l’agent est transmis
  • Modèle configuré de l’agent : Si l’agent a une configuration de modèle personnalisée, ce modèle est utilisé

​
Non inclus (par conception)

  • Connecteurs : Les connecteurs HTTP externes nécessitent des services tiers actifs — ignorés dans l’évaluation pour éviter les tests instables
  • Serveurs MCP : Même raison — dépendances de processus externes
  • Historique de conversation : Chaque cas s’exécute isolément sans contexte préalable
  • Bases de connaissances : Les outils de récupération KB ne sont pas chargés en mode évaluation
Cela signifie que les résultats d’évaluation reflètent la capacité de raisonnement et d’utilisation d’outils de l’agent, et non son intégration avec des services externes. Testez les connecteurs séparément via la fonctionnalité Test de connecteur.

​
L’évaluateur

L’évaluateur est un LLM (le modèle « rapide » du système) qui reçoit quatre informations et retourne un verdict structuré en JSON : Invite système :
You are an impartial AI evaluator. Your job is to judge whether an AI agent’s answer meets the expected behavior for a given prompt. Be strict but fair. A “pass” requires the answer to genuinely address the prompt according to the expected behavior. A “fail” means the answer is wrong, incomplete, off-topic, or misses key requirements.
Le message utilisateur comprend :
  1. L’invite originale
  2. Le comportement attendu
  3. La liste des assertions (ou « Aucune spécifiée »)
  4. La réponse réelle de l’agent
Schéma de sortie : 
{
  "verdict": "pass" | "fail",
  "reasoning": "Explanation of why the answer passes or fails..."
}
L’évaluateur utilise structured_llm_call avec l’appel de fonction pour appliquer le schéma. Si l’évaluateur lui-même échoue (erreur réseau, réponse malformée), le cas est marqué comme error.

​
Bonnes pratiques

​
Conception de l’ensemble de données

  • Commencez petit : 5–10 cas couvrant les cas d’utilisation principaux de l’agent
  • Couvrez les cas limites : Incluez au moins 2–3 invites adversariales ou hors de portée
  • Soyez spécifique dans le comportement attendu : Les attentes vagues conduisent à une notation incohérente
  • Utilisez des assertions pour les exigences strictes : « Doit mentionner le prix » est plus fiable que d’espérer que l’évaluateur le détecte

​
Interprétation des résultats

  • Taux de réussite de 80%+ est une bonne base de référence pour un agent bien configuré
  • Taux de réussite faible avec latence élevée suggère que l’agent a du mal avec le raisonnement multi-étapes
  • Statut d’erreur signifie que l’agent ou l’évaluateur s’est arrêté de manière anormale — vérifiez les journaux du serveur pour plus de détails
  • Désaccords de l’évaluateur : Si vous pensez que l’évaluateur se trompe, lisez son raisonnement. Vous devrez peut-être affiner votre description du comportement attendu

​
Quand réévaluer

  • Après modification des instructions de l’agent
  • Après changement du modèle LLM de l’agent
  • Après ajout ou suppression de catégories d’outils
  • Avant tout déploiement en production (intégration CI/CD à venir dans une version future)