Comment Kiro Auto utilise la mise en cascade des modèles pour adapter le modèle au travail
Nous commençons avec un modèle initial efficace. Un modèle plus performant prend le relais au besoin.
Illustration · données non mesuréesIllustration animée. Une session de programmation est représentée par un sentier pointillé qui longe un terrain plat et facile, puis grimpe abruptement jusqu’à un sommet. Au départ du sentier, un petit drapeau étiqueté modèle initial marque l’endroit où la session commence sur le modèle initial efficace. Un petit fantôme Kiro blanc aux accents bleus s’élance sur le sentier et avance sur le tronçon facile, illuminant le sentier en bleu derrière lui. Au-dessus du sentier, un phare étiqueté vérification indépendante, en arrière-plan, projette un faisceau doux sur le sentier que le fantôme a déjà parcouru, du départ jusqu’à juste derrière le fantôme; le fantôme continue d’avancer et ne s’arrête jamais pour lui. Là où le sentier devient une montée abrupte, la lentille du phare s’illumine une fois, et un fantôme blanc plus grand aux accents violets arrive, prend un petit orbe lumineux au petit fantôme et poursuit l’ascension, illuminant le sentier en violet. Le petit fantôme s’écarte et fait un signe de la main, et le sentier bleu derrière lui reste illuminé. Le texte de l’illustration indique « Nous commençons avec un modèle initial efficace. Un modèle plus performant prend le relais au besoin. »
En bref. En coulisses, Auto utilise la mise en cascade des modèles. Chaque session commence sur un modèle initial, une vérification indépendante examine le travail en arrière-plan, et Auto confie la session à un modèle plus performant lorsque le travail l’exige. Lors d’une évaluation interne sur DeepSWE v1.1, la cascade a obtenu des résultats presque aussi bons que le modèle plus performant utilisé seul, et environ quatre tâches sur cinq se sont terminées sans passage de relais.
Auto est la façon dont nous recommandons à la plupart des gens de travailler dans Kiro. Comme le décrit notre documentation sur les modèles, Auto choisit le modèle pour vous et maintient un niveau de qualité élevé. Dans les forfaits payants, cela signifie une qualité de classe Claude Opus. Ce billet présente l’une des façons dont Auto atteint ce niveau, une technique appelée mise en cascade des modèles.
Vous demandez à Kiro de corriger un analyseur de dates instable. Les premières étapes sont routinières. Lire le fichier, trouver la fonction, écrire un test qui échoue. Puis le test révèle une hypothèse de fuseau horaire qui traverse trois autres modules, et la petite correction devient une refactorisation. L’inverse arrive aussi, lorsqu’une tâche qui semblait importante se révèle être un changement de deux lignes.
À mesure que les modèles deviennent plus performants, vous leur confiez des tâches plus importantes, et les sessions Kiro durent plus longtemps. Une session de longue haleine comporte de nombreuses étapes, de la lecture de fichiers et la modification du code à l’exécution des tests et aux nouvelles tentatives, et sa difficulté n’est pas fixée au départ. Elle a une forme, et vous ne voyez cette forme qu’en avançant. La figure 1 présente la même session de trois façons.
La difficulté se révèle au fil de la session. Un choix fait au départ ne peut pas la voir venir.
Une session, trois façons
Choisir d’emblée le modèle plus performant
Plus que ce dont le tronçon facile a besoin.
capacité inutile pour le tronçon facile
Choisir d’emblée un modèle efficace
Insuffisant pour la montée.
sous-dimensionné pour la montée
Cascade · décider en continu
Commence léger, monte en puissance pour la montée.
pas nécessaire
passe le relais
Diagramme illustratif, données non mesurées. Trois couloirs superposés montrent la même session de programmation, la progression de la session allant de gauche à droite et la difficulté augmentant vers le haut. La tranche d’ouverture de chaque couloir est étiquetée même requête de départ. Dans la session par défaut, qui se corse, la ligne de difficulté commence bas avec de petites bosses, grimpe abruptement un peu avant le milieu, reste élevée et s’adoucit vers la fin. Le couloir 1, Choisir d’emblée le modèle plus performant, montre une ligne de capacité violette plate, décidée ici selon la requête initiale, située bien au-dessus de toute la session; l’espace entre elle et la faible difficulté du début est ombré et étiqueté capacité inutile pour le tronçon facile. Son verdict indique plus que ce dont le tronçon facile a besoin. Le couloir 2, Choisir d’emblée un modèle efficace, montre une ligne bleue plate, décidée au départ, située bas; là où la difficulté la dépasse, l’écart est hachuré et étiqueté sous-dimensionné pour la montée. Son verdict indique insuffisant pour la montée. Dans le couloir 3, Cascade, décider en continu, la ligne commence bas en bleu, monte au violet peu après le début de la montée, étiquetée passe le relais, et reste violette jusqu’à la fin. Un contour pointillé entre le tronçon bleu et le niveau violet élevé est étiqueté pas nécessaire. Un petit fantôme suit la partie bleue et un fantôme plus grand suit la partie violette. Son verdict indique commence léger, monte en puissance pour la montée. Au défilement, un brouillard se lève de gauche à droite, montrant que la difficulté n’est visible qu’au fil de la session, tandis que les deux lignes choisies d’emblée sont tracées en entier dès le départ. Un bouton bascule vers une session qui reste facile. Dans ce cas, les lignes choisies d’emblée ne changent pas, le choix efficace convient, le modèle plus performant dépasse les besoins de la session tout du long, et la cascade reste bleue sans passage de relais.
Lorsque vous choisissez un modèle avant que le travail commence, la requête est la seule information dont vous disposez. Si vous choisissez le modèle plus performant, il prend en charge chaque étape, y compris les étapes routinières qu’un modèle efficace aurait pu accomplir tout aussi bien. Si vous choisissez un modèle efficace, il gère bien les étapes routinières, mais lorsque le travail se corse, il peut commencer à tourner en rond et à refaire du travail déjà accompli. Basculez maintenant la figure vers une session qui reste facile. Les choix faits d’emblée ne changent pas, car la requête est la même. La cascade reste sur le modèle initial tout du long, car la session ne devient jamais plus difficile que ce que ce modèle peut gérer.
La mise en cascade des modèles transforme un choix de modèle unique en une suite de décisions, prises tout au long d’une session d’agent plutôt qu’en une seule décision au départ.
- Commencer sur un modèle efficace. Chaque session commence sur un modèle initial, un modèle efficace qui gère bien un large éventail de tâches courantes. Dans de nombreuses sessions, c’est le bon choix et il accomplit tout le travail.
- Vérifier le travail en arrière-plan. Un modèle indépendant examine la trajectoire de la session, c’est-à-dire le travail accompli jusque-là. La vérification s’exécute de façon asynchrone, de sorte que la session ne l’attend jamais, et le modèle qui travaille n’évalue jamais ses propres progrès.
- Continuer ou passer le relais. Tant que la session progresse régulièrement, rien ne change. Si la vérification détecte des signes indiquant que la session a cessé de progresser efficacement (comme l’exploration répétée du même code ou la reprise de travail déjà fait), Auto confie la session à un modèle plus performant. Le passage de relais transmet l’essentiel du travail accompli, de sorte que le modèle plus performant reprend la session là où elle en est au lieu de recommencer à zéro.
- Répéter au besoin. Ce processus peut se répéter jusqu’à ce que la session s’exécute sur le modèle le plus performant. Pour l’instant, les passages de relais ne vont que vers le haut. Rendre une session à un modèle efficace est une possibilité que nous explorerons dans une prochaine mise à jour.
Pour les équipes qui gèrent l’accès aux modèles, un passage de relais peut utiliser n’importe quel modèle accessible à Auto; il suit donc les mêmes paramètres de gouvernance qu’Auto. Consultez la page gouvernance des modèles pour savoir comment les administrateurs contrôlent l’accès aux modèles.
Chaque session commence léger. Un modèle plus performant prend le relais quand le travail l’exige.
Commencer léger. Le modèle initial commence la session, et souvent il accomplit tout le travail.
Vérifié en arrière-plan. Une vérification indépendante examine le travail accompli jusque-là. La session ne s’arrête pas pour elle, et tant que tout se déroule comme prévu, rien ne change.
Passer le relais. Lorsque la vérification détecte des signes indiquant que la session a cessé de progresser efficacement, un modèle plus performant reprend le même sentier, là où la session s’est arrêtée.
Répéter au besoin. Ce processus peut se répéter jusqu’à ce que la session s’exécute sur le modèle le plus performant. Rendre une session à un modèle efficace est une possibilité que nous explorerons dans une prochaine mise à jour.
Commencer léger. Le modèle initial commence la session, et souvent il accomplit tout le travail.
Vérifié en arrière-plan. Une vérification indépendante examine le travail accompli jusque-là. La session ne s’arrête pas pour elle, et tant que tout se déroule comme prévu, rien ne change.
Passer le relais. Lorsque la vérification détecte des signes indiquant que la session a cessé de progresser efficacement, un modèle plus performant reprend le même sentier, là où la session s’est arrêtée.
Répéter au besoin. Ce processus peut se répéter jusqu’à ce que la session s’exécute sur le modèle le plus performant. Rendre une session à un modèle efficace est une possibilité que nous explorerons dans une prochaine mise à jour.
Diagramme illustratif en quatre étapes de la mise en cascade des modèles dans Auto. À l’étape 1, commencer léger, un petit fantôme blanc aux accents bleus, étiqueté modèle initial, commence une session sur un sentier sinueux en laissant des empreintes bleues. À l’étape 2, vérifié en arrière-plan, un phare étiqueté vérification indépendante, en arrière-plan, projette son faisceau sur le sentier que le fantôme a déjà parcouru, du départ jusqu’à juste derrière le fantôme, pendant que le fantôme continue d’avancer. À l’étape 3, passer le relais, le sentier fait une boucle sur lui-même, une image générique d’une session qui tourne en rond; le faisceau se pose sur la boucle, et un fantôme blanc plus grand aux accents violets, étiqueté modèle plus performant, arrive, prend un petit orbe lumineux au petit fantôme et poursuit sur le même sentier à partir de ce point pendant que le petit fantôme s’écarte et fait un signe de la main. À l’étape 4, répéter au besoin, le plus grand fantôme grimpe jusqu’à un sommet marqué d’un crochet en laissant des empreintes violettes, tandis que les empreintes bleues précédentes restent illuminées; une flèche pointillée vers le haut sur le côté va de modèle initial à modèle le plus performant et indique peut se répéter.
Imaginez une ingénieure qui traite un billet pendant qu’une réviseuse regarde par-dessus son épaule. L’ingénieure continue de travailler et ne s’arrête jamais pour évaluer ses propres progrès. C’est le rôle de la réviseuse. Tant que le travail avance, la réviseuse reste silencieuse. Lorsque la réviseuse voit le travail tourner en rond, le billet passe à une ingénieure plus expérimentée, qui le reprend là où il en est.
C’est ce qui permet d’exécuter une cascade par défaut en toute sécurité. Le modèle qui travaille n’évalue pas ses propres progrès, et un passage de relais s’appuie sur le travail déjà accompli au lieu de recommencer à zéro. Lorsqu’une session a besoin de plus de capacité, elle l’obtient en cours de route, et lorsqu’elle n’en a pas besoin, elle reste sur le modèle initial.
Nous avons évalué la mise en cascade sur DeepSWE v1.1, le banc d’essai de génie logiciel de longue haleine de Datacurve. Ses tâches sont originales, tirées de dépôts à code source ouvert et notées à l’aide de tests comportementaux rédigés à la main; elles exigent donc le type de session en plusieurs étapes où la difficulté peut changer. Nous avons exécuté trois configurations dans le moteur d’agent Kiro, et chaque configuration a été exécutée sur l’ensemble du banc d’essai trois fois de façon indépendante.
- Modèle initial seul. Chaque tâche s’exécute sur le modèle initial efficace du début à la fin.
- Modèle plus performant seul. Chaque tâche s’exécute sur le modèle plus performant du début à la fin.
- Cascade. Chaque tâche commence sur le modèle initial, avec le modèle plus performant disponible pour un passage de relais.
Les trois configurations utilisaient les mêmes paramètres de raisonnement. La seule différence entre elles est le modèle qui accomplit le travail. Nous présentons le pass@1, soit la proportion de tâches résolues en une seule tentative, sous forme de moyenne des trois exécutions ± un écart-type.
La figure 3 compare le pass@1 des trois configurations, et le tableau qui la suit présente les mêmes valeurs.
Presque la même qualité que le modèle plus performant seul. Même si chaque tâche commence sur le modèle initial.
DeepSWE v1.1 · moteur d’agent Kiro · 3 exécutions
pass@1, moyenne ± un écart-type sur trois exécutions
presque égal · dans l’écart entre les exécutions
Graphique à points du pass@1 sur DeepSWE v1.1, trois exécutions, dans le moteur d’agent Kiro, une ligne par configuration. L’axe horizontal représente le pass@1 de 60 % à 74 %; il ne commence pas à zéro. Modèle initial seul, pass@1 de 63,96 %, plus ou moins 2,70. Cascade, avec le modèle initial au départ et le modèle plus performant disponible, pass@1 de 69,37 %, plus ou moins 1,56. Modèle plus performant seul, pass@1 de 70,57 %, plus ou moins 2,08. Les barres d’erreur horizontales indiquent un écart-type sur trois exécutions. Les barres de la cascade et du modèle plus performant se chevauchent, le chevauchement est ombré, et une accolade reliant les deux lignes indique presque égal, dans l’écart entre les exécutions. Les mêmes valeurs figurent dans le tableau sous la figure.
| Configuration | pass@1 (moyenne ± 1 écart-type, 3 exécutions) |
|---|---|
| Modèle initial seul | 63,96 % ± 2,70 |
| Modèle plus performant seul | 70,57 % ± 2,08 |
| Cascade (le modèle initial commence, le modèle plus performant est disponible) | 69,37 % ± 1,56 |
La cascade a résolu 69,37 % des tâches, presque autant que le modèle plus performant seul (70,57 %, dans l’écart entre les exécutions) et 5,40 points de plus que le modèle initial seul (63,96 %). C’est aussi la configuration qui a le moins varié d’une exécution à l’autre. Autrement dit, commencer chaque tâche sur le modèle initial n’a pas nui à la qualité.
La figure 4 montre où les tâches de la cascade se sont terminées.
La plupart des tâches n’ont jamais quitté le modèle initial. Environ une sur cinq a passé le relais.
DeepSWE v1.1 · cascade · 3 exécutions
80,48 %
terminées sur le modèle initial seul
19,52 %
commencées sur le modèle initial, confiées au modèle plus performant
Graphique unitaire de 200 carrés, chacun représentant environ 0,5 % des exécutions de tâches DeepSWE v1.1 dans la configuration en cascade, regroupées sur trois exécutions. 161 carrés bleus pleins, soit 80,48 %, sont des tâches terminées sur le modèle initial seul. 39 carrés, soit 19,52 % ou environ un sur cinq, sont remplis de violet avec un mince contour bleu et un point blanc au centre. Ce sont des tâches qui ont commencé sur le modèle initial et ont été confiées au modèle plus performant. Par défaut, les carrés confiés sont regroupés à la fin de la grille; un bouton les disperse dans la grille à des positions illustratives. De grandes étiquettes indiquent 80,48 % terminées sur le modèle initial seul et 19,52 % commencées sur le modèle initial, confiées au modèle plus performant.
Chaque carré ≈ 0,5 % des exécutions de tâches, regroupées sur trois exécutions. Les carrés montrent où une tâche s’est terminée, et non comment son travail a été réparti entre les modèles. Les positions dispersées sont illustratives.
Afficher les données
| Résultat (cascade) | Proportion des exécutions de tâches |
|---|---|
| Terminées sur le modèle initial seul | 80,48 % |
| Commencées sur le modèle initial, confiées au modèle plus performant | 19,52 % |
Sur l’ensemble des exécutions, 80,48 % des tâches se sont terminées sur le modèle initial. Les 19,52 % restants, soit environ une sur cinq, ont été confiés au modèle plus performant en cours de route.
Dans nos exécutions DeepSWE, les tâches confiées avaient un point commun. Il s’agissait de changements difficiles à réussir de bout en bout, comme des fonctionnalités qui touchent plusieurs couches à la fois, des types et des API jusqu’à la CLI et la configuration, ou un comportement qui dépend de l’état sauvegardé, de la mise en cache ou de l’ordre d’exécution. Les petits changements localisés nécessitaient rarement un passage de relais, mais un changement important n’en avait pas toujours besoin non plus. Ce qui comptait, c’était la part du travail qui dépendait d’une conception soignée et de la cohérence entre plusieurs parties du code.
Le moment du passage de relais est tout aussi révélateur. Dans ces tâches, le modèle initial franchissait presque toujours seul les premières étapes, en écrivant le code et souvent en faisant réussir les compilations et les tests. Le passage de relais survenait généralement plus tard, pendant la vérification et l’intégration. C’est à ce moment que la vérification détectait des signes indiquant que la session avait cessé de progresser efficacement, alors que le modèle initial s’efforçait de démontrer que chaque exigence était respectée dans le code qu’il avait modifié. Rien de tout cela n’était visible dans la requête. Une cascade n’a pas besoin de savoir à l’avance quand le travail se corsera, car la vérification continue de surveiller et un passage de relais peut avoir lieu au moment où la session en a besoin.
C’est l’une des raisons pour lesquelles Auto peut accomplir des tâches complexes avec une grande qualité tout en appliquant un multiplicateur de crédits de 1x. La plupart des sessions se terminent sur le modèle initial, et le modèle plus performant ne prend le relais que lorsque le travail l’exige.
Ces résultats proviennent d’une exécution précise d’un banc d’essai d’évaluation interne. Il ne s’agit pas d’une estimation en production, et les résultats sur les charges de travail des clients en production varieront.
Le taux de passage de relais est une moyenne sur l’ensemble des tâches. La fréquence des passages de relais dépend du travail, de sorte que chaque session variera. L’utilisateur ne voit pas le passage de relais et n’a pas besoin de savoir qu’il a lieu pour profiter de ses avantages en matière de qualité.
Les résultats DeepSWE proviennent d’un banc d’essai interne qui n’est pas identique à la configuration officielle du classement public de DeepSWE. Les pourcentages ne doivent pas être comparés à ceux du classement public.
La mise en cascade des modèles fait partie du fonctionnement d’Auto, et ses avantages en matière d’efficacité sont offerts à tous les clients de Kiro. Sélectionnez Auto dans Kiro lorsque vous commencez votre prochaine session. Consultez la vue d’ensemble des modèles pour la documentation sur le fonctionnement d’Auto et de la sélection des modèles.