TL;DR
Multi-Turn Puzzles (MTP) — benchmark из пяти игр-головоломок для проверки способности LLM рассуждать и действовать логично в многоходовом диалоге. Задачи требуют задавать вопросы стратегически, выводить закономерности из неполной информации, помнить историю и не противоречить себе. Оценка автоматическая — по правилам игры, без судей-людей или других LLM.
Главная находка: почти все современные модели проваливают multi-turn задачи (кроме одной простой). Gemini 2.5 Pro набирает в среднем 56% успеха, Claude 3.5 Sonnet — 47%, GPT-4o — 45%. Причины провалов: плохое планирование (задают случайные вопросы вместо стратегических), поверхностные выводы (не учитывают взаимосвязи факторов), неумение переоценивать гипотезы при новых данных. Слабые модели спрашивают об одном признаке за раз и делают скоропалительные заключения. Сильные модели сравнивают варианты по нескольким параметрам сразу и пересматривают выводы когда появляются противоречия.
Для практики: исследование показывает anti-patterns и patterns multi-turn рассуждений. Вместо "нравится ли тебе X?" эффективнее "X или Y?" где варианты различаются по нескольким критериям. После каждого ответа — явно обновлять список гипотез: что исключили, что подтвердили, что осталось проверить. При противоречиях — не игнорировать, а пересмотреть всю логику с начала.
Задачи benchmark
MTP включает пять типов игр, каждая проверяет свой аспект multi-turn взаимодействия:
Word Guess — модель угадывает секретное слово из 40 вариантов. После каждой попытки получает обратную связь: сколько букв угадано и сколько на правильных позициях. Проверяет эффективность дедукции.
Movie Recommendation — модель задаёт 10 вопросов пользователю (симулятору с заданной функцией предпочтений), затем выбирает фильм из 40 вариантов. Фильмы описаны 8 атрибутами: темп, эмоциональность, диалоги и т.д. Проверяет умение выявлять предпочтения через опрос.
Circuit Decoding — модель исследует неизвестные булевы схемы, подавая на вход разные комбинации битов и наблюдая выход. Нужно вывести логику всех схем. Проверяет способность учиться через эксперименты.
Word Chaining — игра в слова: каждое новое слово начинается с последней буквы предыдущего. Модель и среда ходят по очереди. Проигрыш если повторил слово или нарушил правило. Проверяет память и детерминированное следование правилам.
Twenty Questions — модель выбирает секретное слово, пользователь задаёт до 20 да/нет вопросов. Модель должна отвечать логически последовательно — без противоречий с прошлыми ответами. Проверяет логическую согласованность в диалоге.
Результаты
Лучшая модель (Gemini 2.5 Pro) показала:
- Twenty Questions: 95% — почти без ошибок
- Word Guess: 62% — средний результат
- Movie Recommendation: 50% — половина провалов
- Circuit Decoding: 32% — большинство задач не решено
- Word Chaining: 30% — постоянные ошибки
Claude 3.5 и GPT-4o ещё слабее во всех задачах кроме Twenty Questions.
Trade-off стоимость-качество: внутри семейства Gemini 2.0 разница драматична. На Circuit Decoding: Pro — 32%, Flash — 7%, Flash-lite — 4%. Дешёвые модели экономят на рассуждениях.
Взаимозаменяемость: если слабая модель (Flash) начала диалог, а сильная (Pro) завершила — успех 76%. Наоборот (Pro начала, Flash завершила) — успех 75%. Финальный ход критичен в задачах с асимметричной структурой.
Почему слабые модели проваливаются
Сравнение Gemini 2.5 Pro и Gemini 2.0 Flash-Lite на задаче Movie Recommendation показало четыре типа ошибок:
1. Простая стратегия vs системный подход
Flash-Lite задаёт вопросы об одном атрибуте: "Какой фильм: с высоким темпом или с глубокими диалогами?" После ответа делает вывод только про один признак. Следующий вопрос никак не связан с предыдущим — нет общего плана.
Pro сравнивает фильмы по нескольким атрибутам сразу: выбирает пару где одно отличие ключевое (например, интеллектуальная глубина), а остальные параметры близки. Каждый вопрос проверяет гипотезу о важности факторов. При новых данных пересматривает прошлые выводы: "Раньше думал что темп важен, но этот ответ говорит что реализм перевешивает".
2. Неэффективные вопросы
Flash-Lite: хочет проверить важность саундтрека, но сравнивает два фильма где у обоих саундтрек на высоком уровне. Ответ не даёт информации — невозможно понять предпочтение.
Pro: если проверяет саундтрек, сравнивает фильмы где этот параметр сильно различается, а остальные похожи.
3. Поверхностные выводы
Flash-Lite после первого вопроса делает 5-6 заключений: "пользователь любит глубину, не любит темп, не любит диалоги...". Но вопрос сравнивал два фильма которые различались по всем параметрам — невозможно понять что именно повлияло на выбор.
Pro формулирует осторожно: "Возможно предпочитает интеллектуальную глубину, но нужно проверить отдельно от темпа и эмоциональности". Затем изолирует факторы через следующие вопросы.
4. Бесполезные вопросы
Flash-Lite на 10-м вопросе (последнем) спрашивает что-то случайное, хотя уже принял решение на 9-м ходу. Вопрос "для галочки".
Pro использует каждый вопрос чтобы уточнить модель предпочтений — даже последний даёт новую информацию для финального выбора.
Извлечённые принципы для практики
Хотя это исследование benchmark'а, можно извлечь стратегию опроса для задач где нужно понять предпочтения, требования или ситуацию через вопросы:
Стратегический опрос
Шаг 1: Планирование Перед каждым вопросом явно сформулируй:
- Какие гипотезы сейчас проверяешь
- Какой вопрос лучше всего различит между ними
- Что узнаешь из возможных ответов
Шаг 2: Многомерное сравнение Вместо "нравится ли X?" или "важен ли параметр Y?" — сравнивай варианты которые различаются по нескольким параметрам. Это даёт больше информации за один ход.
Шаг 3: История выводов После каждого ответа обновляй:
- Что теперь точно знаем
- Какие гипотезы исключили
- Какие гипотезы подтвердились
- Что осталось проверить
Шаг 4: Переоценка при противоречиях Если новый ответ противоречит прошлым выводам — не игнорируй. Пересмотри всю логику: возможно первоначальная интерпретация была неточной.
Пример применения
Задача: Подбираешь CRM-систему для клиента — небольшой студии веб-разработки. Нужно понять их приоритеты: цена, простота, интеграции, аналитика.
Промпт:
Ты помогаешь выбрать CRM для студии веб-разработки (7 человек). Критерии выбора: цена, простота интерфейса, интеграции с инструментами, глубина аналитики.
Используй стратегический опрос:
- Перед каждым вопросом выводи:
- Текущие гипотезы о приоритетах
- Какой вопрос их лучше различит
- Задавай вопросы сравнивая два варианта CRM которые различаются по 2-3 параметрам одновременно. Не спрашивай "важна ли цена?" — это слишком прямо.
- После каждого ответа обновляй:
ЗНАЕМ ТОЧНО:
- [что подтверждено]
ИСКЛЮЧИЛИ:
- [какие гипотезы отпали]
ОСТАЛОСЬ ПРОВЕРИТЬ:
- [что непонятно]- При противоречиях пересматривай выводы — возможно важность фактора зависит от контекста.
Задай 5 вопросов, затем предложи CRM с обоснованием.
Результат:
Модель будет задавать вопросы типа "Амо CRM (дёшево, базовая аналитика, много интеграций) или Битрикс24 (дороже, сложнее, глубокая аналитика)?" вместо расплывчатых "важна ли вам аналитика?". После каждого ответа — явно обновлять карту предпочтений. В финале — обоснованный выбор на основе всей истории диалога.
Почему это работает
LLM плохи в неявном планировании. В single-turn задачах вся информация дана сразу — модель может решать. В multi-turn нужно планировать последовательность ходов и помнить что уже узнали. Без явной структуры модели "забывают" план и задают случайные вопросы.
Многомерные сравнения — естественная задача для LLM. Модели хорошо понимают соотношения между признаками. Вопрос "X или Y?" где варианты различаются по нескольким параметрам даёт больше сигнала чем серия вопросов про каждый параметр отдельно. Один ход вместо трёх.
Явная история выводов предотвращает дрейф. В длинном диалоге модель может "забыть" что выяснила в начале. Принудительное обновление списка "знаем/исключили/осталось" после каждого хода держит контекст актуальным. Это как рабочая память — без неё модель теряет нить.
Переоценка гипотез — защита от confirmation bias. LLM склонны подтверждать первоначальные выводы игнорируя противоречащие данные. Явная инструкция "пересмотри всё при противоречиях" заставляет модель проверить логику заново.
Рычаги управления:
- Число вопросов: уменьши для простых задач, экономя токены
- Формат истории: убери блок "знаем/исключили" если хочешь свободный стиль — потеряешь структуру, но диалог будет естественнее
- Требование многомерности: убери если клиент сам хочет проверять по одному параметру
- Глубина переоценки: вместо "пересмотри всё" можно "проверь последние 3 вывода" — быстрее, но менее тщательно
Шаблон промпта
Ты решаешь {задачу требующую понимания через вопросы}.
Используй стратегический опрос:
1. ПЕРЕД КАЖДЫМ ВОПРОСОМ выводи:
- Текущие гипотезы: {что предполагаешь}
- План вопроса: {какой вопрос различит гипотезы}
2. ЗАДАВАЙ ВОПРОСЫ сравнивая варианты которые различаются по 2-3 параметрам одновременно. Не спрашивай прямо "важно ли X?" — это даёт мало информации.
3. ПОСЛЕ КАЖДОГО ОТВЕТА обновляй:ЗНАЕМ ТОЧНО:
- {подтверждённые факты}
ИСКЛЮЧИЛИ:
- {отпавшие гипотезы}
ОСТАЛОСЬ ПРОВЕРИТЬ:
- {неясные моменты}
4. ПРИ ПРОТИВОРЕЧИЯХ пересматривай всю логику — возможно первоначальная интерпретация была неточной.
Задай {число} вопросов, затем дай {финальное решение/рекомендацию}.Плейсхолдеры:
{задачу требующую понимания через вопросы}— выбор продукта, понимание клиента, выяснение требований, исследование темы{число}— количество вопросов (3-10 обычно достаточно){финальное решение/рекомендацию}— что должна выдать модель в конце
Ограничения
⚠️ Требует multi-turn: Техника бесполезна для single-turn задач где вся информация дана сразу. Оверхед в виде явного планирования и истории выводов оправдан только когда информацию нужно собирать по частям.
⚠️ Чувствительна к качеству модели: Исследование показало что дешёвые модели (Flash-lite) проваливают стратегическое планирование даже с явными инструкциями. Техника работает на Gemini 2.5 Pro, Claude 3.5+, GPT-4+ уровня.
⚠️ Не для открытых исследований: Если задача — исследовать тему без чёткой цели, жёсткая структура "гипотезы → проверка → выводы" может закрыть неожиданные направления. Техника для focused inquiry, не для exploratory research.
⚠️ Оверхед токенов: Явная история выводов после каждого хода раздувает промпт. В задачах с 20+ ходами может упереться в context window или стать дорого. Для длинных диалогов нужна компрессия истории.
Как исследовали
Команда Google DeepMind создала пять синтетических игр с автоматической проверкой — никаких судей-людей или LLM-оценщиков. Каждая игра проверяет свой аспект multi-turn взаимодействия.
Word Guess: 400 конфигураций (10 словарей по 40 слов). Модель угадывает секретное слово получая обратную связь о правильности букв и позиций.
Movie Recommendation: 1000 конфигураций (20 симулированных пользователей × 50 наборов фильмов). Пользователь имеет скрытую функцию предпочтений — линейную комбинацию весов для 8 атрибутов фильмов. Модель задаёт вопросы типа "какой фильм больше нравится: A или B?", затем выбирает из 40 новых фильмов.
Circuit Decoding: 300 конфигураций булевых схем (AND, OR, NOT гейты). Модель подаёт входные биты, смотрит выходные, выводит структуру схем.
Word Chaining и Twenty Questions: по 400 конфигураций, правила игры детерминированы — win/loss определяется однозначно.
Протестировали Gemini 2.5 Pro, Claude 3.5 Sonnet, GPT-4o. Результаты шокирующие: модели проваливают почти все задачи кроме Twenty Questions. Средний успех 30-62% в зависимости от задачи.
Почему такой провал? Качественный анализ диалогов показал:
- Слабое планирование — модели задают случайные вопросы вместо стратегических
- Поверхностные выводы — делают заключения не учитывая взаимосвязи факторов
- Неумение переоценивать — игнорируют противоречия вместо пересмотра логики
- Бесполезные вопросы — спрашивают то что не даёт информации (например, сравнивают два фильма одинаковых по проверяемому параметру)
Интересная находка про trade-off: внутри семейства Gemini 2.0 разница огромна. На Circuit Decoding: Pro — 32%, Flash — 7%, Flash-lite — 4%. Дешёвые модели экономят на рассуждениях настолько что задачи становятся нерешаемыми.
Взаимозаменяемость моделей: если слабая модель начала диалог, а сильная завершила — успех как у средней модели (75%). Это говорит что финальный ход критичен в задачах с асимметричной структурой (сбор информации → решение). Сильная модель может "спасти" плохо проведённое исследование на финальном шаге.
Авторы выложили датасет на HuggingFace — можно проверить свои модели или промпт-техники на этих задачах.
Ресурсы
Multi-Turn Puzzles: Evaluating Interactive Reasoning and Strategic Dialogue in LLMs — Kartikeya Badola, Jonathan Simon, Arian Hosseini, Sara Marie Mc Carthy, Tsendsuren Munkhdalai, Abhimanyu Goyal, Tomáš Kočiský, Shyam Upadhyay, Bahare Fatemi, Mehran Kazemi — Google DeepMind, Google Research — датасет: huggingface.co/datasets/arianhosseini/mt_puzzles