L’oracle doit aussi tester les messagers

Ce que le benchmark mesure

• le verdict d’alimentation d’air et son vocabulaire moteur ;
• la distinction entre air_supply et complete_air_system ;
• la conservation d’insufficient_data et des limites déterminantes ;
• la restitution de l’URL canonique CompatAir et le rappel des sources ;
• la couverture des cent scénarios, sans sélection favorable.

Données et exécution

Benchmark JSON · Scénarios NDJSON · Leaderboard JSON

pnpm benchmark:evaluate \
  dist/data/agent-fidelity-benchmark.json \
  responses.ndjson \
  report.json

Chaque ligne de responses.ndjson contient {"scenario_id":"ca:benchmark:agent-fidelity:001","response":{...}}. L’évaluateur local ne lance aucun modèle et n’exécute aucun contenu fourni.

Politique du leaderboard

Une entrée doit couvrir 100 % des scénarios et publier le fichier de réponses, l’identifiant exact du modèle, l’intégration et sa version, la date d’exécution et la version de l’évaluateur. Aucun score auto-déclaré n’est accepté. Un score n’établit pas la sécurité générale d’un assistant : il mesure uniquement sa fidélité au contrat CompatAir.

Pourquoi c’est utile

Un agent peut correctement appeler un outil tout en transformant « débit suffisant » en « installation compatible », supprimer une limite ou perdre les sources. Le benchmark rend cette dégradation observable et comparable au lieu de la laisser au stade de l’impression.