Когда речь заходит о проверке развёрнутых ответов ЕГЭ с помощью ИИ, многие представляют себе модель, которая читает работу и сразу выдаёт итоговый балл. На практике такой подход опасен: LLM может ошибаться в оценке, давать разные результаты при повторных запросах и не гарантировать воспроизводимость. Учитель и эксперт ЕГЭ с двухлетним опытом разработки Telegram-бота для проверки заданий по обществознанию пришёл к выводу: модели нельзя доверять выставление балла. В его боте LLM выполняет только разметку ответа по строгой JSON-схеме, а итоговую оценку считает обычный код. Такой подход позволяет сохранить контроль, прозрачность и снизить риск необоснованных решений.
Почему модель не должна ставить балл
LLM склонны к вариативности: один и тот же ответ при повторной проверке может получить разные оценки. Кроме того, модель может «домыслить» несуществующие критерии или неверно интерпретировать формулировку задания. В образовательном контексте это недопустимо: ученик должен понимать, за что именно снят балл, а эксперт — иметь возможность проверить логику. Поэтому в боте модель только размечает ответ: определяет, какие примеры конкретны, какие суждения верны, какие пункты плана являются ключевыми. На основе этой разметки код применяет формальные правила и вычисляет балл. При этом перепроверки могут только понизить оценку, но не повысить — это защищает от случайного завышения.
Как устроен путь одного ответа
Процесс проверки включает несколько этапов. Сначала ответ ученика поступает в бот, затем модель размечает его по заранее заданной схеме. Схема представляет собой JSON с полями, соответствующими критериям задания. Например, для задания с примерами модель указывает, является ли пример конкретным (с указанием субъекта, действия, объекта) и относится ли он к заданной теме. Для заданий на анализ суждений модель отмечает, верно ли суждение и есть ли обоснование. После разметки код сверяет полученные данные с эталонными критериями и вычисляет балл. Важно, что в задании с планом модель вообще не влияет на балл: там используются лемматизация и сверка с эталонами. Это позволяет избежать субъективности при оценке структуры плана.
Критерии выбора и типичные ошибки
При разработке подобного бота стоит учитывать несколько критериев. Во-первых, схема разметки должна быть максимально формализованной, чтобы минимизировать свободу модели. Во-вторых, необходимо предусмотреть обработку случаев, когда ИИ недоступен: например, переключаться на ручную проверку или использовать упрощённые правила. В-третьих, важно тестировать бота на реальных ответах учеников и сравнивать результаты с оценками экспертов. Типичные ошибки: доверие модели выставление балла без перепроверки, отсутствие валидации JSON-схемы, игнорирование контекста задания. Также часто забывают о том, что один «негативный сигнал» модели (например, модель сочла пример неудачным) не должен автоматически снимать балл — нужна совокупность сигналов или дополнительные проверки.
Практические шаги для внедрения
Если вы хотите построить аналогичный инструмент, начните с определения заданий, где разметка модели действительно полезна. Для каждого типа задания разработайте JSON-схему с чёткими полями и возможными значениями. Затем напишите код, который будет интерпретировать разметку и применять правила выставления баллов. Обязательно предусмотрите логирование всех шагов, чтобы можно было объяснить ученику, почему балл снижен. Проведите пилотное тестирование на небольшой выборке ответов, сравните результаты с оценками экспертов. И помните: стоимость одной проверки складывается из затрат на вызов LLM и вычислительных ресурсов, поэтому оптимизируйте запросы и кэшируйте результаты, где это возможно.
