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

Задача

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

События поступают из четырёх источников: системы мониторинга, 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, схема БД версионируется миграциями. Без такой надёжной инфраструктуры даже самая интересная часть системы никому не пригодится.

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

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