TL;DR
Chat-Debugging — это протокол общения с LLM при диагностике сложной проблемы с несколькими возможными причинами: контекст даётся порциями, модель просят предложить несколько гипотез причины (не одну), каждая гипотеза проверяется тестом по очереди, а пользователь регулярно напоминает модели забытые детали.
Главная находка исследования: в длинном диалоге модель начинает терять нить — путает, какая деталь к чему относится. В примере из статьи студент спросил "можно использовать GP15?", имея в виду пин для светодиода, а модель решила, что речь про питание, и ответила неправильно. Причина простая — модель держит "в голове" весь предыдущий текст диалога, и чем он длиннее и сложнее, тем легче ей перепутать детали.
Протокол решает это через постоянный контроль пользователя: не вываливать всю систему сразу, а вести диалог шагами — понять систему → протестировать → выдвинуть гипотезы → проверить по одной → зафиксировать решение, — и на каждом шаге поправлять модель, если она сбилась.
Схема метода
ШАГ 1: Опиши систему по частям (не всё сразу) → модель объясняет, как должно работать
ШАГ 2: Попроси тест-план → модель даёт пошаговую проверку
ШАГ 3: Сообщи результат теста → модель предлагает НЕСКОЛЬКО гипотез причины, от вероятной к менее вероятной
ШАГ 4: Проверяй гипотезы по одной, докладывай результат → модель сужает круг или меняет гипотезу
ШАГ 5: Нашли причину → попроси финальный тест, чтобы подтвердить фикс
Все шаги — в одном диалоге, но каждый шаг = отдельное сообщение с новой порцией информации, а не один длинный промпт.
Пример применения
Задача: Запустили рекламу в Яндекс.Директ неделю назад. Показы и клики есть, заявок — ноль. Непонятно, в чём проблема: реклама, посадочная страница или форма.
Промпт:
У меня проблема: рекламная кампания в Яндекс.Директ работает неделю.
Показов 5000, кликов 120, заявок 0.
Контекст: нишу — [ремонт квартир], посадочная страница — [квиз-лендинг],
бюджет — [15000 руб/неделю], гео — [Москва].
Помоги разобраться:
1. Кратко объясни, что должно происходить на каждом этапе (показ → клик → заявка).
2. Предложи несколько возможных причин, почему заявок нет — от самой
вероятной к менее вероятной. Для каждой причины дай способ проверки.
Жди мои результаты теста перед следующим шагом, не сваливай всё в один ответ.
Результат: модель распишет путь клиента (показ-клик-заявка), затем даст список гипотез — например, "форма не грузится на мобильных", "нет чёткого призыва к действию", "аудитория не целевая" — с конкретным способом проверить каждую. После того как пользователь протестирует и отпишется по одной гипотезе, модель сузит круг или предложит следующую. Диалог растянется на несколько сообщений, а не решится одним ответом.
Почему это работает
LLM плохо держит длинный контекст без напоминаний — детали "плывут", особенно если в диалоге много технической информации вперемешку. Это слабость, с которой сталкивается любой длинный чат, не только про схемы.
Зато LLM хорошо умеет генерировать сразу несколько гипотез — то, с чем часто плохо справляется человек один, застревая на первой пришедшей в голову идее. Модель насыпает варианты из своих знаний быстрее, чем человек их придумает сам.
Протокол использует эту силу (много гипотез сразу), но компенсирует слабость (забывание контекста) простым правилом — давать информацию порциями и не бояться поправлять модель, когда она путает детали. Это не техническая хитрость, а дисциплина общения.
Рычаги управления: - Число гипотез за раз → попроси "дай 5 вариантов" вместо одного, если хочешь шире охватить проблему - Частота напоминаний контекста → если диалог длинный, раз в 5-7 сообщений скажи "напомню: у нас вот такие условия..." - Порядок гипотез → попроси сортировать "от простого теста к сложному", если хочешь экономить время на проверках
Шаблон промпта
У меня проблема: {краткое описание системы или ситуации}.
Симптом: {что не работает так, как должно}.
Контекст (дам по частям, если сложно):
{деталь 1}
{деталь 2}
Помоги мне разобраться:
1. Кратко объясни, как это должно работать в норме.
2. Предложи тест, чтобы проверить, работает ли как ожидается.
Жди мои результаты теста перед следующим шагом.
Если предложишь причины проблемы — дай несколько вариантов,
от самых вероятных к менее вероятным, и для каждого — способ проверки.
Подставляй: {краткое описание системы} — что за процесс/устройство/проект, {симптом} — что конкретно не работает, {деталь} — параметры, которые важны для диагностики (давай их порциями, а не всё сразу).
🚀 Быстрый старт — вставь в чат:
Вот шаблон Chat-Debugging протокола. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие детали у тебя есть и как разбить их на порции — потому что метод работает только если контекст подаётся дозированно, а не единым потоком.
Ограничения
⚠️ Требует терпения: метод не даёт быстрый ответ за один промпт. Для сложных многофакторных задач диалог растягивается на десятки сообщений — это осознанный обмен скорости на точность.
⚠️ Нужен активный контроль: модель забывает детали в длинных диалогах и путает контекст. Без регулярных напоминаний она начнёт выдавать решения, не соответствующие реальной ситуации.
⚠️ Малая выборка: выводы построены на кейсе одного студента и нескольких его диалогах. Это не статистика, а качественное наблюдение — паттерн вероятный, но не доказанный на широкой аудитории.
Как исследовали
Исследователи взяли одного студента-электрика четвёртого курса (под псевдонимом Дэниел) и попросили поделиться логами его переписки с GPT-4o во время реальных учебных проектов — три диалога: чисто софтверный баг, связка железа с кодом, и чисто "железный" дебаг светодиодной схемы. Два исследователя независимо разбирали логи и интервью с Дэниелом методом постоянного сравнения (constant comparative analysis) — по сути, искали повторяющиеся темы вручную, без автоматической разметки.
Сравнение трёх диалогов показало разницу: софтверный баг чинился за один обмен сообщениями, а "железный" дебаг требовал многих итераций с гипотезами и тестами. Удивило исследователей то, что даже самые короткие и разговорные промпты типа "мне нужно подключить батарею на 11.1В к светодиоду" модель понимала корректно — кроме одного случая ("test LED"), когда контекста было слишком мало.
Главный практический инсайт: успех дебага зависел не от качества модели, а от того, насколько настойчиво студент поправлял её и вёл процесс сам, а не ждал готового решения.
Ресурсы
Andrew Ash, John Hu — Oklahoma State University, School of Electrical and Computer Engineering. Исследование поддержано NSF Award EES-2321255.