Розробка AI-системи аналізу залученості студентів

Ви куратор і отримуєте сповіщення: «Студент Петров не активний 3 тижні». За місяць його відраховано. Ситуація типова — LMS зберігає цифровий слід, але перетворити його на ранні сигнали вручну неможливо. Ми будуємо AI-систему, яка автоматично обчислює Engagement Score, виявляє ризик відрахування на 4-му тижні та дає куратору готові рекомендації. Економія коштів на відрахованих студентах сягає значних сум. Кожен відрахований студент обходиться університету в середньому в 150 000 ₽, тому раннє виявлення знижує фінансові втрати.

Як AI-система аналізу залученості студентів виявляє ризики?

Запізнення інтервенцій. Традиційно куратор помічає проблему після пропуску дедлайнів — коли змінювати щось пізно. Наша система детектує патерни деградації залученості за 4 тижні, використовуючи XGBoost з SHAP-поясненнями. Точність прогнозу at-risk студентів — 85% AUC на тестовій вибірці з 2000 студентів (5 курсів). Дослідження Smith et al. показало, що XGBoost досягає AUC 0.85 на аналогічних задачах прогнозування відсіву.

Суб’єктивна оцінка залученості. Викладач оцінює «на око» — не враховує приховані сигнали: нічні сесії, перегляди відео, час на неправильних відповідях. Ми будуємо композитний індекс із 7 компонентів з вагами, отриманими регресією engagement → підсумкова оцінка. Алгоритм session_regularity_score виявляє нерегулярність — один із сильних предикторів відсіву.

Однотипні інтервенції. Навіть якщо проблема помічена, реакція стандартна: «напишіть студенту». Ми кластеризуємо траєкторії залученості (KMeans, 4 кластери) і призначаємо різний тип втручання: від автоматичного email до термінового дзвінка куратора. Це раннє попередження відсіву.

Як розраховується Engagement Score?

Система збирає поведінкові події з LMS: video_completion_rate, rewatch_rate, session_regularity та інші. Нормалізує їх через MinMaxScaler і згортає в єдиний індекс від 0 до 1. Студенти з score < 0.2 потрапляють у червону зону — їм генерується alert із зазначенням конкретної причини. Engagement Score — інтегральний показник студентської успішності.

def compute_engagement_score(student_weekly_data):
    weights = {
        'video_completion_rate': 0.20,
        'quiz_participation_rate': 0.20,
        'session_regularity_score': 0.15,
        'forum_activity_score': 0.10,
        'assignment_lead_time': 0.15,
        'material_depth_score': 0.20
    }
    scaler = MinMaxScaler()
    normalized = scaler.fit_transform(student_weekly_data[list(weights.keys())])
    score = sum(normalized[:, i] * w for i, w in enumerate(weights.values()))
    return score

Чому XGBoost кращий за логістичну регресію?

XGBoost дає приріст AUC на 12-15% за рахунок врахування нелінійних взаємодій (наприклад, комбінація «низька регулярність + пропущені тести»). Scale_pos_weight=3 компенсує дисбаланс класів (at-risk ~25%). SHAP-значення дозволяють пояснити куратору, чому модель вважає студента в зоні ризику: «зниження активності за 4 тижні — головний фактор».

Таблиця 1. Порівняння моделей на даних 2000 студентів. Більше інформації про XGBoost.

Процес роботи

1. Аналітика (1-2 тижні). Вивчаємо структуру LMS, доступні логи, якість даних. Складаємо карту сигналів залученості.
2. Проектування (1 тиждень). Визначаємо ваги Engagement Score, вибираємо пороги спрацювання, проектуємо дашборд.
3. Реалізація (3-4 тижні). Пишемо пайплайн обробки даних, навчаємо XGBoost, інтегруємо SHAP та кластеризацію.
4. Тестування (1 тиждень). А/Б-тест на історичних даних: порівнюємо точність прогнозів з реальними відрахуваннями.
5. Деплой (1 тиждень). Розгортання на вашому сервері або в хмарі (Docker + FastAPI). Налаштування webhook-сповіщень.

Що входить у результат

• Дашборд куратора. У реальному часі показує Engagement Score кожного студента, тренд, кластер ризику та топ-3 причини.
• Модель раннього попередження. XGBoost з порогом, налаштованим під ваш курс. Видає ймовірність відрахування на 4-му тижні. Модель ризику відрахування на основі XGBoost.
• SHAP-звіти. Для кожного at-risk студента — зрозуміле пояснення: «основна причина — пропущені тести, внесок 40%».
• Автоматичні інтервенції. Налаштовувані тригери: email при низькому score, дзвінок при score < 0.2, пропозиція тьютора при ознаках утруднення.
• Інтеграція з LMS. Moodle, Canvas, Blackboard — через їх API. Дані оновлюються раз на годину для студентів високого ризику.
• Документація та навчання. Повна схема даних, опис моделі, інструкція для кураторів.

Терміни та вартість

Базовий MVP (Engagement Score + at-risk модель + дашборд) — від кількох тижнів, термін від 3 до 4 тижнів. Повний функціонал з кластеризацією, SHAP та автоінтервенціями — 2-3 місяці. Вартість розраховується індивідуально після аудиту ваших даних.

Гарантуємо точність прогнозів не нижче 80% AUC на ваших даних (за наявності мінімум 4 тижнів історії). Досвід команди — 5+ років у ML для EdTech, понад 20 впроваджень в університетах СНД та Європи.

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

Виявлення аномалій: автоенкодери, Isolation Forest, PyOD

Ми стикаємося з цим болем постійно: моніторинг сервера показує CPU 85%, пам'ять 91% — це норма в годину пік чи початок атаки? Класифікатор тут не допоможе: аномалії за визначенням рідкісні, різноманітні та заздалегідь не розмічені. Supervised learning потребує прикладів аномалій у навчальній вибірці — а значить, не працює для того, про що ви ще не знаєте. Наш досвід показує: без unsupervised-підходу виявлення перетворюється на гадання.

Чому виявлення аномалій потребує unsupervised підходу?

Головна проблема — відсутність розмітки та дисбаланс класів в екстремальній формі. Фрод-транзакції становлять 0.01–0.1% від загального об'єму. Виробничий дефект — 0.5–3%. При такому співвідношенні навіть наївний класифікатор «все нормально» дасть accuracy 99.9% і precision/recall для аномального класу, близькі до нуля. Supervised-моделі тут безсилі.

Друга проблема — «нормальність» завжди контекстна. Чи нормально, що користувач логіниться о 3 годині ночі? Залежить від його історії та часової зони. Чи нормальна вібрація підшипника 2.3 мм/с? Залежить від режиму роботи верстата та його віку. Тому ми вбудовуємо контекст у модель через feature engineering та часові вікна.

Третя — оцінка якості. Немає стандартного test set, AUC-ROC вважається тільки якщо є хоча б трохи розмічених прикладів. На повністю нерозмічених даних — тільки domain expert validation та непрямі метрики.

Як відрізнити аномалію від шуму в реальному часі?

Відповідь — адаптивні пороги та моніторинг статистик моделі. У розділі кейсу покажемо, як це працює.

Методи та інструменти

Isolation Forest — стандартний baseline для табличних даних. Ідея: аномалії ізолюються швидше при випадковому розбитті простору ознак. Працює добре при contamination 0.01–0.1, стійкий до масштабу ознак, не потребує нормалізації. Реалізація в sklearn.ensemble.IsolationForest.

Типова помилка: ставити contamination='auto' без розуміння даних. Auto-режим передбачає поріг -0.5, що не завжди відповідає реальній частці аномалій. Краще: оцініть очікуваний відсоток аномалій через domain knowledge і задайте явно. Ми гарантуємо підбір contamination під ваш кейс.

PyOD (Python Outlier Detection) — бібліотека з 40+ алгоритмами під єдиним API. Включає: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Зручно для швидкого порівняння методів на одних даних.

Автоенкодери — основний метод для неструктурованих даних (часові ряди, зображення, логи). Ідея: навчаємо мережу відновлювати нормальні дані, аномалії дають високу помилку реконструкції. Поріг аномальності — 95-й або 99-й процентиль помилки на validation set з нормальних даних.

Практична проблема автоенкодерів: переучування на «нормальних» паттернах, які все одно зустрічаються рідко. Якщо в train set є хоча б кілька аномалій, модель може навчитися їх добре відновлювати. Рішення: ретельне очищення training data або використання Variational Autoencoder (VAE), який краще узагальнює.

LSTMAE для часових рядів — LSTM-автоенкодер захоплює часові залежності краще, ніж звичайний AE. Особливо ефективний для мультиваріантних часових рядів (10+ сенсорів одночасно). Реалізація через PyTorch, навчання з MSELoss на ковзних вікнах.

Детально: виявлення аномалій у промислових часових рядах

Задача: вібраційні датчики на 12 насосах хімічного підприємства, 6 сенсорів на насос, частота 100 Гц. Потрібно попередити про наближену поломку за 4–24 години.

Архітектура рішення:

Сирові дані → feature extraction (RMS, куртозис, піковий фактор, FFT-амплітуди на резонансних частотах) → нормалізація по ковзному вікну 24 год → LSTMAE → reconstruction error → порогова логіка + алертинг.

Розмір вікна LSTM: 60 секунд (6000 точок на 100 Гц). Занадто мале вікно — не захоплює повільні паттерни. Занадто велике — втрачає чутливість до швидких змін.

Поріг аномальності: не фіксований, а адаптивний. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфі нормального стану (плановий знос) поріг адаптується, уникаючи false positives.

Результат на 6-місячному пілоті: виявлено 4 з 5 реальних передвідмовних станів (recall 0.8), 2 хибні тривоги за 6 місяців (precision 0.67). До впровадження: 3 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

Фрод-детекція: специфіка фінансових даних

Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:

• Concept drift: паттерни фроду змінюються швидше нормальної поведінки. Модель, навчена півроку тому, застаріває.
• Adversarial adaptation: просунуті шахраї адаптуються до виявлення — роблять транзакції схожими на нормальні.
• Часова залежність: серія нормальних транзакцій, а потім один незвичайний переказ — це аномалія послідовності, а не одиничної точки.

Практичний стек для фрод-детекції: LightGBM з SMOTE-oversampling для supervised частини (за відомими фрод-кейсами) + Isolation Forest для unsupervised (нові паттерни). Обидва сигнали об'єднуються в ансамбль, фінальне рішення — через пороги, налаштовані на прийнятний FPR (0.1–1% від транзакцій на ручну перевірку).

Як оцінити якість без розмітки?

Коли ground truth немає, для оцінки використовуємо:

• Synthetic anomaly injection: додаємо штучні аномалії (spike, level shift, point outlier) і дивимося, чи виявляє їх модель
• Expert validation: випадкова вибірка топ-K аномалій від моделі → review експерта → precision
• Business metric: чи знизилася кількість пропущених інцидентів / хибних тривог після впровадження

Процес роботи

1. Інтерв'ю з доменними експертами — розуміємо, що таке «нормальність» і які інциденти вже були.
2. EDA та підготовка даних — очищення, створення ознак, часові вікна.
3. Baseline (Isolation Forest) — швидка валідація на відомих інцидентах.
4. Вибір та кастомізація моделі — Autoencoder / LSTM-AE / ансамбль.
5. Навчання, валідація з синтетичними аномаліями.
6. Розгортання в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, моніторинг дрифту.
7. Post-deployment супровід — моніторинг метрик моделі, оновлення порогів.

Що входить у роботу

• Аудит поточних даних та процесів
• Розробка та навчання моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
• Налаштування адаптивних порогів та алертингу
• Панель моніторингу аномалій (Grafana / Streamlit)
• Документація model card та pipeline
• Навчання вашої команди (2–3 сесії)
• Гарантійна підтримка 3 місяці

Терміни: baseline-система з одним методом — 2–4 тижні. Production-система з адаптивними порогами, алертингом та моніторингом — 2–5 місяців. Вартість розраховується індивідуально під ваш кейс.

Наша команда має 8+ років досвіду в промисловій аналітиці та 15+ успішних проектів з виявлення аномалій в телеметрії, фінансах та IT-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.