Transcript
00:00:00Le mois dernier, c'était le "loop engineering", avant cela, le "context engineering", et aujourd'hui, la nouvelle
00:00:05tendance à la mode, c'est le "graph engineering". Mais s'agit-il de quelque chose à comprendre absolument, ou est-ce juste
00:00:11l'engouement autour de l'IA qui en fait trop en collant un titre ronflant sur un sujet bidon ?
00:00:17Dans cette vidéo, nous allons répondre à cette question, et alerte divulgâchage : ce n'est pas un sujet bidon.
00:00:23Le "graph engineering" ne s'appliquera pas à la moindre petite chose que vous concevez,
00:00:28mais c'est un concept que vous voudrez comprendre, surtout si vous utilisez
00:00:33des boucles complexes. Si c'est votre cas ou si ça le devient bientôt, vous devriez suivre la suite.
00:00:38Le "graph engineering" est simplement une extension ou une évolution du "loop engineering".
00:00:43Voyons donc très rapidement ce qu'est le "loop engineering" pour que nous soyons sur la même longueur d'onde.
00:00:47Toutes les boucles comportent trois parties. Premièrement, le déclencheur. Comment la boucle
00:00:54démarre-t-elle ? Idéalement, c'est autonome. Ça s'exécute chaque jour à une heure fixe ou selon un événement.
00:01:00L'étape deux, c'est la tâche. Que fait-elle exactement ? Et à l'étape trois, il faut un critère de réussite.
00:01:07On lui demande de faire quelque chose. Comment savoir si cela a été bien fait ? Car
00:01:13si ce n'est pas bien fait, je veux qu'elle s'exécute à nouveau depuis le début. Idéalement, tout s'exécute et les données
00:01:19sont stockées quelque part pour qu'on puisse y ajouter une forme d'auto-amélioration. Mais au strict minimum,
00:01:25il faut un déclencheur, une tâche à accomplir, puis la capacité de tester si ça a fonctionné,
00:01:30et tout cela doit être automatique. Pour notre exemple ici, nous avons une boucle qui génère un rapport matinal
00:01:35chaque jour pour nous. Nous avons cet agent IA. Il s'exécute chaque jour à 7 h. C'est notre déclencheur.
00:01:42Sa tâche est d'analyser plusieurs réseaux sociaux, YouTube, Twitter et Reddit, pour nous dénicher
00:01:47des informations sur l'IA et les tendances. Et je veux aussi qu'il vérifie mes e-mails. Une fois cela fait,
00:01:54je veux qu'il consolide les informations et génère un rapport. C'est la tâche. La réussite,
00:02:00dans ce cas, est un peu floue. Comment définir que le rapport a été correctement rédigé ?
00:02:05Dans ce cas, nous avons indiqué à la boucle que le rapport doit contenir ce type d'informations et faire une certaine longueur.
00:02:11Il doit inclure des liens. Nous lui avons donc donné des critères d'évaluation. Voilà pour notre
00:02:17boucle. Très simple. Elle est exécutée par un seul agent. Maintenant, comment transformer cela en graphe ?
00:02:25Comment passer du "loop engineering" au "graph engineering" pour exactement la même tâche ?
00:02:30Je veux toujours que notre rapport matinal soit généré chaque jour. Regardons cela, car à droite se trouve
00:02:35la version "graph engineering" de cette même tâche. Nous cherchons à obtenir le même rapport,
00:02:40mais nous avons augmenté le nombre d'agents en action. Plus précisément, nous sommes passés d'un agent qui fait
00:02:46tout à plusieurs agents accomplissant des tâches spécifiques et connectés les uns aux autres.
00:02:53Nous avons toujours le même déclencheur : l'exécution chaque matin à 7 h. Mais nous avons maintenant un agent
00:02:58qui surveille YouTube, un agent qui surveille Twitter, un autre pour Reddit et un pour
00:03:04les e-mails, et ainsi de suite. Chacun de ces agents va récupérer les informations requises, puis
00:03:09les synthétiser de son côté. Ensuite, il va transmettre sa synthèse à l'agent responsable du rapport,
00:03:17qui rassemble toutes ces données et les synthétise à nouveau pour former le rapport voulu. On pourrait
00:03:23même aller plus loin et ajouter un agent de révision chargé de contrôler
00:03:30de lui-même le rapport généré. Il le compare à nos critères de réussite pour déterminer
00:03:36s'il faut refaire une boucle ou si l'on peut passer à la diffusion. Et voilà
00:03:41le "graph engineering" en résumé. Analysons cela d'un peu plus près, car vous vous dites probablement :
00:03:48"On a juste ajouté plein d'agents, je ne vois pas bien la différence."
00:03:51En effet, nous avons ajouté d'autres agents, et il y a une raison à cela. Si le "graph engineering" est
00:03:58un peu plus complexe, ce n'est pas pour le plaisir de tout compliquer. C'est parce que
00:04:03chaque tâche a été confiée à un agent qui exécute sa propre version
00:04:09du "loop engineering". Qu'avions-nous auparavant ? Du "loop engineering", n'est-ce pas ? L'agent gérait
00:04:14toutes ces tâches et vérifiait les critères de réussite, mais il le faisait à un niveau très global
00:04:18en cumulant plein d'actions différentes. Avec le "graph engineering",
00:04:22nous avons fait un zoom sur une tâche spécifique. Cet agent-ci s'occupe exclusivement de la recherche
00:04:29et de l'analyse sur YouTube. Nous avons aussi structuré cela sous forme de boucle.
00:04:34Même réduite à une seule tâche, c'est toujours une boucle. Il y a un déclencheur, n'est-ce pas ?
00:04:39Ce sera toujours 7 h. Il y a une tâche : trouver des infos sur l'IA sur YouTube, puis
00:04:46les synthétiser. Et troisièmement, il y a des critères de réussite. En transformant cela
00:04:51en un système basé sur des graphes, nous pouvons être très précis sur ce qu'est la réussite à chaque
00:04:57étape du processus. On peut exiger par exemple au moins cinq sources, et
00:05:03une synthèse d'au moins deux paragraphes. Ou encore, pour chaque source et chaque information
00:05:09trouvée, expliquer son intérêt. Au lieu d'un processus de vérification
00:05:16très généraliste qui tente de regrouper toutes les validations dans une seule évaluation globale,
00:05:22nous avons tout découpé en étapes distinctes. Pourquoi cela devrait-il vous intéresser ?
00:05:27D'abord, cela améliore la qualité. Au lieu d'avoir un agent unique qui s'occupe de tout,
00:05:33chaque agent se concentre sur une seule tâche. Du strict point de vue de la dégradation du contexte,
00:05:40sa fenêtre de contexte reste relativement claire, contrairement à l'agent unique
00:05:44qui tente de tout faire en même temps. Le résultat est donc meilleur, et c'est aussi plus rapide.
00:05:51Au lieu d'un seul agent exécutant dix tâches à la suite, quatre agents travaillent en parallèle.
00:05:56C'est plus rapide, plus efficace, et il est plus facile de détecter un problème. Je peux identifier
00:06:03très vite si le souci vient de YouTube ou de Reddit, alors qu'il est parfois plus difficile
00:06:08de repérer l'origine exacte de l'erreur dans un processus global quand le rapport ne convient pas
00:06:15et doit être corrigé. Cela est possible car les critères de réussite
00:06:20peuvent être définis pour chaque sous-tâche. Voilà ce qu'est le "graph engineering" et pourquoi
00:06:27c'est important. Il ne s'agit plus d'un agent isolé, mais d'une série d'agents interconnectés de diverses
00:06:33manières. Les tâches sont découpées individuellement, de façon presque atomique. Grâce à cette
00:06:38approche atomique, nous pouvons être très précis pour chaque tâche concernant ce qu'elle doit accomplir
00:06:44et ce qui définit son succès. Chaque agent devient en fait une structure autonome
00:06:48de type "loop engineering". Nous avons simplement relié plusieurs boucles. La question qui se pose
00:06:54désormais est : quand faut-il utiliser le "graph engineering" plutôt que le "loop engineering" ?
00:06:58Soyons honnêtes, il n'est pas toujours nécessaire de créer un système multi-agents super complexe.
00:07:04Une simple boucle suffit bien souvent. Cependant, dans trois cas particuliers,
00:07:09vous devriez envisager une architecture en graphes. Le premier cas
00:07:15concerne les problèmes de contexte, en particulier la dégradation du contexte. Si je demande à
00:07:20un agent de boucler en continu et qu'à chaque itération il doit accomplir quatre, cinq, six
00:07:25ou huit tâches, au point que la fenêtre de contexte après chaque passage atteint
00:07:29300 000, 400 000 ou 500 000 jetons, il devient plus judicieux de répartir le travail.
00:07:36Rien ne justifie de subir une baisse de qualité due à un contexte saturé
00:07:41quand cela peut être évité. Le deuxième cas se présente lorsque nous avons besoin d'une révision indépendante.
00:07:48Dans une boucle bien conçue, il faut à un moment évaluer la réussite, c'est-à-dire appliquer les critères
00:07:55de validation. Posez-vous la question : l'agent qui a créé l'élément, dans ce cas le rapport,
00:08:01est-il le mieux placé pour évaluer son propre travail et dire s'il est bon ou non ? Pour un
00:08:07rapport matinal, c'est probablement acceptable, car ce n'est ni très complexe ni à haut risque.
00:08:13De plus, cela reste assez subjectif. En revanche, si les enjeux sont importants et nécessitent un regard extérieur,
00:08:18il devient préférable d'opter pour du "graph engineering",
00:08:24en faisant intervenir un agent totalement distinct pour contrôler ce qui a été produit.
00:08:28Il peut même s'agir d'un modèle différent, comme GPT 5.6.
00:08:32Quoi qu'il en soit, dans ce scénario d'orchestration multi-agents, le "graph engineering"
00:08:37prend tout son sens. Le troisième cas est la vitesse d'exécution. Dans ce contexte,
00:08:44une automatisation basée sur un graphe est très pertinente. Pourquoi faire analyser par un seul agent
00:08:48YouTube, puis Twitter, puis Reddit, puis Gmail ?
00:08:52Les outils modernes ne fonctionnent pas ainsi. Lors d'une recherche approfondie,
00:08:57les sources sont-elles analysées de manière séquentielle, une par une ? Non, une centaine de sous-agents
00:09:02sont déployés simultanément pour accomplir la tâche. D'ailleurs, la quasi-totalité des flux dynamiques
00:09:08avancés reposent sur une forme de "graph engineering", où plusieurs agents
00:09:13collectent les données pendant que d'autres s'occupent de la synthèse.
00:09:17D'autres agents réalisent une analyse critique des données rassemblées. Dans ces architectures
00:09:23complexes, on ne s'appuie jamais sur une boucle unique, mais sur un réseau d'agents
00:09:28fonctionnant en boucle. Mais comme je l'ai dit au début, la plupart de vos projets ne rentrent pas
00:09:34dans ces trois catégories. Si ce n'est pas le cas, le "graph engineering" n'est pas indispensable. C'est simplement un outil
00:09:39parmi d'autres. Il est parfois nécessaire, parfois non, mais il offre des avantages certains.
00:09:44À l'inverse, son inconvénient est d'ajouter des étapes et une infrastructure
00:09:48complexes à des processus qui n'en ont pas besoin. C'est sur cette réflexion
00:09:52que je vous laisse pour cette vidéo sur le "graph engineering". J'espère qu'elle vous a éclairés sur ce qu'est réellement
00:09:57le "graph engineering". C'est un sujet dont vous allez réentendre parler fréquemment.
00:10:01Mais si vous maîtrisez le "loop engineering", dites-vous simplement qu'il s'agit de plusieurs agents exécutant
00:10:07des boucles de façon coordonnée. Ils communiquent entre eux, ce qui améliore la qualité,
00:10:12accélère le traitement et simplifie le diagnostic des erreurs. Si vous hésitez
00:10:17sur la nécessité de cette méthode pour votre projet, la réponse est probablement non. Comme toujours,
00:10:24dites-moi ce que vous en avez pensé. N'hésitez pas à découvrir Chase AI Plus si vous souhaitez suivre ma
00:10:27Masterclass sur le développement d'agents. Je mettrai le lien ci-dessous. D'ici là, à très bientôt !