TL;DR
Исследование показывает: если попросить LLM оценить работу по рубрике с наблюдаемыми признаками каждого уровня, запретить числовые оценки и потребовать карту доказательств — модель выдаёт структурированную, воспроизводимую обратную связь вместо расплывчатых "хорошо/плохо". Это не одна техника, а паттерн оценочного промпта: роль эксперта + многомерная рубрика + запрет на числа + требование цитировать конкретные фрагменты работы.
Главная находка неочевидна: большая модель (70B параметров) показала худшее согласие с экспертами, чем более компактная модель другой архитектуры. Когда задача — строго следовать структурированной рубрике, архитектура важнее размера. Большая модель "разваливается" на жёстких ограничениях — начинает отклоняться в собственные рассуждения вместо того чтобы следовать заданной структуре оценки.
Решение — добавить в промпт три блокирующих элемента: запрет на числовые оценки (модель вынуждена мыслить качественно), карту доказательств (цитата из работы как обоснование каждой метки) и уровни компетенций с описанием наблюдаемых признаков (модель не придумывает критерии — она сопоставляет работу с уже готовой шкалой).
Схема метода
ШАГ 1: Определи рубрику (один раз)
→ 3-5 компетенций × 3-4 уровня каждая
→ Для каждого уровня: observable evidence (что видно в работе)
ШАГ 2: Составь оценочный промпт (один раз)
→ Роль: эксперт в предметной области
→ Правило: НИКАКИХ числовых оценок
→ Задача: для каждой компетенции — уровень + цитата-доказательство + уверенность
ШАГ 3: Отправь работу на оценку
→ Вставь рубрику + работу студента/кандидата/текст
→ Один запрос = один человек/документ
Все три шага выполняются в одном чате. Рубрика пишется один раз, потом переиспользуется.
Пример применения
Задача: HR-менеджер в технологической компании оценивает тестовое задание кандидата на позицию продуктового аналитика. Нужна не интуитивная "нравится/не нравится", а структурированный отчёт по компетенциям — чтобы потом объяснить кандидату и нанимающему менеджеру.
Промпт:
Ты — опытный Head of Product с 8+ лет практики.
Твоя задача: оценить тестовое задание кандидата на роль продуктового аналитика.
ПРАВИЛА:
- Никаких числовых оценок и баллов
- Каждый вывод должен опираться на конкретную цитату из работы
- Оценивай рассуждения, а не финальный ответ
РУБРИКА ОЦЕНКИ (4 компетенции × 4 уровня):
1. ПОНИМАНИЕ ПРОБЛЕМЫ
Начальный: Повторяет условие задачи, не формулирует суть проблемы
Базовый: Формулирует проблему своими словами с минимальным контекстом
Уверенный: Связывает проблему с бизнес-метриками и пользователем
Экспертный: Переформулирует задачу, выявляя скрытые ограничения и допущения
2. РАБОТА С ДАННЫМИ
Начальный: Описывает данные без анализа
Базовый: Считает базовые метрики, делает очевидные выводы
Уверенный: Сегментирует и сравнивает, выдвигает гипотезы
Экспертный: Выявляет нелинейные зависимости, учитывает смешивающие факторы
3. СТРУКТУРА РЕШЕНИЯ
Начальный: Список идей без приоритизации
Базовый: Есть логика, но шаги не связаны между собой
Уверенный: Чёткая последовательность с обоснованием приоритетов
Экспертный: Учитывает ограничения ресурсов, риски, альтернативные сценарии
4. КОММУНИКАЦИЯ ВЫВОДОВ
Начальный: Разрозненные наблюдения без итога
Базовый: Есть вывод, но не операционализирован
Уверенный: Конкретные рекомендации с метриками успеха
Экспертный: Вывод адаптирован под разные аудитории (CEO, разработчики, поддержка)
ФОРМАТ ОТВЕТА — для каждой компетенции:
[Компетенция]: [Уровень]
Доказательство: "[Цитата из работы]"
Комментарий: [1-2 предложения что именно это показывает]
Уверенность: Высокая / Средняя / Низкая
В конце — раздел ОБЩИЙ ПРОФИЛЬ: где кандидат силён, где пробелы, на что обратить внимание при собеседовании.
---
ТЕСТОВОЕ ЗАДАНИЕ КАНДИДАТА:
[вставить текст работы]
Результат:
Модель выдаст структурированный отчёт: четыре блока по компетенциям с цитатами из работы, уровень и уверенность для каждой. В конце — синтетический профиль кандидата с конкретными вопросами для углублённого собеседования. Результат воспроизводим — два разных HR-менеджера с одним промптом получат сопоставимые оценки.
Почему это работает
LLM при открытом вопросе "оцени работу" генерирует текст по самым частотным паттернам обратной связи из обучающих данных — получается размытое "хорошо написано, но можно улучшить структуру". Модель не знает ваших критериев и придумывает свои.
Рубрика с наблюдаемыми признаками переключает режим работы: вместо генерации "типичной обратной связи" модель выполняет задачу сопоставления — находит в тексте конкретные паттерны и матчит их с описаниями уровней. Это модели делают хорошо.
Запрет на числа — не декоративный. Числовая оценка позволяет модели "срезать угол": поставить 7/10 и не объяснять почему. Без чисел модель вынуждена описывать словами, что именно видит в работе. Карта доказательств (цитата → вывод) блокирует галлюцинации: если цитаты нет — уровень не обоснован.
Рычаги управления: - Число компетенций → 3-4 оптимально, больше 6 — качество падает, модель "размывается" - Детализация уровней → чем конкретнее описаны признаки, тем точнее сопоставление - Запрос уверенности → если модель пишет "Уверенность: Низкая" — сигнал, что это граничный случай, стоит проверить вручную - Роль эксперта → конкретизируй: не "эксперт", а "Head of Product с опытом в B2B SaaS" — модель точнее выбирает критерии
Шаблон промпта
Ты — {роль_эксперта} с {N} лет опыта в {предметная_область}.
Оцени {что_оцениваем}: {название_работы/задания}.
ПРАВИЛА:
- Никаких числовых оценок и баллов
- Каждый вывод подкреплён цитатой из текста
- Оценивай процесс рассуждений, не только финальный результат
РУБРИКА:
1. {КОМПЕТЕНЦИЯ_1}
{уровень_1}: {что_видно_в_работе_на_этом_уровне}
{уровень_2}: {что_видно_в_работе_на_этом_уровне}
{уровень_3}: {что_видно_в_работе_на_этом_уровне}
{уровень_4}: {что_видно_в_работе_на_этом_уровне}
2. {КОМПЕТЕНЦИЯ_2}
[аналогично]
3. {КОМПЕТЕНЦИЯ_3}
[аналогично]
ФОРМАТ ОТВЕТА — для каждой компетенции:
[Компетенция]: [Уровень]
Доказательство: "[Цитата из работы]"
Комментарий: [что именно это показывает]
Уверенность: Высокая / Средняя / Низкая
Завершение — ИТОГОВЫЙ ПРОФИЛЬ: главные сильные стороны, зоны роста, вопросы для follow-up.
---
РАБОТА ДЛЯ ОЦЕНКИ:
{текст_работы}
Плейсхолдеры:
- {роль_эксперта} — конкретная должность, не просто "эксперт": "старший редактор", "архитектор решений", "методолог"
- {компетенция} — измеримый аспект работы: "логика аргументации", "работа с возражениями", "структура текста"
- {что_видно_в_работе} — поведенческие маркеры, не абстракции: "автор цитирует источник", "приводит контрпример", "использует метафору"
- {уровень} — можно взять из оригинала: Начальный → Базовый → Уверенный → Экспертный
🚀 Быстрый старт — вставь в чат:
Вот шаблон для оценки работ по рубрике. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит какие компетенции важны для твоей области и попросит описать признаки каждого уровня — потому что без этого не сможет правильно сопоставить работу с рубрикой. Она возьмёт структуру из шаблона и адаптирует под твой контекст.
Ограничения
⚠️ Субъективные критерии: Если признаки уровней размытые ("хорошо написано", "глубокий анализ") — модель будет галлюцинировать совпадения. Рубрика работает только с конкретными, наблюдаемыми маркерами.
⚠️ Длинные работы: Если документ превышает несколько страниц — качество падает. Исследование прямо отмечает: длинный контекст "путает модель" и увеличивает число некорректных меток. Оценивай по частям.
⚠️ Большая модель ≠ лучшая для рубрик: В эксперименте 70B модель показала нулевое согласие с экспертами — хуже, чем 8B модель другой архитектуры. Для строго структурированных задач оценки Gemini (MoE) превзошла Llama (Dense). При критически важных задачах стоит проверить несколько моделей.
⚠️ Не для итоговой аттестации: Авторы прямо пишут — LLM сейчас не готова к автономной сертификации. Это инструмент предварительного скрининга и помощи, не замена эксперта.
Как исследовали
Команда из Nepal взяла реальные рукописные работы 33 учеников 10-го класса по Optional Mathematics — это серьёзный предмет для тех, кто идёт в науку и технологии. Два опытных преподавателя независимо оценили каждую работу по четырём компетенциям (Comprehension, Knowledge, Operational Fluency, Behavior & Correlation), каждая в четырёх уровнях. Согласие между экспертами — κw = 0.865 (очень высокое). Это и стало эталоном.
Затем те же работы прогнали через четыре LLM с одним идентичным промптом при температуре 0.1 (минимум случайности). Результат удивил: Gemini Flash (MoE, меньший) показал "Fair Agreement" с экспертами (κw ≈ 0.38), а Llama 70B (Dense, больший) показал практически нулевое согласие (κw = −0.03) — хуже случайного. Это называют "Architecture-compatibility gap": разреженная архитектура MoE лучше следует жёстким инструкциям рубрики, чем плотная Dense-сеть большего размера.
Вывод звучит контринтуитивно, но логически объясним: Dense-модели при большом размере начинают "перебивать" инструкции собственными сильными паттернами. MoE-модели активируют разные блоки под разные типы задач — и на структурированной классификации по рубрике оказываются точнее. Для практики: если хочешь надёжной оценки по рубрике — Gemini Flash, а не "самая большая модель".
Адаптации и экстраполяции
🔧 Техника: убрать запрос уверенности → получить компактный отчёт
Если нужен быстрый скрининг без deep-dive — убери строку "Уверенность: ..." из формата. Модель выдаст компактную таблицу уровней с цитатами. Добавь обратно когда нужна флаговая система: "всё с низкой уверенностью → ручная проверка".
🔧 Экстраполяция: оценка не работы, а решения проблемы
Тот же паттерн работает для оценки ответов на кейс-интервью, стратегических решений команды, клиентских питчей. Замени компетенции на: "Диагностика ситуации", "Качество гипотез", "Операционализация", "Работа с рисками" — и рубрика готова для ревью стратегических документов.
🔧 Техника: двойная оценка через два запроса
Отправь одну работу на оценку дважды с небольшим интервалом (или в двух разных чатах). Сравни результаты. Где уровни совпадают — высокая внутренняя согласованность. Где расходятся — граничный случай, который точно стоит оценить вручную. Дешёвый способ измерить надёжность оценки.
Ресурсы
Human-in-the-Loop Benchmarking of Heterogeneous LLMs for Automated Competency Assessment in Secondary Level Mathematics
Jatin Bhusal, Nancy Mahatha, Aayush Acharya, Raunak Regmi
Research and Incubation Center (RAIN), Sunway College Kathmandu, Nepal
Контакт: jatin@sunway.edu.np
Связанные концепции: Competency-Based Education (CBE), Cohen's Weighted Kappa (κw), Mixture-of-Experts (MoE) архитектура, Role-Based Instruction (RBI) промптинг