Кто проверит ответ нейросети: как отделить генерацию заданий от оценки знаний

Редакция APICODIK · 28.10.2026

Разбираем опыт учебной игры «Люмекс»: почему корректного JSON недостаточно, какие ошибки можно исправить кодом и когда задание безопаснее отклонить.

У языковой модели в учебном приложении две разные роли: придумать упражнение и определить, правильно ли ответил ученик. В проекте «Люмекс» столкнулись с тем, что первая задача получается убедительнее второй. По рассказу разработчика на Хабре, модель могла выдать неверный арифметический ключ или отклонить правильное решение. Команда стала переносить проверяемую часть работы в обычный код.

Этот опыт интересен не попыткой написать универсального контролёра для нейросети, а ограничением его полномочий. Проверяющая программа исправляет только то, что умеет однозначно разобрать. В остальных случаях она либо оставляет задание без вычислительной проверки, либо отклоняет его при обнаружении противоречия.

Правильный формат ещё не означает правильного задания

В «Люмекс» пользователь описывает учебную цель своими словами. Игра строит маршрут, а Claude генерирует порции по пять заданий с учётом темы, уровня и предыдущих ответов. Такая схема позволяет не ограничиваться заранее подготовленным каталогом уроков, но делает качество сгенерированного материала частью пользовательского опыта.

Разработчик сообщает о разборе 68 жалоб на ошибки в заданиях. Среди примеров — неверные результаты вычислений, перепутанные отношения между числами и отказ принять правильный ответ. Для учебного продукта проблема не сводится к неточности текста: ошибочный ключ непосредственно влияет на оценку действий ученика.

При этом задания уже приходили в структурированном виде: использовались JSON, Zod и structured outputs. Эти инструменты обеспечивали соответствие ожидаемой форме, но не согласованность содержимого. Наличие строкового поля с ответом не доказывает, что ответ существует среди вариантов или соответствует вопросу.

Практическое различие здесь простое: проверка контракта данных отвечает за возможность обработать объект, а проверка задания — за возможность предложить его человеку.

Не всякий дефект стоит исправлять

Первый уровень защиты в описанной системе отсеивает непригодные задания без математических вычислений. Он проверяет варианты ответа, соответствие ключа, видимые символы и некоторые внутренние противоречия.

Показательный случай — отсутствующий вариант ответа. Раньше приложение добавляло его из ключа модели. Но когда сам ключ оказался испорченным, автоматическое восстановление превратило внутреннюю ошибку в кнопку интерфейса. Теперь такой объект отбрасывается.

Аналогичная проблема возникла с заданиями на несколько правильных вариантов. Преобразование их в одиночный выбор не меняло исходную формулировку вопроса. В результате интерфейс требовал одного действия, а текст — другого. Команда отказалась от такого ремонта.

В этом и состоит важная граница нормализации: убрать невидимые символы можно без изменения смысла, а перестроить тип упражнения — уже содержательное решение. В описанном кейсе попытки сохранить задание любой ценой создавали новые ошибки.

Независимая проверка начинается с ограничений

Следующий уровень пересчитывает распознаваемые математические задания. В его основе — небольшой парсер арифметических выражений с четырьмя действиями и скобками. Перед разбором разные обозначения умножения, деления и минуса приводятся к общей записи.

Однако нормализация тоже требует осторожности. Запись с запятой и тремя следующими цифрами может обозначать разделитель тысяч, а не десятичную дробь. В таком случае описанный валидатор отказывается от вычисления вместо выбора одного толкования.

Этот подход распространяется и на условия. Простое сравнение двух выражений можно пересчитать. Цепочку неравенств или выражение с непонятными элементами программа не берётся исправлять. Для сортировки чисел проверяется однозначность порядка: равные значения означают, что допустим не единственный ответ. При распределении по группам каждая карточка должна подходить ровно одной группе.

С числовыми последовательностями ограничений ещё больше. Два известных значения не всегда позволяют отличить арифметическую закономерность от геометрической. Поэтому проверяющий код не должен подменять неоднозначное упражнение собственной догадкой.

Цена чрезмерной уверенности здесь такая же, как у модели: валидатор может объявить ошибочным корректный ответ. Поэтому отказ от вмешательства — часть конструкции защиты, а не просто недоработанная функция.

Две записи обнаруживают спор, но не устанавливают истину

Для заданий на порядок и распределение по группам разработчики добавили ещё один механизм: модель записывает решение и в основной структуре, и отдельной строкой. Если элементы совпадают, а порядок или распределение различаются, задание отклоняется.

Это проверка внутренней согласованности, а не независимое доказательство правильности. Совпадение двух записей само по себе не подтверждает содержание. Зато расхождение даёт конкретную причину не показывать упражнение. Если дополнительную запись не удалось сопоставить со структурой, система фиксирует это в журнале, не делая вывода о правильности.

Такой механизм полезен именно своей узкой задачей: он ищет противоречие, не изображая полноценного эксперта по теме.

Отказ и повтор вместо обхода защиты

Проверки теряют смысл, если после отбраковки приложение всё равно возвращает исходные данные. По словам автора, раньше при полностью пустом результате система использовала именно такой запасной путь. Пользователь получал задания, которые только что не прошли контроль.

Теперь отсутствие пригодных заданий приводит к серверной ошибке, после которой клиент повторяет запрос. Автор отмечает, что следующая генерация обычно даёт подходящую порцию. Это компромисс между временем ожидания и риском показать сломанный урок, а не гарантия успешного повторения.

Для распространённых учебных целей команда выбрала другой путь: отдельные тренажёры собирают задания кодом без обращения к модели. Генерация остаётся там, где нужна гибкость, а типовые упражнения получают специализированный механизм.

Что остаётся за пределами калькулятора

Описанная система не решает проверку текстовых задач, исторических сведений или грамматики. Для таких случаев автор перечисляет инструкции модели, дублирование ответа в подходящих форматах и пользовательские жалобы. Повторяющиеся сообщения становятся основанием для новых правил.

Главный практический вывод этого кейса — разделять генерацию, проверку формы, вычисление и решение о показе. Код полезен не потому, что способен проверить любой ответ нейросети, а потому, что для ограниченного класса задач может дать результат без её участия. За пределами этого класса важно сохранять неопределённость, а не маскировать её автоматическим исправлением.