Анализ отчётов по качеству прогнозирования рисков

ℹ️Материал подготовлен нейросетью DeepSeek , с использованием философской инструкции.

Запрос

Входные данные :

- markov_chain_tables.sql : Определение таблиц для реализации цепи Маркова

- markov_chain_functions.sql : Определение хранимых функций для реализации цепи Маркова

- crontab.txt : Расписание cron для сервисных функций реализации цепи Маркова

- config.txt : Текущая конфигурация цепи Маркова

- reports.txt : Текущие результаты отчетов по состоянию цепи Маркова

Задача:

- Проанализировать результаты отчетов

- Подготовить подробное описание по каждому отчету

Отчеты

☑️Система накопила достаточный объём данных (12 598 переходов) и демонстрирует хорошую общую достоверность (рейтинг 4).

⚠️Однако качество прогнозов крайне низкое (ROC‑AUC ≈ 0.16, Brier ≈ 0.14, все прогнозы ниже порога 0.5).

ℹ️Основная причина – калибровка вероятностей нарушена: предсказанный риск систематически занижен в одних диапазонах и завышен в других. Кроме того, доля аварийных переходов за период составляет ~24–27%, что указывает либо на чрезмерно широкое определение «аварийного состояния», либо на реальную нестабильность системы.

Ниже – детальный разбор каждого отчёта.

1. Сводный отчёт (mchain_summary_report)

🟢 Все цифры взяты непосредственно из отчёта.

Конфигурация модели (🟢)

• Адаптивное забывание: ВКЛ
• Динамический α: ВКЛ
• base_alpha = 0.1
• min_alpha = 0.01
• half‑life = 7 дней
• Интервал забывания: 180 мин (забывание применяется каждые 3 часа)
• Порог переходов для забывания: 5000 (достигнут – 12 598 > 5000)
• Глубина хранения переходов: 21 день

⚠️Проблема: последнее забывание было 2026-06-15 11:08, а последний инцидент – 2026-06-17 08:16. Это означает, что после инцидента забывание ещё не применялось (интервал 180 минут не истёк). Это нормально, но стоит контролировать, чтобы забывание происходило регулярно.

Текущее состояние системы (🟢)

• State ID: 33 – параметры: correlation = -0.7, os_trend = +1, wait_trend = -1.
• Прогноз риска на следующую минуту = 0 (ситуация no_risk).

🟡 Интерпретация: состояние с отрицательной корреляцией, положительным трендом операционной скорости и отрицательным трендом ожиданий – не относится к аварийным (аварийные имеют os_trend = -1). Поэтому риск на ближайшую минуту нулевой.

Достоверность прогнозов (рейтинг 4 из 5) (🟢)

• Общее число переходов: 12 598 (рекомендуемый минимум 5000) – достаточно.☑️
• Стабильность вероятностей: max_prob_change = 1.0000 при пороге 0.05 – нестабильно.⚠️
• Покрытие частых состояний: 100% (все состояния с частотой >1% имеют ≥50 переходов) – отлично.☑️

🔴 Критическое замечание: max_prob_change = 1.0 означает, что вероятности за две недели изменились на 100% (т.е. от 0 до 1 или наоборот). Это указывает на сильную нестационарность – либо система резко меняет поведение, либо обучающих данных недостаточно для стабилизации, несмотря на объём. Рекомендуется увеличить base_alpha или half_life, чтобы ускорить забывание старых паттернов и адаптироваться к новым.

Анализ переходов в аварию (период 7 дней) (🟢)

• Всего переходов за период: 10 080 (ровно 1440 в день, кроме первого/последнего – значит, данные поступают поминутно).
• Переходов в аварию: 2 459 (24.39%) – очень высокая доля.⚠️
• Модель (с забыванием) оценивает долю в 26.61% – близко к исторической, что говорит о хорошей согласованности модели с реальностью.

Динамика по дням (доля аварийных переходов):

• 10.06: 14.3% – низкий старт
• 11.06: 26.9%
• 12.06: 13.1% – резкий спад
• 13.06: 25.1%
• 14.06: 35.8% – пик
• 15.06: 23.0%
• 16.06: 28.3%
• 17.06 (неполный): 26.1%

🟡 Вывод: доля аварийных переходов сильно колеблется (от 13% до 36%), что подтверждает нестабильность вероятностей. Такая волатильность делает прогнозы ненадёжными, несмотря на высокий рейтинг достоверности.

Общие рекомендации из отчёта (🟢)

• ☑️Модель имеет удовлетворительную достоверность (рейтинг 4), прогнозы можно использовать с осторожностью.
• Для максимальной достоверности требуется улучшить стабильность вероятностей.

2. Детальный отчёт по аварийным состояниям (mchain_incident_state_detail_report)

🟢 Данные о переходах и инцидентах производительности.

Статистика по инцидентам производительности (за 7 дней)

• Всего инцидентов: 103 (приоритеты: 3 – 29 шт., 4 – 74 шт.)
• Все завершены (нет незавершённых).
• Общая длительность: 3600 минут (ровно 60 часов), средняя 35 мин, максимум 107 мин.
• Инцидентов, начавшихся в течение 5 минут после аварийного перехода: 29 (средняя задержка 0.9 мин).

🟢 Это говорит о том, что аварийные переходы в цепи Маркова сильно коррелируют с реальными инцидентами (почти треть инцидентов начинается практически сразу после перехода в аварийное состояние). Это хороший признак – модель захватывает предвестники сбоев.

Детали по каждому аварийному состоянию (9 состояний)

Состояния с отрицательной корреляцией (r от -0.9 до -0.1) и os_trend = -1, wait_trend = 1. Для каждого указано:

• Сырых переходов за период – количество фактических попаданий.
• Вес в модели – частота с учётом забывания.
• Топ-3 предшествующих состояния – откуда чаще всего приходят.

Ключевые наблюдения (все 9 состояний):

• State #11 (r=-0.9): сырых переходов 77, вес модели 25.82, само-переходы 88.3%.
• State #20 (r=-0.8): сырых 393, вес 11.61, само-переходы 91.3%.
• State #29 (r=-0.7): сырых 388, вес 18.06, само-переходы 84.3%.
• State #38 (r=-0.6): сырых 352, вес 0.05, само-переходы 77.3%.
• State #47 (r=-0.5): сырых 279, вес 0.05, само-переходы 69.5%.
• State #56 (r=-0.4): сырых 284, вес 0.05, само-переходы 68.7%.
• State #65 (r=-0.3): сырых 280, вес 0.05, само-переходы 63.2%.
• State #74 (r=-0.2): сырых 260, вес 0.31, само-переходы 65.4%.
• State #83 (r=-0.1): сырых 145, вес 0.39, само-переходы 57.2%.

Проблемы:

1. Аномально низкие веса модели для состояний с r ≥ -0.6 (38,47,56,65) – всего 0.05. Это означает, что забывание почти полностью «стерло» эти переходы, хотя в сырой истории они встречаются сотни раз за неделю. Возможно, alpha слишком велик для этих состояний, либо они редко посещались в более ранние периоды.⚠️
2. Очень высокая доля само-переходов (57–91%) – из аварийных состояний система чаще всего остаётся в них же, а не выходит. Это может означать, что эти состояния являются «ловушками» – попав в них, система надолго застревает, что соответствует длительным инцидентам (средняя длительность 35 мин). Это логично и подтверждает адекватность модели.☑️

🟡 Рекомендация: проверить параметры забывания для состояний с низкими весами. Возможно, стоит увеличить min_alpha или base_alpha, чтобы сохранить значимость этих переходов.

3. Отчёт о качестве прогнозов (горизонт 15 минут) – mchain_quality_report_15min

🟢 Данные по 821 прогнозу за 7 дней (с 10 по 16 июня).

Основные метрики (🟢)

• Всего прогнозов: 821 – достаточно для анализа.☑️
• Доля инцидентов (факт): 42.63% – очень высокая.❗
• Средний предсказанный риск: 0.3907 – близок к фактической доле.
• Brier score: 0.136 – удовлетворительно (0.1–0.2).☑️
• Log-loss: 3.43 – очень высокий (чувствителен к уверенным ошибкам).⚠️
• MAE: 0.165 – умеренная.☑️
• ROC‑AUC: 0.157 – крайне низкий (<0.6 – плохо).⚠️
• Precision@0.5: 0.0 – ни один прогноз не превысил 0.5.
• Recall@0.5: 0.0 – то же.

Калибровочная таблица (представлена как список бинов)

Из отчёта приведены следующие бины (вероятность, среднее предсказание, наблюдаемая частота):

• Бин [0.0 – 0.1): сред. предск. = 0.008, набл. частота = 0.185.
• Бин [0.1 – 0.2): сред. предск. = 0.158, набл. частота = 0.079.
• Бин [0.2 – 0.3): сред. предск. = 0.224, набл. частота = 0.020.
• Бин [0.3 – 0.4): сред. предск. = 0.330, набл. частота = 1.000.
• Бин [0.4 – 0.5): сред. предск. = 0.445, набл. частота = 0.700.
• Бин [1.0 – 1.1): сред. предск. = 1.000, набл. частота = 0.903 (явная ошибка, т.к. вероятность не может быть >1).

Проблемы:

1. Последний бин [1.0 – 1.1) – невозможен, это ошибка в отчёте (вероятно, из-за округления или бага в WIDTH_BUCKET). Это искажает калибровку.
2. Бин [0.3 – 0.4): среднее предсказание 0.33, а наблюдаемая частота 1.0 – сильное занижение риска. Модель предсказывает 33% риска, а на деле инцидент происходит всегда.
3. Бин [0.4 – 0.5): предсказание 0.445, реальность 0.700 – тоже занижение.
4. Бин [0.0 – 0.1): предсказание 0.008, реальность 0.185 – завышение (т.е. в реальности инциденты происходят чаще, чем модель предсказывает).

🔴 Калибровка нарушена: модель не умеет правильно оценивать вероятности. Это объясняет низкий ROC‑AUC и нулевые precision/recall при пороге 0.5 – модель никогда не предсказывает риск выше 0.5, хотя фактическая доля инцидентов 42%.

Дневная динамика (из истории метрик)

Показана только одна запись за 2026-06-16:

• Brier = 0.1669
• Log-loss = 2.8147
• ROC‑AUC = NULL (не рассчитан)
• Наблюдений = 351

🟡 Мало данных для анализа динамики, но значение Brier стабильно в районе 0.14–0.17.

Рекомендации из отчёта (🟢)

• ☑️Удовлетворительная калибровка (Brier 0.1–0.2), но требуется периодический пересмотр параметров.
• ⚠️ROC‑AUC < 0.6 – дискриминационная способность низкая. Предложено изменить критерий аварийности.

Общие выводы и рекомендации

Выявленные проблемы и предложения по их устранению:

⚠️Низкая стабильность вероятностей (max_prob_change = 1.0)

• Причина: модель не успевает адаптироваться к изменчивости системы.
• Предложение: увеличить частоту забывания (уменьшить interval_minute) или повысить base_alpha для более быстрого забывания старых данных.

⚠️Слишком высокий процент аварийных переходов (24–27%)

• Причина: определение аварийного состояния (correlation<0, os_trend=-1, wait_trend=1) может быть слишком широким.
• Предложение: пересмотреть критерии – возможно, включать только состояния с correlation < -0.5 или добавить дополнительное условие (например, порог по частоте).

Плохая калибровка прогнозов (ROC‑AUC ~0.16)

• Причина: модель не различает риски; предсказанные вероятности не соответствуют реальности.
• Предложения:
• Перенастроить пороги аварийности – сделать их более жёсткими.
• Изменить параметры забывания – возможно, слишком сильное забывание для некоторых состояний (веса ~0.05) приводит к потере информации.
• Рассмотреть использование другого горизонта прогноза (например, 5 или 30 минут) и проверить качество.

⚠️Ни один прогноз не превышает 0.5

• Причина: модель систематически занижает риск.
• Предложение: скорректировать калибровку с помощью изотонической регрессии или Platt scaling на основе исторических данных.

Искажённая калибровочная таблица (бин >1)

• Причина: ошибка в SQL-функции WIDTH_BUCKET или в формировании отчёта.
• Предложение: исправить функцию mchain_quality_report_15min, чтобы бины были строго в [0,1].

Итоговая рекомендация:

⚠️Несмотря на высокий рейтинг достоверности (4/5), прогнозы в текущем виде непригодны для принятия решений из-за низкой дискриминационной способности.

📋Необходимо:

• Пересмотреть определение аварийных состояний – возможно, сузить круг до более «тяжёлых» состояний.
• Настроить параметры забывания – увеличить base_alpha или уменьшить half_life, чтобы модель быстрее реагировала на изменения.
• Внедрить пост-калибровку прогнозов (например, с помощью логистической регрессии на исторических парах (predicted_risk, actual_outcome)).
• Увеличить горизонт прогноза (например, до 30 или 60 минут) и переоценить качество – возможно, 15 минут слишком мал для накопления сигнала.

После этих изменений следует повторно запустить mchain_quality_report_15min и убедиться в росте ROC‑AUC и улучшении калибровки.

*Дата анализа: 2026-06-17*

Источник данных: предоставленные отчёты.

Светофоры: 🟢 – подтверждённые факты из отчётов, 🟡 – интерпретации, требующие проверки, 🔴 – критические проблемы.