Analyse des Ablaufs von Entwickler-Prompts in ChatGPT-Gesprächen

Inhaltsverzeichnis

Abstract

1 Einleitung

2 Datensammlung

3 RQ1: Welche Arten von Software-Engineering-Anfragen stellen Entwickler an ChatGPT in der ersten Eingabeaufforderung?

4 RQ2: Wie präsentieren Entwickler ihre Anfragen an ChatGPT in Mehrfach-Konversationen?

5 RQ3: Was sind die Merkmale des Teilverhaltens?

6 Diskussionen

7 Bedrohungen für die Gültigkeit

8 Verwandte Arbeiten

9 Fazit und zukünftige Arbeit

Referenzen

\

RQ2: Wie präsentieren Entwickler ihre Anfragen an ChatGPT in Mehrfach-Konversationen?

==Motivation:== Die in Abbildung 3 und Abbildung 4 dargestellten Ergebnisse zeigen, dass ein wesentlicher Teil in DevGPT-PRs (33,2%) und DevGPT-Issues (26,9%) Mehrfach-Konversationen umfasst. In Einzelkonversationen stellen Entwickler eine SE-bezogene Anfrage in der ersten Eingabeaufforderung und erhalten eine Antwort von ChatGPT, was einen klaren und direkten Austausch ermöglicht. Die Dynamik von Mehrfach-Konversationen führt jedoch zu Komplexität. Diese Interaktionen gehen über eine einfache Anfrage und Antwort hinaus und umfassen eine Reihe von Austauschen, die möglicherweise die ursprüngliche Anfrage verfeinern, erweitern oder klären.

\ Diese vielschichtige Kommunikation wirft eine Frage über die Strategien der Entwickler auf, ihre Anfragen über mehrere Runden zu artikulieren. Daher führen wir RQ2 ein, die die Art der Eingabeaufforderungen der Entwickler in Mehrfach-Konversationen untersucht. Um eine umfassende Analyse zu erleichtern, führen wir zwei Unter-RQs ein:

– RQ2.1: Was sind die Rollen der Entwickler-Eingabeaufforderungen in Mehrfach-Konversationen? Diese Frage zielt darauf ab, die strukturelle Rolle jeder Eingabeaufforderung in der entsprechenden Mehrfach-Konversation zu kategorisieren.

– RQ2.2: Was sind die Flussmuster in Mehrfach-Konversationen? Basierend auf der als Antwort auf RQ2.1 vorgeschlagenen Taxonomie untersucht diese Frage das häufige Übergangsmuster der identifizierten Rollen von Eingabeaufforderungen in Mehrfach-Konversationen. Die Antworten auf die obigen Unter-RQs werden Forschern Einblicke in die Dynamik und Praktiken von Entwicklern bei der Nutzung von ChatGPT über mehrere Interaktionsrunden geben.

\ 4.1 Ansatz

In RQ2.1 betrachten wir Eingabeaufforderungen in allen 189 Mehrfach-Konversationen, d.h. 64 Konversationen aus DevGPT-PRs und 125 aus DevGPT-Issues. Nach einer ähnlichen Methode wie bei RQ1 verwendeten wir offenes Kodieren, um manuell 645 Eingabeaufforderungen (236 Eingabeaufforderungen aus DevGPT-PRs und 409 Eingabeaufforderungen aus DevGPT-Issues) in Mehrfach-Konversationen über drei Runden zu kennzeichnen:

– In der ersten Runde kennzeichneten fünf Co-Autoren unabhängig voneinander zufällig ausgewählte 20 Konversationen aus den Datensätzen der Mehrfach-DevGPT-PRs und DevGPT-Issues, insgesamt 40 Konversationen und 123 Eingabeaufforderungen. Nach der Diskussion entwickelten wir ein Kodierbuch mit sieben verschiedenen Kennzeichnungen.

– In der zweiten Runde kennzeichneten zwei Annotatoren auf der Grundlage des bestehenden Kodierbuchs unabhängig voneinander einen weiteren Satz von 20 Konversationen aus jedem der Mehrfach-DevGPT-PRs und DevGPT-Issues-Datensätze, insgesamt 144 Eingabeaufforderungen. Die beiden Annotatoren erreichten einen Inter-Rater-Übereinstimmungswert von 0,89, gemessen am Cohen-Kappa-Koeffizienten, was eine fast perfekte Übereinstimmung darstellt (Landis und Koch, 1977). Die Annotatoren diskutierten dann und verfeinerten das Kodierbuch.

\ – Schließlich kennzeichnete jeder der beiden Annotatoren aus Runde zwei unabhängig voneinander die verbleibenden Daten. In RQ2.2 verwenden wir ein Markov-Modell (Gagniuc, 2017), um die Konversationsflussmuster durch Darstellung eines Markov-Übergangsgraphen zu analysieren. Ein Markov-Übergangsgraph ist ein gerichteter Graph, der die probabilistischen Übergänge

zwischen verschiedenen Zuständen oder Knoten zeigt. In unserem Fall repräsentiert jeder Knoten im Graphen eine bestimmte Kategorie, die in RQ2.1 entwickelt wurde, und die gerichteten Kanten zwischen Knoten bezeichnen die Wahrscheinlichkeit des Übergangs von einer Taxonomie zu einer anderen basierend auf den von uns gesammelten Mehrfach-Konversationen. Um aussagekräftige Erkenntnisse aus dem Markov-Übergangsgraphen zu gewinnen, schlagen wir die folgenden Nachbearbeitungsschritte vor:

1. Wir haben den Graphen bereinigt, indem wir Übergänge mit Wahrscheinlichkeiten unter 0,05 entfernt haben, um uns auf statistisch signifikante Beziehungen zu konzentrieren.

2. Wir haben die Graphenstruktur verfeinert, indem wir Knoten ohne eingehende und ausgehende Kanten entfernt haben, mit Ausnahme der Start- und Endknoten. Dieser Schritt stellt eine Vereinfachung sicher, da wir nur wesentliche Komponenten beibehalten.

3. Wir haben den Markov-Übergangsgraphen systematisch in ein Flussdiagramm umorganisiert, um seine Interpretierbarkeit zu verbessern und eine leichter verständliche Darstellung der Flussmuster zu bieten.

   \ 4.2 Ergebnisse

   4.2.1 RQ 2.1 Was sind die Rollen der Entwickler-Eingabeaufforderungen in Mehrfach-Konversationen? Tabelle 4 präsentiert unsere vorgeschlagene Taxonomie zur Klassifizierung von Eingabeaufforderungen innerhalb von Mehrfach-Konversationen. Unsere Analyse zeigt, dass sowohl in Pull-Requests als auch in Issues Mehrfach-Konversationen drei Haupttypen von Eingabeaufforderungen enthalten: solche, die Folgefragen stellen (M1), solche, die die ursprüngliche Aufgabe einführen (M2), und solche, die aus einer vorherigen Eingabeaufforderung verfeinert wurden (M3). Eine Eingabeaufforderung aus DevGPT-PRs und sechs Eingabeaufforderungen aus DevGPT-Issues wurden unter "Sonstige" kategorisiert, da sie entweder beiläufige Konversation waren oder nicht genügend Details enthielten, um ihre Rollen zu bestimmen.

   \ Nachfolgend beschreiben wir jede Kategorie detaillierter.

   ==(M1) Iterative Nachverfolgung:== In 33% und 40% der Eingabeaufforderungen in Mehrfach-DevGPT-PRs und DevGPT-Issues stellen Entwickler Anfragen, die direkt auf ChatGPTs vorherige Antworten oder den laufenden Kontext aufbauen, wie z.B. das Debuggen und Reparieren einer Lösung nach der Codegenerierung durch ChatGPT. Solche iterativen Nachverfolgungen entstehen typischerweise, wenn die ursprüngliche Aufgabe eine komplexe Herausforderung darstellt, die ChatGPT möglicherweise nicht in einer einzigen Interaktion vollständig lösen kann. Folglich engagieren sich Entwickler in einer Eingabeaufforderung, die eine Folgeanfrage spezifiziert, wodurch ChatGPT menschliches Feedback einbeziehen und die vorgeschlagene Lösung iterativ verbessern kann.

   \ ==(M2) Offenlegung der ursprünglichen Aufgabe:== Wir stellen fest, dass ein ähnlicher Anteil, d.h. 26% in Mehrfach-DevGPT-PRs und 29% in Mehrfach-DevGPT-Issues, der Eingabeaufforderungen dazu dient, die ursprüngliche Aufgabe bei ChatGPT einzuführen. Diese Verteilung hebt hervor, dass es in Mehrfach-Konversationen, im Gegensatz zu Einzelkonversationen, bei denen die einzige Eingabeaufforderung der Darstellung der Hauptaufgabe gewidmet ist, eine signifikante Anzahl von Eingabeaufforderungen gibt, die anderen Zwecken dienen.

   \ ==(M3) Verfeinerung der Eingabeaufforderung:== Neben der iterativen Nachverfolgung (M1) neigen Entwickler auch dazu, die von ChatGPT vorgeschlagene Lösung zu verbessern, indem sie eine verfeinerte Anfrage-Eingabeaufforderung mit zusätzlichem Kontext oder Einschränkungen bereitstellen. Das Ziel ist es, die Antwortqualität für dieselbe Anfrage, die in der vorherigen Eingabeaufforderung gestellt wurde, zu verbessern. Verfeinerte Eingabeaufforderungen machen 17% der Eingabeaufforderungen in Mehrfach-DevGPT-PRs und 14% in DevGPT-Issues aus.

   \ ==(M4) Informationsgabe:== In 8% und 6% der Eingabeaufforderungen in Mehrfach-DevGPT-PRs und DevGPT-Issues stellen Entwickler keine Anfrage an ChatGPT, sondern teilen Wissen oder Kontext mit ChatGPT.

   \ ==(M5) Offenlegung einer neuen Aufgabe== Wir beobachten, dass 7% und 4% der Eingabeaufforderungen in Mehrfach-DevGPT-PRs und DevGPT-Issues eine neue Aufgabe an ChatGPT stellen, die sich von der/den Aufgabe(n) in den vorherigen Eingabeaufforderungen unterscheidet. Diese Kategorie stellt einen klaren Unterschied zu iterativen Nachverfolgungen (M1) dar, da die neue Aufgabe nicht mit ChatGPTs vorherigen Antworten zusammenhängt oder darauf aufbaut und ein anderes Ziel verfolgt. Zum Beispiel bat ein Entwickler ChatGPT zunächst, das SQL zu einem Django-Queryset zu generieren, und fragte in einer nachfolgenden Eingabeaufforderung nach dem SQL für ein anderes Queryset, wodurch der Fokus der Konversation auf eine völlig neue Aufgabe ohne vorherige Relevanz verlagert wurde.

   \ ==(M6) Negatives Feedback:== Innerhalb von Mehrfach-Konversationen enthalten einige (6% in DevGPT-PRs und 2% in DevGPT-Issues) Eingabeaufforderungen nur negatives Feedback zu ChatGPTs vorherigen Antworten, ohne Informationen zur Verbesserung oder weiteren Lösung zu liefern. Zum Beispiel: "Dein Code ist falsch", "Der gleiche Fehler besteht weiterhin" und "...funktioniert nicht". Diese Kategorie unterstreicht Fälle, in denen Entwickler ChatGPT über seine Mängel informieren möchten, ohne weitere Hilfe oder Klärung zu suchen.

   \ (M7) Bitte um Klärung: 4% und 5% der Eingabeaufforderungen in Mehrfach-DevGPT-PRs und DevGPT-Issues bitten ChatGPT, seine Antwort zu erläutern. Diese Bitten um Erläuterung zielen darauf ab, die Vollständigkeit einer Lösung sicherzustellen, z.B. "Muss ich noch etwas anderes tun?". Sie umfassen auch die Überprüfung von ChatGPTs Fähigkeit, bestimmte Aufgaben zu bewältigen, oder Anfragen zur Überprüfung, ob bestimmte Bedingungen in der Antwort berücksichtigt wurden. Darüber hinaus könnten Entwickler fragen, warum einige Alternativen von ChatGPT übersehen wurden, was auf eine tiefere Auseinandersetzung mit den vorgeschlagenen Lösungen und den Wunsch hindeutet, die Gründe hinter ChatGPTs vorgeschlagener Lösung zu verstehen.

   4.2.2 RQ 2.2 Was sind die Flussmuster in Mehrfach-Konversationen?

   Abbildung 5 zeigt das resultierende Flussdiagramm nach Anwendung der Nachbearbeitungsschritte auf einen Markov-Übergangsgraphen basierend auf annotierten Konversationen als Ergebnis von RQ2.1. Das Flussdiagramm gilt für Mehrfach-Konversationen sowohl in DevGPT-PRs als auch in DevGPT-Issues