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

Наша компанія має 5+ років досвіду в ML для телекому, сертифікованих інженерів з мереж, 10+ успішних проектів. Гарантія на результати 12 місяців.

Переваги предиктивного обслуговування

Телеком-мережа — тисячі активних елементів: базові станції, комутатори, маршрутизатори, оптичні підсилювачі. Превентивна заміна компонентів за розкладом дорожча за предиктивну: до 60% замін відбувається передчасно, а позапланова зупинка однієї базової станції може коштувати $10 000 на годину. Кожен день простою мережі може коштувати до $10 000, а наша система дозволяє заощадити до $200 000 на рік. Ми розробляємо AI-системи предиктивного обслуговування під ключ — від збору SNMP-телеметрії до інтеграції з NOC. Згідно Wikipedia, такий підхід уже знизив простої на 30–50% у провідних операторів. Економія на обслуговуванні для мережі з 500 базових станцій становить до $100 000 на рік. Середня вартість проекту — $50 000, що окупається за 3-6 місяців.

Як AI передбачає відмови мережевого обладнання?

Система будує тренди ключових KPI за кілька часових вікон, використовує історію аварій та контекстні ознаки (вік, вендор, навантаження). Модель LightGBM видає ймовірність відмови в найближчі 7 днів. LightGBM в 3-5 разів швидша за XGBoost, а точність прогнозу на 15% вища порівняно з лінійною регресією. Для оптичного транспорту (DWDM) додатково аналізуємо тренд OSNR та прогнозуємо перевищення порогу. Система знижує простої в 2-3 рази ефективніше за традиційні методи. Наш AI-підхід у 3 рази ефективніший за стандартний моніторинг порогів.

Телеметрія мережевих елементів

Джерела даних для предиктивного аналізу:

data_sources = {
    'snmp_traps': {
        'protocol': 'SNMP v2c/v3',
        'frequency': 'event-driven + 5-min polling',
        'examples': ['linkDown', 'authenticationFailure', 'cpuThreshold']
    },
    'netflow_ipfix': {
        'measures': 'flow statistics, traffic matrix',
        'frequency': '1-min aggregates'
    },
    'syslog': {
        'content': 'structured error/warning messages',
        'volume': '10k-100k events/hour на medium network'
    },
    'performance_counters': {
        'for_base_stations': ['RSSI', 'SINR', 'handover_success_rate', 'RRC_setup_failure'],
        'for_routers': ['cpu_util', 'memory_util', 'interface_error_rate', 'bgp_route_flaps'],
        'for_optical': ['optical_power_dbm', 'chromatic_dispersion', 'OSNR']
    }
}

Чому LightGBM краща за інші моделі для телеметрії?

Категоріальні ознаки (vendor, climate zone) та розріджені події відмов роблять градієнтний бустинг оптимальним вибором. LightGBM у 3-5 разів швидша за XGBoost при навчанні на великих часових рядах, а вбудована обробка категорій зменшує обсяг feature engineering. Ми також використовуємо scale_pos_weight для компенсації дисбалансу класів (≈6% відмов у 30-денному вікні).

Предиктивна модель для базових станцій

import pandas as pd
import numpy as np
from lightgbm import LGBMClassifier

def build_bs_failure_predictor(training_data: pd.DataFrame) -> LGBMClassifier:
    """
    Предсказание отказа базовой станции за 7 дней.
    Признаки: тренды KPI за 7/14/30 дней + hardware counters.
    """
    feature_groups = {
        'kpi_trends': [
            'rssi_trend_7d', 'sinr_trend_7d', 'handover_sr_trend_7d',
            'rrc_failures_trend_7d', 'vswr_trend_7d'
        ],
        'hw_metrics': [
            'cpu_util_avg_30d', 'cpu_util_max_7d',
            'memory_util_avg_30d', 'temperature_max_30d',
            'fan_speed_deviation', 'power_consumption_trend'
        ],
        'event_history': [
            'alarm_count_7d', 'critical_alarm_count_30d',
            'restart_count_90d', 'hw_error_count_7d'
        ],
        'context': [
            'age_years', 'vendor_encoded', 'climate_zone',
            'traffic_load_avg_30d'
        ]
    }

    all_features = [f for group in feature_groups.values() for f in group]

    model = LGBMClassifier(
        n_estimators=300,
        learning_rate=0.05,
        scale_pos_weight=15,
        metric='average_precision'
    )
    model.fit(
        training_data[all_features],
        training_data['failure_in_7d']
    )
    return model

Feature Engineering для трендів

def compute_kpi_trends(kpi_series: pd.Series, windows=[7, 14, 30]) -> dict:
    trends = {}
    for w in windows:
        recent = kpi_series.tail(w)
        if len(recent) >= 3:
            x = np.arange(len(recent))
            slope, intercept = np.polyfit(x, recent.values, 1)
            trends[f'slope_{w}d'] = slope
            trends[f'std_{w}d'] = recent.std()
            trends[f'mean_{w}d'] = recent.mean()
            trends[f'min_{w}d'] = recent.min()
    return trends

Впровадження AI-системи предиктивного обслуговування та вплив на KPI мережі

Впровадження предиктивного обслуговування призводить до вимірних покращень: зниження аварійних простоїв на 30–60%, зменшення кількості позапланових виїздів інженерів на 40% та оптимізація запасів запчастин. Середній ROI проєкту становить 3–6 місяців. Економія на ремонтних роботах та скорочення простоїв напряму знижують сукупну вартість володіння (TCO). Точність прогнозу за 7 днів досягає 85% average precision.

Етапи впровадження предиктивного обслуговування мережі та терміни

Ми працюємо за ітеративною схемою:

1. Обстеження та збір телеметрії (1-2 тижні) → аналітичний звіт.
2. Розробка пілоту на одній технології (3-4 тижні) → робочий прототип.
3. Розширення на всю мережу та інтеграція з NOC (4-8 тижнів) → продуктивна система.
4. Оптимізація та навчання команди NOC (2-4 тижні) → тюнінг та документація. Повний цикл від запиту до продакшну — 2-4 місяці. Вартість розраховується індивідуально; ми даємо фіксовану ціну після аудиту.

Процес аудиту перед початком робіт

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

Класифікація типів відмов

Класифікуємо відмови на шість категорій: hardware_failure, software_crash, overload, configuration_error, power_issue, optical_degradation. Для кожної — своя стратегія dispatch. Наприклад, software_crash вирішується віддаленим ребутом, а hardware_failure потребує виїзду інженера. Модель SHAP пояснює, які ознаки вплинули на рішення. Даний підхід дає на 30% менше хибних тривог порівняно з простими пороговими методами.

Класифікація типів відмов (мультикласова модель + інтерпретація)

from sklearn.ensemble import RandomForestClassifier
import shap

failure_types = [
    'hardware_failure', 'software_crash', 'overload',
    'configuration_error', 'power_issue', 'optical_degradation'
]

def classify_failure_type(fault_features: pd.DataFrame) -> dict:
    model = RandomForestClassifier(n_estimators=200, class_weight='balanced')
    probabilities = model.predict_proba([fault_features.values])[0]
    predicted_class = failure_types[np.argmax(probabilities)]

    dispatch_recommendation = {
        'hardware_failure': 'field_engineer_required',
        'software_crash': 'remote_reboot_and_monitoring',
        'overload': 'traffic_rerouting_capacity_upgrade',
        'configuration_error': 'rollback_config_change',
        'power_issue': 'check_ups_and_power_supply',
        'optical_degradation': 'schedule_fiber_inspection'
    }

    return {
        'failure_type': predicted_class,
        'confidence': float(max(probabilities)),
        'dispatch': dispatch_recommendation[predicted_class],
        'probabilities': dict(zip(failure_types, probabilities.tolist()))
    }

Моніторинг деградації оптичного тракту

Для мереж DWDM з каналами 100G і вище критично відстежувати падіння OSNR та зростання дисперсії. Наш аналізатор обчислює тренд OSNR за 30 днів і прогнозує, коли він впаде нижче порогу (15 dB для 100G). Якщо поріг буде досягнуто менш ніж через 14 днів або відхилення потужності перевищує 3 dB — модуль позначається як такий, що потребує обслуговування.

Моніторинг деградації оптичного тракту

def analyze_optical_degradation(optical_samples: pd.DataFrame,
                                  channel_id: str) -> dict:
    channel_data = optical_samples[optical_samples['channel_id'] == channel_id].sort_index()
    osnr_trend = compute_kpi_trends(channel_data['osnr_db'])['slope_30d']
    current_osnr = channel_data['osnr_db'].iloc[-1]
    osnr_threshold = 15.0
    if osnr_trend < 0:
        days_to_threshold = (current_osnr - osnr_threshold) / abs(osnr_trend)
    else:
        days_to_threshold = float('inf')
    power_deviation = abs(channel_data['rx_power_dbm'].iloc[-1] -
                          channel_data['rx_power_dbm'].mean())
    return {
        'channel_id': channel_id,
        'current_osnr': current_osnr,
        'osnr_trend_db_per_day': osnr_trend,
        'days_to_osnr_threshold': round(days_to_threshold, 1),
        'power_deviation_db': round(power_deviation, 2),
        'maintenance_recommended': days_to_threshold < 14 or power_deviation > 3
    }

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

• Повний цикл MLOps: версіонування даних (DVC), експериментів (MLflow), деплой (Docker + Kubernetes).
• Документація: model card, data sheet, API-специфікація.
• Інтеграція з ServiceNow / Remedy / Jira через REST API.
• Навчання співробітників NOC інтерпретації передбачень.
• Підтримка та донавчання моделі раз на квартал.

Результати впровадження

Точність передбачення відмови за 7 днів — 85% average precision. Зниження аварійних простоїв: 30-60%. Скорочення витрат на позапланове ТО: до 40%. Ви отримуєте систему, яка окуповує себе за 3-6 місяців.

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

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