Аналіз потоку запитів розробників у розмовах ChatGPT

Table Of Links

Abstract

1 Introduction

2 Data Collection

3 RQ1: What types of software engineering inquiries do developers present to ChatGPT in the initial prompt?

4 RQ2: How do developers present their inquiries to ChatGPT in multi-turn conversations?

5 RQ3: What are the characteristics of the sharing behavior?

6 Discussions

7 Threats to Validity

8 Related Work

9 Conclusion and Future Work

References

\

RQ2: How do developers present their inquiries to ChatGPT in multi-turn conversations?

==Motivation:== Результати, представлені на Рисунку 3 та Рисунку 4, показують, що значна частина в DevGPT-PRs (33,2%) та DevGPT-Issues (26,9%) охоплює багатоетапні розмови. В одноетапних розмовах розробники ставлять запитання, пов'язане з SE, у початковому запиті та отримують одну відповідь від ChatGPT, забезпечуючи чіткий та прямий обмін. Динаміка багатоетапних розмов, однак, вносить складність. Ці взаємодії виходять за рамки простого запиту та відповіді, включаючи серію обмінів, які потенційно уточнюють, розширюють або пояснюють початковий запит.

\ Це багатошарове спілкування піднімає питання про стратегії розробників щодо формулювання своїх запитів протягом кількох етапів. Таким чином, ми вводимо RQ2, який вивчає природу запитів розробників у багатоетапних розмовах. Для полегшення комплексного аналізу ми додатково вводимо два під-RQ:

– RQ2.1: Які ролі запитів розробників у багатоетапних розмовах? Це питання спрямоване на категоризацію структурної ролі кожного запиту у відповідній багатоетапній розмові.

– RQ2.2: Які шаблони потоку в багатоетапних розмовах? На основі таксономії, запропонованої як відповідь на RQ2.1, це питання досліджує частий шаблон переходу цих ідентифікованих ролей запитів у багатоетапних розмовах. Відповіді на вищезазначені під-RQ нададуть дослідникам уявлення про динаміку та практики розробників у використанні ChatGPT через кілька раундів взаємодії.

\ 4.1 Approach

У RQ2.1 ми розглядаємо запити у всіх 189 багатоетапних розмовах, тобто 64 розмови з DevGPT-PRs та 125 з DevGPT-Issues. Слідуючи методу, подібному до RQ1, ми використовували відкрите кодування для ручного маркування 645 запитів (236 запитів з DevGPT-PRs та 409 запитів з DevGPT-Issues) у багатоетапних розмовах протягом трьох раундів:

– У першому раунді п'ять співавторів незалежно маркували випадково вибрані 20 розмов з обох наборів даних багатоетапних DevGPT-PRs та DevGPTIssues, що охоплювали 40 розмов та 123 запити. Після обговорення ми розробили кодову книгу, що складається з семи різних міток.

– У другому раунді, на основі існуючої кодової книги, два анотатори незалежно маркували ще один набір з 20 розмов з кожного з наборів даних багатоетапних DevGPT-PRs та DevGPT-Issues, загалом 144 запити. Два анотатори досягли показника міжоцінювальної згоди 0,89, виміряного за допомогою коефіцієнта каппа Коена, що представляє майже ідеальну згоду (Landis and Koch, 1977). Потім анотатори обговорили та уточнили кодову книгу.

\ – Нарешті, кожен з двох анотаторів з другого раунду незалежно маркував решту даних. У RQ2.2 ми використовуємо модель Маркова (Gagniuc, 2017) для аналізу шаблонів потоку розмови шляхом побудови графіка переходів Маркова. Графік переходів Маркова - це спрямований граф, який демонструє ймовірнісні переходи

між різними станами або вузлами. У нашому випадку кожен вузол у графі представляє певну категорію, розроблену в RQ2.1, а спрямовані ребра між вузлами позначають ймовірність переходу від однієї таксономії до іншої на основі зібраних нами багатоетапних розмов. Для отримання змістовних висновків з графіка переходів Маркова ми пропонуємо наступні кроки постобробки:

1. Ми обрізали граф, видаливши переходи з ймовірностями нижче 0,05, забезпечуючи фокус на статистично значущих відносинах.

2. Ми уточнили структуру графа, видаливши вузли без вхідних та вихідних ребер, за винятком початкових та кінцевих вузлів. Цей крок забезпечує спрощення, оскільки ми зберігаємо лише основні компоненти.

3. Ми систематично реорганізували графік переходів Маркова у блок-схему для покращення його інтерпретованості, пропонуючи більш зрозуміле представлення шаблонів потоку.

   \ 4.2 Results

   4.2.1 RQ 2.1 What are the roles of developer prompts in multi-turn conversations? Таблиця 4 представляє нашу запропоновану таксономію для класифікації запитів у багатоетапних розмовах. Наш аналіз показує, що як у запитах на злиття, так і в проблемах, багатоетапні розмови містять три основні типи запитів: ті, що ставлять додаткові запитання (M1), ті, що представляють початкове завдання (M2), і ті, що уточнені з попереднього запиту (M3). Один запит з DevGPT-PRs та шість запитів з DevGPT-Issues були віднесені до категорії "Інші" через їх характер, що є або випадковою розмовою, або не має достатньо деталей для визначення їх ролей.

   \ Нижче ми описуємо кожну категорію більш детально.

   ==(M1) Iterative follow-up:== У 33% та 40% запитів у багатоетапних DevGPT-PRs та DevGPT-Issues розробники публікують запити, які безпосередньо ґрунтуються на попередніх відповідях ChatGPT або поточному контексті, такі як налагодження та виправлення рішення після генерації коду ChatGPT. Такі ітеративні подальші запити зазвичай виникають, коли початкове завдання представляє складну проблему, яку ChatGPT може не повністю вирішити за одну взаємодію. Отже, розробники беруть участь у запиті, вказуючи подальший запит, що дозволяє ChatGPT включити відгук людини та ітеративно покращити запропоноване рішення.

   \ ==(M2) Reveal the initial task:== Ми виявили, що подібна частка, тобто 26% у багатоетапних DevGPT-PRs та 29% у багатоетапних DevGPT-Issues, запитів служить для представлення початкового завдання ChatGPT. Цей розподіл підкреслює, що в багатоетапних розмовах, на відміну від одноетапних розмов, де єдиний запит присвячений окресленню основного завдання, є значна кількість запитів, що служать іншим цілям.

   \ ==(M3) Refine prompt:== Крім ітеративного подальшого запиту (M1), розробники також схильні покращувати рішення, запропоноване ChatGPT, надаючи уточнений запит з додатковим контекстом або обмеженнями. Метою є покращення якості відповіді на той самий запит, опублікований у попередньому запиті. Уточнені запити складають 17% запитів у багатоетапних DevGPT-PRs та 14% у DevGPT-Issues.

   \ ==(M4) Information giving:== У 8% та 6% запитів у багатоетапних DevGPT-PRs та DevGPT-issues розробники не публікують жодного запиту для ChatGPT, а скоріше діляться знаннями або контекстом з ChatGPT.

   \ ==(M5) Reveal a new task== Ми спостерігаємо, що 7% та 4% запитів у багатоетапних DevGPT-PRs та DevGPT-issues публікують нове завдання для ChatGPT, яке відрізняється від завдання(завдань), що розглядалися в попередніх запитах. Ця категорія представляє чітку відмінність від ітеративних подальших запитів (M1), оскільки нове завдання не пов'язане з попередніми відповідями ChatGPT і не ґрунтується на них, а спрямоване на іншу мету. Наприклад, розробник спочатку попросив ChatGPT згенерувати SQL, що відповідає набору запитів Django, а в наступному запиті попросив SQL для іншого набору запитів, тим самим змінивши фокус розмови на абсолютно нове завдання без попередньої релевантності.

   \ ==(M6) Negative feedback:== У багатоетапних розмовах деякі (6% у DevGPT-PRs та 2% у DevGPT-Issues) запити містять лише негативний відгук, спрямований на попередні відповіді ChatGPT, не надаючи жодної інформації для покращення або подальшого вирішення ChatGPT. Наприклад, "Ваш код неправильний", "Та сама помилка зберігається" та "...не працює". Ця категорія підкреслює випадки, коли розробники прагнуть повідомити ChatGPT про його недоліки, не шукаючи подальшої допомоги чи роз'яснення.

   \ (M7) Asking for clarification: 4% та 5% запитів у багатоетапних DevGPTPRs та DevGPT-Issues просять ChatGPT розширити свою відповідь. Ці запити на розширення спрямовані на забезпечення комплексності рішення, наприклад, "Чи потрібно мені робити щось ще?". Вони також включають перевірку здатності ChatGPT виконувати конкретні завдання або запити для перевірки того, чи були враховані певні умови у відповіді. Крім того, розробники можуть запитувати, чому деякі альтернативи були проігноровані ChatGPT, що вказує на глибшу взаємодію з запропонованими рішеннями та бажання зрозуміти обґрунтування запропонованого рішення ChatGPT.

   4.2.2 RQ 2.2 What are the flow patterns in multi-turn conversations?

   Рисунок 5 представляє отриману блок-схему після застосування кроків постобробки на графіку переходів Маркова на основі анотованих розмов як результат RQ2.1. Блок-схема застосовується до багатоетапних розмов як у DevGPT-PRs, так і в DevGPT-Issues. Як показано на Рисунку 5, багатоетапні розмови зазвичай починаються з представлення початкового завдання (M2) або контекстної інформації (M4).

   \ Наш детальний подальший аналіз показує, що 81% багатоетапних розмов у DevGPT-PRs та 90% у DevGPT-Issues починаються з окреслення початкового завдання. І навпаки, близько 13% багатоетапних розмов у DevGPT-PRs та 3% у DevGPT-Issues представляють початкове завдання у другому запиті. У крайніх випадках початкове завдання розкривається так пізно, як на сьомому