Atomisme et bottom up dans l’intelligence générative avec un LLM (2023)

gistfile1.txt

Puisque le contexte de travail est toujours limité lorsqu’on travaille avec un LLM, il est difficile de construire un projet complexe puis de fignoler les détails tout en gardant en contexte l’ensemble du système.

Il est nécessaire d’enchaîner les prompts en procédant avec une sorte de tree-shaking de tout ce qui est une piste vers un détail parallèle qui ne nous intéresse pas.

Dans la perspective de laisser la machine créer complètement un projet, on pourrait imaginer qu’une des premières étapes qu’effectuerait un bot serait de se questionner sur ce que sont les éléments qui hiérarchiquement peuvent constituer le projet final, en partant d’une sorte d’atome.

Exemple: Nous créons un site web. Le site est fait de pages, qui contiennent des sections, qui contiennent des widgets, qui sont constituées d’éléments plus basiques, i.e. des HTMLElement, lesquels peuvent avoir un style ou un thème, et peuvent recevoir ou émettre des valeurs selon un principe de binding et d’émission.

Pour respecter l’idée de tree-shaking, il faut en arriver à créer des éléments atomiques qui ne seraient pas dépendant des autres éléments ni des contextes parents.

Ces éléments, comme dans l’exemple, devraient donc être prêts à être modifiés par l’extérieur.

Top down

Le défi est de pouvoir bien choisir les atomes lors de l’élaboration d’éléments parents (i.e. widgets).

C’est pour ça qu’après avoir bien défini abstraitement ce que sont hiérarchiquement les éléments nécessaires pour constituer le projet, il faut partir de l’élément le plus haut niveau, puis le fractionner en éléments plus primitifs. Durant cette étape, il est crucial de bien définir les attentes envers un élément primitif pour qu’il réponde au maximum au besoin de l’élément parent.

Nous avons donc: 

Ébauche de prompt initial, définit la construction générale d’un TYPE de projet, avec tous les détails techniques (framework)

Je dois créer des projets de type X. [Liste des modalités techniques: i.e. je veux fonctionner sans framework, je veux utiliser le shadow dom pour créer de nouveaux éléments] Quels sont les éléments hiérarchiques qui peuvent m’aider à construire ce projet [etc]. [Le prompt contient une partie théorique qui découle de l’explication plus haute]

Le prompt initial est conservé dans le contexte et s’ajoute un deuxième prompt.

Ébauche de prompt de construction concrète du TYPE d’objet

Je dois donc créer un projet concret qui consiste en [description détaillée]. Selon la hiérarchie théorique d’éléments listée au-dessus, quels sont les éléments et sous-éléments nécessaires dans l’élaboration de ce projet précis. Expose-les sans pour autant les développer. Liste pour chaque niveau d’abstraction tout ce dont nous avons besoin, et cette liste concrète sera basée sur les éléments et sous-éléments théoriques.

Assemblage

Nous arriverons à un blocage logique si nous ne nous posons pas la question: comment le LLM pourra-t-il comprendre comment assembler le tout. Une étape d’élaboration est nécessaire pour avoir un plan pour savoir comment assembler les choses. C’est pour cela qu’il faut pour chaque niveau hiérarchique définir comment est représentée la constitution de l’élément parent à partir de ses éléments primitifs.

Ça signifie que nous avons:

Un prompt pour réfléchir à la quantité de couches que requiert un type de projet spécifique - incluant toutes les spécifications autour de son élaboration - afin d’adopter une approche “atomique” et pouvoir développer indépendamment les composants.

Un prompt qui sert à définir - pour chaque couche - la façon de représenter sous forme d’écriture l’assemblage des éléments primitifs en un élément parent.

Un prompt qui sert à lister pour un projet précis tous les éléments nécessaires.

Puis récursivement, des prompts pour écrire le code des éléments les plus primitifs.

*** 
La récursivité peut également inclure un second niveau, au besoin. Et à continuer de théoriser.