TL;DR
Вместо того чтобы просить LLM оценить твоё объяснение как "правильно" или "неправильно" — попроси её разбить тему на конкретные понятия, которые должны быть в ответе, и отдельно указать, какие из них ты назвал, а какие пропустил. Это превращает размытую оценку в конкретный список того, что нужно добавить.
Когда человек объясняет что-то своими словами (код, статью, концепцию) и получает от LLM только вердикт "верно/неверно" — это слишком грубо, чтобы понять что улучшить. В этом исследовании модель, играющая роль строгого эксперта, систематически занижала оценку правильности — говорила "неверно" там, где объяснение было верным, просто сформулировано иначе. Но при этом список "какие понятия отсутствуют" оказался надёжным сигналом: именно он заставлял людей переписывать ответ.
Метод — это структура промпта, где LLM возвращает не общий балл, а список ожидаемых понятий для конкретного фрагмента, отмечает какие из них присутствуют и какие отсутствуют в твоём объяснении, и даёт отдельное обоснование по правильности и по полноте. Ты видишь конкретно, что дописать — не абстрактную оценку, а точку приложения усилий.
Схема метода
ШАГ 1: Дай LLM материал (код/текст/концепцию) + своё объяснение своими словами → один запрос
ШАГ 2: LLM возвращает JSON:
- Correctness: 0 или 1
- Completeness: число от 0 до 1
- Expected Concepts: список понятий, которые должны быть
- Concepts Present: что ты назвал
- Concepts Missing: что упустил
- Reasoning: обоснование отдельно по правильности и по полноте
ШАГ 3 (цикл, вручную): Дописываешь объяснение, добавляя missing concepts → повторяешь ШАГ 1
Все три показателя формируются одним промптом. Цикл "объяснил → получил список пропусков → дописал" повторяешь сам, вручную, в том же чате.
Пример применения
Задача: Ты проходишь курс по Python на Stepik или разбираешь код на новой работе (например, стажировка в Т-Банке или Яндексе) и хочешь по-настоящему понять чужой скрипт, а не просто прочитать комментарии к нему.
Промпт:
Вот фрагмент кода и описание задачи, которую он решает.
Описание задачи: {описание_программы}
Код: {исходный_код}
Строка №{номер_строки}: {содержание_строки}
Вот как я объясняю, что делает эта строка своими словами:
{моё_объяснение}
Оцени моё объяснение:
1. Correctness — верно ли я описал поведение строки (1 или 0)
2. Completeness — насколько полно (число от 0 до 1) = (сколько понятий я назвал) / (сколько нужно было назвать)
3. Expected Concepts — какие понятия должны быть в правильном объяснении этой строки
4. Concepts Present — какие из них я назвал
5. Concepts Missing — какие пропустил
6. Объясни отдельно, почему correctness именно такой и почему completeness именно такая
Верни ответ в формате JSON.
Результат: Модель вернёт структурированный JSON с бинарной оценкой правильности, числом полноты, и главное — двумя списками понятий (что есть, что упущено). Ты сразу видишь конкретные пробелы — не "плохо объяснил", а "не упомянул, что переменная передаётся по ссылке" — и дописываешь объяснение именно этим.
Почему это работает
LLM плохо справляется с точными числовыми оценками "на глаз" — в исследовании её "completeness" (число от 0 до 1) плохо совпадало с реальной оценкой человека, хотя направление изменения было верным. А вот сопоставление списков — что должно быть против того, что есть — модель делает надёжно: это задача сравнения, а не абстрактной оценки.
Метод обходит слабость модели, переводя "оцени качество" (субъективная, плохо калиброванная задача) в "перечисли, что упущено" (простая задача сопоставления понятий). Числовая оценка становится побочным продуктом, а не главным результатом — главное — список конкретных пропусков.
Рычаги управления: - Можно самому задать список "ожидаемых понятий" вместо того, чтобы LLM их придумывала — это даёт больше контроля, если ты сам знаешь, что должно быть в ответе. - Порог "достаточной полноты" (в оригинале 0.5) можно менять под свою задачу — для беглого повторения снижай, для глубокой проверки перед экзаменом повышай. - Если убрать просьбу про JSON-формат и попросить просто текстовый разбор — увидишь более развёрнутое рассуждение модели, полезно для сложных тем.
Шаблон промпта
Ты — эксперт, который проверяет объяснение студента.
Тема/материал: {материал}
Конкретный фрагмент для объяснения: {фрагмент}
Моё объяснение своими словами: {моё_объяснение}
Оцени по критериям:
1. Correctness (1 или 0) — верно ли я описал суть фрагмента
2. Completeness (0–1) — доля названных понятий от всех нужных
3. Expected Concepts — список понятий, которые должны быть в полном объяснении
4. Concepts Present — какие из них я упомянул
5. Concepts Missing — какие пропустил
6. Обращайся ко мне на "ты" и объясни отдельно причину оценки correctness и отдельно completeness
Верни в формате JSON с полями: Correctness, Completeness, Expected Concepts, Concepts Present, Concepts Missing, CorrectnessReasoning, CompletenessReasoning.
Подставь в {материал} и {фрагмент} то, что изучаешь (код, статью закона, бизнес-модель), а в {моё_объяснение} — свою формулировку своими словами.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для самопроверки понимания через список понятий. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно ты изучаешь и какие понятия считать "ожидаемыми" — потому что без этого она не может построить список Missing Concepts, на котором держится весь метод.
Ограничения
⚠️ Вердикт "правильно/неправильно" ненадёжен: модель как строгий судья чаще занижает оценку правильности, чем завышает — может сказать "неверно" на объяснение, которое верно, просто звучит иначе, чем ожидалось. Не доверяй этому вердикту буквально, смотри на список missing concepts.
⚠️ Числовая полнота — не точный процент: цифра типа "у тебя 45% полноты" плохо соответствует реальной оценке человека. Ориентируйся на направление (растёт/падает после переписывания), а не на конкретное число.
⚠️ Нужен чёткий "правильный ответ": метод работает, когда у темы есть более-менее определённый набор понятий (код, формулы, законы). Для полностью субъективных задач — оценка эссе, творческого текста, личного мнения — список "ожидаемых понятий" построить сложнее, и метод теряет силу.
Как исследовали
Исследователи развернули тьютора ESSE в настоящем курсе Java для начинающих — 8 студентов объяснили своими словами 409 строк кода в четырёх учебных примерах. Каждое объяснение оценивал GPT-4o mini по промпту с двумя показателями, а результат сверили с двумя независимыми "человеческими" стандартами: один эксперт вручную разметил те же попытки, и отдельно 124 краудворкера на Amazon Mechanical Turk переоценили часть объяснений.
Любопытная деталь: модель расходилась с экспертом и с толпой в противоположные стороны — против строгого эксперта она чаще недооценивала правильность (говорила "неверно" на верные ответы), а против снисходительной толпы, наоборот, переоценивала. Это значит, что абсолютная точность модели зависит от того, с каким стандартом сравнивать — единого "смещения" не существует.
При этом список пропущенных понятий оказался надёжным двигателем поведения: студенты статистически значимо чаще переписывали объяснение именно когда фидбек указывал на нехватку понятий (63% случаев после "неверно" против 35% после "верно"), и полнота росла именно за счёт добавления нужных понятий, а не просто увеличения объёма текста — корреляция между приростом слов и приростом полноты была отрицательной. Это главный практический вывод: работает не общая оценка, а конкретный список пропусков.