Назад к блогу

Опубликовано 5 июля 2026 г.

Где в системе мониторинга действительно нужен LLM

LLMMonitoringArchitecturePython

Задача

На сети всё время идут плановые работы, и одновременно случаются аварии. Опасность - в пересечении: бригада гасит кольцо на профилактику ровно там, где уже лежит резерв после аварии. Система, о которой речь, ищет такие пересечения по городу и временному окну и предупреждает до того, как работы начнутся.

События приходят из четырёх источников: система мониторинга, BPMS, корпоративная почта и ручной ввод. Три из них структурированы. Четвёртый - нет.

Правило: LLM там, где нет схемы

Соблазн «прогнать всё через модель» стоит дорого и в деньгах, и в отладке. В системе модель работает ровно на одном участке - разбор писем внешних операторов.

Причина в том, что у писем нет схемы. Один оператор пишет «планово-профилактические работы 12.07 с 01:00 до 05:00 мск, г. N», другой прикладывает вложение с таблицей, третий формулирует так, что дату работ приходится собирать из двух абзацев. Регулярки на этом ломаются каждую неделю, а модель - нет.

Всё остальное - обычный детерминированный код:

  • опрос API мониторинга и чтение очереди BPMS;
  • дедупликация событий;
  • сравнение временных интервалов и поиск пересечений;
  • автозакрытие конфликтов, которые перестали быть актуальными;
  • метрики, UI, импорт CSV/Excel.

Сравнение двух интервалов - это не задача для нейросети. Это start_a < end_b and start_b < end_a, и оно должно давать один и тот же ответ в понедельник и в пятницу.

Что это даёт на практике

Предсказуемость. Когда конфликт найден неверно, вопрос «где ошибка» имеет ответ. Если бы решение принимала модель, ответом было бы пожатие плечами.

Стоимость. Модель вызывается на объёме входящей почты, а не на объёме событий мониторинга — разница в порядки.

Тестируемость. Детекция конфликтов покрывается unit- и интеграционными тестами с поднятой в контейнере БД. Тестировать так же LLM-разбор нельзя — там проверяются только формат ответа и устойчивость к мусору на входе.

Архитектура в трёх сервисах

mail-agent  → IMAP → фильтр шума → LLM → структурированное событие ─┐
                                                                    ↓
monitoring / BPMS / ручной ввод ────────────────────────→ detector (дедуп, поиск
                                                                    пересечений,
                                                                    автозакрытие)
                                                                    ↓
                                                         PostgreSQL → UI

Каждый сервис отдаёт метрики Prometheus, логи собираются в Loki, схема БД версионируется миграциями. Скучная инфраструктура - обязательное условие для того, чтобы интересная часть кому-то пригодилась.

Что бы я сделал иначе

Фильтр шума перед моделью стоило делать сразу, а не после первого счёта за токены: подавляющая часть корпоративной почты к плановым работам отношения не имеет, и отсекается она простыми правилами.