摘要
1 引言
2 資料收集
3 研究問題1:開發人員在初始提示中向ChatGPT提出哪些類型的軟體工程查詢?
4 研究問題2:開發人員如何在多輪對話中向ChatGPT提出查詢?
5 研究問題3:分享行為的特徵是什麼?
6 討論
7 有效性威脅
8 相關工作
9 結論與未來工作
參考文獻
\
==動機:== 圖3和圖4中呈現的結果顯示,DevGPT-PRs(33.2%)和DevGPT-Issues(26.9%)中有相當大一部分包含多輪對話。在單輪對話中,開發人員在初始提示中提出與軟體工程相關的查詢,並從ChatGPT獲得一個回應,提供了清晰直接的交流。然而,多輪對話的動態引入了複雜性。這些互動超越了簡單的查詢和回應,涉及一系列可能會精煉、擴展或澄清初始查詢的交流。
\ 這種分層通信引發了關於開發人員在多輪對話中表達查詢策略的問題。因此,我們提出研究問題2,研究開發人員在多輪對話中提示的性質。為了進行全面分析,我們進一步引入兩個子研究問題:
– 研究問題2.1:開發人員提示在多輪對話中扮演什麼角色? 這個問題旨在對相應多輪對話中每個提示的結構角色進行分類。
– 研究問題2.2:多輪對話中的流程模式是什麼? 基於研究問題2.1的答案所提出的分類法,這個問題探討多輪對話中已識別提示角色的頻繁轉換模式。上述子研究問題的答案將為研究人員提供關於開發人員通過多輪互動使用ChatGPT的動態和實踐的見解。
\ 4.1 方法
在研究問題2.1中,我們考慮所有189個多輪對話中的提示,即來自DevGPT-PRs的64個對話和來自DevGPT-Issues的125個對話。採用類似於研究問題1的方法,我們使用開放式編碼手動標記多輪對話中的645個提示(來自DevGPT-PRs的236個提示和來自DevGPT-Issues的409個提示),分三輪進行:
– 在第一輪中,五位共同作者獨立標記從多輪DevGPT-PRs和DevGPT-Issues數據集中隨機選擇的20個對話,包括40個對話和123個提示。討論後,我們開發了一個包含七個不同標籤的編碼手冊。
– 在第二輪中,基於現有的編碼手冊,兩位註釋者獨立標記了來自多輪DevGPT-PRs和DevGPT-Issues數據集的另外20個對話,共144個提示。兩位註釋者達到了0.89的評分者間一致性分數,以Cohen's kappa係數衡量,代表幾乎完全一致(Landis和Koch,1977)。然後註釋者討論並完善了編碼手冊。
\ – 最後,第二輪的兩位註釋者各自獨立標記了剩餘的數據。在研究問題2.2中,我們使用馬爾可夫模型(Gagniuc,2017)通過繪製馬爾可夫轉換圖來分析對話流程模式。馬爾可夫轉換圖是一個有向圖,展示了
各種狀態或節點之間的概率轉換。在我們的案例中,圖中的每個節點代表研究問題2.1中開發的特定類別,節點之間的有向邊表示基於我們收集的多輪對話從一個分類法轉換到另一個的可能性。為了從馬爾可夫轉換圖中提取有意義的見解,我們提出以下後處理步驟:
我們通過移除概率低於0.05的轉換來修剪圖,確保專注於統計上顯著的關係。
我們通過移除沒有入邊和出邊的節點(除了起始和結束節點)來精簡圖結構。這一步確保簡化,因為我們只保留基本組件。
我們系統地將馬爾可夫轉換圖重組為流程圖,以增強其可解釋性,提供更容易理解的流程模式表示。
\ 4.2 結果
4.2.1 研究問題2.1 開發人員提示在多輪對話中扮演什麼角色? 表4呈現了我們提出的分類法,用於分類多輪對話中的提示。我們的分析顯示,在拉取請求和問題中,多輪對話包含三種主要類型的提示:提出後續問題的提示(M1)、介紹初始任務的提示(M2)和從先前提示精煉的提示(M3)。來自DevGPT-PRs的一個提示和來自DevGPT-Issues的六個提示被歸類為"其他",因為它們的性質是隨意對話或缺乏足夠的細節來確定其角色。
\ 以下,我們更詳細地描述每個類別。
==(M1) 迭代跟進:== 在多輪DevGPT-PRs的33%和DevGPT-Issues的40%的提示中,開發人員發布直接基於ChatGPT先前回應或正在進行的上下文的查詢,例如在ChatGPT生成代碼後進行調試和修復解決方案。當初始任務呈現ChatGPT可能無法在單次互動中完全解決的複雜挑戰時,通常會出現這種迭代跟進。因此,開發人員參與指定後續請求的提示,使ChatGPT能夠納入人類反饋並迭代增強提出的解決方案。
\ ==(M2) 揭示初始任務:== 我們發現,類似比例的提示,即多輪DevGPT-PRs中的26%和多輪DevGPT-Issues中的29%,用於向ChatGPT介紹初始任務。這種分佈突顯了在多輪對話中,與單輪對話不同,在單輪對話中,唯一的提示專用於概述主要任務,而在多輪對話中有相當數量的提示服務於其他目的。
\ ==(M3) 精煉提示:== 除了迭代跟進(M1)外,開發人員還傾向於通過提供帶有額外上下文或約束的精煉請求提示來改進ChatGPT提出的解決方案。目標是提高先前提示中發布的相同查詢的回應質量。精煉提示佔多輪DevGPT-PRs中提示的17%和DevGPT-Issues中的14%。
\ ==(M4) 提供信息:== 在多輪DevGPT-PRs的8%和DevGPT-Issues的6%的提示中,開發人員不向ChatGPT發布任何請求,而是與ChatGPT分享知識或上下文。
\ ==(M5) 揭示新任務== 我們觀察到,多輪DevGPT-PRs的7%和DevGPT-Issues的4%的提示向ChatGPT發布了一個新任務,該任務與先前提示中涉及的任務不同。這個類別與迭代跟進(M1)有明顯區別,因為新任務與ChatGPT先前的回應無關,也不基於它們,而是針對不同的目標。例如,開發人員最初請求ChatGPT生成與Django查詢集對應的SQL,然後在後續提示中要求為不同的查詢集生成SQL,從而將對話焦點轉移到一個全新的任務,沒有先前的相關性。
\ ==(M6) 負面反饋:== 在多輪對話中,少數(DevGPT-PRs中的6%和DevGPT-Issues中的2%)提示僅包含針對ChatGPT先前回應的負面反饋,而沒有提供任何信息讓ChatGPT改進或進一步解決。例如,"你的代碼不正確","同樣的錯誤仍然存在",和"...不起作用"。這個類別強調了開發人員尋求告知ChatGPT其缺點的情況,而不尋求進一步的幫助或澄清。
\ (M7) 要求澄清: 多輪DevGPT-PRs中的4%和DevGPT-Issues中的5%的提示要求ChatGPT詳細說明其回應。這些詳細說明請求旨在確保解決方案的全面性,例如,"我還需要做其他事情嗎?"。它們還包括驗證ChatGPT處理特定任務的能力,或查詢以驗證在回應中是否考慮了某些條件。此外,開發人員可能會詢問為什麼ChatGPT忽略了某些替代方案,表明對提出的解決方案有更深入的參與,並希望了解ChatGPT提出解決方案背後的理由。
4.2.2 研究問題2.2 多輪對話中的流程模式是什麼?
圖5呈現了在研究問題2.1的結果基礎上,對標註對話應用後處理步驟後的馬爾可夫轉換圖所得到的流程圖。該流程圖適用於DevGPT-PRs和DevGPT-Issues中的多輪對話。如圖5所示,多輪對話通常以呈現初始任務(M2)或上下文信息(M4)開始。
\ 我們詳細的後續分析顯示,DevGPT-PRs中81%的多輪對話和DevGPT-Issues中90%的多輪對話以概述初始任務開始。相反,DevGPT-PRs中約13%的多輪對話和DevGPT-Issues中3%的多輪對話在第二個提示中介紹初始任務。在極端情況下,初始任務在第七輪才被披露,或者在某些情況下,初始任務從未被明確呈現—相反,這些對話只向ChatGPT呈現信息,而沒有直接說明任務。
\ 至於完整流程,我們基於圖5識別了以下模式:
開始 → 揭示初始任務 → 迭代跟進 → 結束
開始 → 揭示初始任務 → 精煉提示 → (迭代跟進) → 結束
開始 → 揭示初始任務 → 揭示新任務 → 結束
開始 → 提供信息 → 揭示初始任務 → ... → 結束
開始 → 揭示初始任務 → 要求澄清 → 結束
開始 → 揭示初始任務 → 負面反饋 → 結束
\ 流程模式(1)到(3)顯示了多輪對話中最常見的開發人員-ChatGPT互動流程。初始任務在初始提示中披露,隨後是旨在通過迭代跟進、提示精煉或揭示新任務來改進ChatGPT回應的提示。
模式(4)展示了由開發人員首先提供信息給ChatGPT開始的互動流程。然後,初始任務被揭示,接著是類似於(1)到(3)的模式。模


