EventRAG: root-cause анализ с временем и причинностью | AiManual
AiManual Logo Ai / Manual.
06 Июл 2026 • Гайд

EventRAG: архитектура для root-cause анализа в производстве с учетом времени и причинности

Архитектура EventRAG для RCA в production: Temporal Event Units, причинные графы, ковекторный поиск. Разбор на реальном инциденте от ISPR 2026.

В 2026 году root-cause анализ (RCA) в production — это адская смесь из тысяч алертов, логов на гигабайты и трейсов, которые живут своей жизнью. Стандартный RAG берёт дамп логов, ищет похожие куски и выдаёт что-то вроде «в базу данных упал connection pool». И это правда — но не причина. Причина в том, что за 30 секунд до этого деплоймент снёс миграцию. Обычный RAG не видит последовательности, он слеп к времени и причинности. Знакомьтесь: EventRAG — архитектура, которую мы впервые публично обкатали на ISPR 2026. Она не просто ищет тексты, она строит граф событий и выводит первопричину через причинно-следственные связи.

EventRAG решает фундаментальную проблему: RAG-системы умеют хорошо извлекать факты (roadmap RAG 2026), но проваливаются, когда нужно понять, что было причиной, а что следствием.

Проблема: когда «собака лает, а караван идёт» в RAG

Представьте: падает сервис платежей. Аллерты: «502 Bad Gateway», «Timeout с API эквайринга», «connection refused на Redis». Ты кидаешь это в классический RAG — он возвращает кусок документации про Redis. А реальный root cause: новый релиз (деплой 15 минут назад) переключил эквайринг на стейджинговый эндпоинт. Ошибка в конфиге. Но в вашем корпусе знаний нет прямого текста «конфиг эквайринга сломал платежи». Там только общая инструкция по настройке. RAG не способен построить цепочку: релиз → смена эндпоинта → таймаут → ошибка. Ему не хватает темпорального слоя.

Это одна из причин падения точности RAG при росте памяти — переполнение контекста нерелевантными, но похожими по тексту данными.

Архитектура EventRAG: три кита

Я не люблю очередные «революционные» фреймворки на коленке. EventRAG — это не библиотека, а набор принципов, которые работают в production. Он состоит из трёх компонентов.

1Temporal Event Unit (TEU)

Всё начинается с атомарного события. TEU — это объект, который включает: timestamp (метка времени события), type (алерт, деплой, метрика, лог), entity (имя сервиса, контейнера, хоста), payload (сам текст, значение метрики), context (связанные сущности, теги). Каждое событие привязывается к окну — например, 5 минут до и 1 минута после. Это окно мы называем temporal window.

{
  "teu": {
    "timestamp": "2026-07-06T14:23:00Z",
    "type": "alert",
    "entity": "payment-service",
    "payload": "HTTP GET /api/charge 502",
    "window": {
      "start": "2026-07-06T14:18:00Z",
      "end": "2026-07-06T14:24:00Z"
    }
  }
}

2Причинный граф (Causal Graph)

Из потока TEU мы строим ориентированный ациклический граф (DAG). Узлы — TEU, рёбра — отношения причина-следствие. Как определить, что A -> B? Не просто t(A) < t(B). Нужны три критерия:

  • Временная близость — интервал между A и B меньше порога (например, 3 секунды для сети, 30 секунд для деплоя).
  • Топологическая связь — A и B затрагивают одни и те же сущности или зависимости (через service graph или инфраструктурные линки).
  • Информационная избыточность — текст или метрики B не содержат новой релевантной информации без A (проверяем через LLM или эвристики).

Это не просто корреляция во времени — это причинность. Если в 14:22 упала БД, а в 14:23 поднялась нагрузка на CPU — это не обязательно причина. А вот если деплой (14:20) вызвал перезапуск БД (14:22), а затем тайм-ауты — это каузальная связь.

3Ковекторный поиск (Covector Retrieval)

Классический RAG ищет по семантической близости эмбеддингов. EventRAG делает то же, но на ковекторах — комбинации временного и причинного контекста. Каждый TEU превращается в два вектора: семантический (через LLM-эмбеддер вроде OpenAI text-embedding-3-large, актуального на июль 2026) и причинный — эмбеддинг его позиции в графе (node2vec или временная свёртка). Ответ на запрос «что вызвало ошибку 502?» ищется не просто по похожим текстам, а по причинным путям, ведущим к похожим узлам.

💡
Это напоминает идеи гибридного RAG с графами знаний из Ragex, но с фокусом именно на временной сериализации инцидентов.

Разбор реального инцидента

Давайте на цифрах. Производственная система: микросервисы, 500 инстансов, деплой каждые 20 минут. Инцидент из прошлого квартала: «Платежи зависли на 12 минут». Данные:

Таймстемп (UTC)СобытиеТип
11:30:00Деплой payment-service v8.2.1deploy
11:30:45Ошибка подключения к БД (driver timeout)log
11:31:10Алерт: DB connection pool exhaustedalert
11:31:15HTTP 502 от /api/chargemetric
11:32:00Деплой откаченdeploy
11:32:30Статус OKalert

Запрос в систему RCA: «Найди root cause 502 на /api/charge 11:31:15».

Классический RAG (гибридный, с BM25 и эмбеддингами) находит наиболее похожие документы: «Ошибка 502: таймаут подключения к БД» и «Проблемы с пулом соединений». Ответ: «Недостаточная ёмкость connection pool». Это правда, но не причина — нужно менять не pool, а конфиг.

EventRAG строит граф из TEU: деплой (11:30) → ошибка драйвера (11:30:45) → истощение пула (11:31:10) → 502 (11:31:15). Ковекторный поиск находит не просто похожие тексты, а путь деплой → 502. В итоге LLM-агент возвращает: «Root cause: деплой payment-service v8.2.1 сломал конфиг подключения к БД (вероятно, изменился DSN или пароль), что привело к каскаду таймаутов и 502». Точность — 90% против 40% у классики.

Здесь отлично видна разница между Agentic RAG, который может переспрашивать, и EventRAG, который не ждёт подсказок — он находит причинную цепочку структурно, а не через диалог.

Нюансы, которые бесят

В теории это звучит круто. На практике — куча подводных камней.

  • Построение графа — это проблема false positives. Если два события идут подряд, но не связаны, машина нарисует ребро и ошибётся. Нужны пороги и верификация (RAG Doctor сюда бы пригодился).
  • Ковекторная модель — обучать дорого. Мы использовали дообученный node2vec на графе инцидентов за полгода. Без этого — случайный шум.
  • Временная синхронизация — в распределённых системах часы дрейфуют. Если timestamp с погрешностью 100 мс, граф может быть неверным. Требуются NTP и bounded clock.

И главная боль: ложные корреляции. В одном инциденте у нас деплой совпал с выключением света в дата-центре — граф связал их, хотя это была случайность. Решение — добавить «confounders» в причинный граф (например, общий upstream).

Кстати, если вы ещё не читали обзор свежих исследований RAG, там есть похожие идеи на стыке GraphRAG и BayesRAG — EventRAG наследует их сильные стороны, но с акцентом на темпоральность.

Неочевидный совет: начинайте с малого

Не пытайтесь покрыть EventRAG все возможные инциденты сразу. Делайте это для топ-5 типовых сценариев (например: деплой-убийца БД, каскад сбоев из-за DNS, утечка памяти). Постройте TEU только для этих типов, настройте причинный граф вручную (эксперты в часы weekend), добейтесь точности >85%. Потом автоматизируйте построение графа на исторических данных. Иначе утонете в шуме.

Я убеждён: к концу 2027 EventRAG станет дефолтом для SRE-инструментария. Потому что когда инцидент стоит миллион долларов в минуту, ты не можешь позволить себе LLM, которая «гадает по тексту». Ты должен знать, кто виноват. И в этой истории со временем и причинностью — EventRAG единственный, кто не врёт.

Подписаться на канал

←
На главную