Transcription
Ravi de vous rencontrer, les gars. Euh, je suis Ash. Euh, voici Andrew. Nous travaillons tous les deux en tant qu'ingénieurs dans notre équipe d'IA appliquée ici chez Anthropic. Euh, et le genre de sujet de cette session a été inspiré par un article de blog que nous avons publié il y a quelques semaines en fait, sur la façon de penser à la construction d'agents qui peuvent réellement fonctionner pendant de très longues périodes prolongées. Vous savez, nous parlons de sessions de 5 à 6 heures ou plus. Je pense que nous avons tous vu ces types de démos, vous savez, d'entreprises disant : « Hé, nous avons fait un navigateur en une seule étape. » Par exemple, mais sans nécessairement partager certains des détails de ce qui entre dans le harnais, et c'est de cela que nous voulons parler aujourd'hui. Alors, tout d'abord, euh, mon incroyable et rapide Andrew parlera un peu de la façon dont nous en sommes arrivés là, de certaines des primitives que nous avons livrées dans le code, euh, et, vous savez, où nous en sommes aujourd'hui. Euh, et ensuite, je reviendrai sur scène pour parler un peu de certaines des choses plus expérimentales avec lesquelles nous jouons avec les harnais, ainsi que, vous savez, de quelques exemples de ce que nous avons vu. Mais, à vous. Ça sonne bien. Merci, Ash. Et oui, merci à tous de vous joindre à la première session de la conférence AI Engineer. Donc, je suis content que vous la passiez avec nous. Euh, je m'appelle Andrew. Je fais partie de l'équipe d'IA appliquée basée à Londres, travaillant en tant qu'architecte de solutions avec bon nombre de nos clients natifs numériques et industriels. Donc, euh, oui, je vais vous faire un petit tour d'histoire, un voyage dans le passé, mais vraiment en mettant l'accent sur toutes les choses que nous avons livrées qui permettent aux agents de fonctionner pendant plusieurs heures, voire plusieurs jours à la fois. Euh, et ensuite, je passerai le relais à Ash pour faire davantage sur l'état de l'art. Droit. D'accord, alors euh, une petite citation de ou sur Twitter de Boris, le créateur de Cloud Code. C'était à l'occasion du premier anniversaire de Cloud Code. Euh, en disant qu'il y a un an, Cloud avait du mal à écrire des commandes bash et à échapper des chaînes. Euh, et cela pouvait fonctionner, vous savez, peut-être 20 minutes à la fois. Et puis, nous en sommes maintenant au point où presque tout Cloud Code est écrit par Cloud Code, et il peut fonctionner efficacement pendant des jours à la fois. Euh, donc une sorte de grand grand changement sur une seule année, et je vais vous expliquer cette histoire un peu maintenant. Mais, juste pour laissez-moi euh, zoomer ici. Euh, juste pour cadrer le problème. Je vais expliquer pourquoi il est vraiment difficile pour ces agents de fonctionner pendant des périodes prolongées. Euh, je pense qu'en général, il y a trois grandes catégories. Euh, certaines sont plus intuitives que d'autres. Donc, premièrement, le contexte. Je pense que nous comprenons tous très bien que les fenêtres de contexte sont très limitées. Donc, vous commencez une nouvelle session, il y a une sorte d'amnésie. L'agent doit recommencer à zéro, vous avez donc besoin d'une sorte de composant de mémoire. Euh, également lorsque vous travaillez dans une fenêtre de contexte, il y a cette notion de pourriture du contexte. Donc, euh, il y a moins de cohérence à mesure que vous vous enfoncez dans cette session. Euh, de plus, vous pourriez arriver au point où euh, le modèle présente en fait ce qu'on appelle l'anxiété de fin de contexte. Donc, il devient un peu nerveux à l'approche de la fin de sa fenêtre de contexte, et il se dépêche de finir ce qu'il fait. Euh, cela conduit à la planification. Donc, euh, en général, les modèles ne sont pas très doués pour planifier dès la sortie de la boîte. Euh, ils pourraient essayer de tout faire en une seule étape. Ou, par exemple, ils pourraient construire une moitié de fonctionnalité, puis s'arrêter, ou ils pourraient simplement manquer de contexte et laisser une application à moitié construite. Euh, mais peut-être moins intuitivement, euh, les modèles sont vraiment mauvais pour juger de leur propre sortie. Donc, je sais que nous savons tous que les modèles peuvent être sycophantes et vous dire ce que vous voulez entendre, mais cela s'applique également aux tâches de codage. Donc, il pourrait regarder une fonctionnalité et voir qu'elle est à moitié cuite ou un peu implémentée et dire : « Oui, d'accord, euh, cela semble terminé. » et ensuite il passera à la chose suivante. Ou il pourrait construire une fonctionnalité comme un bouton, mais en fait le backend, vous savez, il n'existe pas pour cela. Il n'y a rien derrière cela, mais il semble que la fonctionnalité soit terminée. Donc, euh, je sais qu'Ash parlera assez longuement de certaines des nouvelles techniques que nous avons pour aider à cela, euh, spécifiquement afin que les modèles puissent mieux juger de leur propre sortie. Donc, il y a vraiment deux façons de résoudre ces problèmes. Euh, la première est évidemment le modèle. Donc, euh, tout intégrer dans les poids du modèle eux-mêmes. Et je suis sûr que vous avez tous vu ce graphique en forme de mètre. C'est essentiellement combien de temps un agent peut fonctionner avec un échafaudage minimal où il accomplit 50 % des tâches. Et vous verrez d'Opus 3.7, c'est environ 1 heure et jusqu'à Opus 4.6, un an plus tard, c'est 12 heures. Donc, une journée entière. Euh, et nous avons bien sûr, vous savez, réussi à faire fonctionner cela beaucoup plus longtemps. D'autres personnes l'ont fait aussi, mais c'est juste un échafaudage très minimal. La deuxième chose que vous pouvez faire est, bien sûr, d'apporter des modifications au harnais lui-même. Donc, c'est l'échafaudage autour du modèle. Et nous avons le SDK d'agent qui est livré avec toutes les primitives que nous avons construites au fil du temps. Il y a donc la boucle d'agent principale elle-même où vous avez le modèle Claude qui détermine quoi faire, quels outils exécuter, euh, peut-être qu'il récupère des outils des serveurs MCP. Euh, il peut déléguer certaines tâches à un sous-agent. Il apporte tout le contexte de choses comme claude.md ou les compétences chargées ou les commandes slash. Et il y a tout un système d'autorisations. Et cela changera également avec le temps à mesure que les modèles s'amélioreront. Mais ce sont les primitives principales avec lesquelles nous travaillons. Et ensuite, bien sûr, vous utilisez ce framework pour construire votre propre harnais pour tout ce que vous essayez de faire, comme certaines des choses qu'Ash montrera plus tard lorsque nous arriverons à des agents plus durables. Euh, je pense que ce qui est également intéressant, c'est de regarder en arrière sur la dernière année de sorties, c'est que lorsque nous avons publié un modèle, nous avons toujours également publié beaucoup de changements de harnais en parallèle avec les modèles. Donc, ces choses évoluent vraiment ensemble. Nous allons donc regarder en arrière, supposons d'abord juste avant l'histoire, au-delà d'un an auparavant. Je pense que nous nous souvenons tous de cette période où Claude avait la section artefact de Claude.ai et Sonnet 3.5 a été le premier modèle qui a vraiment montré des promesses en matière de codage. Et il pouvait maintenant vérifier qu'il pouvait regarder ce qu'il avait construit et itérer à partir de là. C'était un moment assez révélateur avant Claude code. Euh, mais nous avons également livré computer use, il pouvait donc commencer à cliquer, prendre des captures d'écran, tester son propre code, ainsi que le spec MCP, qui lui permettait d'utiliser des outils. Ensuite, en entrant dans Claude code, c'est février 2025. C'est donc il y a un peu plus d'un an. Euh, Sonnet 3.7 a été publié et c'était l'état de l'art sur Swebench. Et Claude code a été publié en avant-première de recherche. Et je pense qu'une citation intéressante que j'ai tirée de cette publication est que l'objectif de Claude code était de mieux comprendre comment les développeurs utilisent Claude pour le codage afin d'informer les futures améliorations du modèle. Essentiellement, lorsque nous avons publié Claude code, l'idée était qu'il soit quelque peu expérimental pour informer la façon dont nous améliorons réellement le modèle de base lui-même. Et vous verrez cette tendance qu'au fil du temps, les modèles s'améliorent. Euh, certains aspects du harnais pourraient devenir moins nécessaires ou évoluer. Euh, juste juste en termes de ces diapositives, également dans le coin inférieur gauche, ce sont certaines des choses qui sont l'objectif de ces publications, qu'il s'agisse de contexte, de planification ou de vérification, puis de quelques statistiques, mais je ne vais pas tout lire. Euh, donc oui, ensuite, c'était vers mai de l'année dernière, Opus 4 et Sonnet 4 4 ont été publiés. Et en général, euh, ces outils sont devenus beaucoup meilleurs pour gérer leur propre contexte et atteindre l'achèvement des tâches sans piratage de récompense ou quoi que ce soit de ce genre. Et puis Claude Code est devenu GA ainsi que nous avons publié le SDK Claude Code. Donc, le harnais qui alimente Claude Code. Petite interruption ici dans la chronologie. Je pense que tout le monde connaît maintenant cette technique de Ralph Wiggum. Vous ne savez peut-être pas que c'est en fait en juillet dernier que cela est sorti, lorsque Jeffrey Huntley a initialement publié le document, car il a vraiment pris beaucoup d'ampleur vers décembre de l'année dernière, lorsque, par exemple, les gens ont commencé à jouer avec eux-mêmes. Claude a également publié notre propre boucle Ralph au sein du harnais Claude Code lui-même. Mais essentiellement, c'est une technique assez simple où vous prenez une invite et vous la donnez à l'invite de commande Claude Code, par exemple, et vous la faites tourner en boucle jusqu'à ce que toutes les tâches soient terminées. C'est un peu plus profond que cela. Je pense que les gens ont tendance à le simplifier. Il y a en fait quelques phases où, au début, vous auriez une sorte de planification où elle décompose cette invite en quelques fonctionnalités différentes, puis elle choisirait une tâche parmi celles-ci et commencerait une nouvelle session, puis travaillerait avec une fenêtre de contexte fraîche. Donc, beaucoup de ces concepts ont été appliqués dans la boucle Ralph, mais je pense que pourquoi elle a attiré autant d'attention, c'est parce qu'elle semble vraiment simpliste et qu'il l'a mise de manière déterministe mauvaise dans un monde indéterministe. L'idée étant qu'il vaut mieux échouer de manière prévisible que de réussir de manière imprévisible. Lorsque nous avons créé notre propre plugin pour cela dans Claude Code, vous verrez, je ne sais pas si les gens peuvent reconnaître quelle est la différence majeure. Certaines personnes disent que ce n'est pas une vraie boucle Ralph. L'idée est que cela fonctionne dans une seule session Claude Code. Donc, cela ne crée pas une fenêtre de contexte fraîche. Cela repose simplement sur la compaction qui se produit au fil du temps. Donc, peut-être que ce n'est pas considéré comme une vraie boucle Ralph, mais vous définiriez le nombre maximum d'itérations, vous définiriez un mot de sécurité, puis un crochet d'arrêt intercepterait le moment où Claude s'arrêterait normalement, et s'il n'est pas terminé, il continuerait simplement jusqu'à ce qu'il atteigne l'un de ces critères de sortie. D'accord, passons à Sonnet 4.5. C'est à ce moment-là que le modèle a généralement recommencé à mieux gérer son propre contexte. Donc, c'est à ce moment-là qu'il est devenu plus conscient du contexte, en suivant le nombre de jetons consommés. Donc, à mesure qu'il approchait de la fin de la fenêtre de contexte, il le comprenait et pouvait gérer son propre contexte. Claude Code 2.0 a également été publié. C'est là que nous avons introduit des points de contrôle. Donc, en gardant une trace du code au fil du temps, en pouvant revenir à des parties précédentes de la session. Et puis nous avons renommé le SDK Claude Code en SDK Agent. Et c'est parce que nous avons réalisé qu'il est beaucoup plus général que juste pour le codage. Donc, vous verrez que nous parlons beaucoup de codage en ce moment, mais je pense que ce qui est très intéressant, c'est d'appliquer ces harnais de longue durée à d'autres domaines également. À ce stade, nous pouvions fonctionner pendant environ 30 heures avec Claude Sonnet 4.5. Mais ensuite, en complétant la famille avec Haiku 4.5 et Opus 4.5, c'est là que les choses sont devenues vraiment intéressantes, car tout d'un coup, exécuter de nombreux sous-agents est devenu très économique. Et Opus 4.5 est devenu très bon en planification. Nous pouvions donc commencer à utiliser Opus 4.5 pour la planification, puis utiliser Sonnet 4.5 comme cheval de bataille pour exécuter tout ce code. Et puis il y a ces quelques mois importants aussi, car c'est à ce moment-là que nous avons publié les compétences, qui sont à nouveau très bonnes pour utiliser efficacement le contexte avec cette notion de divulgation progressive. Donc, seule la partie frontale de la compétence est chargée au lieu de toutes vos descriptions d'outils, vous savez, ce qui peut consommer une grande partie de la fenêtre de contexte dès le départ. Et puis le reste du corps de la compétence est chargé s'il est instancié, suivi par des références à du code qui pourrait s'exécuter de manière plus déterministe. Et puis d'autres améliorations de contexte, des choses comme l'appel de fonctions programmatiques. Donc, au lieu d'exécuter un tas d'outils, de tout ramener dans le contexte, puis d'essayer de le traiter, écrire du code à la volée et pouvoir exécuter une série d'appels de fonctions, puis simplement obtenir le résultat final. Et encore une fois, tout cela vise à améliorer l'utilisation de la fenêtre de contexte. D'accord, donc beaucoup de choses se passent sur cette diapositive, mais à ce stade, c'est vers novembre. Nous avons publié notre premier article de blog sur les agents de longue durée et sur la façon de les construire. Donc, beaucoup des concepts que j'ai déjà décrits devraient rendre cela assez facile à comprendre. Là où un humain écrirait quelque chose comme, vous savez, écrivez-moi un navigateur ou créez un clone de Slack ou un clone de Salesforce, juste quelque chose de vraiment vague. Et la première chose qui se passerait, dans ce harnais que nous avons construit, est qu'il y a un agent initialisateur qui prendrait cette invite simple et la décomposerait en une série d'artefacts persistants. Le premier étant une liste de fonctionnalités, disons X fonctionnalités. Featurelist.json, car nous avons constaté que les modèles pouvaient écraser des fichiers markdown, alors qu'ils sont moins susceptibles d'écraser des fichiers JSON, ce qui est intéressant. Il écrirait également un fichier de progression, bien sûr, démarrerait le dépôt Git, construirait un script d'initialisation, puis aurait simplement un indicateur pour savoir si les fonctionnalités sont terminées ou non, si elles passeraient tous les tests. À partir de là, cela entrerait dans cette boucle de harnais où il y a plusieurs étapes différentes. La première est, encore une fois, dans une fenêtre de contexte fraîche, juste pour prendre ses repères, quel est le répertoire de travail actuel, qu'est-ce que le fichier de progression dit, d'accord. Et puis, faire un test de fumée ou exécuter le script d'initialisation, donc il n'a pas eu à comprendre comment faire cela à chaque fois, mettre le serveur en marche, etc. Et puis choisir une seule fonctionnalité, une seule fonctionnalité qui n'a pas passé tous les tests, implémenter cette fonctionnalité, faire des tests réels, beaucoup comme une boucle de vérification, un peu comme un humain le ferait en utilisant Puppeteer dans ce cas. Et puis si tout passe, écrire réellement le commit Git et changer l'état de cette fonctionnalité particulière en "passes". Et puis s'il y a des fonctionnalités inachevées, continuer cette boucle dans une fenêtre de contexte fraîche. Nous commençons donc à superposer beaucoup de ces concepts ici, des fenêtres de contexte fraîches, ces artefacts persistants, des boucles de vérification, une très bonne planification en amont. Vous verrez que c'est la première itération de ces harnais de longue durée ici. D'accord, en continuant la visite historique, alors Opus 4.6, Sonnet 4.6. Ces modèles sont vraiment géniaux car Sonnet 4.6 offrait essentiellement l'intelligence de niveau Opus à un prix Sonnet, et il est redevenu un cheval de bataille pour beaucoup de Claude code. Et Opus 4.6 est devenu très bon en planification. Nous l'avons qualifié de modèle très agentique. Donc, Opus 4.6 était excellent pour décider quels outils utiliser et simplement pouvoir fonctionner beaucoup plus longtemps. Si vous vous souvenez du graphique en forme de mètre, vous verrez que c'était un saut d'environ 4 heures à 12 heures avec cet harnais très simple. Donc, ce modèle est très, très agentique. Et puis, avec certaines des recherches que nous avions faites, nous avons publié les équipes d'agents, dont l'idée est que dans Claude code, c'est une manière plus générale pour vous de, disons, échafauder votre propre ensemble d'agents personnalisés. Et l'innovation avec les équipes d'agents est qu'au lieu que tout rapporte à l'agent principal, les sous-agents pouvaient communiquer entre eux, donc ils avaient leur propre façon de coordonner, puis de rapporter à l'agent principal uniquement lorsque c'était nécessaire. Nous avons également introduit la compaction côté serveur, ce qui signifie essentiellement que ces modèles peuvent maintenant fonctionner indéfiniment et que la compaction peut simplement se produire côté serveur. Et puis, cette fenêtre de contexte de 1 million est devenue GA. Donc, maintenant, nous avons une grande fenêtre de contexte. Vous voyez que les modèles s'améliorent. Peut-être que vous pouvez simplement exécuter beaucoup de choses dans une seule fenêtre de contexte au lieu d'avoir nécessairement besoin de nouvelles sessions tout le temps. Vous voyez comment les choses commencent à changer au fil du temps. C'est donc un peu la vue d'ensemble. Vous pouvez voir toutes les différentes publications que j'ai partagées ici dans ce tableau et vous pouvez voir comment cela a changé, disons, de Sonic 3.7 à 1 heure à 12 heures avec Opus 4.6. Et puis nous avons aussi nos propres anecdotes, où les tâches prenaient, disons, 20 minutes quand c'était Opus 3.5 et maintenant nous construisons, disons, des applications complètes que vous n'avez pas à exécuter pendant 30 heures. Elles peuvent généralement fonctionner, disons, 3 à 5 heures. Vous pouvez construire une application vraiment complète qui fonctionne dès la sortie de la boîte. Donc, ce qui est vraiment intéressant, c'est que le harnais ne disparaît pas simplement à mesure que les modèles s'améliorent. Il évolue vraiment à mesure que les modèles changent au fil du temps et il est vraiment fascinant de trouver les lacunes du modèle et de les combler avec le harnais, puis vous entraînez le modèle sur cet aspect du harnais et peut-être qu'à un moment donné, vous le supprimez entièrement et cette boucle itérative continue de se produire au fil du temps avec de plus en plus de ces co-publications que nous avons. Donc, euh, oui, j'espère que ce fut un petit voyage intéressant dans l'évolution de Claude et comment cela s'applique aux agents de longue durée. Et je vais passer le relais à Ash pour continuer avec où nous en sommes aujourd'hui en termes d'état de l'art. D'accord. Euh, question rapide. Est-ce que l'un d'entre vous a des agents qui tournent en ce moment en arrière-plan et qui font du travail pendant que vous avez ? Juste un, deux, trois. D'accord. Probablement qu'il devrait y en avoir plus. Euh, j'espère qu'à la fin de ceci, vous aurez quelques idées à emporter et à mettre en pratique. Euh, donc oui, c'est l'histoire. Euh, et j'aime bien cette citation qu'Andrei a mentionnée, où la frontière ne rétrécit pas vraiment, elle se déplace. Et donc, ce dont je voulais parler un peu, ce sont des modèles de harnais très simples avec lesquels nous avons joué en interne et que nous utilisons pour construire ces applications de démonstration sophistiquées en une seule étape. Mais aussi, vous savez, nous expérimentons ces choses en post-entraînement, en RL. Comment rendre nos modèles et leurs comportements généraux plus aptes au travail autonome ? Donc, si vous avez déjà essayé de faire en sorte qu'un agent examine sa propre PR, vous comprendrez où cela va. Donc, cette idée générale est honteusement volée aux GANs, réseaux génératifs contradictoires. Donc, vous avez ce modèle générateur, puis vous avez une sorte de discriminateur, et vous avez une sorte de pression contradictoire entre eux. Vous savez, le générateur construit, l'évaluateur note, et l'idée générale est que nous divisons les fenêtres de contexte, les invites système, le travail entièrement, n'est-ce pas ? L'évaluateur ici ne se contente pas de lire des diffs, mais il utilise en fait playwright pour ouvrir des pages en direct, cliquer, essayer des choses, et ensuite il renvoie finalement la critique qu'il a décidée au générateur réel, et vous, vous continuez cette boucle. Comparez cela à ce que la plupart des gens font aujourd'hui, qui est d'utiliser une seule session de code, lui demander de vérifier son propre travail, et de boucler ainsi. Donc, la question évidente pour moi au moins est, si l'évaluateur est aussi un LLM, pourquoi ne le tamponne-t-il pas aussi ? Et donc, l'idée clé que nous exploitons ici est que oui, l'évaluateur est toujours un grand modèle linguistique, et oui, il sera toujours biaisé en faveur des sorties de style grand modèle linguistique, mais régler un critique autonome pour qu'il soit dur est en fait très réalisable, mais régler un constructeur pour qu'il soit quelque peu auto-critique ne l'est pas. Je pense qu'une très bonne analogie pour cela est la même chose que pour les humains. Il est très facile pour moi de critiquer une belle œuvre d'art ou un bon repas, beaucoup plus difficile pour moi de la peindre ou de cuisiner ce repas moi-même. Donc, ce que nous faisons ici, c'est exploiter l'écart entre la capacité d'un LLM à être un critique par rapport à un générateur. La prochaine chose dont je veux parler est la façon dont vous concevez ces critiques. C'est très similaire au processus de création de bonnes évaluations, mais dans le contexte d'applications full-stack, il y a beaucoup de domaines flous qui entrent dans ce qui rend quelque chose de bon. Il ne s'agit pas seulement de savoir si cela fonctionne, mais aussi de savoir si cela a une belle apparence. Si cela a une bonne sensation. Y a-t-il un élément de goût dans ces types de produits ? C'est là que nous avons fait beaucoup de travaux expérimentaux, en particulier lorsque nous essayons d'insuffler à Claude un goût de design et de post-entraînement, mais aussi, vous savez, de créer ces compétences de conception front-end que nous avons publiées et d'améliorer généralement la capacité de conception front-end de nos modèles. La façon dont nous pensons à cela est que la plupart des gens disent qu'on ne peut pas noter le goût, mais, vous savez, nous pensons que vous pouvez si vous avez une opinion assez forte à ce sujet et que vous l'écrivez simplement. Et donc, la façon dont nous faisons cela au moins est de créer une grille avec quatre critères : design, originalité, artisanat et fonctionnalité. Nous pondérons cela en faveur du design et de l'originalité. Nous avons déplacé les pondérations entre ces quatre éléments en fonction du modèle en jeu, mais pour le moment, vous savez, Opus 4 6 est déjà très bon en matière de fonctionnalité, donc le problème que nous essayons de résoudre est comment empêcher des choses comme les dégradés violets, l'esthétique générale de la "boue IA" en général. Et nous calibrons cela avec des exemples en quelques plans sur des sites de référence, de sorte que le goût de l'évaluateur converge avec le nôtre. Et laissez-moi vous montrer un exemple, je suppose, de ce à quoi cela ressemble en pratique. Donc, voici juste un exemple d'un modèle qui suit une boucle similaire, générateur, l'évaluateur lance Playwright, navigue, prend des captures d'écran, note sur ces quatre critères, écrit une critique, puis la renvoie au générateur. Tous ces exemples sont uniquement en HTML et CSS que j'ai parcourus pendant peut-être 4 heures, 5 à 15 tours. Je pense que la chose intéressante ici, qui est assez unique et quelque chose que vous n'obtiendriez pas nécessairement si vous utilisiez simplement une seule boucle d'agent, c'est que la chose pivote, n'est-ce pas ? Imaginez que le générateur soit bloqué sur l'un des quatre critères. Disons qu'il a vraiment du mal et qu'il obtient constamment de faibles scores en originalité. Vous savez, ce type de harnais de style GAN que nous utilisons jettera tout et essaiera à nouveau à partir de zéro. Alors que dans une génération en passe unique ou une boucle RALF, il continue d'essayer de patcher la même chose. Et cette capacité à corriger le cap sur de très longs horizons temporels est quelque chose qui est assez unique à la décomposition des différents rôles qui entrent dans la construction de quelque chose. C'était donc juste un aperçu de la façon dont nous pensons au composant front-end. Mais comment passer de simples belles pages à des applications entièrement fonctionnelles, nous avons ajouté un rôle de plus : un planificateur. Et donc, encore une fois, cela semble très simple. Il s'agit finalement de prendre une invite d'une seule ligne, puis de la décomposer en une spécification délibérément de haut niveau. Donc, ce qu'il fait, c'est qu'il spécifie le flux de travail général en une série de sprints. Ce qu'il ne fait pas, et ce que la plupart des harnais font aujourd'hui, c'est nécessairement essayer de planifier les détails techniques granulaires du produit. La raison en est que, d'une part, il est très probable qu'il fasse encore une erreur, mais lorsqu'il fait une erreur, elle se propagera à travers chacun de ces sprints et amplifiera les erreurs sur un horizon temporel de plusieurs heures. Si vous plissez les yeux à cela, c'est juste une structure d'organisation très simple de type PM, IC et QA, n'est-ce pas ? Nous n'avons pas inventé cela. Nous avons juste donné à chaque rôle sa propre fenêtre de contexte. Et la partie intéressante, je pense, à discuter, est le lien entre le générateur et l'évaluateur dans ce type de configuration. Donc, avant que le générateur n'écrive une seule ligne, les deux agents négocient ce que signifie "fait". Et donc, disons que le générateur propose : "Je vais construire la fonctionnalité X, et vous devriez la vérifier en testant Y." L'évaluateur pourrait revenir en arrière et dire : "En fait, la portée est trop grande et ces tests que vous proposez sont un peu trop faibles, et vous avez manqué le cas limite XYZ." Et vous avez essentiellement cet échange par le biais de fichiers sur disque. L'un écrit le markdown, l'autre le lit, et vous itérez jusqu'à ce que les deux soient d'accord. Et puis, une fois que vous atteignez cette condition, vous commencez réellement à construire. Et ensuite, l'évaluateur note par rapport au contrat que ces deux agents ont décidé entre eux, pas la spécification d'origine que le planificateur a lancée au début. Et pourquoi cela est important, c'est que cela comble cette idée des histoires d'utilisateurs, c'est-à-dire la spécification, et la convertit en assertions légèrement plus tangibles et testables, une sorte de contrat, sans que le planificateur ait à sur-spécifier à l'avance. Et je pense que c'est l'innovation clé que la boucle Ralph n'a jamais vraiment eue. Elle avait une sorte de plan fixe de type plan.md, mais personne de l'autre côté ne discutait nécessairement avec la boucle principale. Et encore une fois, cela revient à avoir ces fenêtres de contexte séparées et cette pression contradictoire. Laissez-moi donc vous montrer un exemple d'une invite très simple que nous avions dans une boucle solo par rapport au harnais que nous venons de discuter. L'invite était essentiellement de construire un créateur de jeux rétro, et c'est tout. Et je n'essaie pas de vous convaincre que c'est nécessairement le moyen le plus rentable ou le plus efficace d'essayer de construire une application. Comme vous pouvez le voir, cela prend actuellement une quantité de temps extrêmement longue. Deux, c'est très cher. Mais aussi, comme nous le verrons dans une seconde, beaucoup de choses fonctionnent réellement uniquement avec ce harnais alors qu'elles ne fonctionnaient pas dans une boucle solo. Voici donc à quoi ressemblait l'écran d'accueil au moins lorsque nous n'avions pas le harnais. Assez simpliste, un peu ennuyeux, mais ça a toujours l'air bien, n'est-ce pas ? Si c'était toute l'application, vous la livreriez, mais c'est un peu l'appât, si vous voulez. C'était donc l'éditeur de sprites, si vous voulez. Encore une fois, ça a toujours l'air bien. Le canevas est là, la palette, la chronologie des images, la prévisualisation en direct. C'est peut-être un peu encombré. Et le sélecteur de couleurs n'est que des carrés noirs, mais ça fonctionne. Clairement, l'agent a compris ce qu'il essayait de faire. Et puis la seule chose qu'il doit réellement faire, c'est le mode de jeu. Entités rendues, score, santé, toutes les autres choses qui entrent dans un vrai jeu. Appuyer sur la touche fléchée ne fait rien. Appuyer sur la barre d'espace ne fait rien. L'agent n'avait vraiment aucune idée de comment se tester, ce que signifiait réellement jouer à un jeu et réussir. Et oui, c'est le même type d'invite, le même modèle, et c'est le point de rupture. Ça a l'air terminé en surface, mais quand vous essayez de le pousser à ses limites, ça échoue. Et puis, si nous exécutons la même invite avec le même modèle, voici à quoi cela ressemblait lorsque nous avons exécuté le harnais. C'était donc environ 200 dollars, 6 heures. Tout d'abord, il a décidé de s'appeler Retro Forge. Il a décidé de créer une nouvelle boîte de dialogue de projet, d'avoir un très beau canevas. Rien de tout cela n'était dans notre invite. C'est donc le planificateur qui décide, bon, voici à quoi devraient ressembler les décisions de produit. Et puis, les deux autres agents décident, comment vais-je tester cela ? Si nous regardons l'éditeur de sprites, nous avons une palette complète de 54 couleurs, le préréglage 8 bits du dialogue de projet qui s'écoule. Vous voyez le sprite à l'échelle réelle du jeu. C'est un produit beaucoup plus complet en général. Nous avions une toute nouvelle assistance de niveau IA. C'est là que cela a commencé à devenir récursif. Le planificateur avait décidé, bon, nous devrions avoir des fonctionnalités d'IA, ce qui n'est qu'une ligne très vague dans la spécification. Et le harnais en a fait un assistant complet de niveau IA à l'intérieur de l'application qu'il construisait. Donc, quelqu'un pourrait venir et dire : "Hé, créez un château avec des sprites qui le gardent, disons." C'est quelque chose qu'une exécution solo n'aurait jamais même tenté de regarder. Sans planificateur, cette phrase devient simplement une tâche à examiner. Ensuite, enfin, je suppose, les résultats réels appliqués. Mode de jeu, vous avez tout ce HUD de débogage en haut à gauche, ce qui rend clairement la vie plus facile pour l'évaluateur, par exemple. Ces chiffres sont en direct. La boucle physique fonctionne réellement. Les touches fléchées fonctionnent, le joueur bouge, entre en collision avec les murs du château, parce que l'évaluateur a réellement lancé le jeu, a essayé de le jouer, savait nécessairement quelles fonctionnalités devaient être testées pour rendre ce jeu réel et réussi. Et la différence entre cette sortie et la sortie précédente est entièrement due à l'échafaudage. C'est une boucle très simple en fin de compte, mais les résultats sont assez étonnamment différents. Et donc, au cas où vous seriez curieux, les types de choses que l'évaluateur a attrapées sont des choses assez basiques. Ce sont des choses comme, vous savez, l'ordre des routes Fast API, passe tous les tests unitaires mais peut en fait casser en production, l'évaluateur, attrapant des choses comme la touche supprimer, ayant un bug de logique booléenne. Encore une fois, ce sont des choses qui n'ont été attrapées que parce que l'évaluateur utilise réellement l'application. Ce sont des choses qui pourraient passer par CI dans une boucle brute, mais ce n'est pas, ce niveau de spécificité n'est pas quelque chose qui est arrivé par accident. Et donc, c'est le niveau de détail auquel ces modèles parviennent à ce stade. Nous avons parlé des contrats que le générateur et l'évaluateur écrivaient entre eux. Pour cette application, il a été décidé qu'il y avait 27 critères de contrat. C'est le niveau de granularité que nous avons trouvé nécessaire pour rendre les conclusions exploitables. Si vous avez des critères vagues, vous avez des critiques vagues, le générateur hausse les épaules et fait les choses, alors que si vous avez des critères granulaires, l'agent sait, ok, je dois corriger cette ligne exacte. Ce qui est intéressant, je pense, et je veux être honnête à ce sujet, c'est qu'en sortie de boîte, Claude est un très, très mauvais agent d'assurance qualité général. Andrew en a parlé un peu dans sa partie, n'est-ce pas ? Mais le même biais de générosité de six pence s'applique ici. La plupart du temps, dans les premières exécutions, l'agent QA trouvait un bug et disait : "corrigez-le plus tard, cela prendra 2 semaines." Et puis il en avait fini avec ça. Nous avons donc dû passer un temps exorbitant à essayer de régler de petits bugs de mise en page, des cas limites, et à les intégrer dans les invites. J'aimerais qu'il y ait une sorte de secret pour faire cela, mais réalistement, tout l'art de construire ce système et de le rendre bon était de lire les traces. La boucle de débogage principale était celle-ci, et pas nécessairement d'exécuter plus d'expériences. C'était lire ce que l'agent avait réellement fait, trouver où son jugement divergeait du nôtre en tant qu'humains, puis régler l'invite en conséquence. C'était le même muscle que de lire une trace de pile. Une astuce d'outillage que nous avions était de canaliser les transcriptions d'agents dans des fichiers, de les rechercher avec un autre agent, ou d'avoir un autre agent qui les parcourait, puis mettait à jour les invites elles-mêmes. Donc, vous avez une sorte de boucle de fermeture même sur la construction de ce harnais. La dernière chose dont je veux parler est la façon de penser à ajuster votre harnais à mesure que ces modèles s'améliorent. Je pense qu'il y a beaucoup de discussions sur le fait que la conception du harnais est morte ou nulle, surtout là où, vous savez, les modèles que je veux dire, quand j'ai écrit cela, c'était juste Opus 4.6, mais même des modèles de niveau Mythos. Et je pense que la chose clé que nous avons notée est qu'il est vraiment important de comprendre les comportements "pointus" de tout modèle individuel, puis d'essayer d'adapter votre harnais pour combler les lacunes. Donc, Andrew en a parlé un peu, mais vous savez, la réinitialisation du contexte entre les sessions. Nous avons complètement abandonné cela. Opus 4.5 avait une très mauvaise anxiété de contexte. Alors qu'Opus 4.6, il n'en a pas. Dans le cadre du post-entraînement, cela a été fait. Et donc, une session continue et la compaction suffisaient largement à gérer de très longues sessions. Décomposition des sprints. Nous n'avons pas d'opinion très forte à ce sujet, mais c'était quelque chose qui était vraiment critique pour qu'Opus 4.5 fonctionne. Mais Opus 4.6 était capable de maintenir une construction continue de 2 heures de manière cohérente, sans avoir à lui forcer une fonctionnalité à la fois. La cadence à laquelle l'évaluateur devrait s'exécuter. Auparavant, nous nous exécutions à chaque sprint, alors qu'aujourd'hui, nous nous exécutons à la fin d'une génération en une seule étape du modèle, puis nous revenons. Donc, le harnais est toujours le même, nous simplifions simplement les boucles spécifiques et la recette qui la compose. La leçon n'est pas nécessairement que notre harnais était faux, mais plutôt qu'il était bon pour 4.5, la frontière a bougé, et nous avons exécuté une version simplifiée pour voir comment cela fonctionnait. C'est donc à quoi ressemble la configuration finale aujourd'hui. Avoir la boucle planificateur-générateur-évaluateur est toujours le cœur de notre système, mais vous pouvez voir que nous avons abandonné un tas d'autres composants qui rendaient cela un peu plus compliqué qu'il ne le fallait. Nous sommes également, comme mentionné, de grands fans de l'utilisation d'un système de fichiers pour l'état partagé au lieu de s'appuyer sur des fenêtres de contexte pour les agents de longue durée en général. Et voici un exemple du harnais simplifié fonctionnant avec l'un de nos derniers modèles. Encore une fois, très, très cher, mais vous pouvez voir que c'est en fait environ moitié moins cher que les exécutions précédentes. Juste parce que nous faisons les choses d'une manière légèrement plus simplifiée, mais cela fonctionne toujours sur une période de temps très étendue. Et donc, voici un exemple de DAW, qui est essentiellement une application de création de musique, si vous voulez. L'agent définit le tempo, la tonalité, il pose la mélodie, il construit les pistes de batterie. C'est l'évaluateur qui teste l'application elle-même. Nous avons en fait écouté la musique. Bien sûr, Claude ne peut pas entendre pour le moment, et donc la musique était assez nulle, mais l'application était vraiment bonne en général et assez développée, ce qui, il y a un modèle, n'aurait jamais fonctionné. Mais c'est quelque chose qui est possible avec seulement quelques tours. Et c'est un peu cette courbe en mètre qu'Andrew parlait, en action. Et donc, je voulais conclure en disant que vous n'avez pas réellement besoin de notre harnais interne pour commencer à y penser. Nous essayons constamment de livrer des éléments de ces primitives directement dans Claude code, mais il n'y a rien qui vous empêche de construire quelque chose de similaire par vous-même. Nous avons donc livré, vous savez, le mode automatique est probablement ma chose préférée pour une sécurité un peu plus, disons, jaune, plutôt que d'exécuter des permissions dangereusement échappées tout le temps. Nous avons déjà des sous-agents personnalisés comme primitive, n'est-ce pas ? Votre évaluateur, votre rôle QA, donnez-lui une invite système dure et une re-rupture très détaillée. Playwright MTP ou Claude pour Chrome MTP, déjà extrêmement bons pour les applications web ou utilisez simplement computer use si vous construisez des applications natives. Et les compétences, encore une fois, un excellent moyen d'empaqueter vos grilles de notation dans votre flux de développement général. Donc, oui. Cinq choses, si vous prenez une photo, c'est la diapositive que je dirais de retenir. L'auto-évaluation est un piège. Utilisez simplement un évaluateur contradictoire. La compaction n'est pas nécessairement synonyme de cohérence, n'est-ce pas ? Les résumés avec perte dérivent vraiment. Les transferts structurés et les contextes propres sont de très bons modèles que j'ai vus. Ne pensez pas qu'une qualité subjective n'est pas quantifiable. Si vous avez une opinion forte sur ce à quoi quelque chose devrait ressembler, alors forcez-vous à l'écrire. Nous avons constaté que cela faisait une différence énorme pour la qualité des applications qu'un modèle était capable de générer. Et enfin, c'était vraiment, vous savez, asseyez-vous avec le modèle, lisez les traces, seulement alors pourrez-vous vraiment savoir quelles parties d'un échafaudage supprimer, quelles parties garder, surtout à mesure que la frontière se déplace. Mais oui, c'est tout de ma part. Merci beaucoup de m'avoir écouté. Et oui, consultez notre article de blog. Mais je veux juste ouvrir pour une séance de questions-réponses en général, car nous parlons depuis près d'une heure maintenant. Donc, si vous avez des questions pour moi et Andrew, n'hésitez pas. Nous ferons de notre mieux pour y répondre. Oui. Merci. Joan de Paul. Une question pour vous, lorsque vous améliorez l'évaluateur en lisant les journaux et en l'améliorant, est-ce que c'est sur une base par projet ou plutôt une sauce secrète que vous réutilisez entre les projets ? L'objectif est vraiment d'essayer de faire cela d'une manière réutilisable, n'est-ce pas ? Je pense que n'importe qui peut régler cela d'une manière qui crée un type d'application très spécifique, c'est bien. À ce stade, ce n'est pas très différent de, vous savez, aller de l'avant et simplement inviter l'outil code vous-même et le faire, n'est-ce pas ? Je pense qu'il y avait juste les points clés étaient : quels sont les modèles communs que vous pouvez tirer des points faibles du modèle ? Donc, en parlant de cette pièce de conception front-end, nous savions ce que nous pensions être un bon design, n'est-ce pas ? Vous pourriez donner des exemples comme c'est ce à quoi ressemble une invite de lecture préalable. C'est à quoi ressemble la boue IA, n'est-ce pas ? Et cela se généralise assez bien, donc oui. Tout cela concernait les applications web, mais cela pourrait très facilement s'appliquer à d'autres choses. Merci pour Oh. Test. Oh, oui. Merci pour la présentation, très intéressante. Je me demandais juste quelle est votre opinion sur le concept de zone "dump" et zone "smart" d'un modèle. Donc, je comprends qu'avant c'était environ 40 % et maintenant avec 1 million de contextes, c'est environ 100K, c'est ce que je comprends et la façon dont j'ai compris la boucle Ralph, la boucle Ralph a été conçue pour négocier ce problème. Donc, en gros, nous gardons le modèle toujours dans une zone intelligente, donc en essayant de découper la tâche en dessous de 100, il exécute la tâche dans la zone de contexte de 100. Et ce que je comprends de votre présentation, vous préconisez de ne plus l'utiliser parce que nous pouvons maintenant compter sur la compaction et ainsi de suite. Est-ce quelque chose que vous suggérez de faire ou est-ce que nous avons toujours avec le modèle de boucle Ralph, sa propre place étant donné le concept de zone intelligente et stupide ? Oui. Oui, eh bien, je suppose que d'après la présentation d'Ashish et la mienne, vous voyez que la fenêtre de contexte de 1 million est maintenant GA, et donc vous avez une plus grande fenêtre à utiliser. Les modèles sont plus agentiques, donc ils peuvent maintenir la cohérence pendant une période plus longue dans cette fenêtre de contexte. Et puis, avec la sortie de 4.6, nous avons décidé de passer de nouvelles fenêtres de contexte à une seule session continue de longue durée avec compaction. Donc, je pense, je veux dire, que vous utilisiez plusieurs sessions fraîches ou une seule session de longue durée dépend toujours de votre cas d'utilisation et de vos évaluations, en fonction de ce qui fonctionne le mieux. Mais au moins pour ce modèle général générateur-évaluateur avec Opus 4.6, nous avons vu qu'il était possible d'utiliser une seule session. Je ne sais pas si vous voulez ajouter quelque chose. Je pense que c'est aussi juste un problème temporaire, n'est-ce pas ? La pourriture du contexte est un défaut des modèles d'aujourd'hui dans une certaine mesure, et beaucoup moins que même un modèle précédent. Donc, y a-t-il une place pour le type de chose dont vous discutez ? Je pense que oui, en fonction de votre cas d'utilisation, mais ce n'est pas comme si c'était l'une de ces pièces que je regarderais comme : ok, dès que je chercherais la publication du modèle et que je la supprimerais, disons. J'ai toujours beaucoup de FOMO autour de Playwright. Je veux dire, vous avez dit Playwright MCP, est-ce que Playwright skills ? Pouvez-vous parler de la façon d'améliorer Playwright car j'imagine que j'aimerais avoir mon navigateur ouvert et ensuite je peux voir le modèle travailler et ensuite peut-être que je pourrais le diriger, quelques onglets ouverts. Mais oui, y a-t-il une innovation que je manque ou est-ce que Playwright MCP est vraiment ce que vous recommandez aux gens d'utiliser ? Playwright MCP ou utilisez simplement le code pour Chrome MCP, qui est une chose un peu plus robuste, je suppose, pour le contrôle du navigateur. Je ne sais pas pourquoi vous voudriez le regarder faire des choses. Je veux dire, vous pouvez, mais je pense que c'est un manque de confiance, n'est-ce pas, aujourd'hui ? Vous savez, le but de ce que nous essayons de faire ici est que vous lancez quelque chose, vous lui faites confiance pour faire le travail et le tester, et vous avez la confiance qu'il le fait correctement et vous y revenez. Et c'est là que, oui, il y aura une certaine itération au début.
où vous êtes comme en train de regarder, de lire les traces jusqu'à ce que vous arriviez à un point où vous pouvez lui faire confiance. Mais euh, au moins en interne, n'est-ce pas ? Comme, quand je quand je fais du full stack là-bas, euh, j'en suis arrivé à un point maintenant où je me dis : « D'accord, avec Opus 4.x, je peux faire confiance de manière fiable au modèle pour qu'il aille de l'avant, qu'il lise euh les erreurs réseau, euh euh euh les erreurs de console, qu'il navigue réellement dans une application, qu'il zoome là où il doit le faire, euh la vision est maintenant suffisamment bonne sur ces modèles pour qu'ils puissent identifier du texte qui se chevauche sur des éléments et des choses comme ça, alors que ce n'était tout simplement pas le cas euh euh jusqu'à, réalistement, la dernière, vous savez, génération de modèles. Donc, oui, je recommanderais euh je suis curieux, comme, avec le modèle générateur-évaluateur, que se passe-t-il ? Pouvez-vous lui lancer un nombre illimité de tokens ou s'arrêtera-t-il parce que l'évaluateur n'est pas assez bon ? Comme, pouvez-vous m'en dire plus à ce sujet ? Désolé, pourriez-vous clarifier ? J'ai un peu manqué cette partie. >> d'accord, disons euh euh je dis : « D'accord, créez un jeu très cool avec quelques fonctionnalités. » Vous avez le modèle générateur-évaluateur qui euh crée comme les contrats, construit les applications. Si je euh alors il me rendra quelque chose, n'est-ce pas ? Euh puis-je le redémarrer et dire : « D'accord, rendez-le meilleur. Je n'en suis pas satisfait. » Et le générateur-évaluateur choisira le modèle, le prendra en charge et l'améliorera. Oui. Ou l'évaluateur ne sera-t-il pas bon à un moment donné et dira simplement : « C'est tout. » Euh je pense que c'est, je veux dire, un festival comme si vous vouliez comme un certain niveau de boucle humaine dans ce processus, c'est comme ça, vous savez, implémentez simplement des hooks à un moment donné dans ce dans cette boucle. Euh je pense que le morceau qui nous a un peu surpris euh euh était avec ce modèle général et surtout avec les modèles atomiques de type 4.6, à la fois Sauna et Opus, il était extrêmement disposé à jeter tout, vous savez, même s'il avait fait environ 10 passes sur quelque chose. Il était très heureux de tout jeter et de recommencer à zéro si pour une raison quelconque il n'était pas capable de gravir la colline contre la rubrique de l'évaluateur d'une manière efficace. Euh et c'est pourquoi, quand nous jouions avec ce genre de chose, nous n'avons pas naturellement penché vers le fait d'avoir une sorte de système de reprise ou d'intervention humaine dans la boucle, je suppose. Et nous n'avons pas vraiment observé, nous nous attendions à le faire, mais nous n'avons pas vraiment observé euh ce genre de comportement dont vous parliez, où l'évaluateur dit : « Ah, abandonne. Passons simplement, disons-nous ? » Euh oui, il était beaucoup plus disposé à tout jeter et à recommencer. Et c'était un comportement que nous n'avons jamais vu quand c'était le générateur lui-même ou qu'il était fier de son travail et disait : « Je ne vais pas recommencer tout ça. » Euh donc oui, je veux dire, il y a eu des exemples que j'ai vus où l'évaluateur se lasse et dit : « Bon, cette approche que vous adoptez ne fonctionne manifestement pas. Pouvez-vous simplement tout supprimer et recommencer ? » Euh ce que je ne sais pas pour vous, mais en codant régulièrement, je le fais souvent en tant qu'humain pour, vous savez, bénéficier de nouvelles fenêtres de contexte, ne pas avoir à gérer une base de code déjà désordonnée, etc. C'est donc assez intéressant de voir les modèles arriver à ce point maintenant. J'ajouterais aussi brièvement, évidemment, vous pouvez ensuite ouvrir cette base de code dans Cloud Code et continuer là où vous vous êtes arrêté. Euh, cela va sans dire. Et je pense que nous réfléchissons généralement à l'aspect du flux de travail s'il est plus interactif euh parce qu'il y a l'extrême de construisez-moi une application de jeu très complexe dont vous ne savez pas si elle prendra 3 heures, si elle prendra 20 heures. Euh, c'est un peu flou, donc peut-être qu'il y a quelque chose au milieu qui est plus une boucle de rétroaction. J'aime beaucoup l'idée que vous avez de, vous savez, il y a un élément humain ici où c'est comme, vous savez, PM, ingénieur, évaluateur. Le rôle du PM est souvent le scope creep et le maintien du temps, etc. Mais vous laissez cela partir. Vous laissez les ingénieurs jouer dans le bac à sable pendant des heures. Euh y a-t-il une boucle de harnais qui doit revenir au planificateur finalement ? Doit-il bouger à nouveau ? Euh bien peut-être parce que nous sommes des ingénieurs, nous avons juste décidé : « Ah, foutons le PM. Nous allons le mettre de côté. » Euh oui. >> Nous avons en fait, c'est là que le morceau de contractualisation entre l'évaluateur et le constructeur fonctionne assez bien. Pour le contexte, nous insérons généralement la spécification principale générée par le PM en soi dans ces sessions régulièrement. Ainsi, vous savez, c'est toujours un point de référence pour : « D'accord, c'est ce que nous essayons toujours de construire. » Et la fonction principale d'eux, du constructeur et du générateur, euh, désolé, du constructeur et de l'évaluateur est simplement de trouver l'ensemble exact des fonctionnalités et des tests et des contrats qui satisfont réellement cette spécification. Euh mais la raison pour laquelle nous ne le faisons pas, c'est que nous ne voulons pas que le planificateur soit une partie centrale de cette boucle. Il devrait être très haut niveau. Il devrait Son but est vraiment de définir les lignes extérieures dures de ce que ce produit pourrait être. Euh mais son travail n'est pas nécessairement de venir intervenir et dire : « En fait, c'est une fonctionnalité impossible. Nous ne devrions pas le faire. » Et et et de s'éditer. Euh nous voulons garder cette relation de contexte entre juste euh juste le constructeur et le générateur. Cela dit, cette boucle, je l'ai appliquée de nombreuses façons. Il ne doit pas s'agir simplement, vous savez, d'un générateur et d'un constructeur, n'est-ce pas ? Cet arbitrage contradictoire peut être appliqué à un flux de travail composé de plusieurs agents distincts, n'est-ce pas ? Euh je ne sais pas. Cela pourrait euh si vous essayez de faire euh je ne sais pas, générer des évaluations, disons. Vous pourriez utiliser un harnais similaire pour dire : « Hé, générez un euh cela pourrait être comme un planificateur qui génère un générateur de jeu de données synthétiques, n'est-ce pas ? » Euh avec un agent QA. Ensuite, transférez à euh un intégrateur qui euh connecte réellement quelque chose. A également un agent QA. Ensuite, a un euh final. Vous pouvez essentiellement ajouter ce genre de chose générateur-évaluateur dans un flux de travail multi-étapes euh où chaque euh constructeur qui a peut-être une fonction légèrement différente en soi dans le cadre d'un flux de travail plus long. Il existe donc différentes manières de garder les choses sur la bonne voie en fonction de la tâche et de décomposer ce modèle général en tâches ou flux de travail plus spécifiés, si cela a du sens. Pouvez-vous euh vous avez mentionné que certaines des tâches ultérieures ne pouvaient pas être effectuées par un modèle antérieur ? Pouvez-vous parler un peu de votre processus de comparaison des tâches sur les différents modèles ? Comme, lancez-vous la même tâche sur Opus 4.6, Opus 4.5, Sonnet ou est-ce que ce genre de harnais artisanal co-évolutif euh le rend obsolète ? Oui, je suppose que nous avons retracé l'histoire un peu. Et si vous regardez, par exemple, le premier article de blog sur les agents à long terme par rapport au plus récent, euh, il y a des différences assez significatives. L'une d'elles est ce que nous venons de discuter : l'agent initialisateur construirait cette spécification super complète de, disons, 200 fonctionnalités différentes, puis euh dans la boucle devrait en fait exécuter chaque fonctionnalité, ce qui pourrait entraîner des décisions de conception incorrectes, mais il est en quelque sorte forcé à ce comportement. Alors que je pense que maintenant, vous pouvez avoir une direction créative plus générique définie avec, disons, Opus 4.6, puis simplement avoir cette boucle du générateur-évaluateur. Mais cela, oui, votre sélection de modèle informe grandement votre conception de harnais. Euh, bien sûr, dans un monde parfait, vous pourriez simplement tout lancer sur, disons, Opus 4.6, mais si vous avez des préoccupations de coût, par exemple, peut-être utilisez-vous Opus 4.6 pour la planification, puis Sonnet 4.6 pour le codage ou l'exécution, c'est quelque chose que nous voyons assez fréquemment. Euh mais encore une fois, si vous construisez des sous-agents spécifiques pour chacun d'eux, vous voudrez probablement avoir des évaluations pour comprendre pour ce modèle et ce prompt comment il se comporte par rapport à cette tâche, puis simplement optimiser. Avez-vous des conseils pour passer au-delà des applications « one-shot » à des produits à longue durée de vie où vous cherchez à apporter des modifications des jours, des semaines plus tard ? Et quels types d'artefacts devez-vous persister pour les instances futures afin de savoir ce qui s'est passé avant, ce que je peux changer, ce que je devrais changer ? Oui, c'est quelque chose sur lequel nous travaillons. Euh, comme en ce moment, nous utilisons des modèles similaires pour un tas de trucs aléatoires en interne, disons. Et donc, pour le moment, c'est comme lancer cette chose, elle fonctionne, vous savez, euh sur un serveur distant quelque part. Euh, je reviendrai et la vérifierai après cette conversation, disons. Et puis je l'itère manuellement dans le code directement, je polis les bords rugueux, ce genre de choses. Je pense qu'en termes de la façon dont vous configurez réellement ce harnais, il suffit d'avoir, c'est pourquoi nous utilisons par défaut un système de fichiers d'état pour ce genre de boucle. Premièrement, parce qu'il est très facile pour un autre modèle de venir et de faire une recherche et de récupérer ce qui s'est passé. Mais une chose que j'aime faire, c'est d'intégrer un peu de prompting tout au long de cette boucle, qui lui dit essentiellement d'écrire des apprentissages et l'état dans un fichier JSON, car le modèle ne l'écrase pas trop. Euh et donc ce qui est bien, c'est que vous laissez essentiellement des miettes pour qu'un autre modèle vienne les récupérer. Donc, honnêtement, la chose clé pour moi est : comment puis-je instruire ce harnais à laisser des miettes pour qu'un humain vienne et utilise ensuite le code sur celui-ci. Donc, en général, c'est comme, hé, la forme de ce fichier pourrait être comme, j'ai essayé ceci, j'ai évalué, j'ai trouvé ce bug, j'ai implémenté cette correction, cette correction a fonctionné, oui, coche. Et puis continuer. Et vous avez une sorte de journal horodaté, si vous voulez, de tout ce que le modèle a essayé, de la correction qu'il a apportée, et de l'état final. Euh et aussi, avoir une sorte de documentation mise à jour en direct, si vous voulez. Juste très haut niveau, voici la structure du fichier. Et puis ces deux fichiers, pour être honnête, sont plus que suffisants pour que Claude code et un humain viennent commencer à itérer sur l'application. Mais c'est ce que nous faisons en ce moment. Mhm. Parfait. Euh, donc, c'est très intéressant d'entendre le Oh, oui. Tout d'abord, félicitations pour la présentation. Merci. >> Euh et puis je me demandais, il y a deux approches. Comme, vous avez l'équipe d'agents où plusieurs agents interagissent entre eux. Et puis la configuration explicite générateur-critique. Mais quelles sont les euh parce qu'en quelque sorte, l'équipe d'agents a la même configuration où l'agent principal instruit quelqu'un et peut ensuite agir comme critique pour le sous-agent. Mais quelles sont les modes de défaillance actuels qui font que nous avons toujours besoin du harnais spécifique générateur-critique au lieu de simplement l'équipe d'agents elle-même ? Et quelle est votre estimation du nombre de générations de modèles dont nous aurions besoin pour nous fier complètement à l'équipe d'agents ? Mhm. Peut-être clairement. >> Je veux dire, je peux aborder le premier aspect de cela. Donc, je veux dire, une des limitations de Premièrement, Claude code utilise le même harnais que le SDK d'agent. Donc, vous pouvez techniquement construire ce type de modèle dans Claude code. Les équipes d'agents sont un cadre utile pour potentiellement le faire, car vous pourriez dire que le générateur et l'évaluateur communiquent entre eux, ou peut-être que le générateur est l'agent principal et que l'évaluateur est un membre de l'équipe d'agents. Euh mais je pense que cela a évolué davantage à partir de ce premier article de blog que j'ai partagé. Je pense que c'était le résultat de cela dans une certaine mesure pour essayer de le rendre plus généralement disponible. Euh mais l'une des choses qui vous limite évidemment, c'est que cloud code devra simplement s'exécuter sur votre machine. Je pense qu'avec le SDK d'agent, vous pouvez également l'exécuter dans un environnement cloud et un environnement sandbox pendant de longues périodes et sans qu'il échoue ou que vous ayez à exécuter le caffeinate sur votre machine. Euh mais je pense que oui, cloud code est un bon terrain de test pour construire n'importe lequel de ces types de harnais pour expérimenter et explorer et voir ce qui fonctionne avant peut-être de le construire dans le SDK d'agent, puis de le déployer comme sa propre application. Euh et oui, je veux dire encore une fois, j'expérimenterais pour voir si les équipes d'agents sont quelque chose qui a du sens pour vous ou si peut-être l'utilisation de sous-agents réguliers ou une autre formulation de cela fonctionne mieux. Mais oui, je pense que les gens utilisent les équipes d'agents énormément. Je ne sais pas si vous >> Oui, eh bien, c'est la chose, c'est que je ne pense pas que nous ayons un point de vue très fort sur ce qui est le meilleur à n'importe quel moment donné. Et donc Boris met toujours à jour ses tweets comme ceci est ce que je fais maintenant. Euh, comme les équipes d'agents, c'est quelque chose que beaucoup de gens ont aimé en interne, euh et donc nous nous sommes dit : d'accord, expédions-le. Voyons ce que les gens en pensent sur le terrain. Euh, je ne dis pas que nous le ferons, mais nous expédions régulièrement des choses aussi. Euh, et je vois le modèle générateur-évaluateur comme un sous-ensemble de cette approche d'équipe pour penser à la conception de sous-agents. Pas nécessairement contradictoire avec cela en soi. Vous savez, vous pouvez imaginer que les équipes de langage classiques se décomposent comme, vous savez, front-end, back-end, euh une sorte d'intégration entre eux comme des sous-agents. Chacun d'eux mérite probablement sa propre critique, euh un agent qui s'associe à eux, par exemple. Euh, donc, vous pouvez voir comment les deux concepts se chevauchent. Euh, l'idée générale derrière cela est que la plupart des gens, lorsqu'ils exécutent cloud code, en ce moment, leur objectif n'est pas de construire une application en 6 heures. Et donc, ce n'est pas nécessairement un primitif que nous expédions par défaut. Euh, donc, oui. Une chose que je me demandais, avez-vous également essayé un critique qui obtient le contexte du générateur ? Alors je pense que s'il a une idée des traces de l'agent ou de l'exécuteur. Oui. Est-ce le cas actuellement dans le critique ? Euh, nous utilisons un modèle de transfert. Je serais très hésitant à cela. Nous avons essayé cela, mais c'est tout le mélange des pensées entre les deux flux de modèles. Je pense qu'il est beaucoup plus efficace de le laisser simplement juger la sortie. Euh et de fournir, au lieu de dire : « Hé, vous avez fait une erreur en construisant ceci en faisant X, et c'est ce qui a entraîné ce problème. » Il est beaucoup plus efficace que l'évaluateur dise simplement : « C'est un problème. » et ensuite laisser le générateur réfléchir uniquement à son propre travail et essayer de trouver comment résoudre ce problème. Euh sinon, vous voyez, nous avons constaté qu'il est très facile pour le modèle de se tromper en pensant que quelque chose fonctionne ou non, et que cela se répercute également sur l'évaluateur. Et dernière note à ce sujet, je pense qu'il serait alors intéressant si pour l'équipe de formation, vous pouviez entraîner le générateur à prédire ce qu'un critique a dit. Oui. Comme, le rendez-vous plus honnête sur ce qu'il a fait et ainsi de suite. Peut-être que nous y travaillerons. Euh, je voulais poser plus de questions sur la traçabilité. Comme, j'utilise des superpouvoirs ou mes propres prompts pour générer plusieurs sous-agents pour implémenter mon logiciel ou mon application, disons. Mais ce qui se passe, c'est que je ne sais pas vraiment. Je veux revenir en arrière et voir où cela s'est réellement mal passé. Même alors, je ne suis pas capable de comprendre comment trouver ces traces. Comment faites-vous ? Qu'utilisez-vous pour la traçabilité, c'est ma question. Quand vous avez tant d'agents, cinq, six agents qui fonctionnent en arrière-plan, comme, euh oui. Euh, pour être honnête, une grande partie consiste à lire les traces à la main. Euh, nous faisons beaucoup de cela. Je dirais qu'Anthropic en général lit simplement les traces à la main. Euh, nous avons également bricolé diverses choses où nous pointons Claude vers un tas de traces avec des prompts personnalisés pour essayer d'identifier des problèmes avec la boucle, comme c'est ici qu'elle a dévié et ainsi de suite. Euh, nous utilisons cela comme une première passe, je dirais, peut-être juste pour voir où quelque chose, où quelque chose pourrait avoir mal tourné. Mais pour être honnête, de loin, la meilleure approche, du moins celle que nous utilisons en interne, est simplement de lire les traces à la main. Euh, seulement alors pouvez-vous vraiment vous relier à ce que le modèle essaie réellement de faire. Euh, oui. Merci pour la présentation. Euh, j'ai quelques questions. Euh, tout d'abord, comment mesurez-vous la qualité d'une paire d'agents de harnais ? Est-ce que c'est comme un contrôle d'ambiance ? Comme c'est un terrain vierge. Euh, construisons une application. Mhm. Euh, mais disons que vous abordez un nouveau projet, peut-être un projet existant. Euh, cela ressemble à un contrôle d'ambiance ou à une sorte d'art. Pouvez-vous le rendre plus scientifique ou est-ce tout simplement pas faisable ? Je veux dire, la façon dont nous y avons pensé, au moins, n'est-ce pas ? C'est comme si nous spécifiions les rubriques dans des détails extrêmes au niveau du générateur et de l'évaluateur, n'est-ce pas ? Donc, nous avons parlé, par exemple, de ces quatre critères, c'est très haut niveau, la rubrique que nous utilisons pour le goût du design, disons. Et donc nous les avons configurés pour divers éléments de cette application, n'est-ce pas ? Donc, cela peut être juste pour l'élément de conception, peut-être une autre partie pour la façon dont nous pensons à la conception de l'API, disons, la qualité du code, peu importe. Et nous les utilisons comme l'ensemble des rubriques contre lesquelles nous escaladons, n'est-ce pas ? Et alors le travail de l'évaluateur est de, vous savez, encourager le constructeur à escalader contre ceux-ci. Et donc pour n'importe quelle application ou sortie donnée, nous avons un signal de, c'est là que le modèle a commencé sur ces critères, et c'est là que nous avons fini. Maintenant, c'est moins utile pour, comme vous l'avez dit, travailler sur des bases de code plus récentes, mais cela s'applique toujours, n'est-ce pas ? Vous pouvez simplement pointer, vous devez simplement démarrer la boucle d'une manière différente. Euh, vous pointez simplement l'évaluateur sur une base de code donnée. Euh, et dites : « Voici où nous en sommes maintenant », et ensuite euh donnez-lui la spécification de ce que vous essayez d'accomplir, et laissez la boucle euh itérer contre ces critères. Donc, ce ne sont pas nécessairement des évaluations uniques à la toute fin, c'est plutôt : voici les critères de ce que nous pensons être bien, puis laissez l'évaluateur et le générateur proposer un ensemble de tests ou de contrats qui doivent être satisfaits, puis laissez-le simplement comme le harnais escalader contre ceux-ci. Euh, ce n'est pas très comparable entre différents produits et exécutions, mais c'est très utile pour, oui, au sein d'un produit ou d'une exécution. De plus, ce modèle particulier, il est formidable pour les projets neufs, comme vous l'avez dit, mais il est assez opinionné. Vous savez, je pourrais utiliser React, comme Postgres comme base de données, et Node en backend, mais votre application existante pourrait utiliser quelque chose de totalement différent. Ou la rubrique que nous avons créée pour ce que nous pensons être de bons modèles de conception pourrait être totalement différente dans votre projet. Donc, je pense que c'est pourquoi nous proposons cela comme un modèle que vous adapteriez ensuite à votre application. Merci. Euh, une question de suivi. Est-ce que ça marche ? Oui. Euh, dirigez-vous les harnais individuellement et comment coopérez-vous en équipe ? Je trouve qu'il est très difficile de, quand je partage mon écran et que je travaille de manière conversationnelle, il est très difficile pour les gens de suivre. Et inversement, je trouve fastidieux de dicter quoi demander. Euh comment coopérez-vous en équipe ? Avez-vous des harnais détenus par l'équipe ? Euh est-ce peut-être une bonne fonctionnalité pour Cloud Code ? Euh oui, peut-être. Peut-être que je pense que nous avons probablement beaucoup à faire à ce sujet, n'est-ce pas ? Comme je pense que souvent ce qui se passe en interne, c'est que les gens ont ces idées et ensuite elles sont généralement adoptées de manière ascendante par différentes équipes et euh c'est alors le travail du détenteur original de l'idée, devrais-je dire, qui était Prithvi dans ce cas, de la maintenir et de la rendre composable et généralisable pour différentes équipes, et différentes équipes l'adopteront et la rendront utile pour leur section d'une base de code, disons. Euh mais nous n'avons rien de bon dans ce sens. Je pense que, comme, même juste l'observabilité, comme certains en ont parlé, n'est-ce pas, est une chose qui n'est pas entièrement résolue pour ces agents ultra-longue durée. Et oui, un domaine intéressant d'exploration logicielle de type champ vierge. Oui, c'est effectivement une question intéressante, qu'il s'agisse d'une expérience collaborative dans Cloud Code ou même dans Claude.ai. Je pense qu'en exploitant simplement les meilleures pratiques d'ingénierie logicielle avec le contrôle de version et en faisant vos commits et vos pull requests, ou si vous travaillez sur votre propre projet en utilisant quelque chose comme Git work trees afin de ne pas écraser le système de fichiers sur plusieurs fonctionnalités différentes, tout cela a du sens, mais oui, je pense que lorsqu'il s'agit de collaboration, peut-être que cela n'arrive pas autant parce que les gens construisent simplement ces projets comme l'a dit Ash à partir de zéro, puis les présentent au reste de l'entreprise. Euh, je suis Jose de Mercedes-Benz Research and Development ici. Bonjour, merci pour la présentation. Euh, en la regardant, j'ai pensé, d'accord, cela ressemble beaucoup à une équipe Scrum, une équipe de fonctionnalités travaillant plus longtemps sur un produit. Et je pensais à comment l'humain dans la boucle ressemble dans ce scénario ? Parce que vous avez ce genre de sprint. Avez-vous pensé à un moment de type revue de sprint où vous, en tant qu'humain, on vous demande : « Oh, hé, voici ce que nous avons construit ces deux dernières heures. Oui. Comment cela vous semble-t-il ? » Oui. Devrions-nous soumettre nos agents au traumatisme de sauvegarde que les ingénieurs subissent lors des revues Scrum ? Je veux dire, le but de ce général, l'idée générale derrière cette présentation et aussi ce que nous essayons de faire, c'est d'être aussi agile que possible, n'est-ce pas ? Comment construisons-nous des harnais où nous n'avons pas besoin d'un humain dans la boucle ? Qu'est-ce que cela ressemble ? L'utilisons-nous aujourd'hui pour tout ? Évidemment pas, n'est-ce pas ? Euh, mais le but est, vous savez, c'est une technique ou un modèle qui devrait s'étendre très bien de sorte que vous n'ayez pas d'humain dans la boucle pour la plupart des choses. Si vous le faisiez, ce serait comme, vous savez, les hooks sont probablement le primitif principal pour simplement injecter un type de condition d'arrêt spécifique, disons, avec un évaluateur pour simplement revenir à l'humain, permettre une sorte d'entrée de message développeur, puis continuer la boucle serait une façon simple de l'implémenter. Mais oui, pour être honnête, nous explorons cela du point de vue de ce que nous pouvons faire de manière entièrement autonome, par opposition à penser à cela comme de l'or pur et comment le rendre plus puissant. C'est très certainement une exploration de type champ vierge de la conception d'agents. Non, bien sûr, c'est juste que si j'avais la chance de le revoir quelques heures plus tard, je pourrais peut-être l'orienter d'une meilleure manière. Oui. Donc, 8 heures plus tard, c'est plus comme le projet que j'aimerais avoir. Oui, je comprends ce que vous dites. Je pense que la question est alors de savoir si cela devrait être une fonctionnalité permanente du harnais ou si c'est juste une chose que vous devriez avoir, disons, incitée lors de la construction du harnais, n'est-ce pas ? Donc, nous aurions cela, nous exécuterions ce harnais en boucle et nous aurions, nous pourrions lancer 10 générations de choses différentes et trois d'entre elles réussissent et sept échouent de manière aléatoire. Et puis nous nous asseoirions avec ces sept, les lirons, ajusterions les prompts du harnais principal, puis réessayerions, et ce jusqu'à ce que nous arrivions à un point où nous sommes assez satisfaits de le laisser fonctionner de manière entièrement autonome. Donc, en fin de compte, c'est toujours l'objectif final pour nous, par opposition à abandonner le harnais et dire : « D'accord, nous allons insérer un humain ici pour couvrir les problèmes de stabilité », mais plutôt à l'intégrer et à le graver dans le harnais lui-même dès le départ. L'avez-vous utilisé pour construire quelque chose comme, disons, un projet non neuf ou un projet de production, quelque chose dans du code existant, ou l'avez-vous utilisé pour des fonctionnalités réelles et les avez-vous vues jusqu'à la fin ? Je pense que cela s'étend principalement aux projets neufs. Je pense que pour les projets existants, vous avez peut-être besoin d'un peu plus de contrôle alors que vous commencez à construire vos propres rubriques et modèles. Euh, je veux dire, ce que nous voyons dans les projets existants, c'est que si vous regardez l'ensemble du cycle de vie du développement logiciel, ce ne sont pas seulement les aspects de codage que les gens commencent à utiliser quelque chose comme Cloud Code. Il pourrait s'agir, par exemple, d'une surveillance autonome, puis cela pourrait alimenter la génération d'un problème ou d'une demande de fonctionnalité qui pourrait ensuite alimenter un agent qui irait ensuite faire la pull request, puis il y a une revue de pull déjà en cours, puis vous examinez peut-être cela avant de fusionner. Donc, je pense qu'il existe d'autres façons d'automatiser l'ensemble du cycle de vie du développement logiciel dans un projet existant, mais je pense que ce modèle particulier, peut-être sans beaucoup de tests au sein de votre projet et en le personnalisant pour votre projet, est probablement plus adapté aux nouvelles applications. Avez-vous construit des applications neuves comme, je ne sais pas, des outils internes ou autre chose que vous avez utilisé, pas seulement une démo ? Oui, pour être franc, je ne peux pas vraiment parler des outils internes, mais une bonne anecdote à ce sujet était, comme beaucoup des nouvelles choses amusantes que vous voyez dans Cloud Code, quand je parle à l'équipe et que je travaille avec eux sur des choses, ils utilisent beaucoup les leçons de cela, même dans l'utilisation générale de Cloud Code, la façon dont ils demandent au modèle principal de lancer un sous-agent, disons, et d'aller après quelque chose, ou comme Andrew l'a dit, dans les boucles de surveillance et de correction de bugs, comme, quand on génère des corrections, devriez-vous avoir un évaluateur et un générateur distincts qui s'attaquent à la même chose ? Donc, beaucoup de ces principes s'appliquent. Euh, est-ce que c'est, comme, un pour un, peut-être pas, mais c'est comme prendre les bonnes parties de cela ou tout ce que vous pensez être applicable à un certain espace et domaine, puis l'exécuter à votre manière. Bonjour. Quand vous dites que vous avez besoin des traces, est-ce littéralement juste la sortie brute ou y a-t-il quelque chose de plus spécifique que vous lui avez demandé d'écrire dans un fichier, ce sont les types de choses qui m'intéressent et que je veux voir ? Non, vous devez tout lire. Lire tout. Je pense que c'est une compétence vraiment importante lors de la construction d'agents en général, c'est d'avoir autant d'empathie que possible avec le modèle. Euh, il y a eu une anecdote intéressante que nous avons utilisée lorsque nous avons construit, par exemple, le harnais d'agent pour Claude pour Chrome, qui est notre chose de navigation dans le navigateur. Euh, et nous avons mené cette expérience où, imaginez si vous essayiez de naviguer sur une page Web et de cliquer, où vous le faites essentiellement les yeux fermés et toutes les 10 secondes, vous l'ouvriez juste pour voir une page statique, puis vous la refermiez et deviez ensuite faire des choses. Euh, et vraiment vous mettre à la place du modèle, c'est un peu comme un ensemble de compétences empathiques que vous devez développer, et la seule façon de vraiment le faire est de passer autant de temps que possible avec ces modèles, mais aussi oui, de lire ligne par ligne en disant : oh, pourquoi a-t-il pensé cela ? Oh, je peux un peu comprendre pourquoi il l'a fait. Et ensuite, ajuster la façon dont vous lui donnez des instructions la prochaine fois pour qu'il fasse mieux. Euh, mais c'est pourquoi je pense que Claude pour Chrome est très bon, c'était vraiment juste passer beaucoup de temps en équipe à fermer les yeux et à essayer de naviguer sur des pages Web, par exemple. Donc, euh, oui. Mhm. Oui, et je pense qu'ensuite, en fait, prendre ces apprentissages et les mettre dans vos modèles de prompt ou votre Claude.ai MD ou construire une compétence ou généralement comprendre comment éviter ce type de comportement à l'avenir. Je sais que Claude code a maintenant une mémoire automatique pour les sessions, donc il mémorise constamment de petites choses au fur et à mesure. Euh, mais oui, vous pouvez apprendre assez rapidement en lisant certaines traces où les choses pourraient mal tourner. Cool. Devrions-nous conclure là ? Euh, je pense qu'il nous reste quelques minutes, mais nous serons là en général au cas où vous voudriez poser des questions ou simplement discuter. Mais sinon, merci d'être venus. C'est la session pour aujourd'hui. >> Merci.