TL;DR
BRQGen — это цикл из одного запроса к LLM на каждом шаге. Модель получает баг-репорт, перечисляет пробелы, без которых проблему не воспроизвести, и задаёт вопросы только по этим пробелам. Если пробелов нет, отчёт считается достаточным и вопросов не будет. Автор отвечает, модель проверяет достаточность каждого ответа, находит новые пробелы, которые ответы вскрыли, и спрашивает снова. Максимум пять кругов.
Главная проблема в том, что у модели два плохих режима. Если просить «улучши отчёт», она дописывает недостающее сама и выдумывает. В статье со ссылкой на другую работу: доля неверной информации выросла с 2,9% до 13,7%. Если просить «задай уточняющие вопросы», она всегда задаёт одно и то же число вопросов, даже когда всё и так ясно. Люди раздражаются, а время тратится впустую. Кроме того, чем позже у автора спрашивают, тем меньше шансов на ответ и тем он медленнее: при запросе в первый час медианный ответ приходит за 0,5–1,5 часа, после четырёх часов — за 10–13 часов.
Метод состоит из трёх ролей в одном вызове. Оценщик находит пробелы, оценщик ответов проверяет, закрыли ли их, генератор формулирует вопросы. Модель не домысливает, а возвращает вопрос человеку, и останавливается, когда пробелов не осталось. Самое полезное для практики: хватает двух кругов. Первые два раунда дают почти все вопросы, которые вообще удалось получить.
Схема метода
КРУГ 1 (один запрос):
Роль «Оценщик отчёта»: найти пробелы, мешающие воспроизвести → список пробелов
Пробелов нет? → СТОП, отчёт достаточен
Роль «Генератор вопросов»: вопросы только по найденным пробелам → вопросы автору
КРУГ 2–5 (один запрос на круг, после ответов автора):
Роль «Оценщик ответов»: для каждой пары вопрос–ответ — достаточно или нет
+ новые пробелы, вскрытые ответами
Роль «Генератор вопросов»: вопросы только по оставшимся пробелам
СТОП, когда:
• все критичные поля полны и однозначны, ИЛИ
• автор не ответил ни на один вопрос, ИЛИ
• достигнут максимум кругов (5)
Роли выполняются в одном запросе. Следующий запрос нужен после того, как человек ответил.
Пример применения
Задача: Менеджер интернет-магазина на Битрикс24 пишет в чат разработчикам: «Оплата через СБП иногда не проходит, клиенты жалуются». Разработчик хочет не гадать, а сразу получить от ассистента список того, чего не хватает, чтобы воспроизвести проблему.
Промпт:
Ты — триаж-инженер. Твоя работа: решить, достаточно ли в баг-репорте
информации для воспроизведения, и если нет — задать автору вопросы.
Ты не дописываешь недостающее сам и ничего не додумываешь.
Заголовок: Оплата через СБП иногда не проходит
Текст: Клиенты жалуются, что оплата через СБП не проходит. Началось на этой неделе.
Магазин на Битрикс24, эквайринг — Т-Банк.
Круг 1:
1. Перечисли пробелы: что отсутствует или двусмысленно и мешает воспроизвести.
Для каждого пробела укажи серьёзность: высокая / средняя / низкая.
2. Если пробелов нет — напиши «ДОСТАТОЧНО» и остановись.
3. Сформулируй вопросы автору ТОЛЬКО по найденным пробелам.
Один пробел — один конкретный вопрос. Не больше 5 вопросов.
Круги 2–5 (когда я пришлю ответы):
1. По каждой паре «вопрос–ответ» реши: достаточно / недостаточно.
2. Найди новые пробелы, которые вскрыли ответы.
3. Задай вопросы только по оставшимся пробелам.
Остановись, если все критичные пробелы закрыты или я не ответил ни на один вопрос.
Результат: Модель выдаст список пробелов с серьёзностью (шаги до ошибки, текст ошибки, устройство и браузер, доля неудачных платежей, примеры заказов) и 3–5 конкретных вопросов, привязанных к пробелам. После вашего ответа она оценит каждый ответ как достаточный или нет, добавит новые вопросы по вскрывшимся деталям или напишет «ДОСТАТОЧНО». Никаких выдуманных шагов воспроизведения в выводе быть не должно.
Почему это работает
Слабость LLM. Если просить «дополни отчёт», модель выдаёт правдоподобный, но выдуманный текст. Если просить «задай вопросы», она задаёт их по привычке, даже когда всё ясно, потому что вопросы — это то, что её просили сделать. Решение «достаточно или нет» она по умолчанию не принимает.
Сильная сторона. Модель хорошо перечисляет, чего не хватает, и формулирует конкретные вопросы по списку. Проверить, закрыл ли ответ пробел, ей тоже проще, чем придумать содержание с нуля.
Как метод это использует. Он разделяет «найди пробелы» и «сформулируй вопросы». Вопросы привязаны к списку, а не к желанию модели быть полезной. Условие «пробелов нет → стоп» даёт честный выход без обязательных вопросов. Проверка ответов на следующем круге ловит случаи вроде «не знаю» или «посмотри сам».
Рычаги управления: - Число кругов → хватает двух. Больше — рост расхода без прироста новых вопросов. - Порог серьёзности → спрашивай только о пробелах высокой серьёзности. В статье при учёте только таких пробелов решение «полно / неполно» у лучшей модели заметно точнее. - Лимит вопросов за раз → меньше вопросов — выше шанс, что человек ответит. - Условие выхода → можно заменить на «хватает данных, чтобы я начал работу».
Шаблон промпта
Ты — {роль_проверяющего}. Твоя работа: решить, достаточно ли в {тип_документа}
информации для {цель}, и если нет — задать автору вопросы.
Ты не дописываешь недостающее сам и ничего не додумываешь.
{текст_документа}
{контекст_проекта_или_шаблон_полей}
Круг 1:
1. Перечисли пробелы: что отсутствует или двусмысленно и мешает {цель}.
Для каждого укажи серьёзность: высокая / средняя / низкая.
2. Если пробелов нет — напиши «ДОСТАТОЧНО» и остановись.
3. Задай вопросы ТОЛЬКО по найденным пробелам (учитывай {порог_серьёзности}).
Один пробел — один вопрос. Не больше {макс_вопросов} вопросов.
Круги 2–{макс_кругов} (когда пришлют ответы):
1. По каждой паре «вопрос–ответ» реши: достаточно / недостаточно.
2. Найди новые пробелы, которые вскрыли ответы.
3. Задай вопросы только по оставшимся пробелам.
Остановись, если: все критичные пробелы закрыты, ИЛИ автор не ответил
ни на один вопрос, ИЛИ достигнут круг {макс_кругов}.
Что подставлять: {роль_проверяющего} — тестировщик, аккаунт-менеджер, аналитик. {цель} — воспроизвести ошибку, оценить задачу, составить ТЗ. {порог_серьёзности} — «только высокая» или «высокая и средняя». {макс_кругов} — по статье, 2–3 достаточно.
Важно: в доступной части статьи самих промптов нет. Шаблон выше — реконструкция по описанию ролей, цикла и условий остановки.
🚀 Быстрый старт — вставь в чат:
Вот шаблон BRQGen — цикл «найди пробелы → спроси только по ним → проверь ответы».
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что за документ проверяется, какой результат считается «достаточно информации» и какие поля обязательны. Метод держится на списке пробелов, привязанном к цели, поэтому без чёткой цели модель найдёт случайные недочёты.
Ограничения
⚠️ Оценка полноты ненадёжна: модели часто ошибаются в самом решении «хватает данных или нет». Лучшая по этой метрике показала лишь чуть меньше половины по сбалансированной точности (macro-F1). Это решение стоит перепроверять глазами.
⚠️ Покрытие вопросов — около половины: лучшая модель задала примерно половину вопросов, которые реально задали разработчики-люди, худшая — треть. Ассистент не заменяет опытного разработчика, он снимает рутину.
⚠️ Детальные вопросы хуже: вопросы, специфичные для проекта и не вытекающие из шаблона, модель угадывает заметно реже, чем стандартные («версия, ОС, шаги»). Без контекста проекта (авторы планируют добавить поиск по документации) качество ограничено.
⚠️ Лёгкие случаи сложнее: точность определения «полно / неполно» растёт, когда пробел серьёзный. Мелкие недочёты модель путает с нормой.
⚠️ Корреляция, не причина: вывод «ранний вопрос → быстрый ответ» получен по историческим данным без эксперимента. Возможно, свою роль играют сложность задачи и вовлечённость автора.
⚠️ Тест на симуляторе: ответы авторов брались из истории, а не от живых людей. Реальные люди отвечают иначе.
⚠️ Неполный текст: в доступной части статьи нет полных промптов, нет сравнения с простыми базовыми схемами и нет разбора по числу кругов в деталях.
Как исследовали
Команда выбрала два крупных открытых проекта: Home Assistant (умный дом) и Brave Browser. В обоих мейнтейнеры ставят метку «нужно больше информации». По метке и ответу автора набрали 649 кандидатов, три разметчика вручную вытащили из них вопросы разработчиков и ответы авторов. После отсева осталось 429 неполных отчётов с 1081 вопросом. Вопросы разметили как «общие» (закрываются полями шаблона) и «детальные» (требуют вникания в суть). Для проверки решения «полно / неполно» собрали ещё 429 заведомо полных отчётов, которые были закрыты без единого уточнения.
Три современные модели «лёгкого» класса (Gemini 3 Flash Preview, DeepSeek V4.1 Flash, Qwen 3.8 Flash) прогнали по циклу. Роль пользователя играл симулятор: он сопоставлял вопрос модели с реальным вопросом разработчика и возвращал настоящий ответ автора. Покрытие реальных вопросов составило от 35% до 52%. DeepSeek лучше всего справился с общими вопросами (около 64%) и хуже с детальными (около 46%). Gemini точнее остальных решал «полно / неполно», но всё равно лишь около 49%. Если учитывать только пробелы высокой серьёзности, у Qwen точность выросла до 74%.
Отдельно исследователи проверили, зачем вообще спрашивать рано. В реальных данных запросы в первый час получали ответ заметно быстрее и чаще, чем запросы после четырёх часов. Практический вывод: спрашивай быстро, спрашивай мало, спрашивай по делу, и двух кругов достаточно.
Адаптации и экстраполяции
🔧 Техника: порог серьёзности → меньше лишних вопросов
Раз модель точнее определяет полноту, когда пробел серьёзный, добавь жёсткое правило:
Задавай вопросы только по пробелам с серьёзностью «высокая».
Пробелы средней и низкой серьёзности перечисли отдельным списком
«Можно уточнить позже», но не превращай их в вопросы.
Если высоких пробелов нет — напиши «ДОСТАТОЧНО».
Эффект: человеку не приходится отвечать на мелочи, а решение «спрашивать или нет» опирается на самую надёжную часть работы модели.
Экстраполяция: сбор ТЗ от клиента
Этот же цикл подходит для брифов на сайт, ТЗ на автоматизацию или заявок в студию. Нужно заменить документ и цель:
Ты — менеджер проектов в студии. Решаешь, хватает ли в брифе клиента
информации, чтобы оценить задачу и назвать срок. Ничего не додумываешь.
{текст_брифа}
Круг 1: найди пробелы, мешающие оценить срок и стоимость (высокая / средняя / низкая серьёзность).
Если высоких пробелов нет — «ДОСТАТОЧНО, можно оценивать».
Иначе — до 4 вопросов клиенту, простым языком, без жаргона.
Круг 2: проверь ответы по каждому вопросу, найди новые пробелы.
Максимум 2 круга.
Ресурсы
- BRQGen: Towards Adaptive Completeness Assessment and Follow-Up Question Generation for Bug Reports
- Авторы: Tevfik Emre Sungur (Technical University of Munich), Akif Emre Köşüş, Uğurcan Doğruçam, Eray Tüzün (Bilkent University, Турция)
- Данные: баг-репорты репозиториев home-assistant/core и brave/brave-browser; пакет для воспроизведения упомянут авторами (в доступной части текста не приведён)
- Связанные работы из статьи: ClarifyGPT (уточняющие вопросы при неоднозначности требований), FeedAIde, ImproBR, ChatBR