TL;DR
Исследователи сравнили два AI-репетитора на одной и той же модели: простого "помогающего" ассистента и репетитора со специальной структурой из четырёх шагов, которая мешает ему сразу выдавать ответ. Оказалось, что стандартная оценка "насколько ответ полезен" не видит разницы между ними — а иногда даже выше оценивает того, кто чаще спойлерит решение.
Главная находка простая и болезненная: когда LLM-судью просят оценить "полезность" ответа тьютора, он ставит одинаково высокие баллы и репетитору, который выдал готовое решение застрявшему ученику, и репетитору, который довёл его до ответа наводящими вопросами. Хуже того — чем чаще тьютор "утекал" ответ, тем выше была оценка полезности у судьи, и тем меньше ученик пытался решить следующую задачу сам. Причина проста: модель обучена быть услужливой здесь и сейчас, а самый быстрый способ услужить застрявшему — дать ему ответ.
Суть решения — структура из четырёх звеньев: сначала оценить, что ученик понял и где застрял, потом выбрать одну из трёх стратегий (разбить задачу на подзадачи / отказаться дать ответ и подтолкнуть вопросом / давать подсказки по нарастающей), и явно запретить показывать финальное решение до попытки ученика.
Схема метода
ШАГ 1: Оцени состояние ученика → что понял, где застрял, была ли ошибка в рассуждении (невидимо для пользователя, в промпте)
ШАГ 2: Выбери ОДНУ стратегию на основе состояния →
3а. Декомпозиция — разбей задачу на 2-3 подзадачи, дай только первую
3б. Отказ от прямого ответа — задай наводящий вопрос вместо решения
3в. Каскад подсказок — от общей подсказки к конкретной, по одной за раз
ШАГ 3: Никогда не показывай финальный ответ, пока ученик не сделал хотя бы одну попытку
Все шаги можно выполнить внутри одного system-промпта — отдельные запросы не нужны.
Пример применения
Задача: Родитель хочет, чтобы Claude или ChatGPT помогал ребёнку с домашкой по математике, но не решал задачи за него, а именно учил думать.
Промпт:
Ты — репетитор по математике для {класс/предмет}.
Твоя цель — не дать готовый ответ, а довести ученика до решения самостоятельно.
Перед каждым ответом:
1. Определи состояние ученика: что он уже понял, в чём именно застрял,
была ли ошибка в рассуждении.
2. Выбери ОДНУ стратегию:
- Если ученик не понимает с чего начать → разбей задачу на 2-3
маленьких шага, дай только первый шаг.
- Если ученик просит прямой ответ или явно сдался → НЕ давай решение.
Задай вопрос, который подталкивает подумать самому.
- Если ученик близко, но не хватает деталей → дай ОДНУ подсказку,
самую общую. Если не помогло — на следующем шаге дай более конкретную.
3. Никогда не показывай финальный численный ответ, пока ученик не
попытался вычислить его сам хотя бы раз.
Задача: {текст задачи}
Что написал ученик: {реплика ученика}
Результат: модель будет держать паттерн "наводящий вопрос вместо ответа" — задаст уточняющий вопрос или даст первый шаг декомпозиции, но откажется называть финальное число. При повторных сообщениях подсказки будут становиться конкретнее, но решение так и не появится до самостоятельной попытки ученика.
Почему это работает
LLM обучена быть услужливой — самый простой способ угодить застрявшему пользователю — дать ему готовый ответ. Общая инструкция типа "помогай ученику" или просьба "оцени, насколько ответ полезен" не создаёт барьера против этой привычки, потому что для модели "полезно" и "дал ответ быстро" — синонимы.
LLM хорошо умеет следовать явным пошаговым правилам, если их прописать конкретно: сначала диагностика, потом выбор из фиксированного списка стратегий, потом жёсткий запрет. Явный запрет ("никогда не показывай финальный ответ") плюс структура выбора стратегии заставляет модель потратить "усилие" на педагогику вместо угождения в моменте.
Рычаги управления: можно менять число шагов в каскаде подсказок (меньше — быстрее к ответу, больше — дольше держит в напряжении), добавить условие "после N неудачных попыток дай ответ" (для реальных дедлайнов), или ослабить gate до "частичный ответ" вместо полного отказа — для менее упорных задач.
Ограничения
⚠️ Фрустрация пользователя: метод специально замедляет получение ответа. Если человеку нужен just быстрый результат (а не обучение) — это будет раздражать, а не помогать.
⚠️ Требует чёткой задачи с правильным ответом: структура "диагностика → стратегия" плохо работает на открытых, творческих или субъективных задачах, где нет однозначного "решения".
⚠️ Не доверяй общей оценке "насколько это полезно": если просишь LLM оценить качество обучающего диалога, общая рубрика "полезности" не увидит разницы между хорошим и плохим тьютором. Нужна отдельная, специфичная рубрика именно про педагогику (например: "дал ли ответ напрямую", "подталкивал ли к самостоятельному мышлению").
Как исследовали
Исследователи взяли три базовых модели (Claude Sonnet, GPT-5.5, Gemini) и для каждой сделали по два тьютора на одних и тех же весах: простого "помогающего" ассистента и четырёхзвенного "педагогического" тьютора с диагностикой и роутером. Обоих посадили работать с одним и тем же слабым симулированным студентом — моделью Llama-3.1-8B, которая сама решает лишь 11% задач, — чтобы обучение было по-настоящему нужным, а не формальностью.
Провели 90 сессий, каждый ответ репетитора оценивала Claude Opus как "слепой" судья — по общей шкале полезности и отдельно по специальной шкале педагогики. Для проверки те же диалоги пересчитал второй судья, GPT-5.6.
Результат удивил: судья по полезности почти не различал двух тьюторов, а на одной из баз моделей даже предпочёл того, кто чаще спойлерил ответ — причём эта оценка менялась местами в зависимости от того, какая модель судила. А вот жёсткий детектор — "дал ли тьютор ответ прямо" и "попытался ли ученик решить следующую задачу сам" — показал железную закономерность на всех трёх базовых моделях без исключений: чем чаще репетитор выдавал ответ, тем меньше ученик пытался думать сам на следующем шаге. Это единственный результат, который не зависел от того, какая LLM судила — потому что его вообще не считает LLM, а простой поиск совпадений в тексте.
Ресурсы
Rethinking LLM-Judged Helpfulness as a Pedagogy Signal: A Pre-Registered Audit Across Tutor Models. Авторы: Shuyi Fan, Boyuan Deng, Mengyu Xu и др. (Columbia University, Johns Hopkins, University of Chicago, HKUST, HK PolyU, Northwestern University). Код: github.com/bydeng01/conv-vs-ped-tutor