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.
La référence se met aussi à jour d'elle-même. Une référence vérifiée reste un brouillon corrigé à la main, et les modèles que vous passez au benchmark en sont les relecteurs : partout où le juge estime la réponse d'un candidat meilleure que celle de la référence (ou la référence erronée), partout où les échantillons du scénario prouvent que la référence a tort, et partout où un modèle renseigne une valeur laissée vide par la référence et que le juge le confirme, le résultat enregistre une observation. À la fin de chaque passe de notation, les observations de tous les modèles notés sont fusionnées — d'abord ce que prouvent les échantillons, puis la réponse donnée par le plus grand nombre de modèles — puis écrites dans la référence. Une modification déjà effectuée par une passe n'est remplacée que par des preuves plus solides (les échantillons, un verdict indiquant que la valeur est erronée, ou davantage de modèles concordants — comptés sur l'ensemble des passes), jamais par l'avis d'un modèle de plus : évaluer les modèles un par un au benchmark ne peut donc pas faire dériver la référence vers le dernier noté. Ces modifications automatiques ne rendent jamais les scores obsolètes (seuls vos propres enregistrements le font), et chacune d'elles est journalisée avec ce qu'elle a remplacé et les modèles qui l'ont motivée.
Examinez-les comme un suivi des modifications : la vue Référence du scénario, à côté de ses résultats, affiche la référence elle-même avec chaque modification automatique mise en évidence à son emplacement — la valeur précédente barrée, la nouvelle, le nombre de modèles qui la soutiennent et pourquoi. Tout est accepté sauf si vous le rejetez ; un rejet restaure la valeur précédente et exclut ce chemin des passes futures. Filtrez par attribut ou par preuve (les modifications issues d'un seul modèle sont celles à regarder de près), sélectionnez ce qui est affiché et rejetez en masse.
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 difficiles à départager par similarité — tous les champs en texte libre comme les résumés et les descriptions, tout nombre non identique, ainsi qu'une valeur nettement différente que vos documents ou la plupart des autres modèles corroborent — sont envoyées à un modèle juge. Le juge est aveugle : il voit les deux valeurs sous les noms A et B, avec la place du champ dans le schéma (ses parents et leurs descriptions, son type, l'élément de liste auquel il appartient) et vos documents sources lorsque le scénario en comporte, puis indique laquelle sert le mieux le champ, si les deux sont correctes, ou si l'une est erronée. Un candidat jugé équivalent ou meilleur que la référence — ou une référence jugée erronée — obtient le crédit complet ; une réponse plus faible obtient un crédit partiel, une réponse erronée peu ou pas de crédit. Un nombre obtient un crédit partiel lorsque le champ le tolère (une masse moléculaire de 273,37 contre 273,35, une demi-vie de 12 contre 15) et échoue là où l'exactitude compte (une année de sortie 2020 contre 2023). Une valeur laissée vide par la référence fait l'objet d'une question distincte : confirmée correcte, elle compte comme une valeur que la référence aurait dû contenir et que le modèle a trouvée — le score augmente, il n'est pas simplement épargné — et la référence l'adopte.
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 du tableau. Lorsqu’un benchmark alimente la sélection des modèles — en tant que source de notation —, le classement d’un modèle résulte d’un mélange de qualité, de vitesse et de coût, et ce ratio vous appartient : définissez-le par type de scénario dans Paramètres → Organisation → Valeurs par défaut, chaque ensemble totalisant 100 et réparti à parts égales par défaut. Pondérez fortement le coût et un modèle bon marché mais correct devancera un modèle excellent et coûteux — ce qui est le bon choix pour certaines charges de travail et le mauvais pour d’autres : la plateforme se garde donc de trancher à votre place. La vitesse et le coût sont évalués par rapport aux autres résultats du scénario, sur une échelle logarithmique : le modèle le plus rapide ou le moins cher obtient 100 et un modèle dix fois plus lent ou plus cher obtient 0, mais un écart serré n’est jamais étiré pour couvrir toute la plage — deux modèles à 10 $ et 12 $ obtiennent 100 et 92, et non 100 et 0.
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 JSON d’exemple pour la même demande en texte libre) ou la génération de schéma (chaque modèle convertit un échantillon fixe en schéma). Chacune a ses propres règles de notation :
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.
La notation est une passe distincte sur des résultats déjà sauvegardés — elle ne réenrichit jamais, et ne repaie donc jamais les modèles testés. Elle calcule toutefois des embeddings de texte pour comparer les valeurs (et exécute le juge, si le scénario en a un), ce qui déduit des crédits en fonction de l'usage. Cela se produit automatiquement à chaque exécution — chaque modèle est noté dès que ses exécutions se terminent — et de nouveau à chaque renotation. Si votre organisation n'a aucun modèle d'embedding configuré (et que le scénario ne définit aucune substitution), la notation s'exécute quand même mais se rabat sur la correspondance exacte uniquement (les orthographes alternatives comptent alors comme des écarts), et le signale. Un juge défaillant, c'est différent : si un appel au juge échoue, la notation s'arrête avec une erreur explicite et le modèle concerné ne conserve aucun score partiel — un résultat est soit entièrement noté, soit pas noté du tout, et reste renotable plus tard. Les réponses du juge sont mises en cache par scénario selon leur contenu : une même question soulevée par un autre modèle, une répétition ou une autre passe n'est jamais payée deux fois, et une renotation après une mise à jour automatique de la référence ne repose que les questions portant sur les champs modifiés. Rien de ce que fait le juge n'est caché : chaque passe de notation sur un modèle laisse un enregistrement de notation dans l'Historique — une ligne par appel au juge avec son prompt, sa réponse, ses tokens et son coût, appels échoués compris, ainsi que le nombre de questions traitées gratuitement par le cache — et le tableau des résultats affiche pour chaque modèle le coût du juge, le nombre d'appels et le temps de notation, à côté d'un lien vers cet enregistrement. 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 son modèle juge, son modèle d'embedding et son niveau de rigueur). Ensuite, chaque exécution note automatiquement ses résultats réussis — une colonne Qualité triable se remplit sans étape supplémentaire. Utilisez Renoter les résultats (le bouton d'en-tête ou le menu ···) pour réévaluer après avoir modifié la référence ou la configuration de notation. Le badge mises à jour de la référence, à côté de l'état de la référence, ouvre le journal de ce que les passes de notation ont changé, avec une annulation par entrée.