Notation des benchmarks - Documentation Entity Enricher

Notation des benchmarks

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 référence étalon

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.

Comment les valeurs sont comparées

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 :

1
Exact et normalisé

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.

2
Similarité d'embedding

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.

3
Juge LLM

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.

Notation des tableaux (listes d'éléments)

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.

Lecture du score

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.

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

Coût et ce qui s'exécute

La notation est une passe distincte sur des résultats déjà enregistrés — elle ne relance jamais l'enrichissement et ne fait donc jamais repayer les modèles testés. Elle vectorise en revanche du texte pour comparer les valeurs (et exécute le juge, si le scénario en a un), ce qui déduit des crédits selon l'utilisation. Cela se produit automatiquement à la fin de chaque exécution, puis à chaque nouvelle notation. Si votre organisation n'a aucun modèle d'embedding configuré (et que le scénario ne définit aucun remplacement), la notation s'exécute quand même mais se limite à la correspondance exacte (les variantes orthographiques comptent alors comme des écarts), et l'indique.

Où le trouver

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.