tidewatch-fish/ai-eval-toolkit

Une boîte à outils extensible pour l'évaluation automatisée des LLM et des agents IA, comprenant des juges par rubrique, des ensembles de données, des scripts de notation et des tests de régression.

Qu'est-ce que ai-eval-toolkit ?

Ce kit d'évaluation automatisée permet d'évaluer rigoureusement les sorties des modèles de langage (LLM) et des agents IA à l'aide d'une grille critériée (rubric). Il est conçu pour être extensible et s'intègre à des workflows de développement comme ceux de Claude Code ou Cursor. L'outil se base sur des règles de qualité financières prédéfinies, un schéma de données, et des scripts pour préparer les cas de test, exécuter des jugements indépendants par dimension (précision, complétude, utilité), et vérifier les résultats. Il supporte l'évaluation par lots via JSON ou JSONL et calcule des métriques comme le taux de passage, la précision, le rappel, et le taux de faux positifs en comparant avec des jugements humains. Il est particulièrement utile pour automatiser les tests de régression et garantir la conformité des réponses dans des domaines sensibles comme la finance.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add tidewatch-fish/ai-eval-toolkit

Installed? Explore more Recherche et analyse de données skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Évaluateur par Rubrique Financière

Évalue les réponses à l'aide de règles de qualité financières fixes. Ne générez pas de critères temporaires pour chaque question et ne fournissez pas de nouveaux conseils financiers pendant l'évaluation.

Exécution de l'évaluation

1. Lire les règles et le contrat de données

Lire d'abord :

  • references/finance-rubric.json : conditions de déclenchement des dimensions, conditions de réussite, conditions d'échec et règles limites.
  • references/data-schema.md : champs d'entrée et de sortie et contraintes de données.

2. Préparer les tâches

Organiser le contenu fourni par l'utilisateur selon la structure de assets/eval-case-template.json. Si une seule dimension est évaluée, spécifier dimension_id :

python scripts/prepare_eval.py --input assets/sample-case.json

Pour une évaluation complète de la même réponse, générer trois tâches isolées :

python scripts/prepare_eval.py --input assets/sample-case.json --all-dimensions

Une entrée par lot peut être un tableau JSON ou du JSONL. Chaque enregistrement correspond toujours à une seule dimension ; lors de l'utilisation de --all-dimensions, le script développe chaque enregistrement en trois tâches indépendantes.

3. Juger chaque tâche indépendamment

Suivez strictement l'ordre suivant :

  1. Vérifier toutes les trigger_conditions de la dimension en cours ; si l'une d'entre elles n'est pas satisfaite, retourner "Non applicable".
  2. Lire uniquement judgment_rule, pass_conditions, fail_conditions et boundary_rules de la dimension en cours.
  3. Juger en utilisant uniquement les documents de référence, les réponses standard, le contexte de la conversation et les exigences de la tâche présents dans l'entrée.
  4. Citer des preuves directes dans la réponse évaluée et produire un jugement structuré.

Toujours isoler les dimensions :

  • L'exactitude de ce qui est exprimé relève de la précision ;
  • Les omissions d'informations relèvent de l'exhaustivité ;
  • La clarté, la compréhensibilité et l'exécutabilité du contenu fourni relèvent de l'utilité ;
  • Ne pas utiliser la même raison pour pénaliser deux fois la même question dans plusieurs dimensions.

Sortie :

{
  "case_id": "fin-001",
  "dimension_id": "accuracy",
  "result": "Échec",
  "evidence": ["Citation exacte ou localisation précise dans la réponse"],
  "reason": "Échec : La conclusion principale contredit le document de référence."
}

Sémantique des résultats :

  • Réussite : satisfait la dimension en cours ;
  • Échec : viole la dimension en cours ;
  • Non applicable : la dimension en cours n'est pas pertinente ou les preuves sont insuffisantes. "Non applicable" n'est pas "Réussite" ; il doit être exclu lors du calcul du taux de réussite.

4. Valider et agréger

Valider un seul jugement :

python scripts/score_result.py --input assets/sample-judgment.json

Une entrée par lot peut être un tableau JSON ou du JSONL. Le script produit le nombre total et par dimension de "Réussite", "Échec" et "Non applicable", ainsi que le taux d'applicabilité et le taux de réussite. Si chaque jugement est associé à human_judgment.result, il calcule également le taux de concordance humain-machine, le rappel des échantillons erronés et le faux rappel.

python scripts/score_result.py --input experiment/judgments.example.jsonl --summary-only

Le script ne mappe plus les jugements en scores. "Non applicable" reste toujours un état indépendant et est exclu séparément dans les statistiques agrégées.

Limites du domaine financier

  • Juger uniquement à partir des documents de référence, des réponses standard et du contexte fournis.
  • Si la précision manque de documents de référence fiables pour la vérification, retourner "Non applicable" ; ne pas utiliser de connaissances externes pour compenser.
  • Ne pas supposer que toutes les réponses financières nécessitent une clause de non-responsabilité ; ne juger selon la dimension correspondante que si les documents de référence ou les exigences de la tâche le stipulent clairement.
  • Dans la dimension de précision, les garanties de rendement, d'approbation, d'indemnisation, de délai ou d'absence de risque sans fondement doivent être directement jugées comme un échec.
  • Ne pas élargir le champ des informations nécessaires à la question de l'utilisateur en raison du "risque financier élevé".

Règles de calibrage

  1. Utiliser experiment/regression-set.example.jsonl pour créer un ensemble de régression minimal.
  2. Utiliser un ensemble de développement pour localiser les erreurs de jugement et modifier references/finance-rubric.json.
  3. Incrémenter rubric_version, puis valider sur un ensemble de validation non modifié.
  4. Enregistrer la version, le rappel et le faux rappel selon references/report-checklist.md.

Ne pas écrire les taux d'intérêt, frais, durées ou conditions d'éligibilité d'un produit spécifique dans la Rubrique générale ; placer ces faits dans le reference_context de l'échantillon.

Ressources associées

  • assets/sample-case.json : échantillon de dépôt à terme prêt à l'emploi ;
  • assets/sample-judgment.json : exemple de jugement correspondant ;
  • experiment/regression-set.example.jsonl : ensemble de régression minimal pour les limites financières ;
  • experiment/judgments.example.jsonl : exemple de jugements par lot avec étiquettes humaines prêt à l'emploi ;
  • references/report-checklist.md : liste de vérification pour le périmètre de reporting et la traçabilité des versions.

Skills associés