Tirez parti du modèle de langage d’OpenAI pour les résumés de validation automatisés | de Itay Knaan-Harpaz | décembre 2022

Un outil que j’ai créé pour fournir des résumés des modifications introduites par une demande d’extraction dans un référentiel

Vous cherchez des moyens de rendre votre flux de travail plus efficace, ou vous en avez assez de parcourir manuellement les longs journaux de validation pour comprendre les demandes d’extraction ?

Présentation de l’action GitHub de synthèse GPT : un outil puissant qui exploite le dernier et le plus grand modèle de langage d’OpenAI pour générer des résumés concis et informatifs de l’ensemble de la demande d’extraction, ainsi que des descriptions des modifications apportées aux fichiers individuels et aux commits individuels.

Prêt à commencer à utiliser GPT-Commit-Summarizer ? L’ajout de l’action à votre référentiel est rapide et facile – tout ce dont vous avez besoin est un jeton d’API OpenAI, un secret dans votre référentiel et l’ajout d’un seul fichier pour définir le flux de travail.

Suivez les instructions du Lisez-moi, et vous pouvez être opérationnel en quelques minutes. L’action prend en charge tous les langages et cadres de programmation – les résultats peuvent varier. Vérifiez-le ici.

Tous les résultats de véritables bases de code — projets personnels, idem.fitet papiersconnectes.com.

• Les commentaires du résumé des relations publiques sont d’une grande aide pour capturer l’idée principale d’une demande d’extraction. Celles-ci sont libellées comme « Résumé PR jusqu’à présent » car elles sont générées de manière incrémentielle pour éviter d’encombrer la page de discussion avec des commentaires doubles lorsqu’un commit est ajouté à une demande d’extraction.
• Les résumés de diff à fichier unique sont généralement exacts et fournissent une aide supplémentaire pendant le processus d’examen. L’action GitHub se nettoie après elle-même, en supprimant les commentaires récapitulatifs obsolètes pour éviter de spammer la page de révision.
• Si un changement de fichier particulier vous embrouille, vous pouvez toujours vérifier le résumé du commit dans lequel il s’est produit, en trouvant souvent une explication utile.

À l’avenir, il viendra un jour où un modèle existera qui pourra évaluer une demande d’extraction complète dans le contexte de l’ensemble de la base de code et donner un résumé. Cependant, aujourd’hui n’est pas ce jour-là.

Actuellement, le text-davinci-003 Le modèle (celui qui alimente ChatGPT) utilisé dans le projet Summarizer est limité à 4096 jetons, soit environ deux cents lignes de code.

Cela signifie que le nombre de modifications de code pouvant être introduites dans le modèle est bien inférieur au nombre de modifications dans une demande d’extraction typique. De plus, le modèle doit voir les changements de code dans le contexte de quelques lignes au-dessus et en dessous pour pouvoir les comprendre, ce qui fait que l’entrée dépasse ses limites dans tout flux de travail réaliste.

Pour résoudre ce problème, GPT-Commit-Summarizer décompose la demande d’extraction en diffs plus petits – des diffs de fichiers individuels et des commits qu’il contient. Ceux-ci sont ensuite résumés individuellement. Tous ces résumés sont ensuite combinés en une seule requête pour générer un résumé de l’ensemble de la demande d’extraction.

Les ingénieurs logiciels réaliseront rapidement que cela est très similaire au type de réflexion que vous utilisez lorsque vous concevez une solution à un problème. Décomposer un problème en parties plus petites et gérables, comprendre les dépendances entre les tâches, puis obtenir un résultat unifié.

Les similitudes avec le génie logiciel classique ne s’arrêtent pas là — jetez un œil au début de la requête pour résumer les commits git :

You are an expert programmer, and you are trying to summarize a git diff.
Reminders about the git diff format:
For every file, there are a few metadata lines, like (for example):
```
diff --git a/lib/index.js b/lib/index.js
index aadf691..bfef603 100644
--- a/lib/index.js
+++ b/lib/index.js
```
This means that `lib/index.js` was modified in this commit. Note that this is only an example.
Then there is a specifier of the lines that were modified.
A line starting with `+` means it was added.
A line that starting with `-` means that line was deleted.
A line that starts with neither `+` nor `-` is code given for context and better understanding.
It is not part of the diff.
[...]
EXAMPLE SUMMARY COMMENTS:
```
* Raised the amount of returned recordings from `10` to `100` [packages/server/recordings_api.ts], [packages/server/constants.ts]
* Fixed a typo in the github action name [.github/workflows/gpt-commit-summarizer.yml]
* Moved the `octokit` initialization to a separate file [src/octokit.ts], [src/index.ts]
* Added an OpenAI API for completions [packages/utils/apis/openai.ts]
* Lowered numeric tolerance for test files
```
Most commits will have less comments than this examples list.
The last comment does not include the file names,
because there were more than two relevant files in the hypothetical commit.
Do not include parts of the example in your summary.
It is given only as an example of appropriate comments.

Ce… N’a pas envie d’écrire en anglais. Je connais cette sensation. C’est de la programmation.

Ce nouveau type de programmation, où vous écrivez des instructions pour qu’un modèle de langage génère du texte, en utilisant l’anglais comme langage de programmation, apparaît comme un outil puissant dans la boîte à outils du génie logiciel.

Je ne doute pas que « Call large language model » deviendra bientôt une idée de discussion courante dans les réunions d’architecture logicielle et de planification – pour certaines tâches, les spécifier en anglais et appeler une API est tout ce dont vous avez besoin.

Lorsque j’ai commencé à écrire l’action GitHub, je n’avais aucune connaissance préalable de la façon d’écrire de telles actions ni aucune familiarité avec l’API OpenAI.

Cependant, avec l’aide du modèle, j’ai pu écrire rapidement et efficacement de nombreuses parties du code, sans perdre un temps précieux à rechercher la fonction correcte dans la documentation obscure de la bibliothèque.

Même pour les refactorisateurs de code, le modèle s’est avéré être un outil efficace. Dans l’ensemble, je suis certain que l’utilisation de modèles de langage deviendra un outil essentiel pour tous les développeurs de logiciels, quel que soit leur domaine.

Les conseils les plus importants que j’ai appris pour être productif avec cet outil sont :

• Fournissez des instructions claires sur ce que vous voulez qu’il fasse.
• Si votre code ne parvient pas à se construire ou contient des erreurs, dites-le-lui et collez le message d’erreur en demandant au modèle de le réécrire. J’ai trouvé qu’il pouvait généralement corriger les erreurs et les bogues simples.
• Chaque fois que vous avez besoin d’accéder à une API ou d’utiliser une bibliothèque, demandez au modèle « Comment puis-je faire X dans la bibliothèque Y ? » et il fournira souvent la réponse.
• L’utilisation d’un langage typé (j’ai utilisé TypeScript) s’avère être un outil incroyablement utile pour ce processus. Le modèle échoue souvent à produire les signatures de type correctes. Parfois, il s’agissait d’un problème de syntaxe mineur, mais la plupart du temps, il mettait également en évidence de vrais problèmes – que le modèle a ensuite corrigés, lorsqu’il était présenté avec l’erreur de type.
• Vous devez déjà savoir programmer pour utiliser cet outil. Il fait parfois des erreurs stupides et vous devez fournir des conseils lorsqu’il s’agit de refactoriser le code ou d’apporter des modifications.
• Utilisez le terrain de jeux, et non ChatGPT. Cela permet le flux de travail très efficace suivant : chaque fois que vous n’êtes pas satisfait de la sortie, identifiez le premier point où le modèle s’écarte de votre vision, écrivez un ou deux mots (ou environ une ligne de code), supprimez le reste – et laissez le modèle continuez à partir de là (Comme vous pouvez le voir sur les captures d’écran, cette réalisation m’est venue tardivement dans le processus… Et je dois admettre que ChatGPT est plus photogénique).
• Créer de petits commits et utiliser git s’est avéré être une pratique extrêmement précieuse. Parfois, le modèle fait des erreurs lors de la refactorisation du code – validez souvent, et s’il fait quelque chose de mal, réinitialisez à la validation de travail la plus récente.

Je sais que je ne suis pas le premier à le dire, mais je recommande fortement d’utiliser GPT. Pas seulement pour les tâches de programmation, mais pour une grande variété d’activités – j’ai trouvé cela extrêmement utile lors de la rédaction de cet article de blog.

Pour les très grands PR, la solution actuelle dépasse souvent la limite de taille du modèle, ce qui entraîne l’échec de certains résumés. L’action peut le gérer avec élégance – par exemple, si un fichier diff est très volumineux, il ne parviendra pas à le résumer, mais il peut toujours résumer tous les autres fichiers diffs et tous les commits participant au PR, ce qui donne un résumé PR total acceptable.

De plus, parfois (assez rarement dans mes tests), le modèle comprend mal quelque chose, écrivant des commentaires qui sont tout simplement faux. Un peu plus commun est de ne pas écrire sur une partie importante d’un diff. Par conséquent, utilisez votre jugement et ne vous fiez jamais aveuglément aux résultats.

Merci à Soof Golan d’avoir contribué à la base de code et d’avoir écrit add-gpt-summarizer.

L’auteur, Itay Knaan-Harpaz est actuellement directeur technique de idem.fit et co-fondateur de papiersconnectes.com.