TL;DR
Если попросить LLM «придумай хорошие вопросы по этому разговору» — получишь случайный результат: часть вопросов окажутся очевидными, часть нерелевантными. Исследование показывает, что лучший способ — разбить задачу на три последовательных шага: сначала очистить разговор от шума, потом сгенерировать много вопросов с разнообразием по категориям, потом самой же моделью оценить и оставить лучшие.
Главная боль: длинный диалог содержит много «пустого» контента — приветствия, повторы, нерелевантные реплики. Если сразу просить вопросы из сырого разговора, модель улавливает поверхностные темы, а не ключевые. Кроме того, если попросить «дай 3 вопроса», модель сгенерирует первое что пришло, без системного охвата разных углов.
Решение — трёхагентная цепочка в одном или нескольких запросах: Summarizer превращает разговор в структурированную выжимку, Generator создаёт 10 вопросов по шести категориям с few-shot примерами, Evaluator прогоняет через CoT-оценку (плюсы/минусы → баллы) и выбирает топ-3.
Схема метода
ШАГ 1 — SUMMARIZER (1 запрос)
Вход: разговор + контекст о человеке
Задача: извлечь ключевую информацию, убрать шум
Формат вывода: структурированные поля
(главная проблема / история / текущий статус / план)
ШАГ 2 — GENERATOR (1 запрос)
Вход: структурированная выжимка из Шага 1
Задача: сгенерировать 10 вопросов
по 6 категориям (диагноз / действия / детали /
решения / follow-up / консультация)
с 2 few-shot примерами «хорошего вопроса»
Формат вывода: 10 пронумерованных вопросов
ШАГ 3 — EVALUATOR (1 запрос)
Вход: 10 вопросов из Шага 2
Задача: для каждого вопроса — плюсы и минусы,
потом балл по каждому критерию
Формат вывода: топ-3 по среднему баллу
Все три шага выполняются последовательно, каждый в отдельном запросе. Вывод предыдущего — вход следующего.
Пример применения
Задача: После часового созвона с потенциальным инвестором нужно понять, какие три вопроса стоит проработать перед следующей встречей — чтобы закрыть его реальные сомнения, а не гадать.
Промпт — Шаг 1 (Summarizer):
Ты — аналитик переговоров. Прочитай транскрипт
встречи и заполни структурированный протокол.
ТРАНСКРИПТ:
{вставь текст созвона}
КОНТЕКСТ О ПРОЕКТЕ:
{краткое описание: что за стартап, на какой стадии,
что предлагали инвестору}
Заполни поля:
— Главный запрос инвестора (что хочет понять)
— Ключевые возражения (явные и скрытые)
— Что зацепило (на что реагировал позитивно)
— Открытые вопросы (что осталось невыясненным)
— Следующий шаг (что он ждёт от тебя)
Промпт — Шаг 2 (Generator):
На основе этого протокола встречи с инвестором
сгенерируй ровно 10 вопросов, которые мне нужно
проработать перед следующей встречей.
ПРОТОКОЛ:
{вставь вывод Шага 1}
ПРИМЕРЫ ХОРОШЕГО ВОПРОСА:
1. "Инвестор упомянул риск низкой маржи в B2B.
Какие данные по unit economics аналогичных
SaaS-компаний в РФ подтвердят, что наша модель
жизнеспособна при среднем чеке 50 000 руб.?"
2. "Он сравнил нас с конкурентом X. Чем конкретно
наш продукт отличается в сегменте МСБ, и есть ли
кейсы, которые это доказывают?"
Распредели вопросы по категориям:
— Данные и доказательства (3 вопроса)
— Стратегия и позиционирование (2 вопроса)
— Риски и возражения (2 вопроса)
— Команда и исполнение (1 вопрос)
— Условия сделки (1 вопрос)
— Follow-up действия (1 вопрос)
Каждый вопрос должен быть конкретным:
включать контекст из разговора и указывать
что именно нужно выяснить. Не общие вопросы.
Промпт — Шаг 3 (Evaluator):
Оцени каждый из 10 вопросов ниже.
ВОПРОСЫ:
{вставь вывод Шага 2}
Для каждого вопроса:
1. Кратко — главный плюс и главный минус
2. Оцени по трём критериям (1-5):
— Срочность (насколько критично ответить до встречи)
— Влияние (как сильно ответ изменит подготовку)
— Реалистичность (можно ли найти ответ за 3 дня)
3. Средний балл
В конце: выбери топ-3 по среднему баллу.
Объясни выбор одним предложением для каждого.
Результат: Шаг 1 даст структурированный протокол — без лишних слов из разговора, только суть. Шаг 2 — 10 конкретных вопросов с привязкой к деталям встречи и распределением по категориям. Шаг 3 покажет мини-рецензию на каждый вопрос (плюс/минус + баллы) и выделит топ-3 с объяснением, почему именно они важнее остальных.
Почему это работает
LLM плохо справляется с «зашумлёнными» входными данными. Разговор — это не структурированный документ. Там есть отступления, повторы, нерелевантные реплики. Если скормить это всё сразу, модель цепляется за самое частое и поверхностное, а не за ключевое. Сначала структурировать — значит убрать шум до начала основной работы.
LLM тяготеет к первым пришедшим ответам. Если попросить «дай 3 вопроса», модель остановится на первом, что успела сгенерировать. Попросить 10 с жёсткими категориями — значит принудительно раскрыть разные углы, которые она бы проигнорировала. Generate many, select few — это обход «первого достаточного ответа».
CoT-оценка (размышление → балл) точнее, чем прямая оценка. Если попросить «оцени вопросы», LLM даёт всем высокие баллы — она сама их написала. Но если сначала написать плюсы-минусы, а потом поставить балл — оценки становятся дифференцированными. Рассуждение перед числом ломает паттерн оптимизма. Именно это показало исследование: без CoT-процедуры LLM-судья давал всем высокие оценки.
Рычаги управления: - Категории в Шаге 2 → меняй под свою задачу: для ретроспективы — категории типа «что замедляло» / «что ускоряло» / «что повторить» - Число вопросов → уменьши с 10 до 6 для коротких входных данных - Критерии в Шаге 3 → замени «срочность/влияние/реалистичность» на свои; для редакции это может быть «читательская ценность / оригинальность / объём работы» - Примеры в Шаге 2 → чем точнее примеры под твой контекст, тем острее вопросы
Шаблон промпта
Шаг 1 — Summarizer
Прочитай {тип_входных_данных} и заполни протокол.
ВХОДНЫЕ ДАННЫЕ:
{текст_разговора_или_документа}
КОНТЕКСТ:
{краткое_описание_ситуации}
Заполни поля:
— {поле_1}: {что_извлечь}
— {поле_2}: {что_извлечь}
— {поле_3}: {что_извлечь}
— {поле_4}: {что_извлечь}
Шаг 2 — Generator
На основе этого протокола сгенерируй ровно 10 вопросов
о {тема_вопросов}.
ПРОТОКОЛ:
{вывод_шага_1}
ПРИМЕРЫ ХОРОШЕГО ВОПРОСА:
1. {пример_1_с_контекстом}
2. {пример_2_с_контекстом}
Распредели по категориям:
— {категория_1} ({число} вопросов)
— {категория_2} ({число} вопросов)
— {категория_3} ({число} вопросов)
Каждый вопрос: конкретный, с привязкой к деталям
из протокола, указывает что именно нужно выяснить.
Шаг 3 — Evaluator
Оцени каждый из 10 вопросов:
ВОПРОСЫ:
{вывод_шага_2}
Для каждого:
1. Плюс и минус (одно предложение каждый)
2. Баллы (1-5) по критериям:
— {критерий_1}
— {критерий_2}
— {критерий_3}
3. Средний балл
Выбери топ-3. Объясни выбор.
Плейсхолдеры:
- {тип_входных_данных} — транскрипт встречи, статья, интервью, разбор конкурента
- {поля} — подбери под задачу: для анализа текста это «главный тезис / аргументы / пробелы / вопросы автора»
- {категории} — 4-6 категорий, покрывающих разные углы задачи
- {примеры} — 2 реальных примера хорошего вопроса из твоей области
- {критерии} — 3 параметра оценки, важных именно для тебя
🚀 Быстрый старт — вставь в чат:
Вот трёхшаговый шаблон для генерации лучших вопросов
из текста или разговора. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про тип входных данных, тему вопросов и нужные категории — потому что без этого она не знает, какую структуру и примеры подставить в шаблон.
Ограничения
⚠️ Качество примеров в Шаге 2 определяет всё: Если few-shot примеры расплывчатые — вопросы будут расплывчатыми. Два конкретных примера важнее любых инструкций.
⚠️ Не работает для субъективных или творческих оценок: LLM-судья в Шаге 3 систематически завышает баллы, когда критерии размытые («интересность», «оригинальность»). Чем конкретнее критерии — тем надёжнее оценка.
⚠️ LLM-as-judge = хороший для сравнения, ненадёжный для абсолюта: Модель правильно определяет, что одно лучше другого, но абсолютные баллы она завышает. Используй Шаг 3 чтобы выбрать лучшие из своих вариантов — не чтобы оценить «качество в вакууме».
⚠️ Слишком короткий входной текст: Метод покрывает разные категории. Если разговор был пятиминутным и однотемным — принудительное распределение по 6 категориям даст искусственные вопросы.
Как исследовали
Команда Google Research и двух университетов взяла датасет из 2000 реальных (деидентифицированных) записей визитов к врачу в США. Отфильтровали до первичной помощи, убрали выбросы по длине — осталось 810 случаев. Из них отобрали 80 для оценки. Каждый случай тестировали при трёх уровнях «обрезки» разговора: 30%, 70% и 100% от полного диалога — чтобы проверить, работает ли система в реальном времени, до окончания визита.
Что удивило: система работала одинаково хорошо при всех трёх уровнях контекста. При 30% диалога оценки были чуть выше, чем при 100% — потому что клинически важная информация часто звучит в начале, а дальше идёт шум. Это значит: не нужен полный материал, чтобы генерировать хорошие вопросы.
Шесть практикующих врачей (средний опыт 16,5 лет) провели 90+ часов, оценивая вопросы по пяти метрикам: релевантность, навигация по гайдлайнам, совпадение с клиническим мышлением, отсутствие избыточности, полезность. Менее 2% всех оценок были «вопросы не нужны» — показатель, что система генерирует реально полезный контент. Мультиэтапный фреймворк снизил долю «плохих» вопросов с 17% до 9% по сравнению с прямым zero-shot подходом.
Параллельно ту же оценку провёл Gemini 2.5 Pro. Направление эффекта совпало с оценками врачей — многоэтапный метод лучше. Но абсолютные баллы от LLM были заметно выше: модель систематически «добрее» людей. Главный риск — LLM-судья пропускал ошибки в ссылках на конкретные гайдлайны, которые врачи сразу замечали.
Адаптации и экстраполяции
🔧 Адаптация 1: Двухшаговая версия (без отдельного Evaluator)
Если хочешь сэкономить запросы — объедини Шаги 2 и 3 в один:
На основе протокола:
1. Сгенерируй 10 вопросов по {категориям}
2. Для каждого — одно предложение: что хорошо, что слабо
3. Выбери топ-3 по совокупности. Объясни выбор.
Теряешь немного качества отбора, но экономишь шаг.
🔧 Адаптация 2: Принцип «сначала структурируй» для любого сложного текста
Исследование показывает: структурирование входа важнее, чем качество промпта для генерации. Это переносится на любую задачу с длинным шумным текстом:
- Читаешь длинный договор и хочешь найти риски → сначала попроси выжать в «ключевые условия / обязательства / ограничения / открытые вопросы», потом анализируй
- Читаешь большое исследование и хочешь применить идеи → сначала схема «главный тезис / механика / ограничения», потом «как применить в моём контексте»
Принцип: шумный входной текст → структурированный протокол → генерация работает лучше прямого «прочитай и скажи».
🔧 Адаптация 3: Применение инсайта про LLM-as-judge
Если используешь LLM для сравнения вариантов — доверяй ей на относительные суждения (А лучше Б?), но не на абсолютные (насколько хорошо А?). Чтобы сделать оценку точнее:
Перед тем как дать баллы — напиши для каждого варианта:
главный аргумент ЗА и главный аргумент ПРОТИВ.
Потом поставь баллы.
CoT перед числом частично компенсирует системный оптимизм модели.
Ресурсы
Название работы: Dialogue to Question Generation for Evidence-based Medical Guideline Agent Development
Публикация: Proceedings of Machine Learning Research 297, ML4H 2025
GitHub с промптами: https://github.com/Jerryji007/Dialogue2QuestionsML4H2025
Авторы: Zongliang Ji, Ziyang Zhang, Xincheng Tan, Matthew Thompson, Anna Goldenberg, Carl Yang, Rahul G. Krishnan, Fan Zhang
Организации: Google Research, University of Toronto, Vector Institute (Канада), Emory University (США)
Упомянутые системы: Gemini 2.5 Flash/Pro, AMIE (Google DeepMind)