> ## 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.

# Centre d'Évaluation

> Évaluez quantitativement vos agents avec des ensembles de données de test et une notation automatisée par LLM.

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.

<Info>
  Conçu pour l'examen d'approvisionnement en entreprise — chaque résultat est vérifiable, reproductible et stocké de manière persistante.
</Info>

## Fonctionnement

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

<Steps>
  <Step title="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**.
  </Step>

  <Step title="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: "..." }`.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### Décisions de conception clés

| Décision                                  | Raison                                                                                                                            |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **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épendant**            | Pas d'historique de conversation entre les cas ; chacun obtient une nouvelle instance d'agent                                     |
| **Exécution en arrière-plan**             | L'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 :

| Champ                 | Obligatoire | Description                                                                                                                                         |
| --------------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Prompt**            | Oui         | La question ou l'instruction exacte envoyée à l'agent                                                                                               |
| **Expected Behavior** | Oui         | Une description en langage naturel de ce qu'une réponse correcte ressemble                                                                          |
| **Assertions**        | Non         | Une liste de vérifications spécifiques (par exemple, « La réponse mentionne la politique de remboursement », « La réponse fait moins de 200 mots ») |

<Tip>
  **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.
</Tip>

### 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

<Warning>
  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.
</Warning>

## 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

<Info>
  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.
</Info>

## 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 :**

```json theme={null}
{
  "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)