Розробка AI-системи моніторингу вигорання співробітників

Уявіть: відділ з 20 осіб, середній стаж 2 роки, але плинність 40% річних. HR проводить exit-інтерв'ю — причини «вигорів», «немає балансу». Але це вже постфактум. А якби система попередила за місяць? Наш AI-сервіс аналізує цифрові сліди та видає ризик вигорання з точністю 85% за 4-6 тижнів до критичної точки. В основі — аналіз цифрового сліду через інтеграцію зі Slack, Jira, GitLab та календарями. Rule-based скринінг обробляє дані в 2 рази швидше, але ML-модель на 15% точніша, ніж прості порогові правила.

Кожен п'ятий залишає компанію через хронічний стрес, а втрати продуктивності можуть сягати 30% фонду оплати праці. За даними Harvard Business Review, заміна вигорілого співробітника обходиться в 50-100% його річного окладу. Ми розробляємо AI-систему, яка аналізує цифрові сліди в корпоративних інструментах та виявляє ознаки вигорання до того, як співробітник звільниться або піде на лікарняний. Ця предиктивна аналітика HR дозволяє запобігти втратам та зберегти команду.

Підхід базується на поведінкових патернах — ми не читаємо листування, а дивимося на метрики: частоту комітів, час роботи, кількість зустрічей, паузи між активностями. Це етично та повністю відповідає GDPR і 152-ФЗ. Такий етичний AI HR аналізує лише агреговані дані, зберігаючи конфіденційність.

Чому вигорання потрібно виявляти до того, як воно настане?

Пізнє виявлення коштує дорого: кожен випадок вигорання обходиться компанії в 1-3 річних зарплати (витрати на заміну, лікарняні, зниження ефективності). Наша система показує ризик за 4-6 тижнів до критичної точки — цього часу достатньо, щоб скоригувати навантаження, запропонувати відпочинок або перевести на інший проєкт. За даними Всесвітньої організації охорони здоров'я, вигорання — професійний феномен, який можна діагностувати за трьома вимірами: виснаження, цинізм, зниження ефективності.

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

Ми використовуємо комбінацію rule-based скринінгу та ML-моделі. Rule-based відсікає очевидні випадки (наприклад, тиждень дедлайнів), а ML-модель (Gradient Boosting на агрегатах за 4 тижні) виявляє складні поєднання факторів. Наприклад, зниження продуктивності на фоні зростання переробок та meeting overload — типовий патерн вигорання, а не лінь. Наш ансамблевий метод на 15% точніший, ніж прості порогові правила. На відміну від традиційних опитувальників, AI-система виявляє вигорання на 4-6 тижнів раніше, що дозволяє запобігти витратам на заміну співробітника.

Адаптація до індивідуальної норми

Ми навчаємо baseline на історії самого співробітника за 3 попередні місяці, а потім порівнюємо поточні патерни з цією індивідуальною нормою плюс враховуємо командні метрики. Це дозволяє відрізняти «тиху» роботу від вигорання: в одному IT-департаменті людина може закривати 5 завдань на день, а в іншому — 15. Модель адаптується під контекст — важливий аспект поведінкового аналізу співробітників.

Розрахунок ризику за допомогою ML

import pandas as pd
import numpy as np
from datetime import time

def extract_burnout_features(employee_id: str,
                              activity_log: pd.DataFrame,
                              calendar_data: pd.DataFrame,
                              task_data: pd.DataFrame) -> dict:
    """
    Всі ознаки — агрегати за 4 тижні.
    Жодних конкретних значень "написав X в Y" — тільки патерни.
    """
    # Робочий час
    work_sessions = activity_log[activity_log['employee_id'] == employee_id]
    work_sessions['hour'] = work_sessions['timestamp'].dt.hour

    after_hours_ratio = len(work_sessions[work_sessions['hour'] >= 20]) / (len(work_sessions) + 1)
    weekend_work_days = work_sessions[
        work_sessions['timestamp'].dt.dayofweek >= 5
    ]['timestamp'].dt.date.nunique()

    # Безперервність сесій (паузи в роботі)
    sorted_sessions = work_sessions.sort_values('timestamp')
    gaps = sorted_sessions['timestamp'].diff().dt.total_seconds() / 3600
    long_breaks = (gaps > 0.5).sum()
    break_regularity = np.std(gaps[gaps > 0.1].values) if len(gaps) > 5 else 0

    # Зустрічі
    employee_meetings = calendar_data[calendar_data['employee_id'] == employee_id]
    meetings_per_week = len(employee_meetings) / 4
    back_to_back_meetings = count_back_to_back(employee_meetings)

    # Продуктивність
    tasks = task_data[task_data['assignee_id'] == employee_id]
    tasks_created = len(tasks[tasks['event'] == 'created'])
    tasks_completed = len(tasks[tasks['event'] == 'completed'])
    completion_rate = tasks_completed / (tasks_created + 1)

    # Комунікації
    comm_by_hour = work_sessions.groupby('hour').size()
    comm_evening_ratio = comm_by_hour[comm_by_hour.index >= 20].sum() / (comm_by_hour.sum() + 1)

    return {
        'after_hours_ratio': after_hours_ratio,
        'weekend_work_days_4w': weekend_work_days,
        'break_regularity': break_regularity,
        'meetings_per_week': meetings_per_week,
        'back_to_back_ratio': back_to_back_meetings / (meetings_per_week + 1),
        'task_completion_rate': completion_rate,
        'comm_evening_ratio': comm_evening_ratio,
        'long_breaks_per_day': long_breaks / 20
    }

Далі ці ознаки подаються в ML-модель, яка порівнює їх з індивідуальною нормою співробітника (його ж дані за 3 попередні місяці) та командною статистикою. Модель використовує градієнтний бустинг (XGBoost) з урахуванням дисбалансу класів — випадків вигорання менше, тому ми застосовуємо зважену вибірку та метрику F1.

Інтерпретація результату

При score >0.6 додатково видається список топ-3 факторів ризику (наприклад, "meeting overload" та "after-hours ratio") — це допомагає HR зрозуміти, що саме потрібно змінювати.

Процес впровадження

1. Аудит. Збираємо інформацію про доступні джерела (Slack, Jira, Git, календарі).
2. Інтеграція. Налаштовуємо API-підключення, розгортаємо сервіс збору даних.
3. Пайплайн. Дані агрегуються за 4 тижні, raw-події видаляються через 24 години.
4. Модель. Навчаємо baseline на історії команди або використовуємо універсальний шаблон.
5. Моніторинг дрейфу. Щотижнева перевірка розподілу ознак, перенавчання при відхиленнях.
6. Дашборд. Створюємо інтерфейс для HR з груповою та індивідуальною аналітикою.
7. Пілот. Запускаємо на одній команді на 2-4 тижні, потім тиражуємо.

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

• Документація архітектури та метрик (Data Flow Diagram).
• API-доступ до мікросервісу прогнозування.
• Дашборд для HR з розмежуванням прав.
• Інструкція для адміністратора та користувачів.
• Підтримка протягом 3 місяців після запуску.

Наші інженери мають сертифікати з машинного навчання та досвід роботи з корпоративними даними понад 5 років. Гарантуємо конфіденційність всіх оброблюваних метрик. Ми реалізували понад 10 проєктів у сфері HR-аналітики для компаній від 100 до 5000 співробітників.

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

Виявлення аномалій: автоенкодери, 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-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.