Framework pour agents : automatiser le test des skills
Un agent de parsing a corrompu notre table de production à 3 heures du matin. La mise à jour du prompt de l’agent n’avait pas été validée par un pipeline de régression automatique.
L’intégration de l’intelligence artificielle dans nos flux batch z/OS impose une rigueur de test identique à celle du COBOL. Nous manipulons des volumes de données critiques où une erreur de 0,1% est inacceptable. Le Framework pour agents est devenu notre seule barrière contre l’entropie des modèles de langage.
Après ce passage en revue, vous saurez implémenter un cycle de validation pour vos compétences d’agents. Vous apprendrez à mesurer précisément le taux de succès de chaque skill via la CLI sivchari.
🛠️ Prérequis
Installation des outils nécessaires pour orchestrer le test des compétences.
- Python 3.12+ pour les scripts de validation de données.
- Go 1.22+ pour l’exécution de la CLI sivchari.
- GnuCOBOL 3.1.2 pour la génération des fichiers de test COBOL.
- Docker 24.0+ pour l’isolation des environnements de test.
📚 Comprendre Framework pour agents
Un skill dans un Framework pour agents n’est pas une simple fonction. C’est une unité de compétence testable comprenant un input, un output attendu et une métrique de succès. Contrairement à une procédure COBOL qui suit un chemin déterministe, un skill peut varier selon le modèle utilisé.
Le fonctionnement de sivchari repose sur trois piliers :
1. La Définition : On déclare le format de l’entrée (ex: structure Copybook).
2. Le Test : On exécute le skill sur un jeu de données d’entraînement.
3. La Mesure : On compare le résultat à la vérité terrain (Ground Truth).
Voici une représentation de la boucle de validation :
[ Input Data (EBCDIC/Flat) ]
|
v
[ Agent Skill (LLM/Logic) ] <--- [ sivchari CLI ]
| |
v v
[ Output Parsed ] <---- (Compare) ----> [ Ground Truth ]
| |
+——> [ Metric: Accuracy/Precision/Recall ]
Si vous utilisez une approche classique sans ce Framework pour agents, vous ne faites que du monitoring, pas du testing.
🏦 Le code — Framework pour agents
📖 Explication
Dans le premier snippet, la structure TXN-RECORD définit le contrat de données. C’est la base de notre ‘Ground Truth’. Si l’agent ne respecte pas cette structure, le test échoue. L’utilisation de PIC 9(07)V99 est cruciale. Elle impose une précision décimale fixe que l’agent doit respecter.
Le second snippet montre une logique de validation métier. Nous utilisons WS-VALID-FLAG pour signaler une erreur. Dans un contexte de Framework pour agents, ce code COBOL sert de test de validation post-extraction. Si l’agent extrait une donnée qui fait échouer 100-CHECK-AMOUNT, le score de qualité du skill chute immédiatement. Le piège classique est de tester uniquement le format, et non la cohérence métier.
Documentation officielle COBOL
🔄 Second exemple
Retour d'expérience
L’incident s’est produit lors de l’intégration d’un nouvel agent capable d’extraire des données de fichiers plats convertis depuis l’EBCDIC. Nous avions mis à jour le prompt pour améliorer la détection des dates. Cependant, ce changement a introduit une régression sur le champ TXN-AMOUNT. L’agent commenç’t à ignorer la virgule décimale dans les montants élevés.
Le problème était invisible sur les petits jeux de tests manuels. Nous n’utilisions pas encore de Framework pour agents structuré. Le déploiement a eu lieu sur un environnement de pré-production. Le batch de fin de journée a échoué avec un écart de caisse de 12 000 euros. La cause : l’agent transformait « 000125050 » en « 125050 » sans la précision décimale.
Pour corriger cela, nous avons implémenté sivchari. Nous avons créé un dossier de ‘skills’ contenant des exemples de transactions critiques. Chaque modification de prompt est désormais soumise à la commande sivchari test --skill txn-parser. Cette commande compare le résultat de l’agent avec des fichiers de vérité terrain pré-générés en COBOL. Le pipeline CI/CD bloque désormais toute baisse de l’accuracy en dessous de 99.95%.
La résolution a nécessité la création d’un dataset de 5000 cas d’usage. Ce dataset inclut des cas limites comme les montants nuls ou les dates de fin de mois. Grâce au Framework pour agents, nous avons pu quantifier la perte de précision avant même le premier commit en production. Le taux d’erreur est passé de 15% lors de la régression à 0% après correction du prompt et validation par le nouveau framework.
▶️ Exemple d’utilisation
Exécution d’un test de compétence sur le module de parsing de transactions.
# Initialisation du dossier de test
$ sivchari init --project mainframe-parser
# Création d'un nouveau skill pour les transactions
$ sivchari create skill txn-parser --type extraction
# Exécution du test de régression sur le dataset de production
$ sivchari test --skill txn-parser --dataset production-v1-golden
# Résultat attendu :
# [INFO] Running tests for skill: txn-parser
# [INFO] Found 500 test cases.
# [INFO] Accuracy: 99.98%
# [INFO] Precision: 100.00%
# [RECALL] Recall: 99.96%
# [SUCCESS] No regressions detected.
🚀 Cas d’usage avancés
1. Validation de formatage EBCDIC vers ASCII : Utiliser sivchari pour vérifier que les caractères spéciaux ne sont pas corrompus lors du parsing par l’agent. sivchari run --skill ebcdic-fix --input sample.dat.
2. Détection d’anomalies transactionnelles : Créer un skill qui analyse les logs de batch pour identifier des patterns de fraude. L’agent doit être évalué sur sa capacité à ne pas générer de faux positifs.
3. Migration de code legacy : Utiliser l’agent pour traduire des routines COBOL en Python. Le Framework pour agents permet de comparer le résultat de la fonction Python avec l’output de l’original COBOL sur 1000 inputs différents.
🐛 Erreurs courantes
⚠️ Prompt trop permissif
L’agent accepte des formats de date variés, ce qui casse le parsing COBOL suivant.
Extract date as stringExtract date in YYYYMMDD format⚠️ Absence de Ground Truth
Tester l’agent uniquement sur des exemples que vous avez inventés sans vérification.
Manual inspection of 5 samplesAutomated comparison with 1000 pre-validated records⚠️ Oubli des types numériques
L’agent transforme les montants décimaux en entiers, rendant les calculs batch erronés.
Parse amount as integerParse amount as fixed-point decimal (7,2)⚠️ Dépendance au modèle
Le test passe sur GPT-4 mais échoue sur un modèle local (Llama-3) plus petit.
Testing only on high-end modelsCross-model testing using sivchari matrix✅ Bonnes pratiques
Pour maintenir une qualité industrielle, suivez ces règles :
- Immuabilité des datasets : Ne modifiez jamais le dossier ‘golden-dataset’ sans une procédure de versioning stricte.
- Isolation des environnements : Utilisez Docker pour que vos tests de skill ne dépendent pas de la configuration locale de votre machine.
- Granularité des skills : Ne créez pas un seul skill géant. Divisez vos compétences en petites unités : parsing, validation, transformation.
- Automatisation du feedback loop : Intégrez la commande
sivchari testdirectement dans votre pipeline GitLab CI ou Jenkins. - Monitoring de la dérive : Re-testez vos skills chaque semaine avec de nouvelles données réelles pour détecter le ‘model drift’.
- Le Framework pour agents permet de transformer l'incertitude des LLM en métriques mesurables.
- L'utilisation de dossiers de vérité terrain est indispensable pour éviter les régressions.
- Un skill doit être testé sur sa capacité à respecter des contraintes de format strictes (type COBOL).
- La CLI sivchari automatise la comparaison entre l'output de l'agent et le standard attendu.
- L'erreur humaine lors du changement de prompt est le principal vecteur de panne en production.
- La précision décimale est le point de rupture classique lors du parsing de données financières.
- Le testing doit inclure une matrice de modèles pour garantir la portabilité de la solution.
- L'intégration dans un pipeline CI/CD transforme le test de prompt en test de régression logicielle.
❓ Questions fréquentes
Peut-on utiliser sivchari pour tester du code COBOL lui-même ?
Non, sivchari teste les compétences des agents (LLM). Cependant, vous pouvez utiliser le COBOL pour générer les données de test (Ground Truth) que l’agent doit traiter.
Quel est l'impact sur la performance de l'agent ?
L’utilisation du framework n’impacte pas l’agent en production. Elle intervient uniquement durant la phase de validation et de CI/CD.
Comment gérer les changements de schéma dans mes fichiers ?
Vous devez mettre à jour la définition du skill dans sivchari et ré-exécuter le cycle de validation sur votre nouveau dataset.
Est-ce compatible avec des modèles locaux comme Ollama ?
Oui, tant que l’interface API est compatible avec le format attendu par la CLI sivchari (standard OpenAI).
📚 Sur le même blog
🔗 Le même sujet sur nos autres blogs
📝 Conclusion
La maîtrise des agents nécessite la même rigueur que la gestion de programmes batch critiques. Le Framework pour agents n’est pas une option, c’est une nécessité pour tout projet industriel. Ne vous contentez pas de vérifier si l’agent « répond ». Vérifiez s’il respecte le contrat de données défini par votre architecture legacy. Pour approfondir les tests unitaires sur les structures de données, consultez la documentation COBOL officielle. Une donnée mal parsée est une dette technique qui se paie en heures de debugging à 3 heures du matin.
