Après 6 mois de travail sur un outil de développement CodeGen (pilote GPT), voici ce que j'ai appris

Au cours des 6 derniers mois, j'ai travaillé sur GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ) pour comprendre à quel point nous pouvons réellement automatiser le codage avec l'IA, j'ai donc voulu partager nos apprentissages jusqu'ici et jusqu'où il peut aller.

Lorsque j'ai commencé à créer GPT Pilot, j'ai écrit cet article de blog sur la façon dont il est envisagé. Maintenant, je souhaite partager ma réflexion révisée et aborder ce qui a fonctionné et ce qui n'a pas fonctionné.

Enfin, vous verrez des exemples d'applications créées avec GPT Pilot et comment vous pouvez créer une application avec un véritable programmeur de paires d'IA.

Quelle est l’idée derrière le pilote GPT ?

GPT Pilot est considéré comme un véritable développeur d'IA – et non comme un outil de saisie semi-automatique ou un chatbot . C'est plutôt un développeur qui crée un plan sur la façon dont votre application ou fonctionnalité doit être créée et commence à coder. Il veut effectuer la majeure partie du codage par lui-même, mais lorsqu'il est bloqué, qu'il a besoin de clarifications sur les exigences données, ou qu'il nécessite une révision du code, il vous demande de l'aide.

L’IA est-elle comme un développeur junior ? Ou…

Je vois souvent des outils basés sur CodeGen GPT-4 qui disent qu'ils construisent un développeur junior d'IA.

D'une manière ou d'une autre, j'ai toujours eu un problème avec cela, car lorsque j'utilise ChatGPT pour le codage, cela me donne des réponses et des idées que seule une personne très expérimentée pourrait donner – quelque chose qu'absolument aucun développeur junior ne serait capable de comprendre. Pourtant, aucun LLM ne peut créer une application aussi bien qu'un développeur senior, mais les connaissances de GPT-4 sur le codage dépassent largement celles de n'importe quel développeur junior.

Je dirais que GPT-4 possède tellement de connaissances sur chaque partie du développement logiciel qu'il est le développeur le plus expérimenté au monde, mais avec la mémoire d'un poisson rouge. Je l'imagine comme un robot surhumain qui se tient juste au milieu d'une pièce et ne peut effectuer qu'une seule petite action à la fois, mais il ne peut pas combiner plusieurs actions et travailler de manière répétitive. Vous devez lui dire exactement ce qu'il doit faire ensuite.

C'est ce que nous recherchons avec GPT Pilot : nous voulons créer un cadre de réflexion pour le LLM qui permet à ce robot surhumain de travailler en permanence en révisant ses actions précédentes, d'avoir une boucle de rétroaction et de déterminer ce qu'il doit faire ensuite. pour atteindre l'objectif final, qui est de créer une application prête pour la production.

Dans l'article de blog que j'ai mentionné ci-dessus , j'ai décrit les principaux piliers sur lesquels GPT Pilot a été construit. Mais ceux-ci ont un peu changé en fonction des apprentissages de notre équipe, voici donc les piliers révisés :

1. Un humain est nécessaire pour superviser l'IA, non seulement parce que l'IA n'est pas assez bonne, mais aussi parce que vous souhaiterez peut-être changer la façon dont quelque chose fonctionne ou s'en occupe après sa mise en œuvre. Il est courant qu'un développeur ou un chef de produit, une fois qu'il voit à quoi ressemble une implémentation, décide de la modifier.

   
   

2. Ou alors, vous réalisez qu'il y a plus de cas extrêmes que prévu initialement et pensez qu'il est plus facile de refactoriser votre implémentation actuelle que de résoudre tous les problèmes. Le problème est lorsque vous terminez l’intégralité de l’application et que vous essayez ensuite de la refactoriser – c’est à ce moment-là que cela devient beaucoup plus difficile car chaque modification aura un impact sur toutes les autres fonctionnalités.

   
   

   D'un autre côté, si vous effectuez le refactor avant de valider vos modifications, vous pourrez passer aux fonctionnalités suivantes en plus d'un code bien écrit. C'est pourquoi il est crucial pour un développeur d'IA d'avoir un humain au courant chaque fois qu'une tâche est mise en œuvre .

   
   

   De cette façon, l'humain peut examiner la mise en œuvre de chaque tâche (tout comme une révision de code avant de fusionner un PR) avant que GPT Pilot ne passe à la tâche suivante. Si un humain indique à GPT Pilot ce qui ne va pas, il sera beaucoup plus facile de résoudre les problèmes au sein de la tâche elle-même. En même temps, le LLM présente le contexte de ce qui doit être fait dans le cadre de la tâche et de ce qui a été fait jusqu'à présent.

   
   

3. L’IA peut répéter ses propres erreurs. J'ai le sentiment que beaucoup de gens jugent la capacité de ChatGPT à écrire du code par la façon dont il fonctionne la première fois que vous lui demandez de coder quelque chose. S'il ne produit pas de code fonctionnel, beaucoup penseront que ce n'est pas impressionnant. En réalité, les humains n’écrivent presque jamais de code fonctionnel du premier coup . Au lieu de cela, vous écrivez du code, l’exécutez, voyez les erreurs et itérez. C'est exactement ce que GPT Pilot permet à GPT-4 de faire : après avoir écrit le code, GPT Pilot peut exécuter le code, prendre la sortie et demander au LLM si la sortie est correcte, si quelque chose doit être corrigé et si oui, comment .

   
   

4. Le développement de logiciels peut être orchestré . Il existe de nombreuses routines répétitives que tous les développeurs suivent lors de la création d'une application. L'une des routines peut être : écrire du code, l'exécuter, lire les erreurs, modifier le code, le réexécuter, etc. Une autre de niveau supérieur peut être : prendre une tâche, l'implémenter, tester l'implémentation (répéter jusqu'à ce que tous les tests réussissent). , envoyez-le pour examen, corrigez les problèmes (répétez jusqu'à ce que le réviseur approuve) et déployez. Beaucoup de ces routines peuvent être orchestrées si nous avons un décideur intelligent dans la boucle (comme un LLM).

   
   

5. Le processus de codage n'est pas une ligne droite . Lorsque nous avons créé la première version de GPT Pilot, nous pensions qu'elle devrait parcourir les tâches, implémenter le code, le corriger et passer à autre chose. En réalité, vous ne progressez pas continuellement lorsque vous codez une application : vous réécrivez votre code tout le temps.

   
   

   Parfois, vous refactorisez la base de code car, après la mise en œuvre initiale, vous réalisez qu'il existe une meilleure façon d'implémenter quelque chose. D’autres fois, vous le faites en raison d’un changement dans les exigences. Comme je l'ai mentionné au point 1, après avoir constaté qu'une solution ne fonctionne pas, vous devez parfois annuler un certain nombre de modifications, réfléchir à une solution alternative au problème et essayer de le résoudre de cette façon.

   
   

   Pour que GPT Pilot, ou tout autre développeur d'IA, fonctionne à grande échelle, il doit disposer d'un mécanisme qui lui permettra de revenir en arrière, de choisir une voie alternative et de réimplémenter une tâche.

Qu’avons-nous appris ?

Les LLM, en général, sont une nouvelle technologie que tout le monde essaie de comprendre – comment elle fonctionne, ce qui peut être amélioré, comment réaliser une ingénierie rapide appropriée, etc. Notre approche consiste à nous concentrer sur la création de la couche d'application au lieu de travailler sur l'obtention de Des LLM pour produire de meilleurs résultats .

Le raisonnement est que les LLM s'amélioreront et que si nous passons des semaines à optimiser une invite, le problème pourrait être complètement résolu avec la nouvelle version de GPT.

Au lieu de cela, nous nous concentrons sur ce à quoi devrait ressembler l'expérience utilisateur et sur les mécanismes nécessaires pour contrôler le LLM afin de lui permettre de fonctionner en continu, en nous rapprochant de plus en plus de la solution finale. Voici donc nos apprentissages jusqu’à présent :

1. La description initiale de l'application est bien plus importante que nous le pensions . Notre idée initiale était qu'avec la contribution humaine, GPT Pilot serait capable de naviguer dans la bonne direction et de se rapprocher de plus en plus de la solution de travail, même si la description initiale était vague.

   
   

   Cependant, la réflexion de GPT Pilot se divise en plusieurs invites, en commençant par la description initiale. Et avec cela, si quelque chose est trompeur dans l’invite initiale, toutes les autres informations dont dispose GPT Pilot mèneront dans la mauvaise direction. Ainsi, lorsque vous le corrigerez sur toute la ligne, il sera si profondément enfoncé dans cette voie incorrecte qu’il sera presque impossible de le mettre sur la bonne voie.

   
   

   Au moment où j'écris ces lignes, cela semble évident, mais c'est quelque chose que nous devions apprendre : nous concentrer davantage sur la description initiale. Nous avons donc créé un nouvel agent appelé « Spec Writer », qui travaille avec vous pour décomposer les exigences du projet avant qu'il ne commence le codage.

   
   

2. Le codage n'est pas une ligne droite . Comme je l'ai mentionné ci-dessus dans la section sur les piliers, la refactorisation se produit tout le temps, et GPT Pilot doit le faire également. Nous n'avons pas encore mis en œuvre de solution pour cela, mais elle fonctionnera probablement en ajoutant la possibilité à GPT Pilot de créer des marqueurs autour de son arbre de décision afin que chaque fois que quelque chose ne fonctionne pas, il puisse examiner les marqueurs et réfléchir à l'endroit où il pourrait avoir fait un mauvais tour.

   
   

3. Les agents peuvent s'évaluer eux-mêmes . Je pensais que si un agent examinait ce que l'autre agent avait fait, cela serait redondant car c'est le même LLM qui retraite les mêmes informations. Mais il s’avère que lorsqu’un agent examine le travail d’un autre agent, cela fonctionne étonnamment bien. Nous avons 2 agents « Reviewer » différents qui examinent la façon dont le code a été implémenté.

   
   

   L'un le fait à un niveau élevé, par exemple sur la façon dont l'ensemble de la tâche a été implémenté, et un autre examine chaque modification avant qu'elle ne soit apportée à un fichier (comme faire un git add -p).

   
   

4. Les LLM fonctionnent mieux lorsqu'ils peuvent se concentrer sur un problème plutôt que sur plusieurs problèmes dans une seule invite. Par exemple, si vous demandez à GPT Pilot d'effectuer 2 modifications différentes dans une seule description, il aura du mal à se concentrer sur les deux. Ainsi, nous divisons chaque entrée humaine en plusieurs morceaux au cas où l'entrée contiendrait plusieurs demandes différentes.

   
   

5. Les journaux détaillés aident . C'est très évident maintenant, mais au départ, nous n'avons pas dit à GPT-4 d'ajouter des journaux autour du code. Désormais, il crée du code avec une journalisation détaillée, de sorte que lorsque vous exécutez l'application et rencontrez une erreur, GPT-4 aura beaucoup plus de facilité à déboguer lorsqu'il verra quels journaux ont été écrits et où se trouvent ces journaux dans le code.

   
   

6. Diviser la base de code en fichiers plus petits aide beaucoup . C’est aussi une conclusion évidente, mais nous avons dû l’apprendre. Il est beaucoup plus facile pour GPT-4 d'implémenter des fonctionnalités et de corriger des bugs si le code est divisé en plusieurs fichiers au lieu de quelques gros. Tout comme nous, les humains, le pensons : il est beaucoup plus facile de traiter de petits morceaux de code plutôt que de gros. Nous faisons cela en créant des niveaux d'abstraction – fonctions, classes, etc.

   
   

   L'un des moyens les plus simples pour amener le LLM à créer une abstraction plus gérable est simplement de lui dire de créer un code plus modulaire et de le diviser en davantage de fichiers. Cela fonctionne incroyablement bien et le résultat final est également meilleur pour nous, développeurs.

   
   

7. Pour qu'un humain puisse corriger le code, il faut lui montrer clairement ce qui a été écrit dans la tâche et l'idée qui la sous-tend . L'objectif de GPT Pilot est d'effectuer 90 % de toutes les tâches de codage et de laisser les 10 % restants à un humain. Ces 10 % comprennent généralement des correctifs ou de petits changements que le LLM a du mal à remarquer, mais pour l'humain, il peut s'agir d'un simple changement.

   
   

   Cependant, le problème est qu’il n’est pas facile de dire à l’humain ce qui ne fonctionne pas et quel code il doit examiner. Si GPT Pilot écrit 3 000 lignes de code, le développeur humain, s'il souhaite aider GPT Pilot, doit comprendre l'intégralité de la base de code avant de plonger dans le code lui-même.

   
   

   Dans les futures versions de GPT Pilot, le développeur humain aura une explication détaillée du code qui a été ajouté à la tâche en cours et du raisonnement qui le sous-tend. De cette façon, vous pourrez aider GPT Pilot.

   
   

8. Les humains sont paresseux . Il est préférable pour les LLM de poser des questions aux humains plutôt que de les laisser réfléchir à toutes les erreurs possibles. Encore une fois, c'est très évident avec le recul, mais l'une des choses que nous avons remarquées est que les gens étaient beaucoup plus disposés à répondre aux questions que GPT Pilot leur posait au lieu d'avoir un champ de saisie ouvert dans lequel ils pouvaient rédiger des commentaires sans contrainte.

   
   

9. Il est difficile d'amener un LLM à sortir des sentiers battus . Cela a été l’un des plus grands apprentissages pour moi. J'ai pensé que vous pourriez inviter GPT-4 en lui donnant quelques solutions qu'il avait déjà utilisées pour résoudre un problème et lui dire de réfléchir à une autre solution. Cependant, ce n’est pas aussi simple qu’il y paraît.

   
   

   Nous avons fini par demander au LLM de lister toutes les solutions possibles auxquelles il pouvait penser et de les sauvegarder en mémoire. Lorsque nous devions essayer autre chose, nous retirions les solutions alternatives et lui demandions d'essayer une solution différente, mais spécifique.

Applications créées avec GPT Pilot

Actuellement, vous pouvez créer des applications simples mais non triviales avec GPT Pilot. Nous avons également vu des gens créer des applications très impressionnantes avec GPT Pilot, comme une application capable d'affiner un modèle ResNet pour compter les palmiers, puis, lorsque vous téléchargez une image, de compter les arbres qu'elle contient. Voici quelques applications que nous avons créées, ainsi que le code, les statistiques et les démos :

Laboratoire d'invite ( DÉMO )

Considérez cela comme OpenAI Playground sous stéroïdes : il vous permet de charger une conversation à partir d'un tableau JSON ou de la saisir manuellement, d'exécuter la conversation avec le LLM X un certain nombre de fois, de sauvegarder la conversation dans la base de données et de la recharger. Nous utilisons réellement cette application lorsque nous concevons une invite et que nous voulons voir comment elle se comporte.

Le Playground n'est pas suffisant car il faut beaucoup de temps pour réexécuter une seule invite de manière répétée. Avec Prompt Lab, vous pouvez choisir combien de fois l'exécuter et laisser l'application exécuter l'invite à plusieurs reprises.

Une fois terminé, vous pouvez analyser les résultats. Cela peut être utile pour les personnes qui créent une application d'IA et qui ont besoin d'optimiser leurs invites.

• ⏳ Temps passé : ~2 jours
• 💾 Dépôt Github

Outil d'analyse de base de données SQLite ( DÉMO )

C'est également une application que nous utilisons en interne pour analyser une base de données SQLite locale. Il extrait les données de la base de données dans un format très spécifique à la structure de la base de données GPT Pilot, mais il peut facilement être modifié pour s'adapter à d'autres structures.

Il lit et télécharge votre base de données SQLite, divise les lignes par un champ spécifique, décompresse les lignes en valeurs, charge les données de conversation LLM dans un formulaire et vous permet de simplement modifier l'un des messages et de soumettre la demande LLM à GPT-4. pour voir à quoi ressembleront les résultats.

De cette façon, vous pouvez analyser les conversations que les agents de GPT Pilot ont avec le LLM et explorer facilement ce qui se passerait si les invites étaient différentes.

• ⏳ Temps passé : ~2 jours
• 💾 Dépôt Github

Code Whisperer ( DÉMO )

Code Whisper est un projet amusant que nous avons créé comme exemple à présenter. L'idée est que vous pouvez l'utiliser pour poser des questions au LLM sur votre base de code. Vous collez le lien vers un dépôt Github public.

Ensuite, il clone le référentiel, envoie les fichiers pertinents au LLM pour analyse, qui crée une description pour chaque fichier sur ce que fait le code et enregistre ces descriptions dans la base de données.

Après cela, vous pouvez poser des questions à l'application sur la base de code, et la base de code vous montre la réponse. Dans cette démo, nous utilisons GPT-3.5.

• ⏳ Temps passé : 7 heures
• 💾 Dépôt Github

Histoire des étoiles ( DÉMO )

Je publie des projets open source depuis des années maintenant et j'ai toujours voulu voir à quelle vitesse mon dépôt Github se développe par rapport à d'autres référentiels à succès sur https://star-history.com/ . Le problème est que sur Star History, je ne parviens pas à zoomer sur le graphique, donc un nouveau dépôt qui contient 1 000 étoiles ne peut pas être comparé à un gros dépôt qui en contient 50 000 car vous ne pouvez pas voir comment se comporte le plus gros dépôt à son début. .

J'ai donc demandé à GPT Pilot de créer cette fonctionnalité. Il récupère les dépôts Github pour les astronomes, les enregistre dans la base de données, les trace sur un graphique et permet de zoomer et dézoomer sur le graphique.

• ⏳ Temps passé : 6 heures
• 💾 Dépôt Github

Conclusion

J'espère que vous avez acquis un aperçu de l'état actuel, des problèmes et des conclusions que nous traitons chez GPT Pilot.

Alors pour récapituler :

Nous pensons qu’un véritable outil de développement d’IA doit reposer sur les piliers suivants :

• Un humain est nécessaire pour superviser l’IA.

  
  

• Nous devrions permettre à l’IA de répéter ses propres erreurs.

  
  

• Le développement de logiciels peut être orchestré , qui doit être implémenté sur une couche au-dessus des LLM.

  
  

• Le développeur d’IA devrait être capable de refactoriser la base de code car, en réalité, le processus de codage n’est pas une ligne droite.

Jusqu'à présent, nous avons appris que :

1. La description initiale de l'application est bien plus importante que nous le pensions

2. Le codage n'est pas une ligne droite, les agents peuvent se réviser eux-mêmes

3. Les LLM fonctionnent mieux lorsqu'ils se concentrent sur un problème plutôt que sur plusieurs problèmes dans une seule invite.

4. Les journaux détaillés font des miracles

5. Diviser la base de code en fichiers plus petits aide beaucoup

6. Pour qu'un humain puisse corriger le code

7. Il faut leur montrer clairement ce qui a été écrit et l'idée qui se cache derrière.

8. Les humains sont paresseux

9. Il est difficile d'amener le LLM à sortir des sentiers battus

   
   

Qu'en penses-tu? Avez-vous remarqué l'un de ces comportements dans vos interactions avec les LLM, ou avez-vous une opinion différente sur l'un d'entre eux ?

Je serais très heureux d'avoir de vos nouvelles, alors laissez un commentaire ci-dessous ou envoyez-moi un e-mail à [email protected] .

Vous pouvez essayer de créer une application avec l'IA avec GPT Pilot ici :

• Dépôt open source GPT Pilot
• Extension de code GPT pilote VS

Si vous avez aimé cet article, cela signifierait beaucoup si vous mettiez en vedette le dépôt GPT Pilot Github , et si vous l'essayez, dites-nous ce que vous en pensez. Vos commentaires sont vraiment importants pour toute l’équipe pilote GPT.

Également publié ici