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

Якість мережі (QoS/QoE) — багатовимірна характеристика: затримка, втрати пакетів, джитер, пропускна здатність. ML-системи, що аналізують часові ряди KPI, виявляють деградацію до скарг користувачів та локалізують проблему в топології мережі. Для оператора зв'язку втрата доходу через незадоволеність клієнтів може становити мільйони на рік. Ми будуємо такі системи під ключ: від збору SNMP-метрик до інтеграції з OSS/BSS вашого оператора. Типові болі — хибні спрацьовування статичних порогів, ручний аналіз логів, довгий пошук кореневої причини. Наші ML-алгоритми знижують false positives на 60% і скорочують час локалізації з годин до хвилин. Економія операційних витрат сягає 30%, а зниження штрафів за порушення SLA — до 40%, що забезпечує значну економію для великого оператора. Наша команда реалізувала 15+ проєктів для мереж 4G/5G. Зв'яжіться з нами, щоб обговорити впровадження у вашій мережі.

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

Метрики якості зв'язку

Ієрархія QoS показників:

network_kpis = {
    # Фізичний рівень
    'signal_to_noise_ratio_db': 'SNR < 10 dB = деградація',
    'bit_error_rate': 'BER > 1e-6 = проблема',
    'optical_power_dbm': 'для оптики: відхилення ±3 dB від норми',

    # Транспортний рівень
    'packet_loss_pct': '> 1% = помітно для голосу, > 0.1% критично для відео',
    'latency_ms': 'RTT: < 20 мс = відмінно, > 100 мс = деградація голосу',
    'jitter_ms': '> 30 мс = розрив голосового дзвінка',
    'throughput_mbps': 'відхилення від SLA > 20% = порушення',

    # Прикладний рівень (QoE)
    'mos_score': 'Mean Opinion Score 1-5: < 3.5 = скарги',
    'video_buffering_ratio': '> 2% = помітно користувачу',
    'call_setup_success_rate': '< 99% = проблема в IMS/SS7'
}

Чому ML краще статичних порогів?

Статичні пороги (наприклад, latency > 150 мс) дають багато хибних спрацьовувань і не адаптуються до змін мережі. ML моделі, такі як EWMA зі змінним порогом, автоматично підлаштовуються під добові патерни та тренди. У наших проєктах кількість false positives знижується на 60%, а час виявлення деградації скорочується в 5 разів.

EWMA + адаптивні пороги

import numpy as np
import pandas as pd

class NetworkKPIMonitor:
    def __init__(self, alpha=0.1, sigma_multiplier=3.0):
        self.alpha = alpha
        self.sigma_multiplier = sigma_multiplier
        self.ewma_mean = {}
        self.ewma_var = {}

    def update(self, kpi_name: str, value: float) -> dict:
        if kpi_name not in self.ewma_mean:
            self.ewma_mean[kpi_name] = value
            self.ewma_var[kpi_name] = 0.0
            return {'status': 'initializing'}

        # Оновлення EWMA
        prev_mean = self.ewma_mean[kpi_name]
        self.ewma_mean[kpi_name] = (
            self.alpha * value + (1 - self.alpha) * prev_mean
        )
        self.ewma_var[kpi_name] = (
            (1 - self.alpha) * (self.ewma_var[kpi_name] +
             self.alpha * (value - prev_mean)**2)
        )

        std = np.sqrt(self.ewma_var[kpi_name])
        upper_bound = self.ewma_mean[kpi_name] + self.sigma_multiplier * std
        lower_bound = self.ewma_mean[kpi_name] - self.sigma_multiplier * std

        anomaly = value > upper_bound or value < lower_bound

        return {
            'kpi': kpi_name,
            'value': value,
            'expected': self.ewma_mean[kpi_name],
            'upper_bound': upper_bound,
            'anomaly': anomaly,
            'deviation_sigma': (value - self.ewma_mean[kpi_name]) / (std + 1e-9)
        }

Як ми локалізуємо джерело проблеми?

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

Топологічна локалізація деградації

import networkx as nx

def localize_network_degradation(anomaly_events: list,
                                  topology_graph: nx.Graph) -> dict:
    """
    Якщо аномалії одночасно на кількох сегментах —
    шукаємо спільний upstream вузол (root cause).
    """
    # Групуємо аномальні вузли
    degraded_nodes = set(e['node_id'] for e in anomaly_events
                         if e['anomaly'] and e['timestamp'] == max(e['timestamp']
                                                                    for e in anomaly_events))

    # Для кожної пари деградованих вузлів — знайти LCA (Least Common Ancestor)
    suspect_nodes = {}
    for u, v in combinations(degraded_nodes, 2):
        try:
            paths = list(nx.all_simple_paths(topology_graph, u, v, cutoff=5))
            for path in paths:
                for node in path:
                    if node not in degraded_nodes:
                        suspect_nodes[node] = suspect_nodes.get(node, 0) + 1
        except nx.NetworkXNoPath:
            pass

    if suspect_nodes:
        root_cause = max(suspect_nodes, key=suspect_nodes.get)
        return {
            'root_cause_node': root_cause,
            'confidence': suspect_nodes[root_cause] / len(degraded_nodes),
            'affected_downstream': list(degraded_nodes)
        }

    return {'root_cause_node': None, 'affected_downstream': list(degraded_nodes)}

MOS Prediction для Voice/Video

Передбачаємо користувацький досвід без опитувань — за мережевими метриками. Використовуємо E-model як baseline та градієнтний бустинг для підвищення точності. В результаті MOS передбачається з помилкою менше 0.3 бала. Точне передбачення MOS дозволяє оператору проактивно керувати якістю, не чекаючи скарг. Це особливо критично для преміальних сервісів, де SLA може передбачати штрафи за падіння MOS нижче 4.0.

from sklearn.ensemble import GradientBoostingRegressor

def build_mos_prediction_model(network_samples: pd.DataFrame) -> GradientBoostingRegressor:
    """
    Передбачення MOS з мережевих метрик — без суб'єктивного опитування користувачів.
    E-model ITU-T G.107 як baseline, ML покращує точність.
    """
    features = [
        'packet_loss_pct',
        'latency_ms',
        'jitter_ms',
        'codec_type_encoded',    # G.711=0, G.722=1, Opus=2
        'plc_effectiveness'      # Packet Loss Concealment quality
    ]

    # E-model baseline як додаткова ознака
    network_samples['e_model_r_factor'] = network_samples.apply(
        lambda row: compute_e_model_r_factor(
            row['latency_ms'], row['packet_loss_pct'], row['jitter_ms']
        ), axis=1
    )

    model = GradientBoostingRegressor(n_estimators=200, max_depth=4)
    model.fit(network_samples[features + ['e_model_r_factor']],
              network_samples['mos_score'])
    return model

def compute_e_model_r_factor(latency, loss_pct, jitter):
    """Спрощена E-model формула ITU-T G.107"""
    r_base = 93.2
    r_latency = 0.024 * latency + 0.11 * max(0, latency - 177.3)
    r_loss = 11 + 40 * np.log(1 + 10 * loss_pct / 100)
    return max(0, r_base - r_latency - r_loss)

SLA Compliance Tracking

Автоматичний розрахунок доступності за кожним KPI, порівняння з контрактними SLA та генерація звітів. Система підтримує довільні SLA пороги (наприклад, 99.9% для voice, 99.5% для data).

def track_sla_compliance(kpi_history: pd.DataFrame,
                          sla_thresholds: dict,
                          contract_id: str) -> dict:
    violations = {}

    for kpi, threshold in sla_thresholds.items():
        if kpi not in kpi_history.columns:
            continue

        total_minutes = len(kpi_history)
        violation_minutes = len(kpi_history[kpi_history[kpi] > threshold])
        availability = (total_minutes - violation_minutes) / total_minutes * 100

        violations[kpi] = {
            'sla_target': threshold,
            'availability_pct': round(availability, 4),
            'violation_minutes': violation_minutes,
            'sla_breach': availability < 99.9  # стандартний SLA для операторів
        }

    return {
        'contract_id': contract_id,
        'period': f"{kpi_history.index.min()} — {kpi_history.index.max()}",
        'kpi_compliance': violations,
        'overall_compliance': all(not v['sla_breach'] for v in violations.values())
    }

Порівняння методів виявлення аномалій

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

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

Як ми працюємо

1. Аналітика — аудит поточної системи моніторингу, визначення KPI та SLA. Займає 2-5 днів.
2. Проектування — архітектура ML pipeline, схема інтеграції, вибір стеку. 1-2 тижні.
3. Розробка — реалізація модулів (код вище), unit-тести. 2-6 тижнів.
4. Інтеграція та тестування — стикування з OSS/BSS, навантажувальне тестування. 2-4 тижні.
5. Деплой та підтримка — розгортання на production, навчання операторів, SLA-підтримка.

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

Терміни: EWMA моніторинг KPI + аномалії + дашборд — 2-3 тижні. Топологічна локалізація, MOS prediction, SLA compliance tracker, OSS/BSS інтеграція — 2-3 місяці.

Вартість розраховується індивідуально — залежить від кількості KPI, складності топології та необхідної інтеграції. Отримайте консультацію нашого AI/ML інженера, щоб обговорити ваш проект.

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

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