инженерные заметки
Событийные ИИ-системы вместо простых сценариев
Почему линейный сценарий ломается на исключениях, а событийная архитектура делает ИИ-систему устойчивой и наблюдаемой.
Коротко для руководителя. Линейный сценарий «шаг 1 → шаг 2 → шаг 3» красив на демонстрации и хрупок в проде, потому что реальность не линейна: события приходят не по порядку, сервисы отвечают с задержкой, часть шагов повторяется. Событийная архитектура — это про надёжность операций: меньше инцидентов, предсказуемое поведение под нагрузкой, наблюдаемость. Это инженерное решение с прямым следствием для стоимости эксплуатации.
Большинство ИИ-автоматизаций рисуются как прямая линия: получили запрос, сделали A, потом B, потом C, отдали результат. На демо это работает. В проде реальность подаёт события не в том порядке и не по одному — и линия рвётся.
Реальность не линейна — и системы не должны быть.
Гипотеза: реальные процессы событийны, а не линейны
В реальном процессе одновременно: приходят новые данные посреди обработки, внешний сервис отвечает позже шага, который его ждал, один и тот же сигнал приходит дважды. Это не исключения «на потом» — это норма потока. Система, спроектированная как линия, борется с собственной природой задачи.
Проблема: линейный сценарий живёт на «хорошем порядке»
Линейный конвейер неявно предполагает, что всё происходит по порядку и ровно один раз. На реальном потоке это предположение нарушается постоянно: гонки, повторы, опоздавшие ответы. Линия отвечает на это зависаниями, дублированными действиями и тихими потерями — и чинится бесконечными «если» поверх исходного сценария.
Почти 80% отказов — это спецификация и координация, то есть архитектура, а не «слабая модель». Лечится контрактами и явной координацией, а не сменой LLM.
Большая часть отказов многошаговых ИИ-систем — это именно сбои координации и состояния: ровно то, что линейный сценарий не моделирует.
Почему обычные подходы не работают
«Добавим обработку этого случая» поверх линии не масштабируется: каждое новое «если» усложняет сценарий и плодит новые гонки.
«Сделаем повтор при ошибке» без идемпотентности приводит к дублированным действиям: повтор шага выполняет его дважды.
«Подождём ответа синхронно» превращает задержку внешнего сервиса в зависание всего процесса.
Инженерная модель: события, состояние, идемпотентность
Событие как единица. Шаг не «вызывает следующий», а порождает событие; на событие подписан тот, кто должен реагировать. Порядок и параллельность перестают ломать процесс.
Состояние процесса. У задачи есть явное состояние: что произошло, что сделано. Опоздавшее или повторное событие обрабатывается корректно, потому что есть с чем сверяться.
Идемпотентность. Повтор шага не меняет результат и не удваивает действие. Это то, что делает повторы безопасными, а значит — допустимыми.
Эскалация по событию. Низкая уверенность, таймаут, противоречие — это события, на которые подписана передача человеку, а не «ветка if в конце функции».
Наблюдаемость потока. Видны события, их порядок, задержки и обработка. Инцидент превращается из «где-то зависло» в «событие X не обработано подписчиком Y».
Практический вывод для бизнеса
Событийность — это про число инцидентов и стоимость эксплуатации. Линейная система требует постоянной ручной починки исключений; событийная переносит исключения внутрь модели и стабилизируется.
По данным IDC, из 33 запущенных пилотов до промышленной эксплуатации доходят около 4. Причина провала — не технология, а недооценённая сложность доведения до процесса.
Часть причины, по которой пилоты не доходят до прода, — именно здесь: линейная демонстрация не выдерживает реального, непорядоченного потока, а переписать её в событийную «потом» дороже, чем заложить сразу.
Спросите, как система ведёт себя при опоздавшем и повторном событии. Если ответ «такого не будет» — это будет, и цена узнать об этом в проде выше, чем спроектировать заранее.
Приложить это к вашим процессам — .
Открытые вопросы
Где граница оправданной событийности — для простых редких процессов линия достаточна; вопрос в честной оценке, а не в моде на архитектуру. Событийные системы сложнее отлаживать без хорошей наблюдаемости — это встроенная цена подхода. Насколько дробить процесс на события — компромисс между гибкостью и сложностью.
Если ваша автоматизация постоянно требует ручной починки «странных случаев» — это симптом линейной архитектуры. — посмотрим поток событий и где он рвётся.