Pour les équipes techniques · L’IA en pratique
Mesurer une tâche d’IA jusqu’à la recette
Un suivi concret de l’utilisation des modèles, des corrections et de la revue aide une équipe technique à comparer les processus d’agents de programmation et à repérer les lacunes dans sa vision des coûts.
Une tâche de programmation peut consommer des appels de modèles pendant le développement, une nouvelle tentative après une vérification échouée et d’autres interventions lors de la revue. Le premier message de fin ne représente qu’un point de ce parcours. Une comparaison utile suit le travail jusqu’à ce que son issue soit connue.
Commencez par une tâche dont une personne peut évaluer le résultat. Pour une modification illustrative d’API, rendez un champ d’entrée obligatoire et testez les valeurs valides et absentes. Convenez des réponses attendues avant de comparer les approches, en conservant le même périmètre de tâche et les mêmes vérifications de recette. L’exemple ci-dessous ne contient aucun chiffre comparatif.
Figure 1 en texte
Consignez l’utilisation pendant le développement. Les vérifications et la revue indépendante évaluent le travail. Si la revue révèle un problème, consignez sa correction et la décision humaine finale ; une tâche infructueuse reste dans le périmètre de comparaison.
Suivez le travail, corrections comprises
Dans la pratique interne de développement de Devmojos, un opérateur prépare un cadrage limité avec le contexte pertinent et les vérifications de recette. Des contrôles automatisés examinent ce cadrage avant le démarrage d’un agent exécutant. Celui-ci réalise la modification confiée dans une copie isolée du projet, puis indique ce qu’il a modifié et vérifié.
La revue indépendante et la vérification de l’opérateur éclairent la recette. Si un contrôle ou une revue révèle un problème, sa correction reste dans le même dossier de tâche. Consignez le constat, la tentative suivante et l’issue finale. Une tâche rejetée, arrêtée ou abandonnée appartient aussi au périmètre de comparaison déclaré.
Cette structure qui entoure un agent constitue son environnement d’encadrement : les consignes, outils, contexte, transferts et revues qui soutiennent son travail. Un test réussi apporte des éléments sur le comportement qu’il a vérifié. Les personnes décident toujours si le travail convenu est acceptable et s’il doit être mis en production.
Figure 2 en texte
Convenez de la tâche, réunissez le contexte pertinent, choisissez une approche, réalisez le travail défini, vérifiez et faites une revue indépendante, puis prenez la décision humaine de recette. Les retours peuvent renvoyer au développement ; un résultat non accepté peut ramener à la définition de la tâche.
Constituez un dossier avec des mesures distinctes
Ce qui suit est une proposition de fiche pour la modification illustrative d’API. Ce n’est pas un tableau de bord de mesures déjà recueillies par Devmojos. Laissez un champ inconnu lorsque sa source manque.
Figure 3 en texte
Examinez séparément l’utilisation des modèles, les outils et l’infrastructure, le temps écoulé, la revue et les reprises, et le résultat. La fiche de l’article propose un relevé plus complet des coûts ; elle ne présente pas l’ensemble des mesures actuellement recueillies.
| Relevé pour la tâche | Unité ou forme | À inclure |
|---|---|---|
| Résultat et vérifications de recette | Statut et constats consignés | Accepté, rejeté ou abandonné ; vérifications et revue qui fondent ce statut |
| Utilisation des modèles | Catégories d’utilisation communiquées par le fournisseur | Appels de développement, de correction et de revue ; identifier les catégories de cache lorsqu’elles sont fournies |
| Coût monétaire | Devise, avec base de facturation ou d’affectation | Frais connus des fournisseurs et outils, et coût d’infrastructure attribuable ; signaler les exclusions |
| Temps écoulé | Délai entre l’attribution et l’issue déclarée | Attente, tentatives et revue, avec des définitions cohérentes du début et de la fin |
| Travail humain | Temps et activité consignés | Préparation, revue, vérification et aide à la correction |
| Reprises | Tentatives et motifs | Vérifications échouées, constats de revue, reprises d’exécution et travaux rouverts |
Les jetons, les minutes et les statuts décrivent des choses différentes. Convertissez les composantes monétaires selon une base explicite de tarification ou d’affectation avant de les additionner, et évitez de compter deux fois le même montant. Les abonnements et le matériel local nécessitent une décision d’affectation ; l’absence de données de coût ne prouve pas un coût nul.
Modifiez une composante d’une tâche comparable
Le contexte doit fournir à l’agent les exigences, le code pertinent et les vérifications nécessaires. Un cadrage qui omet une contrainte peut entraîner des corrections. Chaque élément supplémentaire doit justifier sa présence par son utilité pour la tâche. Les recommandations d’Anthropic sur l’ingénierie du contexte abordent cette question de sélection.
Le choix du modèle dépend aussi de la tâche. Ses capacités, son temps de réponse, les contraintes d’exploitation et la difficulté du travail comptent tous. Comparez les tentatives et les constats de revue obtenus avec l’utilisation. Le cache figure dans le relevé d’utilisation lorsque l’information est disponible ; un pourcentage de succès du cache ne suffit pas à établir une variation de facture.
Pour une comparaison, déclarez les tâches terminées et infructueuses incluses, ce qui reste comparable et ce qui a changé. Consignez les coûts exclus ou inconnus. Si une approche produit un résultat utilisable mais exige davantage de revue, le relevé doit rendre cet arbitrage visible plutôt que de le réduire à un total de jetons.
Ce que notre pratique interne permet d’établir
Notre relevé interne de routage comprend des délais de recette vérifiés, des vérifications échouées et des reprises. Il n’établit ni le coût monétaire complet par fonctionnalité acceptée ni des économies clients reproductibles. La fiche plus complète ci-dessus est une recommandation de mesure. Les recherches d’Anthropic sur les environnements d’encadrement des agents constituent une lecture complémentaire utile, pas une preuve des résultats de Devmojos.
Apportez une tâche technique récurrente, ses outils et vérifications de recette actuels, ainsi que le point où la revue ou la correction devient difficile. L’offre AI Engineering de Devmojos peut commencer par une évaluation du processus et une expérimentation d’adoption cadrée, pour aider votre équipe à décider de ce qu’elle conserve.