Розробка ШІ-системи автогенерації тестів та іспитів

Автоматична генерація тестів: де ламається ручний процес

Поки в ручному банку тестів дві-три сотні завдань, збірка тримається на одному експерті: він пам'ятає, що вже питав, і тримає формулювання в голові. Банк переростає ці розміри — і в ньому з'являються теми, яких немає, хоча в програмі навчання вони є.

Першим розсипається контроль якості. Дублі в завданнях майже не видно оком: один і той самий факт запитують у трьох редакціях підряд, і слухач отримує бал за пам'ять, а не за розуміння.

Поруч — неузгодженість формулювань: десь «виберіть один варіант», десь «позначте всі правильні», ваги та шкали в різних авторів не збігаються, і однаковий рівень знань оцінюється по-різному.

Матриця покриття зазвичай не ведеться взагалі. Зрозуміти, які розділи програми закриті завданнями, а які порожні, можна лише ручним перебором — це дні роботи.

Тому складні теми виявляються перепредставленими, а рідкісні не покриті, і атестація перестає щось доводити: вона вимірює не компетенцію, а випадковий набір питань, що трапилися.

Трудомісткість перевірки зростає не від кількості слухачів, а від обсягу звірки. Експерт витрачає основний час на пошук дублів, вичитку формулювань і розбір спірних ключів — тобто на приведення банку до ладу замість оцінки знань.

Коли ця робота йде паралельно з навчанням, зрив термінів атестації стає питанням часу, а не ризиком.

Розбираємо, як це закривається: формалізованою моделлю компетенцій — рівнями за Bloom, правилами формулювань і автоматичною перевіркою банку на дублі та прогалини до видачі завдань слухачеві.

Що дає автоматизація: вимірювані ефекти впровадження

Перелік нижче — це те, що замовник бачить у системі після запуску. Кожен пункт перевіряється на прийманні, і якщо вимірюваного ефекту немає, пункт не закритий — повертаємося до налаштувань генерації.

• Варіанти збираються в рази швидше. Генератор видає готовий комплект під задану кількість груп і рівнів складності, тому викладач витрачає час на вичитку, а не на ручну збірку та перестановку завдань.
• Частка дублів падає до одиниць відсотків. Перетини перевіряються за нормалізованими формулюваннями та за змістом, а не за точним збігом рядків, тому однакові за суттю завдання не розходяться за різними варіантами.
• Єдиний стандарт якості. Структура питання, кількість варіантів відповіді та рівні за таксономією Блума задаються правилами генерації, а не звичками окремих авторів — комплекти залишаються рівними за складністю.
• Банк завдань масштабується без пропорційного зростання команди. Новий предмет підключається словником термінів і регламентом: обсяг банку зростає кратно, ручної роботи додається лише на вичитці.
• Перевірка стає прозорою. У кожного питання зберігається джерело, версія та обґрунтування правильної відповіді — при апеляції видно, звідки взялося завдання і за яким правилом зібрався варіант.
• Цілий клас помилок зникає. Друкарські помилки, загублені варіанти відповіді та розбіжності між ключем і формулюванням ловляться валідатором до публікації, а не на самому іспиті.

Режими генерації завдань: порівняння підходів

Режим генерації обирають не за «потужністю» моделі, а за ціною помилки в конкретному типі завдання та за наявністю структурованого джерела.

Числовий приклад з підстановкою параметрів безпечно збирається шаблоном, а питання на розуміння теми вимагає тексту-першоджерела — інакше перевіряється пам'ять, а не розуміння.

На виході будь-який режим дає банк завдань у єдиній схемі: формулювання, варіанти, правильна відповідь, теги теми та складності, посилання на фрагмент джерела.

Це знімає проблему сумісності — вивантаження в QTI або плоский JSON підключається до вашої системи навчання без ручного переформатування.

Робочим зазвичай стає гібридний режим: завдання йде в шаблон або в генерацію за ознакою типу, а експерт перевіряє не все підряд, а вибірку та все, що потрапило в атестаційний блок.

Так частка завдань, що проходять валідацію з першого разу, зростає, а експерт зайнятий спірними формулюваннями, а не вичиткою однотипних прикладів.

Головне обмеження будь-якого режиму — джерело. На неструктурованих матеріалах частка придатних завдань падає, тому ми зберігаємо прив'язку кожного завдання до фрагмента тексту: партію можна перегенерувати після правки методички, не збираючи банк заново.

Як проходить впровадження: етапи інженерної роботи

Порядок робіт будуємо так, щоб кожен етап спирався на вже перевірений попередній. Нижче — послідовність, яку ми проходимо на задачах автоматичної генерації тестів: від аудиту матеріалів до передачі команді.

1. Аудит навчальних матеріалів. Розбираємо лекції, методички та минулі банки завдань, відзначаємо теми з достатнім матеріалом і прогалини. Прогалини закриваємо до старту — інакше генерація видає правдоподібні, але невірні питання.

2. Схема генерації. Описуємо вхід (тема, фрагмент матеріалу, цільова складність) і тип завдання на виході. Схема зберігається як конфігурація, яку править методист, а не розробник.

3. Налаштування правил перевірки. Для закритих завдань — еталонні відповіді та допуски за формулюваннями; для відкритих — рубрики з обов'язковими тезами та умовою відправлення на ручну перевірку.

4. Тестова вибірка. Прогоняємо схему на матеріалах, яких вона не бачила, рахуємо частку завдань, прийнятих методистом, і частку фактичних помилок. За результатами правимо правила та повторюємо прогін.

5. Збірка варіантів. Комплекти збираються з банку за темами та складністю, щоб варіанти в групі не повторювалися, а будь-який виданий комплект можна було відтворити та розібрати.

6. Передача та навчання. Віддаємо опис схеми, рубрик і структури банку, показуємо методистам, як додавати теми та розбирати спірні перевірки.

Після запуску фіксуємо регламент оновлення банку та повторного прогону перевірки після правок схеми — так якість завдань не розходиться з програмою курсу.

Що залишається в проєкті: завдання, схеми, регламенти

Здаємо проєкт комплектом артефактів, з яким команда замовника працює далі без нашої участі, а не демонстрацією працюючого сервісу. Нижче — що саме залишається після запуску і навіщо потрібен кожен елемент.

• Комплект документації — архітектура генератора, модель даних банку завдань, точки інтеграції з навчальною платформою, перелік зовнішніх сервісів та їхня роль.
• Схема потоків завдань — шлях від завантаження навчального матеріалу та розмітки тем до генерації, перевірки експертом, публікації та видачі студентові, з відмітками контрольних точок.
• Регламент оновлення — як додавати типи завдань і теми, змінювати шаблони запитів до моделі, випускати версії та відкочуватися, якщо якість просіла.
• Політики доступу — ролі методиста, експерта, адміністратора та студента: хто править банк завдань, хто бачить журнали, хто вивантажує дані.
• Інструкції для експертів — критерії приймання завдання, типові дефекти формулювань і неправильних варіантів відповіді, порядок відхилення та переробки.
• Метрики якості — частка завдань, прийнятих з першого разу, покриття тем, частка дублів; зведення збирається автоматично за журналом перевірок.
• Регламент експлуатації — резервне копіювання банку, порядок оновлення середовища та звірка з навчальною програмою після кожної зміни.

Кожен артефакт показуємо на прийманні та розбираємо, як ним користуватися: документація та схеми повинні бути робочими, а не декоративними.

Кейс: як скоротили ручну роботу над банком завдань

Освітній центр з банком на 12 000 завдань оновлює програму кожного семестру, а збірка варіантів трималася на чотирьох експертах-предметниках.

Один варіант на 30 питань збирали вручну 6–8 годин: підбирали завдання за темами, звіряли рівень складності та чистили перетини між варіантами.

Перевірка одного чернетки займала в експерта 12–15 хвилин, тому банк майже не зростав — підтримувати його в актуальному вигляді було нікому.

Охоплення тем у готових варіантах трималося на 60–70%: рідкісні розділи залишалися без питань, бо заготовок під них не вистачало. Частка повторів формулювань між варіантами сягала 18% — студенти обмінювалися відповідями, і системно перетини ніхто не відслідковував.

Що перебудували

Генерацію розділили на три кроки: чернетки за картою тем, автоматична валідація на відповідність розділу та рівню складності, ручна вичитка. Робочим варіантом стали моделі OpenAI у зв'язці з окремим шаром перевірок на дублі та вихід за рамки теми.

Що вийшло

Збірка варіанта скоротилася до 20 хвилин разом із фінальною вичиткою, охоплення тем у кожному варіанті — 100% програми. Частка повторів упала нижче 2%, а перевірка одного завдання в експерта займає 3–4 хвилини: формальні звірки пішли в автоматику, людина приймає рішення по суті.

Клас помилок «завдання не відповідає заявленій темі або рівню» закритий на вході — такі чернетки відсікаються до експерта. Звільнений час предметники витрачають на розширення банку та розбір спірних формулювань, а не на переперевірку очевидного.

Що робити, якщо банк завдань уже зібраний вручну?

Однотипної відповіді немає: банк на кілька тисяч завдань майже завжди дешевше перенести, ніж збирати заново, — але тільки якщо в нього є формальна розмітка.

Якщо завдання лежать розрізненими файлами з помітками всередині тексту, перенесення перетворюється на повторну ручну роботу і втрачає сенс.

Міграція починається з інвентаризації: матеріали вивантажуються в єдиний структурований вигляд, дублі та дефектні завдання (невірний ключ, відсутній варіант відповіді, застаріле формулювання) відсіюються відразу.

Потім кожне завдання розмічається за темою та підтемою програми, рівнем складності та типом уміння, що перевіряється, після чого зіставляється з програмою. Результат — карта покриття: видно, де розділи закриті з надлишком, а де прогалини, які доб'є автоматична генерація.

Після перенесення банк живе як єдине джерело: нові завдання генеруються в ту саму розмітку і проходять ті самі перевірки, тому охоплення програми не розповзається. Це знімає головний ризик — набір ручних файлів, який не можна ні перевірити, ні розширити.

Часті сумніви щодо якості та перевірки завдань

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

Тому генерація в нас працює не поверх «сирого» тексту, а поверх формалізованої структури курсу — переліку тем, критеріїв засвоєння та затвердженого банку прикладів. Кожне згенероване завдання несе посилання на конкретний пункт програми, а не на матеріал «в цілому».

Далі вмикаються два фільтри: автоматичний розбір на неоднозначність і розбіжності варіантів відповіді, потім перевірка експертом-предметником, який підтверджує коректність і знімає спірні формулювання.

Такий порядок дає трасованість: на будь-якому етапі видно, чому завдання з'явилося і до якої вимоги прив'язане.

Що робити з неоднозначними формулюваннями?

Правила однозначності зашиті в перевірку: один правильний варіант, відсутність подвійного заперечення, відсутність підказок у дистракторах, єдиний стиль умов.

Спірні випадки не викидаються мовчки — вони потрапляють у звіт з обґрунтуванням, щоб експерт прийняв рішення щодо правки або відхилення.

Як оновлюються застарілі матеріали?

Джерела версіонуються: при зміні програми або нормативної бази позначаються порушені пункти, і пов'язані завдання перезбираються заново. Старі версії залишаються доступними для порівняння, тому зміни вимог, що перевіряються, не губляться між релізами.

Хто відповідає за якість після передачі?

Ми передаємо правила генерації, критерії валідації та регламент експертного приймання — їх можна змінювати своєю командою без нас.

Відповідальність за сенс завдань на стороні замовника закріплюється за предметним експертом; ми відповідаємо за те, щоб генерація слідувала заданим правилам. Після передачі доступні супровід і розбір інцидентів з якістю.

Обговоримо задачу: з чого починається впровадження

Перша розмова потрібна не для презентації, а щоб окреслити межі задачі: який предмет, яка аудиторія, які формати питань уже прийняті в організації. За цими вступними ми рахуємо обсяг робіт і збираємо план впровадження — від підключення джерел до видачі готових варіантів. Щоб оцінка була предметною, а не «плюс-мінус», від замовника потрібен короткий набір даних:

• типи атестацій та їх призначення — вхідний контроль, проміжний зріз, підсумковий іспит, сертифікація;
• обсяг і стан матеріалів: навчальні тексти, методички, накопичений банк завдань і те, в якому вигляді вони зберігаються;
• ролі перевіряльників і погоджувачів — хто затверджує формулювання, хто відповідає за предметну коректність;
• вимоги до типів завдань: один правильний варіант, кілька правильних, відкрита відповідь, прив'язка до рівнів складності;
• правила внутрішнього контролю — допустима частка повторів, чутливість до формулювань, вимоги до відтворюваності;
• критерії приймання: що вважаємо результатом — частку валідних питань після експертизи, час на підготовку варіанта, обсяг ручної правки.

Далі пропонуємо пробний запуск на одній темі: проганяємо повний цикл на обмеженому матеріалі, звіряємо результат з вашими критеріями і тільки після цього масштабуємо на весь курс. Опишіть задачу — повернемося з оцінкою обсягу та планом впровадження.