ℹ️Материал подготовлен нейросетью DeepSeek.
Отчет по результатам эксперимента
☑️Данные уже накоплены в достаточном объёме (12 700+ переходов), поэтому этап 1 завершён, переходим к улучшению модели.
1. Внедрение аддитивного сглаживания (этап 2)
📋Цель: устранить нулевые и единичные вероятности, сделав оценки риска непрерывными и более реалистичными.
1.1. Модификация функций расчёта вероятностей
Создать новую функцию update_markov_probabilities_smoothed(p_alpha_smooth REAL DEFAULT 0.1), которая:
- Для каждой пары (from_state, to_state) использует сглаженную частоту: frequency + p_alpha_smooth.
- Пересчитывает вероятности как отношение сглаженной частоты к сумме сглаженных частот по каждому исходному состоянию.
- Обеспечивает вставку всех возможных переходов из state_descriptions (включая те, которых нет в markov_frequencies), чтобы каждое состояние имело полный ряд вероятностей.
- Интегрировать вызов этой функции в mchain_apply_forgetting вместо стандартной update_markov_probabilities, добавив параметр сглаживания в markov_config (например, столбец smoothing_alpha).
1.2. Эксперименты со значением параметра сглаживания
Провести ретроспективные эксперименты (аналогично предыдущим) для значений p_alpha_smooth = 0.01, 0.1, 0.5, 1.0.
Для каждого значения:
- Перестроить вероятности и поглощающую матрицу.
- Сгенерировать прогнозы за последние 14 дней (использовать уже имеющийся механизм run_experiment с модифицированной функцией расчёта вероятностей).
- Сохранить метрики качества (ROC‑AUC, Brier, Log‑loss, калибровку) в таблицу сравнения.
- Выбрать оптимальное значение, обеспечивающее наилучший компромисс между ROC‑AUC и калибровкой.
1.3. Внедрение выбранного сглаживания в production
- Обновить markov_config, добавив столбец smoothing_alpha со значением, выбранным по результатам экспериментов.
- Изменить mchain_apply_forgetting, чтобы она использовала update_markov_probabilities_smoothed с параметром из конфигурации.
- Перестроить markov_probabilities и markov_absorbing один раз вручную для применения сглаживания к текущим данным.
- Запустить сбор прогнозов (через collect_prediction_15min) и оценить качество на свежих данных через mchain_quality_report_15min.
1.4. Мониторинг и корректировка
- Наблюдать за метриками качества в течение недели.
- Если улучшение незначительно, повторить эксперименты с более широким диапазоном p_alpha_smooth (например, 0.001, 2.0) или рассмотреть возможность использования бета-сглаживания.
❓2. Применение альтернативных алгоритмов (этап 3) – только внутри PostgreSQL
📋Цель: если сглаживание не даёт нужного качества, перейти к более сложным моделям, не требующим выгрузки данных.
❌2.1. Калибровка существующей цепи Маркова (платтиновское масштабирование)
Сбор обучающих данных: выбрать исторические прогнозы из prediction_log за последние 30 дней, для которых известен actual_outcome. Сохранить пары (predicted_risk, actual_outcome).
❌Обучение логистической регрессии на этих данных (с использованием расширения madlib или встроенного PL/R/PL/Python) для модели:
- actual_outcome ~ log(predicted_risk / (1 - predicted_risk)) (или просто ~ predicted_risk).
- Получение коэффициентов a и b модели.
Создание новой функции прогнозирования mchain_predict_risk_calibrated(), которая:
- Вызывает существующую цепь Маркова для получения сырого риска p.
- Применяет калибровку: p_calibrated = 1 / (1 + exp(-(a + b * log(p/(1-p))))).
- Возвращает откалиброванную вероятность.
- Интеграция: заменить вызов mchain_predict_risk_15min на новую функцию в collect_prediction_15min для тестового периода.
- Оценка: сравнить метрики качества с текущей моделью. Если улучшение есть – оставить калибровку, иначе перейти к п.2.2.
❌2.2. Логистическая регрессия на основе признаков состояния (без цепи Маркова)
Формирование обучающей выборки:
- Для каждого момента времени (каждые 5 минут) за последние 30–60 дней извлечь:
- correlation, os_trend, wait_trend текущего состояния (из state_descriptions).
- Возможно, добавить производные признаки: комбинации трендов, скользящие средние за последние 5 минут, 15 минут и т.д.
- Целевой бинарный признак: наличие инцидента в течение следующих 15 минут (по таблице performance_incident).
- Сохранить выборку в таблицу train_data.
❌Обучение модели с использованием madlib:
- Выполнить madlib.logregr_train для построения модели (можно использовать полиномиальные признаки, если нужно).
- Сохранить модель в таблицу logregr_model.
- Создание функции прогнозирования predict_risk_logregr(correlation, os_trend, wait_trend):
- Использует madlib.predict_logregr для получения вероятности на основе обученной модели.
- Интеграция: заменить цепь Маркова на эту функцию в процессе сбора прогнозов.
- Оценка: сравнить качество (ROC‑AUC, калибровку) с текущей моделью и с моделью после сглаживания.
❌2.3. Гибридный подход – ансамбль (опционально)
Если ни одна из моделей не даёт явного преимущества, попробовать объединить предсказания:
- Усреднить вероятности, полученные от цепи Маркова (после сглаживания) и от логистической регрессии.
- Или использовать логистическую регрессию как мета-модель, принимающую на вход риск из цепи и признаки состояния.
- Реализовать функцию ансамбля и оценить её качество.
❌2.4. Выбор лучшей модели и внедрение в production
Сравнить все разработанные варианты (базовая цепь, цепь со сглаживанием, калиброванная цепь, логистическая регрессия, ансамбль) по метрикам качества на отложенном периоде (например, последние 3 дня).
Выбрать модель с наилучшим ROC‑AUC и калибровкой (Brier, Log‑loss, калибровочная кривая).
Внедрить выбранную модель:
- Переписать collect_prediction_15min для использования новой функции прогнозирования.
- Удалить или закомментировать старые функции (можно оставить для сравнения).
- Настроить мониторинг качества (ежедневный расчёт метрик через calculate_daily_quality_metrics с учётом новой модели).
❌3. Дополнительные мероприятия (сопутствующие)
❌3.1. Настройка расширения madlib (если ещё не установлено)
- Установить пакет madlib в PostgreSQL (требует прав суперпользователя).
- Создать схему madlib и предоставить права на использование.
3.2. Обеспечение воспроизводимости экспериментов
- Создать отдельную схему experiments для хранения временных таблиц и результатов экспериментов.
- Разработать скрипты для автоматического запуска экспериментов (можно использовать уже созданную функцию run_experiment, расширив её параметрами для выбора модели).
3.3. Документирование и обучение команды
- Задокументировать все созданные функции, их параметры и логику.
- Подготовить краткое руководство для эксплуатации модели.
Ожидаемые результаты
- После сглаживания – получение плавных вероятностей вместо бинарных (0 или 1), что должно улучшить калибровку и снизить Log‑loss.
- После калибровки или логистической регрессии – потенциальное повышение ROC‑AUC до значений >0.6, что позволит использовать модель для принятия решений.
- В случае успеха – система прогнозирования становится более надёжной и интерпретируемой.
Риски и меры снижения
- ❓Сглаживание может «размыть» вероятности, сделав их слишком однородными. – контроль через ROC‑AUC; при ухудшении – уменьшить alpha.
Madlib может отсутствовать в окружении.– альтернатива: использовать PL/R или PL/Python (если разрешено) для выполнения регрессии, но это требует установки соответствующих расширений. Если это невозможно, ограничиться калибровкой через простую логистическую регрессию, реализованную вручную на PL/pgSQL (итеративный метод) – но это трудоёмко.- ❓Производительность прогнозирования может снизиться. – провести нагрузочное тестирование, при необходимости использовать материализованные представления или кэширование.
Заключение
Предложенный план полностью реализуем силами команды без привлечения внешних сред.
📋Приоритет – сначала внедрить сглаживание (это быстро и может дать улучшение),
❌затем, при необходимости, перейти к калибровке и логистической регрессии.