Harnais d'abord
Un modèle est un moteur. La plupart des « problèmes de modèle » sont dus à un harnais manquant : rien ne définit une sortie correcte, rien ne vérifie les changements, rien ne limite les dépenses, les données n'ont pas de définitions convenues, les actions n'ont pas d'approbation, et il n'y a pas de traces pour trouver l'appel défaillant. Auditez cela avant de toucher au modèle.
1. Reproduire le symptôme à partir de preuves, pas d'impressions
- Lisez le code de l'agent que le symptôme touche : la boucle, les définitions d'outils, l'assemblage du prompt, l'accès aux données, les outils avec effets de bord.
- Lisez les journaux/traces/transcriptions qui existent. Agrégéz-les (par conversation, par outil, par erreur) : qui dépense les tokens, quels appels échouent, quelles réponses sont erronées. Quelques valeurs aberrantes dominent généralement.
- Énoncez la cause racine comme un mécanisme avec des preuves (fichier:ligne, identifiants de journal, chiffres que vous avez calculés). « Le modèle est mauvais » n'est pas un mécanisme.
Mécanismes courants :
- Brûlure de tokens : boucle sans nombre maximal d'itérations, nouvelle tentative sur une erreur déterministe, historique complet ou résultat d'outil volumineux renvoyé à chaque tour, absence de mise en cache du contexte stable.
- « Hallucination » : l'agent a fidèlement utilisé une source ambiguë ou erronée (deux tables/champs avec le même nom et une signification différente, documentation obsolète). Recalculez les deux nombres vous-même pour le prouver.
- Fragilité : modifications de prompt déployées sans ensemble de régression ; comportement que seul l'auteur a vérifié manuellement.
2. Noter les six parties du harnais
Pour chacune, indiquez présent / partiel / manquant avec les preuves que vous avez trouvées :
| Partie | Présent signifie |
|---|---|
| Ensemble de référence | ~20+ cas avec réponses/contraintes attendues, tirés du trafic réel, des incidents et des cas limites |
| Juge | vérifications déterministes d'abord (nombres, règles de politique, contenu interdit), grille LLM uniquement pour ce que le code ne peut pas vérifier ; s'exécute sur chaque changement de prompt/modèle/outil |
| Gouvernance des coûts | limites dures de tokens/coûts par utilisateur et par workflow, nombre maximal d'itérations par exécution, arrêt gracieux avec un message |
| Couche de données | identifiants en lecture seule pour les lectures, un dictionnaire de données qui définit chaque métrique/champ que l'agent peut utiliser |
| Sécurité des actions | les actions irréversibles ou externes (envoyer, payer, supprimer, écrire, rembourser) sont réversibles ou verrouillées par une approbation humaine |
| Traçage | chaque appel de modèle et d'outil journalisé avec identifiant de conversation, workflow, entrée, sortie, tokens, coût, latence, erreur |
3. Décider avant de construire
- Ne recommandez jamais un changement de modèle sans preuve d'évaluation. Si quelqu'un demande « devrait-on changer de modèle ? », la réponse est : corrigez le mécanisme, puis exécutez l'ensemble de référence sur les deux modèles et comparez la qualité et le coût. Dites ce que la correction seule est censée économiser, avec vos chiffres.
- N'approuvez jamais le déploiement d'un changement de prompt/agent sans une exécution sur l'ensemble de référence. Si des sorties enregistrées existent, notez-les par rapport aux réponses attendues vous-même et signalez les échecs par identifiant de cas.
- Les lacunes de sécurité (effets de bord non verrouillés, accès en écriture sur un chemin de lecture, fuite de données internes) sont bloquantes, même lorsque personne ne les a demandées.
4. Construire le harnais minimum, dans cet ordre
- Arrêter l'hémorragie : nombre maximal d'itérations, pas de nouvelle tentative sur les erreurs non transitoires, tronquer/résumer les sorties d'outils volumineuses, limite de coût dure par exécution.
- Verrouiller les effets de bord : étape d'approbation ou mode brouillon pour les outils irréversibles ; connexion en lecture seule pour les outils de requête.
- Fichier d'ensemble de référence (
evals/golden.jsonlou similaire) : entrée, réponse attendue ou contraintes, source (identifiant de journal / incident / clause de politique). Incluez les cas qui viennent d'échouer. - Script de juge qui exécute l'ensemble de référence et affiche réussite/échec par cas plus les totaux. Vérifications déterministes avant la notation LLM.
- Dictionnaire de données pour chaque métrique que l'agent rapporte (définition, table/champ source, exclusions).
- Champs de traçage listés ci-dessus, s'ils manquent.
Écrivez de vrais fichiers, pas une description de fichiers. Exécutez ce qui peut être exécuté et rapportez le résultat.
5. Rapport
- Réponse en une ligne à la question réellement posée (par ex. « Ne changez pas encore de modèle : 3 exécutions bloquées dans une boucle de nouvelle tentative ont dépensé 71 % des tokens »).
- Cause racine avec preuves et chiffres.
- Tableau de bord du harnais (les six parties).
- Ce que vous avez modifié ou créé, et ce que vous avez exécuté.
- Risques bloquants, puis une courte liste d'étapes suivantes priorisées.
Crédit
La méthode suivie par cette compétence provient d'un article public de Mark Ajzenstadt (@mardehaym) : https://x.com/mardehaym/status/2099562230647804152. L'argument est le leur ; la procédure, le libellé et l'évaluation ici sont propres à Edge, et l'auteur ne les a pas révisés.