摘要
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和DevGPT-Issues的提示中,分别有33%和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和DevGPT-Issues的提示中,分别有8%和6%的开发者不向ChatGPT发布任何请求,而是与ChatGPT分享知识或上下文。
\ ==(M5) 揭示新任务== 我们观察到,多轮DevGPT-PRs和DevGPT-Issues的提示中分别有7%和4%向ChatGPT发布了一个新任务,该任务与先前提示中涉及的任务不同。这个类别与迭代跟进(M1)有明显区别,因为新任务与ChatGPT先前的回应无关,也不基于它们,而是针对不同的目标。例如,一个开发者最初请求ChatGPT生成与Django查询集对应的SQL,随后在另一个提示中要求为不同的查询集生成SQL,从而将对话焦点转移到一个全新的、与先前无关的任务上。
\ ==(M6) 负面反馈:== 在多轮对话中,少数(DevGPT-PRs中6%,DevGPT-Issues中2%)提示仅包含针对ChatGPT先前回应的负面反馈,没有提供任何信息让ChatGPT改进或进一步解决。例如,"你的代码不正确","同样的错误仍然存在",和"...不起作用"。这个类别强调了开发者寻求告知ChatGPT其缺点的实例,而不寻求进一步的帮助或澄清。
\ (M7) 要求澄清: 多轮DevGPT-PRs和DevGPT-Issues中分别有4%和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)的模式。模式(5)指的是开发者在揭示初始任务并从ChatGPT接收回应后要求ChatGPT澄清。
\ 模式(6)代表开发者在揭示初始任务并从ChatGPT接收回应后提供负面反馈的交互流程。虽然自循环被排除在图5之外,但重要的是要注意某些类型的提示,即那些揭示任务、细化先前提示、提出迭代跟进问题或提供信息的提示,可以重复出现。这种模式的一个例子是当开发者在两个连


