Évaluation continue des requêtes : comment nous utilisons des juges LLM et des signaux en direct pour améliorer la qualité de l'agent Kiro

Le comportement des requêtes est difficile à valider de façon exhaustive. Une requête système s'applique à des combinaisons de modèles, d'outils, de bases de code, de tâches et d'utilisateurs qu'aucune suite de tests ne peut couvrir entièrement. Une instruction qui semble raisonnable isolément peut provoquer un comportement imprévu dans des cas que l'auteur de la requête n'avait pas anticipés, et une modification qui améliore un scénario peut en dégrader un autre.

L'obsolescence des requêtes est une manifestation de ce problème plus large. Une instruction peut déjà causer des problèmes rares ou difficiles à observer, puis devenir plus visiblement nuisible quand un modèle plus récent la suit plus strictement. De nouveaux outils, flux de travail et habitudes des utilisateurs peuvent révéler les mêmes défauts latents.

Les tests de référence demeurent un signal de qualité important, mais ils ne peuvent pas saisir tous les comportements qui apparaissent dans le travail de développement quotidien. Il nous fallait un processus qui détecte les problèmes sur de vrais flux de travail, catégorise les tendances récurrentes, les rattache à des instructions de requête et valide les correctifs à mesure que les modèles et l'utilisation évoluent.

Cet article porte sur l'évaluation des modifications de requête système et de configuration rédigées par des humains. Il ne couvre pas l'exploration automatisée des trajectoires, la génération de modifications, ni l'auto-amélioration plus large du harnais. Le flux de travail associe les résultats des tests de référence à une analyse par LLM de milliers de conversations Kiro avec nos développeurs internes afin de repérer des occasions d'amélioration dans l'accomplissement des tâches, la vérification et l'utilisation des outils. Il comporte quatre étapes :

• Diagnostiquer les catégories de plaintes fréquentes et les rattacher à des instructions de requête
• Concevoir des modifications de requête ciblées pour une évaluation isolée
• Tester les modifications dans des cohortes contrôlées sur le trafic interne
• Évaluer chaque cohorte avec le juge LLM pour détecter les variations d'insatisfaction et de problèmes de qualité comportementale

Le diagramme ci-dessus résume les quatre mêmes étapes décrites ci-dessous. Nous répétons ce cycle à mesure que les requêtes, le comportement des utilisateurs et les capacités des modèles changent :

1. Diagnostiquer. Nous exécutons le juge sur le trafic interne actuel pour repérer et catégoriser les tendances de plaintes récurrentes, puis rattacher chaque grappe à forte fréquence à une instruction de requête contributive ou à une instruction manquante. Par exemple, des plaintes récurrentes de « tâche incomplète » pointaient vers une directive qui incitait l'agent à expliquer son plan plutôt qu'à l'exécuter.

2. Concevoir. Nous rédigeons des modifications candidates ciblées pour le problème diagnostiqué. Les candidates portent souvent sur la sûreté, la vérification, le ton ou le comportement, et chaque candidate énonce le comportement visé et le risque de régression avant les tests.

3. Tester. Nous comparons les candidates au témoin dans des cohortes isolées et, lorsque c'est utile, dans une cohorte combinée qui peut révéler des interactions. La conception de l'expérience et la taille de l'échantillon déterminent si un résultat n'est que directionnel ou s'il appuie une conclusion plus large.

4. Évaluer. Nous appliquons la même grille de juge LLM à chaque cohorte, comparons les taux d'insatisfaction et de qualité comportementale, et utilisons les preuves disponibles pour livrer, réviser ou rejeter chaque candidate.

Nous avons bâti un cadre d'évaluation qui note les conversations internes selon 15 dimensions comportementales, dont :

• Complétude des tâches
• Exactitude des affirmations (l'agent a-t-il vérifié avant d'affirmer?)
• Respect du style de code
• Reconnaissance des approches infructueuses répétées
• Signalement des actions destructrices
• Pertinence de l'utilisation des outils
• Comportement de vérification (exécuter les tests, vérifier la compilation)

Le juge exige des preuves explicites tirées de la conversation : corrections, plaintes, tâches abandonnées ou confirmations. Les conversations ambiguës ne comptent contre aucune des variantes, ce qui garde les comparaisons cohérentes et prudentes afin d'éviter un excès de jugements faux positifs.

Les requêtes du juge représentées dans la figure sont des exemples illustratifs minimaux et ne correspondent pas à ce qui est réellement utilisé pendant l'évaluation.

Le juge mesure deux signaux principaux :

• Insatisfaction explicite : l'utilisateur a-t-il explicitement exprimé de la frustration, abandonné la conversation ou refait le travail de l'agent? Cela est déduit uniquement de la rétroaction explicite dans la conversation, pas de résultats d'outils implicites ni de scores de sondage.
• Problèmes de qualité comportementale : l'agent a-t-il manqué l'une des 15 normes de qualité? Par exemple, faire des affirmations sans d'abord lire le code, s'arrêter avant d'avoir terminé la tâche, ou ignorer les conventions existantes du projet.

Les deux métriques utilisent la même grille pour les groupes témoin et de traitement, ce qui permet des comparaisons cohérentes entre configurations au sein d'une même conception d'évaluation.

Avant de livrer une modification de requête, nous comparons des configurations dans des cohortes distinctes sur le trafic interne. Pour ces expériences, le service affecte les développeurs internes admissibles à des compartiments d'utilisateurs stables au moyen d'un hachage déterministe de l'identité de l'utilisateur, indépendamment des résultats de conversation observés. Chaque compartiment correspond à une variante de requête pour une expérience donnée.

Le pipeline du juge analyse les conversations selon leur affectation d'expérience enregistrée et applique la même grille à chaque cohorte. L'affectation stable contrôle la sélection de cohorte au sein de l'expérience de requête, mais elle n'élimine pas toutes les sources de biais ou d'interaction dans le trafic réel. L'affectation exacte et la taille de l'échantillon varient selon l'expérience, de sorte que la force d'une conclusion dépend des preuves disponibles pour cette comparaison. Les petites cohortes candidates isolées demeurent des diagnostics directionnels plutôt que des estimations précises de l'impact en production.

Lors d'un déploiement interne accéléré, nous avons passé au crible 27 modifications de requête candidates dans quatre catégories : sûreté, vérification, ton et comportement. Nous avons comparé un témoin stable à des cohortes candidates isolées et à une cohorte qui combinait les candidates. Les petites cohortes isolées étaient des diagnostics directionnels pour localiser d'éventuelles régressions, non des estimations d'impact individuellement puissantes sur le plan statistique. Les candidates qui montraient une dégradation ont été révisées ou retirées, tandis que des comparaisons de suivi combinées et plus grandes ont appuyé des conclusions plus larges.

Comme le pipeline du juge note les résultats des conversations, il peut aussi comparer des choix de configuration visibles par l'utilisateur. Nous l'avons utilisé pour évaluer les niveaux d'effort de raisonnement par défaut, où des tâches courantes comme la modification de code et le débogage ont montré des gains à des niveaux d'effort plus élevés. Pour en savoir plus sur la configuration des niveaux d'effort de raisonnement, consultez la documentation sur l'effort de raisonnement.

Les chiffres ci-dessous sont des écarts observés lors de comparaisons internes au niveau des expériences. Ils décrivent ces échantillons d'évaluation et ne doivent pas être lus comme des estimations universelles d'effet en production.

Kiro CLI (première configuration modèle-requête évaluée) :

• Signaux d'insatisfaction explicite : en baisse de 5 %
• Problèmes de qualité comportementale : en baisse de 32 %
• Problèmes de complétude des tâches : en baisse de 10,6 %

Kiro IDE (première configuration modèle-requête évaluée) :

• Problèmes de qualité comportementale : en baisse de 20 %
• Livraison de tâches incomplètes : en baisse de 21 %
• Approches infructueuses répétées : en baisse de 36 %
• Incohérences de style : en baisse de 54 %

La revalidation répond à une question différente de celle des premières expériences. Ces expériences mesuraient l'effet des modifications de requête sur la première configuration modèle-requête évaluée. La revalidation vérifie si les mêmes modifications aident encore après une mise à niveau de modèle.

La référence modèle-requête plus récente présentait déjà moins de problèmes de qualité comportementale sous la même grille, de sorte qu'il y avait moins de marge qu'une requête pouvait ajouter; les gains ici sont donc plus petits que ceux du cycle initial par conception, et non une régression. Même face à cette référence plus exigeante, les mêmes modifications de requête ont tout de même fait bouger les deux signaux dans le bon sens : elles ont réduit les problèmes de qualité comportementale de 4 % supplémentaires et amélioré l'insatisfaction explicite de 2,6 points de pourcentage. Nous lisons cette étape comme une confirmation directionnelle que les modifications aident encore après une mise à niveau de modèle, non comme une estimation précise en production.

Le modèle plus récent a aussi suivi certaines instructions plus littéralement, surtout aux niveaux d'effort plus faibles, de sorte que des directives ajustées pour le modèle précédent ne se transféraient pas proprement dans tous les cas. Nous traitons donc chaque mise à niveau de modèle comme une nouvelle configuration modèle-requête : rejouer les cas de plainte connus, utiliser les cas déjà réussis comme tests de régression, mesurer la qualité comportementale, l'insatisfaction, les régressions et l'efficacité, puis réajuster avant le déploiement.

L'évaluation en usage réel complète les tests de référence. Les tests de référence standards demeurent utiles. La rétroaction interne révèle des occasions d'amélioration de la requête système à partir de vraies sessions d'utilisateurs qui contiennent souvent des dimensions que les tests de référence standards ne saisissent pas ensemble, comme le contexte d'espace de travail propre à l'utilisateur, l'interaction avec de vrais services en production, des conversations reprises sur des sessions de travail distinctes, et d'autres bruits du monde réel.

Utilisez des cohortes isolées pour un dépistage directionnel. De petites cohortes candidates peuvent aider à localiser les régressions, tandis que des comparaisons de suivi combinées et suffisamment puissantes sont nécessaires avant de tirer des conclusions plus larges.

Les effets des requêtes dépendent du modèle. Les mêmes modifications ont réduit les problèmes de qualité comportementale de 32 % sur une version de modèle et de 4 % sur une autre. Chaque mise à niveau de modèle nécessite une étape de revalidation.

Retirez les directives qui ne sont plus nécessaires. Certains des plus grands gains viennent du retrait de contraintes désuètes, y compris des limites de lignes et des contournements d'outils obsolètes. Des requêtes plus simples sont plus faciles à garder alignées sur le comportement du modèle.

Ces modifications rendent Kiro plus susceptible de mener la tâche à terme, de changer de cap quand une approche ne fonctionne pas, et de suivre le style de code existant du projet. Elles incitent aussi Kiro à vérifier que les modifications compilent et que les tests passent avant de poursuivre, et à demander avant les actions risquées tout en procédant directement pour le travail sans risque. Nous répétons cette évaluation des requêtes à mesure que les requêtes et les modèles changent, en validant les mises à jour avant le déploiement.