MarsDawn

Quatre modèles de conception d’agents et les documents que chacun vous remet

En mars 2024, Andrew Ng a décrit dans sa newsletter, The Batch, quatre modèles de conception pour les agents IA : la réflexion, l’utilisation d’outils, la planification et la collaboration multi-agents. On les aborde généralement du point de vue de ceux qui construisent les agents, comme des moyens d’obtenir de meilleurs résultats d’un modèle. Cet article se place de l’autre côté. Si vous utilisez un agent fondé sur l’un de ces modèles, qu’est-ce qui atterrit dans votre dossier, et que devez-vous lire en premier ?

Les quatre modèles sont d’Andrew Ng. Les documents que chacun tend à vous remettre, et ce qu’il faut y vérifier, relèvent de notre propre déduction. Il n’écrit sur aucun des deux points, et il ne plaide pas pour la relecture humaine dans cette série.

Les quatre modèles, en bref

Ng les décrit dans « Agentic Design Patterns Part 1 ». En résumé : avec la réflexion, le modèle relit son propre travail et l’améliore. Avec l’utilisation d’outils, il peut appeler des outils comme la recherche web ou l’exécution de code. Avec la planification, il élabore un plan en plusieurs étapes et l’exécute. Avec la collaboration multi-agents, plusieurs agents se répartissent le travail et en discutent.

Dans la partie 1, il montre le gain sur un benchmark de code, HumanEval, avec des résultats que son équipe a rassemblés auprès de plusieurs groupes de recherche : « GPT-3.5 (zero-shot) obtenait 48,1 % de réponses correctes. GPT-4 (zero-shot) fait mieux, avec 67,0 %. Cependant, le progrès de GPT-3.5 à GPT-4 est éclipsé par l’intégration d’un workflow agentique itératif. De fait, intégré à une boucle d’agent, GPT-3.5 atteint jusqu’à 95,1 %. » Ces chiffres portent sur un seul benchmark de code, et 95,1 % est le meilleur cas (« jusqu’à »). Ils montrent que les workflows d’agents peuvent améliorer le résultat. Ils ne disent rien de qui le vérifie.

À partir d’ici, les documents et les vérifications sont notre lecture, pas celle de Ng. Les vrais agents mélangent d’ailleurs les modèles. Un agent de code peut planifier, lancer des outils et relire son propre travail dans une même session : vous recevrez donc souvent les quatre types de fichiers.

1. Réflexion : un brouillon qui s’est déjà relu

L’article de Ng sur la réflexion la présente comme l’automatisation du retour qu’une personne donnerait sinon : « Et si l’on automatisait l’étape du retour critique, pour que le modèle critique automatiquement sa propre sortie et améliore sa réponse ? »

Ce qu’il tend à vous remettre : un document révisé, parfois avec une section d’autoévaluation ou des lignes comme « cas limites revérifiés ».

Ce qu’il faut vérifier : le résultat par rapport à votre demande, pas par rapport à l’autocritique de l’agent. L’autoévaluation peut se tromper à sa façon. Chip Huyen : « Un mode intéressant d’échec de planification provient d’erreurs de réflexion. L’agent est convaincu d’avoir accompli une tâche alors que ce n’est pas le cas. » Lilian Weng, sur son blog Lil’Log en juin 2023, alors chez OpenAI, à propos des modèles de l’époque : « Le manque d’expertise peut empêcher les LLM de connaître leurs défauts, et donc de bien juger de la justesse des résultats d’une tâche. » (Dans l’étude qu’elle décrivait, l’évaluation des résultats par un LLM et celle d’experts humains ne concordaient pas.) S’il est écrit « vérifié », vérifiez une chose vous-même.

2. Utilisation d’outils : un compte rendu de ce qui a tourné

Ce qu’il tend à vous remettre : un résumé de ce que l’agent a lancé ou recherché et de ce qui en est ressorti. « Suite de tests lancée : tout passe. » Un tableau de résultats. Des liens trouvés.

Le guide d’Anthropic présente les résultats d’outils comme la vérification que l’agent fait de lui-même : « Pendant l’exécution, il est crucial que les agents obtiennent à chaque étape une “vérité terrain” de l’environnement (comme les résultats d’appels d’outils ou d’exécution de code) pour évaluer leur progression. » Cette vérification se fait à l’intérieur de l’agent. Ce qui vous parvient, c’est le récit qu’il en fait.

Ce qu’il faut vérifier : que chaque affirmation remonte à une sortie que vous pouvez voir. Comparez un chiffre du résumé à la vraie sortie. Ouvrez l’un des liens.

3. Planification : plan.md

Ce qu’il tend à vous remettre : un plan, une spécification, une liste de tâches que l’agent coche au fur et à mesure.

Ng est franc sur ce modèle dans la partie 4 :

« D’un côté, la planification est une capacité très puissante ; de l’autre, elle produit des résultats moins prévisibles. D’après mon expérience, si j’arrive à faire fonctionner de façon fiable les modèles agentiques de réflexion et d’utilisation d’outils et à améliorer ainsi les performances de mes applications, la planification est une technologie moins mûre, et j’ai du mal à prévoir à l’avance ce qu’elle va faire. »

Il est aussi optimiste : « Mais le domaine continue d’évoluer rapidement, et je suis convaincu que les capacités de planification vont progresser vite. »

Ce qu’il faut vérifier : le plan avant qu’il ne s’exécute, avec la relecture en cinq minutes : structure, une affirmation, étapes irréversibles, diagrammes, périmètre. Si l’agent réécrit le plan en cours de route, comparez-le à la version que vous avez approuvée ; s’il est dans git, git diff plan.md montre ce qui a changé. Dans MarsDawn, l’onglet Plan montre la structure d’un long plan, et un plan réécrit se recharge sans vous faire perdre votre position, tant que vous n’avez pas de modifications non enregistrées.

4. Collaboration multi-agents : plusieurs fichiers, plusieurs auteurs

Ce qu’il tend à vous remettre : une spécification d’un agent, des notes d’implémentation d’un deuxième, une relecture d’un troisième, et des résumés qui circulent entre eux. Parfois, chacun travaille dans sa propre branche ou son propre worktree.

Ce qu’il faut vérifier : les passations. Là où un agent résume le travail d’un autre, cherchez une exigence qui ne serait pas passée. Cherchez deux fichiers qui se contredisent, et décidez lequel fait foi avant que quiconque ne s’appuie sur l’autre. Dans MarsDawn, ouvrez le dossier partagé avec Fichier ▸ Ouvrir un dossier… (⇧⌘O) : les nouveaux fichiers apparaissent dans l’onglet Fichiers en une seconde environ, à mesure que les agents les écrivent, et pour un checkout git, l’en-tête indique la branche ou le worktree, pour que deux fenêtres affichant le même nom de fichier sur des branches différentes ne se ressemblent pas. Quand le résultat doit parvenir à des personnes qui ne lisent pas le Markdown, Partager des PDF exportés couvre cette étape.

En un coup d’œil

Modèle (Ng)Ce qu’il tend à vous remettre (notre déduction)À lire en premier (notre suggestion)
RéflexionUn brouillon révisé, peut-être avec une autoévaluationLe résultat par rapport à votre demande ; vérifier un « vérifié »
Utilisation d’outilsUn compte rendu de ce qui a tourné et de ce qui en est ressortiUne affirmation remontée jusqu’à la vraie sortie
Planificationplan.md, une spécification, une liste de tâchesLa relecture en cinq minutes, avant l’exécution
Collaboration multi-agentsPlusieurs fichiers de plusieurs agents, peut-être sur plusieurs branchesLes passations, et le fichier qui fait foi

Aucun des auteurs cités ici ne mentionne MarsDawn, et aucun ne le recommande, pas plus qu’aucun autre outil Markdown. MarsDawn n’embarque aucun modèle d’IA : il ne sait pas quel modèle a produit un fichier, et il ne fera pas ces vérifications à votre place. Il garde les fichiers lisibles pendant que vous les faites.

Essayer

MarsDawn est sur le Mac App Store. Il existe aussi l’outil en ligne de commande gratuit marsdawn :

brew install redtear1115/tap/marsdawn

Il exporte le Markdown en PDF sans l’app : voir Markdown en PDF.

Ligne de commande · À savoir avant d’acheter : Ce que MarsDawn ne fait pas

Pour aller plus loin

Sources