Section outline

  • Collapse Expand

    General

    Collapse all Expand all
    • Оголошення Forum

    • Славко Г.В.

      Кременчуцький національний університет імені Михайла Остроградського

      SQL-аналіз поведінкових патернів у Moodle для виявлення порушень академічної доброчесності

      Питання академічної доброчесності в середовищі дистанційного навчання набуває дедалі більшого значення — не лише як інституційна норма, а як методологічна проблема, що потребує системних технічних рішень [1-3]. Moodle збирає достатній обсяг поведінкових даних для статистично значущого аналізу поведінкових патернів користувачів системи. Так, викладач курсу може застосовувати непрямі методи ідентифікації [4] учасників тестування в Moodle. Проте у разі великої кількості курсів у системі та учасників тестування ефективне використання цих даних вимагає розуміння архітектури бази даних, відмінностей версій та коректної інтерпретації отриманих звітів. SQL-аналіз логів Moodle дозволяє виявляти нетипову поведінку студентів задовго до того, як вона стає очевидною. Розглядаємо конкретні патерни, запити та версійні особливості схеми бази даних від 2.9 до 4.5. Саме цей діапазон версій обрано через їх масовість використання.

      Ключові версійні відмінності [5], що впливають на SQL-запити:

      • Moodle 2.9–3.4: у mdl_logstore_standard_log відсутнє поле realuserid або воно не заповнюється стабільно — це обмежує аналіз сесій з імперсонацією (login as);
      • Moodle 3.5–3.11: поле realuserid стає надійним; з'являється підтримка mdl_analytics_* таблиць для прогностичних моделей (Learning Analytics API);
      • Moodle 4.0–4.5: суттєво переструктуровано mdl_quiz_slots і mdl_quiz_sections, додано підтримку random question sets через mdl_quiz_slot_random_tags; таблиця mdl_question_bank_entries замінює частину логіки, що раніше лежала в mdl_question.

      Окрема увага — полю origin в mdl_logstore_standard_log. Значення web, ws (web service), restore, cli дозволяють одразу фільтрувати нерелевантні події. Активність через мобільний додаток фіксується як ws — і це важливо враховувати при аналізі часових патернів.

      Часові аномалії при проходженні тестів

      Найпоширеніший і найпростіший у виявленні патерн — невідповідність між часом виконання тесту та результатом. Для коректного аналізу слід використовувати не лише timestart і timefinish з mdl_quiz_attempts, а й зіставляти їх із timelimit з mdl_quiz та фактичною кількістю питань.

      Наведемо далі приклад sql-запиту, який знаходить користувачів з аномаліями поведінки за часом здачі тестів зі списку студентів, зареєстрованих в системі дистанційного навчання на платформі Moodle. Для прикладу розглянуто версію Moodle 2.9. Запит реалізується через плагін Configurable Reports [1].

      SELECT `Студент`, `Курс`, `Назва тесту`, `Ліміт часу (с)`, `Фактичний час (с)`, `pct` AS '% використаного часу', `score` AS 'Бал (%)', `Дата здачі` FROM (SELECT CONCAT(u.firstname, ' ', u.lastname) AS 'Студент', c.fullname AS 'Курс', q.name AS 'Назва тесту', q.timelimit AS 'Ліміт часу (с)', (qa.timefinish - qa.timestart) AS 'Фактичний час (с)', ROUND((qa.timefinish - qa.timestart) / IF(q.timelimit = 0, NULL, q.timelimit) * 100, 1) AS 'pct', ROUND(qa.sumgrades / IF(q.sumgrades = 0, NULL, q.sumgrades) * 100, 1) AS 'score', FROM_UNIXTIME(qa.timefinish) AS 'Дата здачі' FROM {quiz_attempts} qa JOIN {quiz} q ON q.id = qa.quiz JOIN {course} c ON c.id = q.course JOIN {user} u ON u.id = qa.userid WHERE qa.state = 'finished' AND qa.preview = 0 AND q.timelimit > 0 AND qa.sumgrades IS NOT NULL AND u.deleted = 0 AND (qa.timefinish - qa.timestart) / IF(q.timelimit = 0, NULL, q.timelimit) < 0.10 AND qa.sumgrades / IF(q.sumgrades = 0, NULL, q.sumgrades) > 0.85) AS tmp ORDER BY tmp.pct ASC, tmp.score DESC

      Поріг 10% від ліміту часу при результаті понад 85% — консервативний, але достатньо надійний фільтр, отриманий емпіричним шляхом. Звісно, через особливості курсів, їх тематики та встановлені ліміти часу ці порогові значення можна змінювати адаптуючи видачу за запитом до реальних умов. Зазначимо, що для тестів без обмеження часу (timelimit = 0) медіанне значення тривалості по групі є кращим орієнтиром, ніж абсолютний поріг.

      Враховуючи відмінності версій Moodle для зручності наведемо ще одну версію sql-запиту, адаптовану під виконання в Moodle 4.1 Configurable Reports. Функціонал запиту без змін, застосовані лише адаптивні зміни під особливості Moodle 4.*.

      SELECT student AS "Студент", course_name AS "Курс", quiz_name AS "Назва тесту", limit_sec AS "Ліміт часу (с)", actual_sec AS "Фактичний час (с)", pct AS "% використаного часу", score AS "Бал (%)", finished_at AS "Дата здачі" FROM (SELECT CONCAT(u.firstname, ' ', u.lastname) AS student, c.fullname AS course_name, q.name AS quiz_name, q.timelimit AS limit_sec, (qa.timefinish - qa.timestart) AS actual_sec, ROUND((qa.timefinish - qa.timestart) / NULLIF(q.timelimit, 0) * 100, 1) AS pct, ROUND(qa.sumgrades / NULLIF(q.sumgrades, 0) * 100, 1) AS score, FROM_UNIXTIME(qa.timefinish) AS finished_at FROM {quiz_attempts} qa JOIN {quiz} q ON q.id = qa.quiz JOIN {course} c ON c.id = q.course JOIN {user} u ON u.id = qa.userid WHERE qa.state = 'finished' AND qa.preview = 0 AND q.timelimit > 0 AND qa.sumgrades IS NOT NULL AND u.deleted = 0 AND (qa.timefinish - qa.timestart) / NULLIF(q.timelimit, 0) < 0.10 AND qa.sumgrades / NULLIF(q.sumgrades, 0) > 0.85) AS tmp ORDER BY tmp.pct ASC, tmp.score DESC

      Наведемо для розуміння три зміни відносно версії для 2.9. IF(x = 0, NULL, x) замінено назад на NULLIF(x, 0) — Moodle 4.1 працює на MySQL 8.0 або MariaDB 10.6+, де NULLIF повністю стабільний. Одинарні лапки в аліасах замінено на подвійні — MySQL 8.0 у стандартному SELECT через подвійні лапки вирішує питання відображення українських назв у звіті.

      Верифікація запитів здійснювалась на освітній платформі "Математика.Укр" [6] (база студентів та учнів 2500 учасників, 35 курсів) та в системі дистанційного навчання Кременчуцького національного університету імені Михайла Остроградського [7] (понад 4500 користувачів та 1650 курсів). Нижче наведено приклад видачі за такими запитами (з незначними варіаціями форматування відповідно до платформи).

      Результат sql-запиту

      Таким чином, маючи значну кількість учасників навчання користуючись запитом можна виявити тих користувачів які аномально мало витратили часу (менше 10%) на виконання тестових завдань але отримали високі бали (понад 85 відсотків). Запит може бути реалізований з незначними модифікаціями як на рівні платформи так і рівні окремих курсів.

      Рівномірність інтервалів між відповідями

      Цей патерн значно інформативніший за просту тривалість. Якщо студент відповідає на питання через рівні проміжки часу — це статистично нехарактерно для людини, яка реально обдумує відповідь. Аналіз виконується через mdl_question_attempt_steps (не плутати з mdl_quiz_attempt_steps — це різні таблиці в Moodle 3.x+).

      Мережеві патерни та ідентифікація спільної активності

      Колізії IP-адрес між різними акаунтами

      Збіг IP-адрес під час подачі тестових спроб — класичний індикатор, але він потребує контекстуалізації. На рівні університетської мережі може давати масові хибнопозитивні результати. Тому аналіз слід звужувати до конкретного тесту і часового вікна.

      Геолокаційні аномалії в послідовних сесіях

      Moodle не зберігає геолокацію безпосередньо, але послідовна зміна IP-підмережі між подіями одного користувача з мінімальним часовим інтервалом є непрямим індикатором передачі доступу. Виявляється через самоз'єднання таблиці логів.

      Патерни множинних спроб і навігаційна поведінка

      Аналіз розподілу оцінок між спробами

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

      Навігаційні аномалії: перегляд без взаємодії

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

      Аномалії в роботі з завданнями (Assignment)

      Часові патерни подачі файлів

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

      Подача файлу розміром кілька мегабайт через 2-3 хвилини після відкриття завдання фізично означає, що файл був підготовлений заздалегідь — до того, як студент побачив умови. Для деяких типів завдань це нормально, для інших — ні.

      Повторне редагування після перегляду оцінювання

      У Moodle є легальна можливість редагувати подачу до дедлайну. Але якщо студент редагував роботу після того, як переглянув зворотний зв'язок від іншого студента (у peer assessment) або після того, як побачив попередні оцінки в журналі — це варто відстежувати через послідовність подій у логах.

      Імперсонація та делегований доступ

      Починаючи з Moodle 3.5, поле realuserid у mdl_logstore_standard_log надійно фіксує адміністративну імперсонацію ("увійти як"). Але є інший, технічно складніший патерн: студент передає облікові дані іншій особі, яка діє від його імені без будь-якої імперсонації на рівні Moodle. Виявити це можна через поведінкові відмінності — наприклад, мову браузера або User-Agent, якщо вони логуються зовнішніми засобами, або через різку зміну навігаційних патернів у межах одного акаунту.

      У межах самого Moodle виявлення таких випадків через SQL обмежене. Але запит на виявлення адміністративної імперсонації під час навчальних активностей може бути корисним для аудиту та під час розробки власних плагінів [8] для моніторингу поведінкових патернів.

      Описані запити мають практичну цінність лише у випадку регулярного виконання з автоматичним агрегуванням результатів. Архітектурно доцільні підходи:

      1. Винесення запитів у збережені процедури з параметрами курсу і часового вікна; виклик через cron із записом результатів у окрему аналітичну таблицю.
      2. Підключення Moodle DB як джерела даних у Metabase або Grafana — з побудовою дашбордів для координаторів курсів без необхідності доступу до SQL-консолі.
      3. Використання Moodle DB API з реалізацією scheduled tasks і системою сповіщень.
      4. Інтеграція з Learning Analytics API (Moodle 3.5+): визначення власних індикаторів (indicator) і таргетів (target) дозволяє включити виявлення аномалій у стандартний аналітичний pipeline платформи.

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

      Запропонована тут методика програмного виявлення нетипової поведінки користувачів LMS Moodle на основі аналізу журналів подій і поведінкових патернів засобами SQL для підтримки процедур контролю академічної доброчесності та готові до адаптації приклади SQL-запитів можуть бути корисними адміністраторам та розробникам освітніх Moodle-платформ.

      Залишається відкритим питання про межі автоматизації: де закінчується виявлення аномалій і починається необґрунтоване стеження. Кожен учасник тестування має бути попереджений про збір даних та аналітику поведінкових патернів, що вже є певним застереженням від шахрайських дій. З розвитком Learning Analytics у Moodle 4.x ця межа стає все менш чіткою — платформа вже зараз дозволяє будувати предиктивні моделі поведінки студентів, і питання про те, як саме ці дані використовуються, виходить за межі технічного і стає питанням інституційної політики під час інтеграції системи дистанційного навчання у освітній процес навчального закладу [9].

      Список використаних джерел

      1. Gennadii Slavko. Problems and organizational measures of implementing and providing the distance electrical engineering education at the university using lms moodle in the conditions of modern challenges in Ukraine // Матеріали Міжнародної конференції «MEES 2022. MODERN ELECTRICAL AND ENERGY SYSTEM», 20-22 жовтня 2022 р.
      2. Славко Г.В., Набок Т.А. Дослідження можливостей штучного інтелекту для оцінювання знань з програмування // Матеріали Міжнародної науково-практичної конференції «Розвиток науки та освіти в умовах глобалізації», 02 серпня, 2024 р., м. Чернігів, С. 34.
      3. Славко Г. В., Сергієнко С. А., Григорова Т. А., Кирилаха Н. Г. (2023). Дослідження проблем оцінювання знань із програмування в умовах дистанційного навчання на платформі Moodle. Педагогічні науки: теорія та практика, 3(47), 154-163. https://doi.org/10.26661/2786-5622-2023-3-22
      4. Славко Г.В. Непрямі методи ідентифікації користувачів Moodle // Восьма міжнародна науково-практична конференція "MoodleMoot Ukraine 2020". Теорія і практика використання системи управління навчанням Moodle. Київський національний університет будівництва і архітектури, 22-23 травня 2020 р.
      5. LMS Moodle. [Електронний ресурс] – Режим доступу до ресурсу: http://moodle.org.
      6. Система онлайн освіти "Математика.укр" [Електронний ресурс] – Режим доступу до ресурсу: http://математика.укр.
      7. Система онлайн-навчання. КрНУ [Електронний ресурс] – Режим доступу до ресурсу: http://krnu.org.
      8. Славко Г. В. Розробка та інтеграція плагінів математичного спрямування у систему дистанційної освіти Moodle / Г. В. Славко, В. В. Решетило, С.В. Шевченко // Вісник Кременчуцького національного університету імені Михайла Остроградського - 2017. - Вип. 2(1). - С. 48-53.
      9. Сергієнко С.А., Славко Г.В. Досвід упровадження та інтеграції онлайн-навчання на платформі Moodle у освітній простір університету. Інженерні та освітні технології. 2019. Т. 7. № 2. С. 126–136.
    • Форум обговорення доповіді Forum