Aller au contenu principal

Classification avec Promptfoo

Mis à jour le 28 juillet 2026

Évaluations de classification avancées

Promptfoo excelle pour les tâches de classification car il offre des assertions puissantes et une visualisation intuitive des résultats par catégorie. La raison est structurelle : un classificateur produit une valeur prise dans un ensemble fini, donc chaque cas de test se réduit à une paire ticket / catégorie attendue, et cette paire s’écrit en quatre lignes de YAML. Là où un script Python vous demandait de gérer vous-même le comptage par classe, l’interface de Promptfoo vous montre directement quelles catégories tiennent et lesquelles s’effondrent.

Configuration détaillée

prompts:
  - |
    Tu es un classificateur de tickets de support.
    Classe ce ticket dans UNE des categories suivantes :
    - BUG : rapport de bug ou probleme technique
    - FEATURE : demande de fonctionnalite
    - QUESTION : question sur l'utilisation
    - FACTURATION : question sur le paiement

    <ticket>{{ticket}}</ticket>

    Reponds avec uniquement le nom de la categorie.

providers:
  - id: anthropic:messages:claude-sonnet-5
    config:
      max_tokens: 20
      temperature: 0

tests:
  - vars:
      ticket: "L'application plante quand je clique sur le bouton Enregistrer"
    assert:
      - type: equals
        value: "BUG"
  - vars:
      ticket: "Serait-il possible d'ajouter un mode sombre ?"
    assert:
      - type: equals
        value: "FEATURE"
  - vars:
      ticket: "Comment exporter mes données en CSV ?"
    assert:
      - type: equals
        value: "QUESTION"
  - vars:
      ticket: "Ma carte bancaire a ete debitee deux fois"
    assert:
      - type: equals
        value: "FACTURATION"

Plusieurs choix de cette configuration méritent d’être compris plutôt que recopiés. Le prompt donne une définition courte à chaque catégorie au lieu de se contenter de les nommer : c’est cette définition qui sera votre levier principal quand une classe se révélera mal reconnue. Le ticket est encadré par une balise <ticket>, ce qui empêche le texte de l’utilisateur de se confondre avec vos instructions — un message qui contiendrait lui-même le mot « catégorie » ne viendra pas parasiter la consigne. La dernière ligne du prompt exige une réponse réduite au seul nom de la catégorie, ce qui est la condition pour que l’assertion equals ait un sens.

Du côté du provider, temperature: 0 demande la sortie la plus déterministe possible. Sur une tâche de classification, la créativité n’apporte rien et la variabilité vous empêcherait de savoir si un score qui bouge vient de votre prompt ou du hasard. Le max_tokens: 20 joue le même rôle de garde-fou : il coupe court à toute tentative d’explication et rend le coût de la campagne négligeable, même sur plusieurs centaines de tickets.

Assertions personnalisées en Python

Pour une logique de notation plus complexe :

tests:
  - vars:
      ticket: "Le bouton ne marche pas sur mobile"
    assert:
      - type: python
        value: |
          output_clean = output.strip().upper()
          return output_clean == "BUG"

La variable output est fournie par Promptfoo et contient la réponse brute du modèle ; il ne vous reste qu’à retourner un booléen. Ce petit bloc fait exactement ce que equals fait, à une différence près qui compte en pratique : il nettoie la sortie avant de comparer. Un espace de fin ou une majuscule de moins ne feront plus échouer un cas pourtant bien classé.

Gérer la normalisation

Les LLM produisent parfois des variations (“Bug”, “BUG”, “bug”, “C’est un bug”). Normalisez :

tests:
  - vars:
      ticket: "..."
    assert:
      - type: javascript
        value: "output.trim().toUpperCase() === 'BUG'"

Cette version en une ligne est souvent la plus commode quand la seule difficulté est la casse. Notez toutefois la limite : la normalisation résout « Bug » et « bug », pas « C’est un bug ». Cette dernière forme est un problème de prompt, pas de notateur — c’est le signe que votre consigne de format n’a pas été assez ferme, et l’ajouter dans le notateur reviendrait à masquer un défaut que vous verriez ressurgir en production, où aucun trim() ne vous protégera.

Résultats et analyse

Après exécution, Promptfoo affiche le taux de réussite global, le détail cas par cas et, pour chaque échec, la sortie complète du modèle. Ce dernier élément est celui qu’il faut lire en premier. Un score de 82 % vous apprend seulement qu’il reste du travail ; les sorties fautives vous disent si le modèle a mal compris la catégorie ou s’il a simplement mal obéi au format. Cherchez ensuite les régularités : si tous les échecs concernent la même catégorie attendue, vous avez identifié une définition à réécrire ; s’ils se répartissent au hasard, c’est plutôt la tâche elle-même qui est ambiguë.

Itérer sur le prompt

La boucle de travail suit toujours le même enchaînement : une exécution initiale, l’identification des catégories problématiques, l’ajout d’exemples ou la clarification des définitions, une nouvelle exécution dont on compare les scores aux précédents, et ainsi de suite jusqu’à satisfaction.

La première exécution ne sert pas à réussir, elle sert à établir la référence contre laquelle tout le reste sera mesuré ; gardez son résultat sous les yeux pendant tout le travail qui suit. Quand vous corrigez ensuite les catégories fautives, ne changez qu’une chose à la fois : si vous ajoutez trois exemples et reformulez deux définitions dans la même passe, un score qui monte de quatre points ne vous apprendra rien sur ce qui a fonctionné. Quant à « jusqu’à satisfaction », la satisfaction se définit à l’avance — décidez du seuil acceptable pour votre usage avant de commencer, sinon vous continuerez d’optimiser un jeu de test au lieu d’améliorer un produit.

Points clés à retenir

  • Un cas de test de classification tient en quatre lignes de YAML : le ticket dans vars, la catégorie dans l’assertion.
  • Donnez une définition courte à chaque catégorie et encadrez l’entrée utilisateur par une balise.
  • temperature: 0 et un max_tokens bas rendent la campagne déterministe et peu coûteuse.
  • Les assertions python et javascript servent à normaliser la sortie avant comparaison, pas à masquer un défaut de prompt.
  • Notez le score initial, ne changez qu’une variable par itération et fixez le seuil de réussite à l’avance.