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

У великих молочних фермах на 1000+ голів ветеринар не встигає оглянути кожну корову щодня. Втрата одного дня при маститі — падіння надою на 10–15%, а несвоєчасне осіменіння — пусті дні та значні збитки. Ми розробляємо AI-системи під ключ: склеюємо дані з вушних датчиків, румен-болусів, молокомірів та відео, видаємо алерти за 24–48 годин до клінічних проявів. Наш досвід — 10+ проєктів в Україні та СНД, середнє зниження падежу — 15–20%. Автоматичне виявлення охоти в 2 рази ефективніше візуального спостереження: точність досягає 95% проти 60%. Використовуємо машинне навчання для поведінкового аналізу худоби та IoT-пристрої для збору даних.

Які проблеми вирішує AI-моніторинг?

Три ключові задачі, які закриває система:

1. Пропущена охота — кожна охота триває 12–18 годин, візуально її помічають у 60% випадків. Система аналізує активність і румінацію з інтервалом 2 хвилини та видає алерт за 4–6 годин до завершення вікна осіменіння.

2. Субклінічний мастит — електропровідність молока зростає за 24–48 годин до появи згустків. Чутливість 85% при специфічності 90%.

3. SARA (субклінічний ацидоз рубця) — pH рубця падає нижче 5.8 на 3+ години, знижуючи продуктивність на 15%. Аналіз часових рядів з румен-болуса виявляє ризик за 1–2 дні.

Як детектувати охоту з точністю 95%?

Алгоритм за активністю та румінацією:

import pandas as pd
import numpy as np
from scipy.signal import find_peaks

def detect_estrus(animal_id: str, sensor_data: pd.DataFrame,
                  baseline_days: int = 21) -> dict:
    """
    Охота у ВРХ: різке зростання активності + зниження румінації
    Цикл ~21 день — патерн періодичний
    """
    recent = sensor_data[sensor_data['animal_id'] == animal_id].tail(baseline_days * 24)

    activity_baseline = recent['activity_count'].quantile(0.5)
    rumination_baseline = recent['rumination_time'].quantile(0.5)

    current_24h = sensor_data[
        sensor_data['animal_id'] == animal_id
    ].tail(12)

    activity_ratio = current_24h['activity_count'].mean() / (activity_baseline + 1e-9)
    rumination_ratio = current_24h['rumination_time'].mean() / (rumination_baseline + 1e-9)

    estrus_score = activity_ratio * (2 - rumination_ratio)

    prev_cycle_score = check_previous_cycle(animal_id, sensor_data, days_back=21)

    return {
        'animal_id': animal_id,
        'estrus_score': float(estrus_score),
        'estrus_detected': estrus_score > 2.5,
        'confidence': 'high' if prev_cycle_score > 2.0 else 'medium',
        'recommended_action': 'insemination_window_12-18h' if estrus_score > 2.5 else None
    }

Чому румінація — ключовий індикатор здоров'я?

Рання детекція маститу:

def mastitis_risk_score(milking_data: pd.DataFrame, animal_id: str) -> float:
    """
    Мастит → запалення → зростання іонів Na+, Cl- → зростання електропровідності
    """
    today_milking = milking_data[
        (milking_data['animal_id'] == animal_id) &
        (milking_data['date'] == milking_data['date'].max())
    ]

    if today_milking.empty:
        return 0.0

    quarters = ['LF', 'RF', 'LR', 'RR']
    conductivities = {q: today_milking[f'conductivity_{q}'].mean()
                      for q in quarters if f'conductivity_{q}' in today_milking.columns}

    if len(conductivities) < 2:
        return 0.0

    mean_cond = np.mean(list(conductivities.values()))
    max_deviation = max(abs(v - mean_cond) for v in conductivities.values())

    relative_deviation = max_deviation / (mean_cond + 1e-9)

    yield_deviation = check_yield_drop(animal_id, milking_data, today_milking)

    risk_score = 0.6 * (relative_deviation / 0.1) + 0.4 * yield_deviation
    return min(1.0, risk_score)

Додаткові ознаки маститу: підвищення температури молока в квартеті (+0.5°C), флокуляція, зниження надою, зміна поведінки.

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

1. Збір еталонних даних: мінімум 500 доїнь без патології для кожної корови.
2. Обчислення baseline електропровідності по кожному квартету з урахуванням стадії лактації.
3. Налаштування порогів спрацювання: чутливість 85% при специфічності 90%.
4. Валідація на історичних даних: мінімум 50 підтверджених випадків маститу.
5. A/B тест на 10% поголів'я перед повним деплоєм.

Що дає моніторинг SARA?

Субклінічний ацидоз рубця (SARA) — зниження pH < 5.8 більше 3 годин:

def detect_sara_risk(rumen_bolus_data: pd.DataFrame, animal_id: str) -> dict:
    """
    Дані від rumen bolus SmaXtec оновлюються кожні 10 хвилин
    """
    today_data = rumen_bolus_data[
        (rumen_bolus_data['animal_id'] == animal_id) &
        (rumen_bolus_data['date'] == pd.Timestamp.today().date())
    ]

    low_ph_minutes = len(today_data[today_data['rumen_pH'] < 5.8]) * 10

    avg_ph = today_data['rumen_pH'].mean() if not today_data.empty else 6.5
    rumination_today = today_data['rumen_motility'].mean() if not today_data.empty else 1.0

    sara_risk = 'high' if low_ph_minutes > 180 else (
        'medium' if low_ph_minutes > 60 else 'low'
    )

    return {
        'animal_id': animal_id,
        'low_ph_hours': round(low_ph_minutes / 60, 1),
        'avg_ph': round(avg_ph, 2),
        'sara_risk': sara_risk,
        'action': 'adjust_roughage_ratio' if sara_risk == 'high' else None
    }

Моніторинг SARA дозволяє точне годування: при виявленні ризику система рекомендує змінити співвідношення грубих кормів. Впровадження знижує витрати на ветобслуговування та підвищує продуктивність стада.

Як інтегрувати систему з існуючим ПЗ?

Ми підтримуємо REST API для передачі подій у DairyComp 305, Lely T4C, DeLaval ALPRO, а також у Herd monitoring software. Інтеграція займає 1-2 дні. Дані передаються в реальному часі: події охоти, ризики захворювань, вагові показники.

Як ми впроваджуємо систему: кейс

На фермі з 2000 голів ВРХ ми встановили вушні акселерометри SCR та румен-болуси SmaXtec. За перший тиждень зібрали ~1.5 млн записів активності та 200 тис. замірів pH. Через 3 тижні моделі досягли 92% чутливості по охоті та 90% по SARA. Порівняйте: візуальний метод дає 60% охоти, а ручний аналіз pH — поодинокі заміри. Автоматизація в 1.5 рази скоротила витрати на ветслужбу.

Етапи проєкту та терміни

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

• Архітектурна документація та опис API
• Навчання персоналу (2 дні очно або онлайн)
• 30 днів пострелізної технічної підтримки
• Гарантія на моделі — 6 місяців (безкоштовні оновлення при зміні стада)
• Адаптація під існуючу інфраструктуру (DairyComp 305, Lely T4C, DeLaval ALPRO)

Залиште заявку — ми оцінимо вашу ферму за 2 дні та запропонуємо архітектуру. Зв'яжіться з нами, щоб обговорити проєкт. Отримайте консультацію по вашому стаду та дізнайтесь, як AI-моніторинг може знизити падіж та підвищити надої.

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