Перевірка на плагіат у Moodle: інтеграція та налаштування

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

Це важливо і в контексті академічної доброчесності. Закон України № 4742-IX передбачає, що заклади освіти мають використовувати програмні засоби для виявлення ознак порушень академічної доброчесності. Водночас із цього не випливає, що закон установлює один обов’язковий сервіс, єдиний «допустимий відсоток» схожості або вимогу перевіряти абсолютно кожен файл однаково. Нормативну рамку варто відділяти від технічного регламенту закладу.

Закон України «Про академічну доброчесність» № 4742-IX задає загальну вимогу, а конкретну схему перевірки заклад має організувати у своїх процесах.

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

Зміст

Як це працює технічно
Вибір сервісу
Встановлення й підключення плагіна
Налаштування на рівні завдання
Ліміти й економіка
Кейс: інтеграція у ЗВО на 5000+ користувачів
Типові помилки
Що показати перевіряльнику
FAQ
Інтеграція антиплагіату під ключ

Як це працює технічно

У Moodle немає універсального вбудованого антиплагіатного сервісу з власною базою порівняння. Платформа надає механізм інтеграції — Plagiarism API — через який сторонні плагіни можуть передавати студентський контент у систему перевірки й показувати результат у Moodle.

Типова схема виглядає так:

Moodle → плагін перевірки → API зовнішнього сервісу → аналіз → звіт у Moodle.

Після здачі студентом роботи відбувається кілька технічних кроків:

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

Офіційна документація Moodle прямо описує Plagiarism API як набір функцій для передавання користувацького контенту системам перевірки. Конкретні можливості — автоматичний запуск, доступ студента до звіту, виключення джерел, підтримка певних активностей — залежать уже не від Moodle як такого, а від конкретного плагіна та сервісу.

Для адміністратора це означає, що налаштування має щонайменше три рівні.

Глобальний рівень. Антиплагіатні плагіни потрібно дозволити в Site administration → Advanced features, після чого встановити та налаштувати потрібний компонент у розділі плагінів.

Рівень сервісу. Тут задаються ключі API, облікові дані, адреси сервісів, параметри передавання даних та інші опції конкретної інтеграції.

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

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

Для викладача головна перевага — звіт прив’язаний до конкретної роботи та конкретного користувача. Не потрібно завантажувати десятки файлів із Moodle, вручну переносити їх у зовнішній кабінет, а потім зіставляти результати зі списком студентів.

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

Вибір сервісу

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

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

Сервіс	Мова інтерфейсу	База / джерела порівняння	Модель ліцензування	Інтеграція з Moodle
Turnitin	Локалізацію потрібної мови варто перевірити в демо та договорі	Інтернет-джерела, раніше подані студентські роботи, періодика, журнали та публікації	Інституційна ліцензія; ціна залежить від закладу та набору продуктів	Є Moodle-інтеграції
Compilatio	Перевірити потрібну локалізацію перед закупівлею	Вендор заявляє порівняння з мільярдами цифрових документів; склад доступної бази треба уточнювати для конкретного тарифу	Комерційна модель для закладів; інтеграція з Moodle може оплачуватися окремо	Є інтеграція з Moodle
Copyleaks	Перевірити потрібну локалізацію інтерфейсу; сервіс заявляє багатомовну перевірку	Вебджерела, журнали, внутрішні документи та спільні колекції даних залежно від продукту	Комерційні плани та інституційні умови	Є окреме рішення для Moodle
Originality.ai	Локалізацію Moodle-плагіна слід перевірити на тестовому стенді	Публічні матеріали вендора описують веборієнтовану перевірку; точний склад доступних джерел для інституційного сценарію варто підтвердити до закупівлі	Кредитна / підписна модель; є освітні та корпоративні сценарії	У каталозі Moodle є плагін OriginalityAI Plagiarism & AI Detection

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

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

Особливо важливо перевірити не тільки сторінку продукту, а й поточну версію плагіна. Інтеграція, яка працювала на попередній версії Moodle, не повинна автоматично вважатися сумісною з поточною платформою.

Встановлення й підключення плагіна

Конкретні назви полів відрізняються між сервісами, але логіка налаштування однакова.

1. Перевірити сумісність

До встановлення потрібно звірити:

версію Moodle;
мінімальну та максимальну підтримувані версії плагіна;
потрібну версію PHP;
залежності від інших компонентів;
підтримувані типи активностей;
спосіб автентифікації із зовнішнім сервісом.

Цей крок краще робити на тестовому середовищі. Для робочої LMS, особливо з тисячами користувачів, встановлення нового плагіна без перевірки сумісності створює непотрібний ризик для навчального процесу.

2. Увімкнути механізм plagiarism prevention

За актуальною MoodleDocs, адміністратор спочатку активує Enable plagiarism plugins у розділі Site administration → Advanced features.

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

3. Встановити плагін

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

Для продуктивного середовища краще дотримуватися стандартного циклу:

резервна копія → тестовий стенд → встановлення → перевірка сценаріїв → продуктивне середовище.

Після встановлення треба переконатися, що компонент не лише відображається в переліку плагінів, а й коректно виконує реальну перевірку тестового документа.

4. Додати ключі або облікові дані

Більшість зовнішніх систем потребують API-ключа, секрету або іншого набору облікових параметрів. Їх не варто передавати викладачам і тим більше вставляти в інструкції для студентів.

Секрети мають зберігатися на рівні адміністративної конфігурації з доступом лише для уповноважених адміністраторів.

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

5. Увімкнути перевірку там, де вона потрібна

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

Після пілота правила можна масштабувати на кафедри або типові шаблони курсів.

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

Налаштування на рівні завдання

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

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

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

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

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

Тому перед запровадженням будь-якого порогу потрібно перевірити, як конкретний сервіс:

розпізнає бібліографію;
обробляє цитати;
виключає короткі збіги;
працює з шаблонними фрагментами;
враховує попередні версії тієї самої роботи;
зіставляє роботи студентів одного закладу.

Четвертий параметр — поріг схожості. Тут варто уникати правила «вище X% — плагіат». Показник схожості є індикатором текстових збігів, а не готовим висновком про академічне порушення. Наприклад, Turnitin прямо зазначає у своїй документації, що Similarity Report показує збіги з джерелами, а викладач має сам оцінити їхній характер.

Технічно правильний процес виглядає так:

звіт → перегляд джерел і фрагментів → застосування правил закладу → академічне рішення уповноваженою особою.

Не навпаки.

Ліміти й економіка

У великому ЗВО вартість інтеграції визначає не тільки ціна ліцензії, а й сценарій використання.

Якщо в системі 5000+ користувачів і перевірка запускається автоматично для кожної чернетки, ліміт можна витрачати значно швидше, ніж очікувалося під час закупівлі. Особливо це помітно у моделях, де оплата прив’язана до кількості слів, кредитів, документів або обсягу використання.

Перед запуском варто порахувати мінімум чотири показники:

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

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

3000 студентів × 2 роботи × 3 перевірки = 18 000 перевірок.

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

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

Кейс: інтеграція у ЗВО на 5000+ користувачів

У нашій практиці інтеграцію перевірки було виконано для ЗВО з понад 5000 користувачів Moodle. У проєкті використовувалося рішення Plagiarism & AI Detection.

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

Типові помилки

Вважати поріг схожості автоматичним вироком

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

Перевіряти лише дипломи

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

Це не означає перевіряти все. Навпаки, потрібна матриця: тип роботи → потрібна перевірка чи ні → хто аналізує результат → що відбувається далі.

Відкривати звіт студенту без правил повторної здачі

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

Не перевірити роботу після оновлення Moodle

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

Не визначити, хто читає звіти

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

Що показати перевіряльнику

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

До нього можуть входити:

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

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

Технічні журнали Moodle можуть допомогти встановити, коли користувач подавав роботу або виконував інші дії в курсі, але логи також потрібно налаштовувати й зберігати заздалегідь. Цю тему окремо розбираємо у матеріалі «Логи Moodle як доказова база при розгляді порушень».

Після успішної перевірки кваліфікаційної роботи наступним етапом може бути її передання до інституційного репозитарію. Про цей процес — у статті «Репозитарій кваліфікаційних робіт на базі DSpace».

FAQ

Який відсоток схожості вважати порушенням?

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

Тому коректніше встановлювати не «відсоток вини», а порядок реакції: наприклад, коли звіт потребує обов’язкового додаткового перегляду.

Чи потрібно перевіряти курсові роботи?

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

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

Скільки коштує інтеграція антиплагіату з Moodle?

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

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

Інтеграція антиплагіату під ключ

Якщо потрібно не просто встановити плагін, а включити перевірку в робочий процес ЗВО, важливо узгодити архітектуру інтеграції, права, шаблони завдань, правила повторних перевірок, ліцензійні ліміти та тестування після запуску.

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