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

Качество сети (QoS/QoE) — многомерная характеристика: задержка, потери пакетов, джиттер, пропускная способность. ML-системы, анализирующие временные ряды KPI, обнаруживают деградацию до жалоб пользователей и локализуют проблему в топологии сети. Для оператора связи потеря дохода из-за неудовлетворённости клиентов может составлять миллионы в год. Мы строим такие системы под ключ: от сбора SNMP-метрик до интеграции с OSS/BSS вашего оператора. Типичные боли — ложные срабатывания статических порогов, ручной анализ логов, долгий поиск корневой причины. Наши ML-алгоритмы снижают false positives на 60% и сокращают время локализации с часов до минут. Экономия операционных затрат достигает 30%, а снижение штрафов за нарушение SLA — до 40%, что для крупного оператора может составить до 2 миллионов рублей в год. Наша команда реализовала 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 инженера, чтобы обсудить ваш проект.

Средняя экономия от внедрения — около 1,2 млн рублей в месяц для оператора среднего размера. Снижение штрафов за нарушение SLA может достигать 1,5 млн рублей в год.

Детекция аномалий: автоэнкодеры, 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 незапланированных остановки по $40k каждая. Экономия после внедрения — $120k за полгода (отчёт о пилоте на объекте клиента).

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

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

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