Мы делаем учебную игру, где человек формулирует цель своими словами, а игра строит под неё путь из локаций. В каждой локации — порция из пяти заданий. Готовых курсов нет: тема может быть любой, поэтому задания пишет языковая модель. Придумывает задания модель хорошо, а считает плохо. В октябре мы разобрали 68 жалоб «Задание с ошибкой?» — игроки отправляют их кнопкой прямо из урока. Типичные случаи: неверный ответ в арифметике, несколько правильных вариантов в тесте с одним ответом, отсутствие правильного ответа среди вариантов, логические противоречия в условии.

Проблема не в том, что модель глупа, а в том, что она не выполняет вычисления надёжно. Даже простые примеры вроде «6 − 2 = 3» могут появиться в сгенерированном задании. Поэтому мы решили не доверять модели в том, что можно проверить кодом, и добавили автоматическую валидацию.

Какие проверки можно автоматизировать

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

  • Арифметические выражения. Если в задании есть пример, его ответ можно вычислить и сравнить с тем, что указала модель. Для этого не нужен сложный парсер: достаточно вытащить регулярным выражением числа и операторы, вычислить результат и сравнить с предложенным ответом.
  • Согласованность вариантов ответа. В тесте с одним правильным ответом должен быть ровно один вариант, помеченный как верный, и он должен присутствовать в списке. Проверяем, что количество правильных ответов равно одному, а сам ответ не дублируется.
  • Формат и структура. Убеждаемся, что в задании есть условие, варианты (если нужны), правильный ответ и объяснение. Проверяем, что текст не пустой, нет лишних символов, не нарушена разметка.
  • Логические ограничения. Например, если в задании спрашивается «сколько будет 2 + 2», а варианты ответов: 3, 4, 5, 6 — проверяем, что правильный ответ 4 действительно есть среди вариантов. Если ответа нет — задание отбраковывается.

Как мы встроили проверки в пайплайн

Проверки работают не после того, как задание попало к игроку, а до этого. Пайплайн выглядит так:

  • Модель генерирует задание в структурированном виде (JSON с полями: условие, варианты, правильный ответ, объяснение).
  • Валидатор прогоняет набор проверок. Если проверка не пройдена, задание помечается как невалидное.
  • Для невалидных заданий мы либо запрашиваем у модели новое, либо (если ошибка простая) исправляем автоматически — например, пересчитываем арифметику и подставляем верный ответ.
  • Только прошедшие проверку задания показываются игроку.

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

Критерии выбора проверок

Не все проверки одинаково полезны. Мы отбирали их по трём критериям:

  • Покрытие ошибок. Проверка должна ловить частые случаи. Мы посмотрели на 68 жалоб и выделили, какие ошибки встречаются чаще всего. Арифметика и согласованность вариантов дали наибольший эффект.
  • Простота реализации. Чем проще проверка, тем меньше шансов, что она сама содержит баг. Мы старались использовать регулярные выражения и простые вычисления, а не сложные эвристики.
  • Отсутствие ложных срабатываний. Проверка не должна отбраковывать корректные задания. Например, если задание предполагает несколько правильных ответов (выберите все подходящие), проверка на «ровно один правильный» не должна применяться.

Типичные ошибки при автоматической проверке

Мы сами наступили на несколько граблей, когда начинали. Вот что стоит учитывать:

  • Слишком строгие проверки. Если проверка требует идеального совпадения строк, она будет отбраковывать задания, где ответ записан с другими пробелами или в другом регистре. Нужно нормализовать данные перед сравнением.
  • Игнорирование контекста. Арифметическая проверка не сработает, если в задании есть переменные или условие «вычислите при x = 2». В таких случаях лучше пропустить проверку, чем ошибиться.
  • Отсутствие логирования. Важно сохранять, какие проверки не прошли и почему. Это помогает улучшать и проверки, и промпты для модели.
  • Попытка проверить всё. Невозможно автоматически проверить творческие задания или задания с открытым ответом. Не стоит пытаться — лучше сосредоточиться на том, что действительно проверяемо.

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