Résumé
1 Introduction
2 Collecte de données
3 RQ1: Quels types de requêtes d'ingénierie logicielle les développeurs présentent-ils à ChatGPT dans le prompt initial?
4 RQ2: Comment les développeurs présentent-ils leurs requêtes à ChatGPT dans les conversations à plusieurs tours?
5 RQ3: Quelles sont les caractéristiques du comportement de partage?
6 Discussions
7 Menaces à la validité
8 Travaux connexes
9 Conclusion et travaux futurs
Références
\
==Motivation:== Les résultats présentés dans la Figure 3 et la Figure 4 révèlent qu'une part substantielle des DevGPT-PRs (33,2%) et des DevGPT-Issues (26,9%) comprend des conversations à plusieurs tours. Dans les conversations à tour unique, les développeurs posent une requête liée à l'ingénierie logicielle dans le prompt initial et reçoivent une réponse de ChatGPT, offrant un échange clair et direct. La dynamique des conversations à plusieurs tours introduit cependant une complexité. Ces interactions vont au-delà d'une simple requête et réponse, impliquant une série d'échanges qui potentiellement affinent, développent ou clarifient la requête initiale.
\ Cette communication en couches soulève une question sur les stratégies des développeurs pour articuler leurs requêtes sur plusieurs tours. Ainsi, nous introduisons RQ2, qui étudie la nature des prompts des développeurs dans les conversations à plusieurs tours. Pour faciliter une analyse complète, nous introduisons deux sous-questions:
– RQ2.1: Quels sont les rôles des prompts des développeurs dans les conversations à plusieurs tours? Cette question vise à catégoriser le rôle structurel de chaque prompt dans la conversation à plusieurs tours correspondante.
– RQ2.2: Quels sont les modèles de flux dans les conversations à plusieurs tours? Basée sur la taxonomie proposée comme réponse à RQ2.1, cette question explore le modèle de transition fréquent de ces rôles identifiés des prompts dans les conversations à plusieurs tours. Les réponses aux sous-questions ci-dessus fourniront des insights aux chercheurs sur la dynamique et les pratiques des développeurs utilisant ChatGPT via plusieurs cycles d'interactions.
\ 4.1 Approche
Dans RQ2.1, nous considérons les prompts dans toutes les 189 conversations à plusieurs tours, c'est-à-dire 64 conversations de DevGPT-PRs et 125 de DevGPT-Issues. Suivant une méthode similaire à RQ1, nous avons utilisé le codage ouvert pour étiqueter manuellement 645 prompts (236 prompts de DevGPT-PRs et 409 prompts de DevGPT-Issues) dans des conversations à plusieurs tours sur trois cycles:
– Dans le premier cycle, cinq co-auteurs ont indépendamment étiqueté 20 conversations sélectionnées aléatoirement à partir des ensembles de données DevGPT-PRs et DevGPT-Issues à plusieurs tours, englobant 40 conversations et 123 prompts. Après discussion, nous avons développé un livre de codage composé de sept étiquettes distinctes.
– Dans le deuxième cycle, basé sur le livre de codage existant, deux annotateurs ont indépendamment étiqueté un autre ensemble de 20 conversations de chacun des ensembles de données DevGPT-PRs et DevGPT-Issues à plusieurs tours, soit un total de 144 prompts. Les deux annotateurs ont atteint un score d'accord inter-évaluateurs de 0,89, mesuré par le coefficient kappa de Cohen, représentant un accord presque parfait (Landis et Koch, 1977). Les annotateurs ont ensuite discuté et affiné le livre de codage.
\ – Enfin, chacun des deux annotateurs du deuxième cycle a indépendamment étiqueté les données restantes. Dans RQ2.2, nous utilisons un modèle de Markov (Gagniuc, 2017) pour analyser les modèles de flux de conversation en traçant un graphe de transition de Markov. Un graphe de transition de Markov est un graphe orienté qui démontre les transitions probabilistes
entre divers états ou nœuds. Dans notre cas, chaque nœud du graphe représente une catégorie spécifique développée dans RQ2.1, et les arêtes orientées entre les nœuds indiquent la probabilité de transition d'une taxonomie à une autre basée sur les conversations à plusieurs tours que nous avons collectées. Pour extraire des insights significatifs du graphe de transition de Markov, nous proposons les étapes de post-traitement suivantes:
Nous avons élagué le graphe en supprimant les transitions avec des probabilités inférieures à 0,05, assurant une concentration sur les relations statistiquement significatives.
Nous avons affiné la structure du graphe en supprimant les nœuds sans arêtes entrantes et sortantes, à l'exception des nœuds de début et de fin. Cette étape assure la simplification car nous ne gardons que les composants essentiels.
Nous avons systématiquement réorganisé le graphe de transition de Markov en un organigramme pour améliorer son interprétabilité, offrant une représentation plus facile à comprendre des modèles de flux.
\ 4.2 Résultats
4.2.1 RQ 2.1 Quels sont les rôles des prompts des développeurs dans les conversations à plusieurs tours? Le Tableau 4 présente notre taxonomie proposée pour classifier les prompts dans les conversations à plusieurs tours. Notre analyse révèle que, dans les pull requests et les issues, les conversations à plusieurs tours contiennent trois types principaux de prompts: ceux qui posent des questions de suivi (M1), ceux qui introduisent la tâche initiale (M2), et ceux qui sont affinés à partir d'un prompt précédent (M3). Un prompt de DevGPT-PRs et six prompts de DevGPT-Issues ont été catégorisés sous "Autres" en raison de leur nature de conversation informelle ou du manque de détails suffisants pour déterminer leurs rôles.
\ Ci-dessous, nous décrivons chaque catégorie plus en détail.
==(M1) Suivi itératif:== Dans 33% et 40% des prompts dans les DevGPT-PRs et DevGPT-Issues à plusieurs tours, les développeurs postent des requêtes qui s'appuient directement sur les réponses antérieures de ChatGPT ou sur le contexte en cours, comme le débogage et la réparation d'une solution après la génération de code par ChatGPT. De tels suivis itératifs émergent généralement lorsque la tâche initiale présente un défi complexe que ChatGPT pourrait ne pas résoudre entièrement en une seule interaction. Par conséquent, les développeurs s'engagent dans un prompt spécifiant une demande de suivi, permettant à ChatGPT d'incorporer les retours humains et d'améliorer itérativement la solution proposée.
\ ==(M2) Révéler la tâche initiale:== Nous constatons qu'une fraction similaire, c'est-à-dire 26% dans les DevGPT-PRs à plusieurs tours et 29% dans les DevGPT-Issues à plusieurs tours, des prompts servent à introduire la tâche initiale à ChatGPT. Cette distribution souligne que dans les conversations à plusieurs tours, contrairement aux conversations à tour unique où le seul prompt est dédié à l'esquisse de la tâche principale, il y a une quantité significative de prompts servant à d'autres fins.
\ ==(M3) Affiner le prompt:== Outre le suivi itératif (M1), les développeurs ont également tendance à améliorer la solution proposée par ChatGPT en fournissant un prompt de requête affiné avec un contexte ou des contraintes supplémentaires. L'objectif est d'améliorer la qualité de la réponse pour la même requête postée dans le prompt précédent. Les prompts affinés représentent 17% des prompts dans les DevGPT-PRs à plusieurs tours et 14% dans les DevGPT-Issues.
\ ==(M4) Donner des informations:== Dans 8% et 6% des prompts dans les DevGPT-PRs et DevGPT-Issues à plusieurs tours, les développeurs ne postent aucune demande à ChatGPT, mais partagent plutôt des connaissances ou du contexte avec ChatGPT.
\ ==(M5) Révéler une nouvelle tâche== Nous observons que 7% et 4% des prompts dans les DevGPT-PRs et DevGPT-Issues à plusieurs tours postent une nouvelle tâche à ChatGPT, qui est distincte de la ou des tâches concernées dans les prompts précédents. Cette catégorie représente une différence claire par rapport aux suivis itératifs (M1), car la nouvelle tâche n'est pas liée ou ne s'appuie pas sur les réponses antérieures de ChatGPT et vise un objectif différent. Par exemple, un développeur a initialement demandé à ChatGPT de générer le SQL correspondant à un ensemble de requêtes Django et, dans un prompt ultérieur, a demandé le SQL pour un ensemble de requêtes différent, déplaçant ainsi le focus de la conversation vers une tâche entièrement nouvelle sans pertinence antérieure.
\ ==(M6) Retour négatif:== Dans les conversations à plusieurs tours, quelques prompts (6% dans les DevGPT-PRs et 2% dans les DevGPT-Issues) contiennent uniquement des retours négatifs dirigés vers les réponses précédentes de ChatGPT, sans fournir d'informations pour que ChatGPT s'améliore ou résolve davantage. Par exemple, "Votre code est incorrect", "La même erreur persiste", et "...ne fonctionne pas". Cette catégorie souligne les instances où les développeurs cherchent à informer ChatGPT de ses lacunes, sans chercher d'assistance ou de clarification supplémentaire.
\ (M7) Demander des clarifications: 4% et 5% des prompts dans les DevGPT-PRs et DevGPT-Issues à plusieurs tours demandent à ChatGPT d'élaborer sur sa réponse. Ces demandes d'élaboration visent à assurer l'exhaustivité d'une solution, par exemple, "Dois-je faire autre chose?". Elles incluent également la vérification de la capacité de ChatGPT à gérer des tâches spécifiques, ou des enquêtes pour vérifier si certaines conditions ont été prises en compte dans la réponse. De plus, les développeurs peuvent demander pourquoi certaines alternatives ont été négligées par ChatGPT, indiquant un engagement plus profond avec les solutions proposées et un désir de comprendre la logique derrière la solution proposée par ChatGPT.
4.2.2 RQ 2.2 Quels sont les modèles de flux dans les conversations à plusieurs tours?
La Figure 5 présente l'organigramme résultant après avoir appliqué les étapes de post-traitement sur un graphe de transition de Markov basé sur les conversations annotées résultant de RQ2.1. L'organigramme s'applique aux conversations à plusieurs tours dans les DevGPT-PRs et DevGPT-Issues. Comme illustré dans la Figure 5, les conversations à plusieurs tours commencent généralement par la présentation de la tâche initiale (M2) ou des informations contextuelles (M4).
\ Notre analyse de suivi détaillée révèle que 81% des conversations à plusieurs tours dans les DevGPT-PRs et 90% dans les DevGPT-Issues commencent par l'esquisse de la tâche initiale. À l'inverse, environ 13% des conversations à plusieurs tours dans les DevGPT-PRs et 3% dans les DevGPT-Issues introduisent la tâche initiale dans le deuxième prompt. Dans des cas extrêmes, la tâche initiale est divulguée aussi tard que le septième tour, ou, dans certains cas, la tâche initiale n'est jamais explicitement présentée—à la place, ces conversations ne présentent que des informations à ChatGPT sans énoncer directement la tâche.
\ Quant au flux complet, nous avons identifié les modèles suivants basés sur la Figure 5:
Début → révéler la tâche initiale → suivi itératif → fin
Début → révéler la tâche initiale → affiner le prompt → (suivi itératif) → fin
Début → révéler la tâche initiale → révéler une nouvelle tâche → fin
Début → donner des informations → révéler la tâche initiale → … → fin
Début → révéler la tâche initiale → demander des clarifications → fin
Début → révéler la tâche initiale → retour négatif → fin
\ Les modèles de flux (1) à (3) montrent les flux d'interaction développeur-ChatGPT les plus courants dans les conversations à plusieurs tours. La tâche initiale est divulguée dans le prompt initial, suivie de prompts visant à améliorer les réponses de ChatGPT via un suivi itératif, des affinements de prompt, ou pour révéler une nouvelle tâche.
Le modèle (4) démontre des flux d'interaction commencés par des développeurs fournissant des informations à ChatGPT comme première étape. Ensuite, la tâche initiale a été révélée, suivie de modèles semblables à (1) à (3). Le modèle


