Автоматическая генерация тестов и заданий

Кратко

Автоматическая генерация тестов работает так: языковая модель читает транскрипт лекции и за секунды набрасывает вопросы (с выбором ответа, «верно/неверно», на заполнение пропуска и другие), на которые у человека ушли бы часы. Для видеокурса это самый быстрый способ превратить пассивный просмотр в активное припоминание. Но модель хорошо справляется с лёгкой половиной работы (сформулировать понятный вопрос и верный ответ) и плохо с трудной (придумать правдоподобные неверные ответы и поднять вопрос выше простого припоминания), поэтому сырой результат – черновик, а не готовый тест. В статье разберём, как идёт генерация из транскрипта, почему слабые места – качество дистракторов и когнитивный уровень, какая проверка человеком делает процесс безопасным и как публиковать каждый сгенерированный вопрос как отслеживаемое взаимодействие, чтобы платформа его действительно оценивала и учитывала.

Зачем это читать

Если вы строите обучающий продукт, ведёте программу обучения или отвечаете за каталог курсов, оценочные материалы – самая дорогая часть разработки курса и первое, что устаревает при его обновлении. Эксперт пишет хорошие тестовые вопросы медленно, по несколько качественных заданий в час, поэтому большинство видеокурсов выходят со слишком малым числом вопросов или вовсе без них. Автогенерация меняет экономику: модель набрасывает банк вопросов по уже готовому транскрипту, а эксперты переключаются с написания на проверку. В России это уже практика: в феврале 2025 года Skyeng запустил генерацию планов уроков и домашних заданий с помощью ИИ, и, по данным компании, ею пользуются около 10% преподавателей. В статье – реальная картина качества, процесс проверки, стандарты, без которых сгенерированный вопрос не попадёт в учёт, и расчёт затрат: этого хватит, чтобы решить, насколько здесь опираться на ИИ, и поставить задачу инженерам и методистам, не полагаясь на демо вендоров. Статья продолжает материалы где ИИ встраивается в обучающий продукт и квизы и опросы в плеере (о механике тестов).

Что на самом деле значит «автогенерация теста»

За просьбой «пусть ИИ напишет тест» стоит целый конвейер, и путать его с моделью – первая ошибка. Модель – лишь его середина.

Сначала термин: большая языковая модель (LLM) – программа того же типа, что стоит за чат-ассистентами: она читает текст и порождает текст, в том числе вопросы и ответы. Дайте ей текст лекции, и она набросает вопросы по нему. Именно эту часть обычно и представляют. Но пригодный тест – больше, чем вызов модели: нужны очищенный транскрипт, модель с промптом, где заданы учебные цели, черновые задания в известном формате, человек, который их проверяет, и публикация, после которой каждое задание оценивается и отслеживается внутри платформы.

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

Нажмите, чтобы увеличить

Как идёт генерация из транскрипта

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

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

Далее транскрипт и инструкции передаются языковой модели. Хороший промпт делает три вещи: привязывает вопрос к заявленной учебной цели (чему должен научить фрагмент), задаёт нужный тип задания (с выбором ответа, «верно/неверно» и так далее) и часто передаёт модели только релевантный фрагмент транскрипта, а не весь курс. Этот приём называется генерацией, дополненной поиском (RAG, retrieval-augmented generation): модель опирается на реальный материал и реже выдумывает факты. В российском продукте модель обычно берут из трёх источников: GigaChat от Сбера, Alice AI в Yandex AI Studio или открытая модель в собственном контуре; зарубежные API, на которых работают популярные чат-ассистенты, официально в России недоступны. Транскрипт лекции преподавателя обычно не содержит персональных данных учащихся, поэтому для генерации вопросов подходит облачная модель с размещением в РФ. Устройство самих LLM и поискового слоя разобрано в курсе AI for Video Engineering, а эта статья – про обучающую часть и продуктовое решение. Ближе всего к теме с точки зрения моделей – руководство по видеосуммаризации 2026.

Модель выдаёт черновые задания. У вопроса с выбором ответа три части: основа (сам вопрос), ключ (верный ответ) и дистракторы (правдоподобные неверные ответы). Основу и ключ модель пишет надёжно, а с дистракторами справляется плохо, и это главная тема статьи.

Затем идёт шаг, без которого тест остаётся риском: проверка человеком. Эксперт проверяет каждое задание на фактическую точность, качество дистракторов, связь с целью, когнитивный уровень и предвзятость, а затем принимает, правит или отклоняет его. Проверка человеком нужна любой ИИ-функции в обучении, а для оценивания она обязательна: неверный ключ учит неверному каждого, кто проходит тест.

Только после этого задание публикуется и отслеживается: хранится в переносимом формате, отображается в плеере, оценивается при отправке ответа и попадает в аналитику как запись о попытке. Подробности ниже.

Самое сложное: качество дистракторов

Самое дорогое заблуждение – считать главным в тесте сам вопрос. Написать вопрос легко; написать хорошие неверные ответы – мастерство, и именно здесь автогенерация чаще всего подводит.

Хороший дистрактор неверен, но правдоподобен: он отражает реальное заблуждение учащегося, поэтому его выбор что-то говорит о знаниях. Плохой дистрактор очевидно неверен: учащийся отбрасывает его, не зная материала, и вопрос перестаёт что-либо измерять. Десятилетия исследований тестирования (классический ориентир – рекомендации Халадайны по составлению вопросов с выбором ответа) сходятся в одном: сложность и диагностическая ценность такого вопроса почти целиком определяются дистракторами.

Без контроля LLM склонна выдавать один сильный дистрактор и два слабых или дистракторы, грамматически не согласованные с основой (классическая подсказка: вариант, который грамматически подходит к вопросу, и есть ответ). Ещё она любит «всё из перечисленного» и абсолютные слова вроде «всегда» и «никогда», по которым опытные тестируемые угадывают ответ. Поэтому самая ценная инструкция для генератора касается дистракторов: просите варианты на основе реальных заблуждений по теме, совпадающие с ключом по длине и грамматике, без «всё/ничего из перечисленного». Но и тогда человек должен подтвердить, что каждый дистрактор правдоподобен и действительно неверен: это главное, что делает эксперт при проверке.

Нажмите, чтобы увеличить

Что выходит хорошо, а где модель вводит в заблуждение

С одними типами вопросов автогенерация справляется отлично, с другими – плохо; знание этой границы убережёт от лишнего доверия.

Педагоги классифицируют вопросы по типу мышления, которого они требуют, с помощью таксономии Блума (в редакции 2001 года): внизу запоминание и понимание (вспомнить факт, пересказать определение), в середине применение и анализ (применить процедуру, сравнить случаи), наверху оценка и создание (взвесить варианты, спроектировать новое). Задания от LLM в основном оказываются на двух нижних ступенях: вопросы на припоминание и определения почти напрямую берутся из транскрипта. Аккуратный промпт и хороший исходник помогут подтянуть модель к «применению» и «анализу», но сильное задание на «оценку» или «создание» она сама выдаёт редко, а именно такие вопросы измеряют настоящее понимание.

Вторая слабость свойственна всему генеративному ИИ – галлюцинации: модель уверенно выдаёт складное, но ложное утверждение. В тесте это особенно опасно: ложь может попасть в ключ ответа и предстать перед каждым учащимся как верная. RAG снижает риск, привязывая модель к реальному транскрипту, но не устраняет его, поэтому человек сверяет каждый ключ с источником.

Нажмите, чтобы увеличить

Проверка человеком

Раз модель сильна в лёгкой половине работы и слаба в трудной, проверка – не формальность: именно она превращает черновик в тест. Сделайте её чётким процессом, а не просмотром «на глаз».

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

Консорциум 1EdTech, который развивает стандарты QTI и LTI, выпустил AI-Generated Content Best Practices (v1.0, 2024) как раз потому, что этому процессу нужны правила: документ рекомендует контроль человека над оценочным контентом, созданным ИИ, прозрачность в том, что контент сгенерирован машиной, и внимание к предвзятости и доступности. Опирайтесь на него, когда пишете регламент проверки. Для руководства это можно сформулировать так: ИИ не убирает эксперта из разработки тестов, а переключает его с написания на проверку и правку. На одно задание уходит в три-пять раз меньше времени, а банк вопросов получается больше и свежее.

Нажмите, чтобы увеличить

Чтобы вопросы учитывались: стандарты и трекинг

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

Первое – QTI (Question and Test Interoperability), стандарт 1EdTech (актуальная версия 3.0, 2022). Он упаковывает вопросы и тесты так, что любая совместимая система может их показать, оценить и передать другой. QTI – своего рода транспортный контейнер для оценочных материалов: в нём хранятся основа, варианты, логика оценки и даже статистика задания, например сложность, поэтому вопрос, созданный или сгенерированный в одном инструменте, переносится в другую LMS без пересборки. Если генерировать задания и хранить их в QTI 3.0, вы сохраните переносимость и получите доступность от самого стандарта (QTI 3.0 заявляет соответствие WCAG 2.1 AA, а на WCAG 2.1 основан и ГОСТ Р 52872-2019), не реализуя её вручную. Строгий формат к тому же заставляет генератор выдавать чёткую структуру задания, а не расплывчатый текст. Российская оговорка: в вузах стандарт де-факто – Moodle, а его банк вопросов проще всего наполнять через собственные форматы импорта (Moodle XML или GIFT). Рабочая схема – мастер-копия в QTI 3.0 и экспорт в формат вашей LMS.

Второе – xAPI (Experience API): стандарт, который записывает обучение как утверждения вроде «Мария верно ответила на вопрос 4» в Learning Record Store – хранилище таких записей. xAPI (версия 1.0.3, ADL) задаёт фиксированный набор типов взаимодействия, и сгенерированный вопрос должен относиться к одному из них, чтобы результат можно было обработать автоматически. Допустимые типы: true-false, choice (выбор), fill-in, long-fill-in, matching, sequencing, likert, numeric, performance и other. Генерируйте вопросы сразу в одном из этих типов, а не в свободной форме, которую аналитика не разберёт, и каждая попытка будет давать структурированное утверждение с вопросом, ответом учащегося и признаком правильности. Подробнее о проектировании утверждений – в статье трекинг видео через xAPI, об упаковке внутри курса – в статье SCORM: объяснение.

Минимальное xAPI-утверждение для одного ответа (данные вымышленные):

{
  "actor": { "name": "Тестовый учащийся", "mbox": "mailto:learner@example.org" },
  "verb": { "id": "http://adlnet.gov/expapi/verbs/answered",
            "display": { "ru-RU": "ответил" } },
  "object": {
    "id": "https://example.org/course/safety/q4",
    "definition": {
      "type": "http://adlnet.gov/expapi/activities/cmi.interaction",
      "interactionType": "choice",
      "correctResponsesPattern": ["b"]
    }
  },
  "result": { "success": true, "response": "b" }
}

Важна структура, а не синтаксис: раз задание объявляет свой interactionType и correctResponsesPattern, платформа сама, без человека, определяет, верен ли ответ, и может учесть его в метриках обучения. Чтобы это работало на больших объёмах, нужны стабильные имена: дайте каждому заданию постоянный id и один и тот же глагол, чтобы «ответил на тест по безопасности» был одним показателем по всем учащимся и языкам, а не россыпью разовых событий.

Ответы учащихся – уже персональные данные. Если вы передаёте модели развёрнутые ответы на автопроверку или храните попытки в LRS, действует 152-ФЗ: с 01.07.2025 операции с ПДн граждан России с использованием баз данных за рубежом не допускаются (ч. 5 ст. 18), поэтому и LRS, и модель для проверки ответов должны работать в России или в вашем контуре.

Хороши ли вопросы: немного психометрики

Сгенерировать и опубликовать задание – ещё не конец. Вопрос заслуживает места в тесте, только если хорошо работает на реальных учащихся, а измеряет это психометрика – статистика тестовых заданий. Важнее всего два показателя. Сложность задания – доля учащихся, ответивших верно: задание, с которым справляются все или никто, ничего не измеряет. Различающая способность (дискриминативность) показывает, отделяет ли задание сильных учащихся от слабых: вопрос, на который сильные и слабые отвечают одинаково, не работает. Анализ дистракторов проверяет, что каждый неверный вариант кто-то действительно выбирает: дистрактор, который не выбирает никто, бесполезен, и это та самая проблема слабых дистракторов, которую создаёт генерация.

Рабочий цикл такой: сгенерировать, проверить, опробовать задание на пилотной группе, посмотреть сложность и различающую способность, затем оставить, поправить или убрать. Здесь академическая область автоматической генерации заданий (AIG, automatic item generation) встречается с новым генеративным подходом. AIG старше LLM: она использует экспертные шаблоны для массового выпуска откалиброванных заданий. Шаблоны дают статистический контроль, но требуют большой работы экспертов заранее; LLM дают скорость и разнообразие, но чтобы заслужить то же доверие, нужны проверка и пилот. Большинство серьёзных программ сочетают оба подхода. Всё это касается не только онлайн-обучения, но именно здесь проходит граница между тестом, который впечатляет на демо, и оценкой, на которую может опереться документ об обучении. Особенно если от результата зависит, например, удостоверение о повышении квалификации, сведения о котором организация вносит в ФИС ФРДО; это уже тема защиты от списывания и проектирования оценивания.

Частая ошибка: сгенерировать и опубликовать

Чаще всего мы видим такую картину: команда прогоняет транскрипт через модель, получает сотню вопросов, видит их в плеере и считает, что тесты в курсе готовы. На демо это выглядит красиво, но встречи с учащимися не выдерживает. Опытный тестируемый замечает подсказывающие дистракторы и набирает балл, не зная материала; внимательный учащийся натыкается на выдуманный ключ и запоминает ложное; а весь банк застревает на нижних ступенях таксономии Блума и проверяет припоминание, хотя курс обещает научить принимать решения. Вторая, менее заметная ошибка – структурная: вопросы сгенерированы свободным текстом без interactionType и стабильного id, поэтому плеер не может проверить их автоматически, а аналитика – построить отчёт. Тест похож на оценку, но данных не даёт. От первой ошибки защищает проверка человеком с отдельным просмотром дистракторов и точности, от второй – генерация сразу в QTI 3.0 и типы взаимодействия xAPI. Опубликованный черновик автогенерации – не оценивание, а его видимость, и расплачиваются за неё учащиеся, которые доверились баллу.

Расчёт: банк из 200 вопросов

Теперь о деньгах: разработка тестов – расходы, которые растут с каждым курсом и каждым обновлением.

Возьмём курс, которому нужен банк из 200 вопросов, и ставку эксперта около 6 800 ₽ в час. Это ориентир, подставьте свою: соотношение двух вариантов от ставки не зависит. Сначала традиционный способ, когда эксперт пишет задания с нуля:

Эксперт пишет с нуля:
  ~4 качественных задания в час
  200 заданий ÷ 4 = 50 часов времени эксперта
  50 часов × 6 800 ₽/час = 340 000 ₽ за банк

Теперь с ИИ: модель набрасывает черновик, эксперт проверяет и правит:

С ИИ (генерация, затем проверка):
  Генерация: минуты вычислений, затраты ничтожны
  Проверка: ~15 проверенных и исправленных заданий в час
  200 заданий ÷ 15 ≈ 13,3 часа времени эксперта
  13,3 часа × 6 800 ₽/час ≈ 90 000 ₽ за банк

Вариант с проверкой обходится почти вчетверо дешевле (340 000 ÷ 90 000 ≈ 3,8), занимает лишь часть времени и хорошо масштабируется: чтобы обновить вопросы к переработанному модулю, достаточно дешёвого прогона модели и короткой проверки, а не нового проекта на 50 часов. Но это не «бесплатные вопросы». Валидность теста обеспечивают проверка и пилот, и экономия на них – ложная: в курс уйдёт сотня неработающих заданий. Реалистичная оценка – ускорение в три-пять раз на задание при обязательном участии эксперта и банк вопросов, который остаётся актуальным при изменении курса. Полную картину затрат на создание и эксплуатацию см. в модели стоимости платформы обучения и покупать или разрабатывать ИИ-функции и сколько это стоит.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Мы встраиваем генерацию тестов в обучающий продукт, а не прикручиваем сбоку генератор текста, не связанного с платформой. Фора Софт с 2005 года разрабатывает видеоконференции, стриминг, e-learning и ИИ-функции для видео. Когда клиенту нужна ИИ-генерация тестов, мы начинаем с выбора между готовым сервисом и своим решением: вендор быстрее всего доводит дело до рабочего демо и берёт плату за задание или пользователя, а конвейер генерации, встроенный в вашу систему разработки курсов, требует вложений в разработку заранее, зато банк вопросов, исправленные задания и данные об ответах учащихся остаются у вас. Мы связываем очищенный транскрипт на входе, модель с размещением в России или в вашем контуре, промпт с привязкой к учебным целям, проверку человеком и вывод сразу в задания QTI 3.0 (с экспортом в формат вашей LMS, например Moodle XML) и xAPI-утверждения о взаимодействиях. Так каждый вопрос попадает в каталог как переносимое, автоматически оцениваемое и отслеживаемое задание, а не абзац, который плеер не может оценить. И честно говорим: валидность обеспечивают проверка человеком и пилот заданий, а экономия на них в ИИ-оценивании обходится дороже всего.

Главное

• Генерация набрасывает вопросы из транскрипта за секунды; сырой результат – черновик.
• Модель сильна в основе и ключе, слаба в дистракторах и заданиях высокого уровня.
• Тест делает тестом проверка человеком по пяти пунктам, а не модель.
• Генерируйте в QTI 3.0 (и формат импорта вашей LMS) и типы взаимодействия xAPI, чтобы вопросы оценивались и отслеживались.
• Ответы учащихся – ПДн: модель для проверки и LRS – только в России или в своём контуре.
• С ИИ разработка заданий идёт в три-пять раз быстрее, но эксперт остаётся в процессе.

Что читать дальше

• Квизы и опросы в плеере: дизайн и трекинг
• Трекинг видео через xAPI: видеопрофиль
• Суммаризация лекций и учебные материалы