Anthropic vient de corriger le plus grand défaut de l'ingénierie des graphes
AAI LABS
컴퓨터/소프트웨어AI/미래기술
Transcript
00:00:00Un nouveau terme fait le buzz actuellement : la « graph engineering », et tout le monde en parle sur X.
00:00:04Avant les graphes, on ne jurait que par la « loop engineering », où l'on donnait un objectif à l'agent qui travaillait
00:00:09en autonomie. Mais avec les graphes, le travail est plus rapide et couvre bien plus de terrain en une fois
00:00:14qu'une boucle ne pourrait jamais le faire. Il y a pourtant un problème majeur. Une seule erreur dans une petite partie du
00:00:18graphe perturbe l'ensemble du résultat final, et c'est difficile à identifier car tout ce que vous obtenez
00:00:23à la fin, c'est le produit fini. Anthropic vient donc de publier une solution qui résout exactement
00:00:27ce problème et permet à vos graphes de fonctionner sans planter. Si vous êtes nouveau ici, nous sommes une entreprise
00:00:32de logiciels, et voici notre chaîne AI Labs, où nous vous montrons comment optimiser votre entreprise grâce à l'IA,
00:00:37et si vous n'en avez pas, vous pouvez utiliser ces compétences pour être rémunéré en l'optimisant pour quelqu'un
00:00:42d'autre. Dans cette vidéo, nous allons passer en revue la graph engineering pour ceux qui ne la connaissent pas
00:00:46et vous donner le correctif exact suggéré par Anthropic. Avant de vous expliquer la graph engineering, vous
00:00:52devez comprendre ce qu'est réellement la loop engineering. Si vous le savez déjà, vous pouvez sauter cette section.
00:00:56Une boucle est en fait un cycle de travail que vous confiez à l'agent. Au lieu d'écrire un prompt
00:01:02pour chaque étape, vous lui indiquez le but ultime à atteindre, et il y parvient de lui-même
00:01:07en s'ajustant en cours de route. Nous les utilisons énormément dans nos propres workflows. Nous avons d'ailleurs une vidéo complète
00:01:12sur la loop engineering, où nous avons approfondi les différentes façons de les configurer, mais les boucles
00:01:17évoluent désormais vers ce qu'on appelle des graphes. Le problème avec les boucles vient de leur structure même.
00:01:22Une boucle effectue une tâche, puis une étape de vérification intervient pour s'assurer que le résultat est bien conforme.
00:01:27Une fois cette étape validée, la suivante commence. Tout s'exécute en ligne droite, de sorte que chaque étape
00:01:32attend la précédente, même lorsque les deux n'ont aucun rapport entre elles. La graph engineering
00:01:37corrige précisément cela. Au lieu de s'exécuter en ligne droite, un graphe divise la tâche principale en sous-parties
00:01:42plus petites, et chaque partie se voit attribuer son propre agent. Le premier avantage est la vitesse, car plusieurs
00:01:47agents traitent le travail en parallèle, au lieu qu'un seul agent s'échine sur la totalité. Et diviser le
00:01:52travail ainsi réduit aussi un peu les coûts, car vous pouvez choisir sur quel modèle s'exécute chaque agent.
00:01:56Vous arrêtez ainsi de gaspiller votre modèle le plus cher sur des parties qui n'ont jamais nécessité autant
00:02:01d'intelligence. Mais cela concerne le coût par agent, pas le coût global. Un graphe consomme bien plus
00:02:07de tokens qu'un agent unique ne le fera jamais, car vous avez tout un ensemble d'agents qui fonctionnent en même temps.
00:02:12Si vous utilisez des graphes, attendez-vous à atteindre vos limites bien plus vite que d'habitude, donc vous ne pouvez
00:02:17pas vraiment mettre cela en place avec les forfaits à 20 $ de ClaudeCode et Codex. Maintenant, si vous utilisez ClaudeCode,
00:02:22ce n'est probablement pas tout à fait nouveau pour vous, car vous avez déjà vu un graphe : le workflow
00:02:27dynamique. Un workflow dynamique prend la tâche confiée et la répartit sur un ensemble de sous-agents,
00:02:33ce qui est exactement ce que fait un graphe. Avant de voir les formes qu'un graphe peut prendre, vous devez
00:02:38savoir de quoi il est constitué. Chaque graphe repose sur deux éléments : des nœuds et des arêtes. Un nœud est
00:02:44une tâche individuelle au sein du projet global, et il s'exécute de façon autonome. C'est un agent
00:02:49qui accomplit une tâche dans sa propre fenêtre de contexte isolée et fait son rapport. Ce qui relie toutes ces tâches
00:02:55séparées, c'est l'arête. L'arête contrôle le transfert des données d'un nœud à l'autre, afin que le résultat d'un agent
00:03:01parvienne au bon agent, au bon moment. Chaque nœud doit donc être connecté au reste du graphe
00:03:06d'une manière ou d'une autre. On le voit bien avec un groupe d'agents examinant tous le même travail. Aucun
00:03:10d'entre eux n'attend les autres. Mais ils sont tous partis de la même base, et chacun de leurs rapports alimente
00:03:15le même endroit à la fin : voilà de quoi est fait un graphe. Voyons maintenant les formes que ces éléments
00:03:20peuvent adopter. La première est une forme déjà présentée sur cette chaîne, mais nous nous étions trompés
00:03:25de nom à l'époque. Nous l'avions appelée une boucle, car la graph engineering n'existait pas encore. Mais
00:03:30ce que nous avions en réalité, c'était un graphe exécuté en boucle, et sa forme était un losange. Une tâche initiale
00:03:35se divise en plusieurs sous-agents travaillant en parallèle, puis ils se rassemblent vers un seul
00:03:41agent qui synthétise leurs découvertes en une réponse unique. Il y a aussi le graphe à regroupement sur barrière (fan-in),
00:03:46qui est la forme idéale lorsqu'un élément doit être évalué sous plusieurs angles à la fois. La phase de dispersion
00:03:51La phase de divergence envoie le même problème à un groupe d'agents, et chacun l'examine sous un angle différent.
00:03:56Rien ne progresse tant que chacun de ces agents n'a pas rendu son rapport, et c'est seulement après cela
00:04:00que leurs correctifs sont appliqués. Il existe plein d'autres structures. Mais toutes ces formes reposent sur
00:04:05la même chose : la vérification. Si ces contrôles ne sont pas bien configurés, chaque agent qui intervient
00:04:10ensuite ne fait que construire par-dessus une erreur. Mais avant de parler de vérification, n'hésitez pas
00:04:15à vous abonner à la chaîne et à cliquer sur le bouton d'interaction. Ce petit soutien compte énormément pour nous.
00:04:20Quand on gère toute une flotte d'agents, des problèmes inédits surviennent, absents avec un agent unique.
00:04:25Le principal souci réside dans la quantité de travail. Tous travaillent simultanément, donc une montagne
00:04:30de données revient d'un coup, ce qui rend la révision finale très difficile. L'autre problème est que
00:04:34vous ne voyez pas ce qui s'est passé. En cas de pépin, impossible de savoir ce qui l'a provoqué.
00:04:39Désormais, tous les agents vérifient ce qu'ils écrivent, qu'on le leur demande ou non. Si vous développez du code,
00:04:44l'agent exécute vos tests et intercepte les erreurs renvoyées. Mais cela ne repère que les erreurs majeures.
00:04:49Cela ne contrôle pas la façon dont le code est rédigé, ce qui est crucial car si Claude
00:04:53continue de coder ainsi, cela créera des problèmes plus tard. Il existe quelques outils intégrés
00:04:58pour cela dans Claude code. Le premier est la compétence « verify », qui analyse le code de A à Z
00:05:03et confirme qu'il se comporte comme prévu. Le deuxième est le chaînage d'outils (tool chaining),
00:05:08où l'agent exécute différents outils pour vérifier. Claude sait déjà utiliser les outils qui
00:05:13contrôlent votre travail, il lit donc les erreurs renvoyées et les corrige de lui-même. Il peut aussi deviner les
00:05:18commandes exactes de votre projet. Mais les inscrire dans votre fichier Claude.md lui évite de devoir
00:05:24les chercher à chaque fois. Enfin, le troisième est la compétence de revue de code, qui vérifie le code
00:05:29par rapport à un ensemble de normes. Tous les agents n'en intègrent pas, mais vous pouvez demander au vôtre d'en créer
00:05:33une s'il n'en a pas. Cela dit, la vérification la plus efficace reste celle que vous configurez vous-même,
00:05:38plutôt que de compter uniquement sur les outils intégrés. Le moyen le plus rapide de créer une compétence de vérification
00:05:44est le plugin « skill creator » dans Claude code. Vous pouvez d'ailleurs utiliser cette compétence
00:05:49de Claude code dans Codex également. Lancez la commande des plugins, cherchez « skill creator » et installez-le.
00:05:54À partir de là, deux options s'offrent à vous. L'installer au niveau utilisateur, pour l'avoir sous la main quel que soit
00:05:58le dossier de travail. Ou l'installer uniquement pour le projet en cours.
00:06:03S'agissant d'une compétence appelée à servir constamment, nous avons choisi le niveau utilisateur. Ensuite,
00:06:07rechargez les plugins avec la commande slash et le skill creator est prêt à l'emploi. Expliquez-lui
00:06:12ce que vous voulez créer : c'est le moment de décrire le type de vérification que vous recherchez
00:06:17vraiment. Nous utilisons principalement une compétence de revue pour comparer le travail fini avec la demande
00:06:22initiale. C'est d'autant plus crucial dans un graphe que chaque agent ne voit que sa propre partie.
00:06:28Cela lui permet de vérifier ce morceau par rapport aux exigences d'origine. Mais une compétence ne vaut
00:06:32que ce que vaut le modèle qui l'exécute. Lors de la création du système de vérification de l'interface
00:06:37de notre site communautaire, nous avons fait tourner le relecteur sur Haiku car c'est économique et la tâche semblait
00:06:43assez simple. Il est revenu avec une longue liste de problèmes. À en juger par le nombre de remarques, il semblait
00:06:47avoir fait un excellent travail. Puis nous avons relancé exactement le même sur Opus, qui a signalé bien moins de choses.
00:06:53Cela semblait être le pire résultat, jusqu'à ce qu'on lise le raisonnement. Une grande partie de ce que Haiku rapportait
00:06:58était des éléments laissés là intentionnellement. La plupart de ses remarques étaient donc totalement superflues.
00:07:03Opus l'avait compris grâce au code environnant, alors que Haiku l'avait complètement manqué. La revue bon marché
00:07:08ne nous avait rien fait gagner, car il fallait maintenant relire la revue elle-même. Intégrez cela
00:07:13dans un graphe où une série de nœuds contrôlent leur travail avec cette même compétence : vous aurez
00:07:18des agents qui gâchent du temps et des tokens à corriger des choses qui fonctionnaient très bien. Et comme cela se produit
00:07:23sur plusieurs agents séparés à la fois, impossible de savoir lequel a commencé.
00:07:27Le modèle choisi ne détermine donc pas seulement la qualité de la revue, mais celle
00:07:31de tout le graphe. Le nœud qui évalue est le seul endroit où économiser des tokens peut tout faire échouer.
00:07:37L'autre décision concerne la méthode et le moment où cette compétence est invoquée, ce qui les divise
00:07:41en trois catégories. Mais avant d'entrer dans les détails, un mot de notre sponsor.
00:07:46Si vous avez déjà extrait des données en direct du Web, vous savez que le scraping est un vrai calvaire :
00:07:51on se bat contre les captchas et les limites de débit, on galère avec les proxys et on répare des structures qui cassent
00:07:56dès la mise en ligne. C'est pourquoi nous utilisons SERP API, qui résout tout cela pour vous laisser vous concentrer sur le développement.
00:08:01Un seul appel API suffit : vous envoyez une requête et recevez un objet JSON propre contenant exactement les données voulues,
00:08:07avec une disponibilité de plus de 99,9 % et un temps de réponse d'environ 1,2 seconde. Pour vos agents IA, vous pouvez
00:08:14connecter l'API Google Search à un agent qui a besoin d'infos récentes, ou utiliser l'API Google Scholar pour
00:08:20des articles scientifiques complets avec métadonnées, ce qui explique pourquoi tant d'agents en production l'utilisent. Profitez de
00:08:25250 crédits gratuits via le lien en description ou en scannant le QR code à l'écran. Merci à SERP API de
00:08:32sponsoriser cette vidéo. Le premier type est la compétence autonome (standalone), qui ne s'exécute que si vous
00:08:37la lancez manuellement. Elle est conçue pour analyser en profondeur un élément existant, et repasser proprement
00:08:42sur un résultat final. C'est pourquoi elle ne doit pas se déclencher après chaque passage : cela consommerait inutilement
00:08:48des tokens pour une grosse révision de travaux non terminés. Nous avons par exemple utilisé la
00:08:53« thermonuclear code review » de Cursor. Elle déploie plusieurs agents et envoie chacun inspecter le code sous un angle
00:08:59de sécurité spécifique. Toutes les remarques sont centralisées au même endroit pour traiter les correctifs
00:09:04ensemble ; c'est le genre de contrôle qu'on ne lance qu'une fois l'application terminée. Pour en créer une, il vaut mieux passer par
00:09:10le skill creator que de la prompter directement, car le résultat est testé et donc plus facile
00:09:15à valider. Précisez dans le prompt quelle zone doit être révisée, et mentionnez bien que la revue
00:09:20doit être exhaustive pour obtenir une analyse approfondie et non un simple survol. Mais une compétence
00:09:26autonome ne sert à rien à un nœud en cours de travail, puisqu'il faut la lancer soi-même. C'est là qu'interviennent
00:09:31les compétences intégrées (embedded skills). Elles s'exécutent automatiquement au sein du workflow en cours, sans action
00:09:36de votre part. Vous pouvez en créer une qui se déclenche dès que quelqu'un demande une nouvelle fonctionnalité. Elle vérifie
00:09:41que chaque composant créé respecte les règles définies dans la compétence, et empêche la fin de
00:09:45l'implémentation tant que ces règles ne sont pas validées. Vous pouvez concevoir vos propres compétences intégrées,
00:09:50mais vous ne pouvez pas automatiser l'appel d'une compétence préinstallée, comme la compétence
00:09:54« verify » évoquée plus tôt. Leurs instructions sont ancrées dans le produit et vous n'y avez pas accès.
00:10:00Pour créer la vôtre, demandez au skill creator de lancer des étapes de vérification après chaque ajout de fonction,
00:10:05en lui spécifiant de tester la fonctionnalité de bout en bout pour vérifier que le nouveau travail ne casse rien d'existant.
00:10:10Claude génère alors la compétence qui, étant issue du skill creator, inclut les références et scripts
00:10:16structurés et testés au cours du processus. Pour vérifier une fonctionnalité, Claude utilise par défaut
00:10:21des tests par navigateur : il contrôle l'interface en ouvrant un navigateur Chrome complet, charge la page et prend
00:10:26des captures d'écran. Si vous utilisez Puppeteer ou Playwright (les outils les plus répandus
00:10:31pour piloter un navigateur automatiquement), ils fonctionnent de la même manière. Mais Chrome est réputé pour consommer beaucoup de mémoire
00:10:36et être gourmand en ressources ; pour vérifier une page à répétition dans un workflow, sa lenteur finit
00:10:41par vous faire perdre un temps précieux. Il existe une méthode plus légère : Chrome Headless Shell.
00:10:46C'est une version épurée du navigateur dont on a retiré les éléments superflus. L'agent accède toujours
00:10:52à la page et prend ses captures d'écran de la même façon, mais il s'exécute bien plus rapidement
00:10:57qu'un Chrome classique. Vous pouvez intégrer cela directement dans la compétence de vérification créée.
00:11:02Chaque fonctionnalité développée par l'agent est alors contrôlée visuellement sans réglage préalable à chaque fois.
00:11:07À part cela, la compétence que nous utilisons le plus dans notre propre workflow est « second opinion »,
00:11:12et la raison est simple : l'agent qui a créé un élément est le pire choix possible pour le relire.
00:11:17Il évalue son travail à partir du même contexte que celui utilisé pour le concevoir, la révision en découle donc directement.
00:11:23Une session Claude toute neuve n'a rien vu de tout cela. Elle apporte un regard impartial et donne une réponse directe.
00:11:28Claude intègre bien un conseiller natif qui fait un peu la même chose, mais il lit le chat en cours
00:11:33et hérite donc de tout ce contexte. « Second opinion » s'utilise quand on veut une révision sans cet historique.
00:11:38Elle démarre une autre session Claude depuis celle en cours grâce au fanion -p, qui lance
00:11:43une session Claude code entièrement séparée en arrière-plan en lui transmettant un prompt sur lequel travailler.
00:11:48Quelques points sont toutefois à garder en tête. Comme cela lance une session totalement distincte,
00:11:53le temps de réponse est très long, et le choix du modèle compte ici plus qu'ailleurs, car l'objectif est d'obtenir
00:11:57une seconde lecture plus pertinente. Il est donc judicieux d'ordonner à Claude d'ouvrir cette session
00:12:02sur Opus. Cela offre à chaque nœud du graphe un moyen de faire vérifier son travail par une instance
00:12:07externe. Cependant, une seule compétence ne peut pas tout couvrir. Pour relire un projet correctement,
00:12:12il faut l'examiner sous plusieurs angles, chacun ayant ses propres critères d'évaluation. On ne peut pas
00:12:18entasser tous les types de contrôle dans une seule compétence, car l'agent aura trop de directives et ses résultats
00:12:22empireront au lieu de s'améliorer. Il faut donc créer une compétence distincte par angle et les enchaîner.
00:12:27L'équipe d'Anthropic fonctionne de la même manière : elle combine la compétence de revue de code avec la compétence
00:12:33« simplify » et la compétence « verify », toutes trois désormais intégrées à Claude code. De plus,
00:12:38elle utilise sa propre compétence de design, qui compare l'interface au fichier design.md (le document
00:12:43regroupant chaque décision de design du produit). On obtient ainsi une révision sous quatre angles au lieu d'un seul.
00:12:49Le résultat est identique : un ensemble de compétences couvrant chacune un aspect précis. Mais il ne suffit pas
00:12:54de demander à l'agent de toutes les lancer en même temps. Il faut une compétence supérieure qui chapeaute les autres :
00:12:59une compétence orchestratrice dont le seul rôle est d'exécuter les autres compétences. Elle instancie un agent pour
00:13:04chaque compétence de relecture disponible et lui confie sa tâche. Tous relisent en parallèle dans leurs
00:13:09fenêtres de contexte respectives, puis la compétence regroupe l'ensemble des remarques dans un rapport unique exploitable
00:13:15par les agents correcteurs. Ainsi, lors de la création d'un graphe, il suffit d'indiquer dans le prompt
00:13:20qu'il doit utiliser cette compétence unique. Chaque nœud généré charge cette compétence et toute l'analyse
00:13:25se déploie automatiquement. Nous avons préparé un document détaillant toutes les façons de configurer
00:13:30les vérifications pour les graphes. Ce document ainsi que toutes les compétences présentées dans cette vidéo sont disponibles
00:13:35sur AI Labs Pro, notre communauté. Si vous appréciez notre travail et souhaitez soutenir
00:13:40la chaîne, c'est le meilleur moyen de le faire. Le lien est dans la description. Nous voici arrivés à la fin
00:13:45de cette vidéo. Si vous souhaitez soutenir la chaîne et nous aider à continuer à produire ce type de contenu, vous pouvez le faire
00:13:50en utilisant le bouton Super Merci ci-dessous. Comme toujours, merci de nous avoir suivis et à la prochaine !
00:13:55Comme toujours, merci de votre visionnage et à bientôt dans une prochaine vidéo.
00:14:00Prenez soin de vous et à la prochaine !