La notation transforme un benchmark : au lieu d'inspecter le JSON à l'œil nu, vous obtenez un chiffre objectif. Le résultat de chaque modèle est évalué par rapport à une référence étalon — la sortie attendue — produisant des scores de complétude, d'exactitude et une note de qualité globale sur lesquels vous pouvez trier.
La notation a besoin d'un élément de comparaison. Chaque scénario porte une sortie de référence : la bonne réponse pour son unique entité fixe. Construisez-la en générant avec des modèles puissants (recherche web + un document source de vérité), en collant un résultat connu comme fiable, puis en l'éditant à la main — et marquez-la vérifiée une fois que vous lui faites confiance. Une référence vérifiée est requise pour lancer un benchmark sur le scénario, il y a donc toujours une base de notation. Si vous modifiez ensuite la référence — ou la configuration de notation du scénario — les scores existants sont marqués obsolètes jusqu'à ce que vous relanciez la notation.
Le problème de fond : deux réponses correctes peuvent être écrites différemment. Un modèle qui nomme un acteur « R. Downey Jr. » au lieu de « Robert Downey Jr. » n'a pas tort. Chaque champ est donc comparé selon une échelle à paliers — d'abord le moins coûteux et le plus sûr, avec escalade uniquement si nécessaire :
Les valeurs identiques correspondent. C'est aussi le cas des valeurs qui ne diffèrent que par la casse, les espaces environnants ou la précision numérique ("Acme" = "ACME", 4.0 = 4). Gratuit et entièrement déterministe.
Pour le texte, le candidat et la référence sont vectorisés puis comparés par similarité cosinus. Au-dessus du seuil, ils sont considérés comme identiques — ainsi, une variante orthographique valide comme « R. Downey Jr. » vs « Robert Downey Jr. » est une correspondance, pas une erreur. Les dates font exception : elles sont comparées comme des valeurs calendaires, jamais par similarité, de sorte qu'une date proche mais fausse (« 1972-03-14 » vs « 1972-03-24 ») constitue une non-correspondance nette plutôt qu'un cosinus trompeusement élevé. De même, les booléens sont soit exacts, soit rien.
Les valeurs trop proches pour être départagées par similarité — tous les champs en texte libre comme les résumés et les descriptions, ainsi que chaque nombre non identique — sont envoyées à un modèle juge, qui note de 0 à 100 dans quelle mesure la réponse restitue le sens de la référence. Il récompense une réponse correcte formulée différemment ou plus brièvement, et accorde un crédit partiel à un nombre lorsque le champ le tolère (une masse moléculaire de 273,37 contre 273,35, une demi-vie de 12 contre 15), tout en le rejetant là où l'exactitude compte (une année de sortie de 2020 contre 2023). Sans juge, le texte libre retombe sur un score de similarité continu, et un nombre non identique est simplement une non-correspondance.
Un paramètre de rigueur contrôle le seuil d'embedding : plus il est élevé, plus deux valeurs écrites différemment doivent être similaires pour être considérées comme identiques. La rigueur, le modèle juge facultatif et le modèle d'embedding sont tous définis sur le scénario — et non choisis à chaque notation — afin que chaque modèle soit noté de manière identique et que les scores restent comparables.
Les listes — le casting d'un film, les effets secondaires d'un médicament — sont là où les modèles diffèrent le plus : un petit modèle peut trouver 4 acteurs là où un modèle performant en trouve 15. L'ordre n'a pas d'importance, et trouver plus d'éléments corrects doit l'emporter. Les tableaux sont donc notés comme un ensemble, et non position par position :
Développez une ligne de résultat pour voir exactement quels éléments ont été trouvés, manqués ou hallucinés.
Un chiffre unique masque trop d'informations, c'est pourquoi chaque résultat comporte des sous-scores :
La ligne dépliable affiche le détail champ par champ : candidat vs référence, quel palier de l'échelle a tranché, et la similarité le cas échéant.
La qualité ne représente qu'un tiers de l'équation. Lorsqu'un benchmark alimente la sélection de modèles — en tant que source de notation —, le classement du modèle résulte d'un mélange de qualité, de vitesse et de coût, et cette pondération vous appartient : définissez-la par type de scénario dans Paramètres → Organisation → Valeurs par défaut, chaque total valant 100 et réparti à parts égales par défaut. Donnez beaucoup de poids au coût et un modèle bon marché mais correct devancera un modèle excellent et onéreux — ce qui est le bon choix pour certaines charges de travail et le mauvais pour d'autres : la plateforme se refuse donc à trancher à votre place.
Lorsqu'un scénario exécute un modèle plus d'une fois (répétitions), chaque exécution est notée individuellement et la ligne affiche la qualité moyenne ainsi qu'un écart de cohérence (minimum–maximum des exécutions) — un modèle juste en moyenne mais erratique est ainsi facile à repérer. La sortie visible est l'exécution médiane en qualité.
Les benchmarks ne se limitent pas à l'enrichissement : un scénario peut aussi tester la génération d'échantillon (chaque modèle invente un exemple JSON pour un type d'entité) ou la génération de schéma (chaque modèle convertit un échantillon fixe en schéma). Chacun possède ses propres règles de scoring :
Dans tous les cas, les colonnes habituelles conservent leur signification — survolez un en-tête de colonne pour la définition propre au type, et développez une ligne pour le détail complet.
Le scoring est une passe distincte sur des résultats déjà enregistrés — il ne réalise jamais de nouvel enrichissement, il ne repaie donc jamais pour les modèles testés. Il calcule des embeddings de texte pour comparer les valeurs (et exécute le juge, si le scénario en comporte un), ce qui déduit des crédits en fonction de l'utilisation. Cela se produit automatiquement à chaque exécution — chaque modèle est scoré dès que ses exécutions se terminent — puis à nouveau à chaque re-scoring. Si votre organisation n'a aucun modèle d'embedding configuré (et que le scénario ne définit aucune surcharge), le scoring s'exécute quand même mais se rabat uniquement sur la correspondance exacte (les orthographes alternatives comptent alors comme des non-correspondances), et l'indique. Un juge défaillant, c'est différent : si un appel au juge échoue, le scoring s'arrête avec une erreur explicite et le modèle concerné ne conserve aucun score partiel — un résultat est soit entièrement scoré, soit pas scoré du tout, et reste re-scorable ultérieurement. Au moment de choisir le juge, notez que les juges LLM peuvent favoriser leur propre famille de modèles — préférez un juge issu d'un provider que vous n'évaluez pas.
Dans Gestion des modèles → Benchmarks, définissez et vérifiez une référence dans l'éditeur de scénario (et choisissez-y le modèle juge, le modèle d'embedding et le niveau de rigueur). Dès lors, chaque exécution note automatiquement ses résultats réussis — une colonne Qualité triable se remplit sans étape supplémentaire. Utilisez Réévaluer les résultats (le bouton d'en-tête ou le menu ···) pour renoter après avoir modifié la référence ou la configuration de notation.