Développement d'agents piloté par l'évaluation : comment j'ai arrêté d'ajuster mes prompts au feeling

J'ai modifié un prompt. L'exécution suivante semblait meilleure. Ce changement a-t-il aidé, ou ai-je simplement eu de la chance ?

Pendant longtemps, ma réponse était « Je pense que oui ». Je modifiais une commande, je lançais le pipeline, je regardais le succès, et je déployais. C'est de l'ingénierie basée sur le « feeling ». Presque tous ceux qui construisent des agents font cela parce que l'alternative semble trop complexe.

Mais les agents de codage sont non déterministes. Vous pouvez exécuter la même tâche deux fois et obtenir deux résultats différents. Une seule bonne exécution ne vous apprend rien. Vous ne pouvez pas savoir si votre modification a fonctionné ou si les dés sont simplement tombés du bon côté.

J'ai résolu ce problème en appliquant la discipline du machine learning. J'ai construit un framework d'évaluation pour encadrer l'ensemble de mon système.

Voici comment le framework fonctionne :

• Cible : Une base de code figée. Elle reste identique pour que les scores soient comparables. • Tâche : Un élément de benchmark spécifique avec un prompt et un oracle. • Oracle : Une vérification déterministe. Il s'agit de commandes shell qui doivent réussir. • Variante : Le changement spécifique que vous testez, comme un nouveau planificateur. • Essai : Une seule exécution. J'exécute chaque tâche plusieurs fois pour tenir compte de l'aléa.

J'utilise deux types de scoring pour détecter différents types d'échecs :

  • Code Graders (Déterministes) : Ils vérifient les taux de réussite des tests, le coût, le temps et les modifications de fichiers.
  • LLM Judge (Probabiliste) : Un modèle distinct et fixe évalue la qualité des spécifications et la fidélité de l'implémentation.

Les code graders vous disent si le code s'exécute. Le judge vous dit si le code est bon. Vous avez besoin des deux.

J'ai également arrêté d'utiliser des moyennes. Les moyennes mentent sur les agents. Si une tâche réussit 2 fois sur 3, cela semble correct. Mais ce n'est pas fiable. À la place, j'utilise deux métriques :

  • pass@k : L'agent a-t-il réussi au moins une fois ? (Capacité)
  • pass^k : L'agent a-t-il réussi à chaque fois ? (Fiabilité)

Une augmentation de pass^k est la véritable victoire. Cela signifie que vous avez rendu l'agent cohérent, et pas seulement chanceux.

Pour maintenir le système performant, j'ajoute des tâches difficiles qui nécessitent une compréhension profonde. Lorsqu'un agent échoue sur un bug réel, je transforme cet échec en une tâche permanente. Cela crée une boucle fermée. Le benchmark devient de plus en plus difficile à mesure que l'agent s'améliore.

Cette infrastructure demande beaucoup de travail, mais c'est l'élément ayant le plus de levier que j'aie construit. Elle a transformé le « Je pense que c'est mieux » en « c'est 20 % plus fiable à un coût inférieur ».

Les agents de codage sont faciles à démontrer, mais difficiles à faire confiance. Si vous voulez dépasser le stade des démos, vous devez décider de mesurer.

Source : https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi