EventRAG: как научить RAG искать первопричину во времени, а не в тексте

On-prem RCA-ассистент для цеха + AR-HUD. Полный разбор: архитектура, формулы, расчёты, живой инцидент на роботе-паллетайзере Hyundai Hi5-N00 и что мы везём на международную конференцию

TL;DR. Обычный RAG отлично отвечает по инструкциям, но проваливается на root-cause-анализе (RCA) в цеху: косинусная близость по эмбеддингам выбрасывает время и причинность — ровно то, без чего нельзя связать «наряд, отложенный 67 дней назад» с «алармом, который встал сегодня». EventRAG — архитектура, которая нормализует каждое событие в Temporal Event Unit, хранит его в двойном индексе (вектор + причинный граф), ищет по времени, обходит граф назад от симптома к корню, а ре-ранкинг score = α·sim + β·causal + γ·exp(−λ·|Δt|) сшивает смысл, причинность и время в одну оценку. Ниже — почему стандартный пайплайн ломается (с формальной постановкой), как устроен EventRAG на уровне формул, полный числовой разбор реального по типажу инцидента на паллетайзере Hyundai (9 событий, все скоры посчитаны руками), профиль AR-железа, экономика с выводом каждой цифры, юнит-экономика, RICE-приоритизация — и что из этого уехало в position paper на международную конференцию.

Научное ядро написано в соавторстве с Яковом Дятловым (НИУ ВШЭ): с этим докладом мы участвуем в ISPR 2026 — 26-м Международном симпозиуме по производственным исследованиям (International Symposium for Production Research, Сараево, Босния и Герцеговина, 15–17 октября 2026, гибридный формат). Продуктовая часть (AR-связка, экономика, приоритизация) — отдельная концепция, не входящая в академическую подачу. Все экономические числа и оценки sim/causal в разборе — модельные, это помечено.

Содержание

1. Простой стоит не тогда, когда сломалось, а пока ищут почему

2. Почему обычный RAG структурно не подходит для RCA

3. Формальная постановка задачи

4. Что мы везём на конференцию: position paper

5. Архитектура EventRAG: пять стадий и одна формула

6. Живой разбор: паллетайзер Hyundai Hi5-N00 встал

7. Железо: AR-очки как тонкий клиент и edge-сервер

8. Экономика: выводим каждую цифру

9. Юнит-экономика поставщика

10. Приоритизация: RICE по функциям и сегментам

11. Дорожная карта, риски и план валидации

12. Заключение

1. Простой стоит не тогда, когда сломалось, а пока ищут почему

Есть контринтуитивная вещь про производство: деньги теряются не в момент поломки, а в те минуты и часы, пока никто не может понять, почему оно сломалось. Замена подшипника — это полчаса. Понять, что подшипник убила отложенная на два месяца замена фильтра, из-за которой поднялась температура, из-за которой поплыл зазор, — это те самые часы, которые и стоят дорого.

Цифры делают проблему осязаемой. По отчёту Siemens/Senseye «True Cost of Downtime 2024», совокупный незапланированный простой 500 крупнейших компаний мира оценивается примерно в $1,4 трлн в год — около 11% их выручки (рост с $864 млрд в предыдущей волне исследования). Операционно ближе к цеху другая метрика: средний крупный завод теряет ~27 часов в месяц примерно на 25 инцидентов. Ещё два числа из отраслевых опросов: ~23% инцидентов имеют первопричину в человеческом факторе (важно: это доля инцидентов, а не сумма потерь), и до 70% знаний о том, «как на самом деле чинится эта конкретная линия», нигде не записано — оно живёт в голове мастера, который через два года уйдёт на пенсию (Deloitte / Manufacturing Institute).

Единственный по-настоящему управляемый параметр в себестоимости простоя — MTTR (mean time to repair). А внутри MTTR самая тяжёлая и самая «человеческая» часть — диагностическая: время до правильной гипотезы о первопричине. Данных при этом всё больше — CMMS, Historian, MES, PLC, SCADA льют тысячи событий в час — а время до правильной гипотезы не падает. Вот этот разрыв и есть цель.

Тезис статьи. Узкое место на цеху — не предсказание отказа (predictive maintenance), а root-cause-анализ после инцидента. И его нельзя закрыть «обычным» корпоративным RAG-ассистентом — по структурным, а не косметическим причинам.

2. Почему обычный RAG структурно не подходит для RCA

RAG (retrieval-augmented generation) прекрасно себя показал там, где нужно заземлить LLM на статический корпус: мануалы, троблшутинг-гайды, регламенты. Стандартный пайплайн — chunk → embed → retrieve (top-k по косинусу) → generate — для документов работает. Но как только на вход приходит поток событий с таймстемпами из разных систем, у него вылезают три структурных провала.

2.1. Временная слепота

Косинусная близость по плотным эмбеддингам трактует все чанки как взаимозаменяемые и не умеет выразить, что «событие A произошло за 12 минут до события B». Для эмбеддинга две записи J2 position deviation, случившиеся вчера и месяц назад, — это почти один и тот же вектор. А для RCA разница между «12 минут назад» и «67 дней назад» — это и есть весь ответ.

2.2. Причинная фрагментация

Плоский векторный поиск возвращает top-k самых похожих пассажей, а не самых причинно связанных. Фрагмент-левел RAG вытащит первопричину только если она текстуально совпадает с прошлыми инцидентами. Как только настоящая цепочка причинности идёт через события, которые не похожи на симптом по тексту, модель начинает «прыгать» по слабо связанным узлам и теряет путь — в литературе это называют path confusion.

2.3. Мультимодальность и «племенное знание»

Причина инцидента почти никогда не лежит в одном источнике. Она собирается из отложенной заявки в CMMS, тренда в Historian, переналадки в MES, аварии в PLC — плюс из неписаного опыта мастера. Это смесь структурированной телеметрии, полуструктурированных логов и свободного текста, и единое пространство эмбеддингов обрабатывает такой разброс плохо.

Итог: на RCA обычный RAG либо галлюцинирует, либо выдаёт банальности («перемастерьте ось и продолжайте»). Не потому что модель слабая, а потому что пайплайн выбрасывает два измерения, которые в цеху несут основную информацию — время и причинность.

3. Формальная постановка задачи

Зафиксируем задачу строго — так, как она сформулирована в статье.

Пусть S = {s₁, …, s_M} — множество из M гетерогенных источников событий на цеху (PLC, MES, Historian, CMMS). Каждый источник эмитит поток событий; i-е событие глобально индексируется как

eᵢ = (tᵢ, src(eᵢ), aᵢ, dᵢ)

где tᵢ — таймстемп ISO-8601, src(eᵢ) ∈ S — источник, aᵢ — вектор структурированных атрибутов, dᵢ — опциональное текстовое описание.

По инцидентному запросу q (код аларма, описание на естественном языке или временное окно с аномалией) мы ищем функцию:

f(q, E_history) → r = (root_causes, evidence_chain, remediation)

То есть на выходе — не «похожий текст», а ранжированный набор гипотез о первопричине, временная цепочка доказательств и рекомендации по устранению. Ключевые ограничения:

• Временная согласованность — цепочка доказательств обязана уважать хронологию.

• Причинная правдоподобность — события связаны известными или выведенными причинными отношениями, а не просто семантической близостью.

• Латентность — черновик RCA нужен за минуты, не за часы.

• Объяснимость — каждый элемент цепочки трассируется до конкретного события-источника.

Важная рамка — Industry 5.0. Европейская рамка Industry 5.0 переопределяет ИИ на цеху как усиление надёжностного инженера, а не его замену; в фрагментированной мировой экономике добавляется требование резильентности — система должна работать при ограниченном доступе к трансграничным облакам. Поэтому целевой режим EventRAG — advisory: система выкладывает ранжированные объяснимые цепочки, а финальное решение остаётся за человеком. «Augment the engineer»: не автопилот, а второй пилот.

4. Что мы везём на ISPR 2026: position paper

Научное ядро этой статьи — position paper «EventRAG: A Human-Centric Retrieval-Augmented Assistant for Resilient Shop-Floor Root-Cause Analysis in a Fragmented Global Economy» (соавторы — Яков Дятлов и я, НИУ ВШЭ). С ним мы участвуем в ISPR 2026 — 26-м Международном симпозиуме по производственным исследованиям (Сараево, Босния и Герцеговина, 15–17 октября 2026): первый день очно в International University of Sarajevo, презентационные сессии — в гибридном формате. Организаторы — TU Wien, Society for Production Research и IUS; принятые статьи выходят в сборнике Springer-Verlag с индексацией SCOPUS.

Девиз симпозиума этого года — «Next Generation Production Systems in a Fragmented Global Economy», и это не совпадение с хвостом названия нашей статьи: резильентный on-prem RCA-ассистент, работающий без трансграничных облаков, — прямой ответ на постановку «производственные системы следующего поколения во фрагментированной мировой экономике». Ниже — что именно в статье заявлено и на чём это стоит.

4.1. Три вклада статьи

1. Синтез литературы на пересечении трёх направлений: RAG, темпоральный retrieval событий и LLM-based RCA — направления развивались почти независимо, и их стык для manufacturing никем систематически не собран.

2. Архитектура EventRAG: темпоральные единицы событий (TEU) + двойной индекс «вектор с партициями / причинный граф» + генерация под SOP-ограничениями (подробно — §5).

3. Конкретный экспериментальный план валидации на публичных process-mining-бенчмарках и симулированном цеховом корпусе (подробно — §11).

Это именно position paper: архитектура на момент подачи не реализована, и мы прямо пишем это в тексте — вместе с планом, как её проверить.

4.2. На чьих плечах стоим: карта смежных работ

• Классический RCA и process mining: rule-based системы (не обобщаются на новые и составные отказы), FMEA (каталоги отказов; свежие работы расширяют FMEA онтологиями, графовым обучением и LLM), process mining с conformance checking по событийным логам, включая object-centric логи; PM-LLM-Benchmark оценивает LLM на задачах process mining.

• LLM-based RCA в IT-операциях: Flow-of-Action (WWW’25) кодирует SOP как code-level-ограничения мультиагентной системы и почти удваивает точность RCA; GALA сочетает статистическую причинную инференцию по телеметрии с итеративным LLM-рассуждением; Roy et al. (Microsoft, FSE’24) — ReAct-агенты на продакшн-инцидентах; ARCA — мультимодальный RAG для нестабильности облачной платформы.

• RAG для индустриальных и событийных данных: MindRAG строит мультимодальный векторный стор для condition monitoring, используя наряды на ТО как суррогат разметки; Narimani & Klarmann — RAG для real-time-траблшутинга на площадке; Padella et al. — LLM-фичи в predictive process monitoring на малых логах; link prediction для событийных логов процессной индустрии — как препроцессинг для graph RAG.

• Темпоральный retrieval: DyG-RAG вводит Dynamic Event Units с точными временными якорями, событийный граф для multi-hop-рассуждения и Time Chain-of-Thought; TPP-Embedding объединяет тексты и таймстемпы в одном пространстве через temporal-point-process-objective; RAG with Covariate Time Series тянет RAG в time-series-фундаментальные модели для предиктивного обслуживания.

4.3. Доказательная база — и честная оговорка

Собственных экспериментов на manufacturing-OT у EventRAG пока нет. Дизайн опирается на количественные результаты систем-аналогов, и все бенчмарки ниже получены на cloud/microservices или общем temporal QA, не на цеховых данных:

Как это читать. Два самых сильных сигнала — Flow-of-Action (SOP-ограничения почти удваивают точность RCA: 35,5% → 64,0%) и GALA (граф-усиление даёт до +42,22% Top-1). Оба — про то, что структура (SOP, граф) важнее сырой мощности модели. DyG-RAG показывает, что явные временные якоря дают прирост на темпоральных вопросах. EventRAG — перенос этих трёх идей в цех. Оговорка честная и вынесена в статью отдельным пунктом: cloud-метрики не переносятся на завод автоматически — у OT другой словарь, другая физика отказов и другой шум. Ровно поэтому в статье есть §5 «Experimental Design», а не таблица обещаний.

5. Архитектура EventRAG: пять стадий и одна формула

EventRAG — это конвейер из пяти стадий. Гетерогенные источники нормализуются в Temporal Event Units; двойной индекс (вектор с темпоральными партициями + причинный граф) обеспечивает time-aware гибридный поиск; LLM под SOP-ограничениями генерирует отчёт; петля обратной связи от инженера замыкает цикл. Дизайн синтезирует паттерны из DyG-RAG, Flow-of-Action, GALA, MindRAG и KG-enhanced RAG.

5.1. Ingestion: Temporal Event Units (TEU)

Вдохновляясь Dynamic Event Units из DyG-RAG, каждое сырое событие нормализуется в Temporal Event Unit:

TEU = (tᵢ, eᵢ, srcᵢ, typeᵢ, dᵢ)

— таймстемп ISO-8601, плотный эмбеддинг текстового представления события, идентификатор системы-источника, код нормализованной таксономии события и исходный payload.

Ключевой принцип: каждый TEU несёт явный временной якорь — в отличие от обычных RAG-чанков, где время неявно («где-то в тексте»). Мультисорсное выравнивание идёт по общему таймлайну с настраиваемым допуском на расхождение часов между OT-системами (clock-skew): PLC, MES и CMMS почти никогда не синхронизированы идеально, и без явного допуска цепочки «рассыпаются» на границах.

Поле typeᵢ — не косметика: именно нормализованный тип события становится узлом причинного графа. Без единой таксономии MOTOR_OVERTEMP из одного цеха и Перегрев эл.двиг. из другого — разные сущности, и граф не накапливается.

5.2. Indexing: двойной индекс

EventRAG держит два комплементарных индекса, и каждый TEU пишется в оба.

(1) Векторный стор с темпоральными партициями. Эмбеддинги TEU разложены по временным бакетам (по сменам, суткам, неделям — глубже лежит архив). Это позволяет сначала отфильтровать окно, а потом искать семантически — и не вытаскивать семантически похожие, но темпорально нерелевантные события. Партиционирование ещё и дешёвое инженерно: старые партиции уходят на медленное хранилище, свежие живут в памяти.

(2) Причинный граф знаний (CKG). Узлы — типы событий (не экземпляры), рёбра — типизированные связи: причинная, темпорально-предшествующая, co-occurrence. Граф бутстрапится LLM-извлечением из троблшутинг-гайдов и FMEA-документов, а онлайн обогащается link-prediction по входящим логам. Именно CKG даёт то, чего нет у плоского поиска: возможность прийти к предку-первопричине, который не похож на симптом по тексту и далёк по времени.

Разделение ролей простое: вектор отвечает на вопрос «что похоже по смыслу?», граф — «что связано причинно?». Порознь каждый ошибается; вместе они находят корень.

5.3. Retrieval: time-aware гибридный поиск в четыре шага

По запросу q с окном [t_q − Δ, t_q] поиск идёт так:

1. Фильтр окна — ограничиваем поиск партициями, пересекающими окно. Всё остальное даже не сканируется.

2. Семантический retrieval — top-k TEU по близости эмбеддингов внутри отфильтрованных партиций.

3. Обход графа назад — от типов событий, найденных на шаге 2, идём по причинным рёбрам CKG назад, вытаскивая предков даже вне top-k по близости. Это шаг, который отличает EventRAG от «RAG с фильтром по дате»: граф втягивает события, которые семантика вообще не нашла бы.

4. Ре-ранкинг с временным затуханием — сшиваем три сигнала в одну оценку.

5.4. Формула ре-ранкинга: разбор по членам

score(eᵢ | q) = α·sim(eᵢ, q) + β·causal_rel(eᵢ, q) + γ·exp(−λ·|t_q − tᵢ|),   α + β + γ = 1

• α·sim — «насколько похоже по смыслу»: косинус эмбеддинга события к запросу. Силён на «уже видели такое», слеп к непохожим предкам.

• β·causal_rel — «насколько причинно связано»: сила причинного пути в CKG от события-кандидата к симптому. Это главный член: именно он вытянет наряд на замену батарей при sim = 0.16 и Δt = 67 дней (числовой разбор — в §6.6).

• γ·exp(−λ·|Δt|) — «насколько близко по времени»: экспоненциальное затухание. При λ = 0.040 сут⁻¹ (дефолт нашего интерактивного прототипа) вес свежести падает вдвое каждые ln 2 / λ ≈ 17,3 дня. Недавнее получает бонус, но время не диктует: у члена свой ограниченный вес γ.

Формула — расширение time-aware обхода из DyG-RAG явным членом причинной релевантности. Все три коэффициента и λ — ручки настройки под площадку: в прототипе их можно двигать ползунками и в реальном времени смотреть, как первопричина всплывает или тонет в выдаче (и что происходит, если выключить CKG: β обнуляется — и корень уходит на дно).

5.5. Generation: рассуждение под SOP-ограничениями

Переранжированная последовательность событий идёт в LLM, усиленную двумя механизмами.

SOP-guardrails (паттерн Flow-of-Action): стандартные операционные процедуры кодируются как деревья решений, ограничивающие LLM в точках ветвления диагностики. Пример из статьи: если в выдаче есть и сенсорная аномалия, и недавняя отложенная заявка на ТО, SOP обязывает сначала проверить риск-оценку отложенной заявки, прежде чем списывать причину на дрейф датчика. На cloud-бенчмарке ровно этот механизм дал Flow-of-Action 64,01% против 35,50% у ReAct — SOP не даёт модели убегать по нерелевантным диагностическим веткам.

Time Chain-of-Thought (паттерн DyG-RAG): модель обязана рассуждать пошагово вдоль временной последовательности, проговаривая интервалы («разряд батареи зафиксирован за 9 дней до аларма; просадка питания — за 3 ч 20 мин») и оценивая темпоральную правдоподобность каждой гипотезы.

На выходе — структурированный RCA-отчёт: ранжированные гипотезы, временная цепочка доказательств со ссылками на конкретные TEU, рекомендации по устранению и явные флаги неопределённости (система обязана говорить «не уверена», а не выдумывать).

5.6. Feedback loop: петля обратной связи

Правки инженера («настоящая причина была X, не Y», «события A и B в этом контексте не связаны») возвращаются в оба индекса:

• в CKG — добавляются рёбра, корректируются веса, гасятся ложные связи;

• в эмбеддинги — исправленные отчёты переэмбеддиваются и используются как hard-examples для дообучения (подход supervision-surrogate из MindRAG: наряды и подтверждения инженера — это и есть разметка, которой в OT всегда не хватает).

Каждый разобранный инцидент обогащает базу — система ускоряется на похожих кейсах. Это и есть механика, которая со временем «оцифровывает» те самые 70% незаписанного племенного знания.

6. Живой разбор: паллетайзер Hyundai Hi5-N00 встал

Абстракция ничего не стоит без разбора. Возьмём реальный по типажу инцидент на конкретном цеховом железе.

6.1. Что за машина

Робот-паллетайзер с контроллером Hyundai HHI серии Hi5, модель Hi5-N00 (шкаф A01-R1, конфигурация P/TRAY) на конце упаковочной линии №3: складывает короба на паллету — типичный FMCG-сценарий.

Деталь про батареи — не случайная: абсолютные энкодеры осей держат позицию при выключенном питании именно на резервных батареях. Села батарея → пропало питание → энкодер «забыл», где ось. Запомним.

6.2. Симптом

Смена идёт штатно. В t₀ паллетайзер аварийно останавливается, линия встаёт. На пульте — ALARM 1042 · position deviation / mastering lost по оси J2, ROBOT I/L trip. Наивный вывод дежурного — «перемастерить ось и продолжить». Он снимает симптом, но не причину: на следующем отключении питания инцидент повторится. Истинная причина лежит в CMMS, на 67 дней раньше и «на другом языке» — семантический поиск её не видит.

6.3. Девять событий из четырёх систем

EventRAG сшивает события на один таймлайн. Вот полная картина — включая отвлекающие события, которые в реальном цеху всегда есть (похожие по тексту или близкие по времени, но не причинные):

6.4. Причинная цепочка

Логика читается снизу вверх — так её и собирает обход графа назад:

Мёртвая батарея энкодера (наряд на замену отложен 67 дней назад, предупреждение BLB за 9 дней проигнорировано) → при просадке 380 В и переходе на UPS контроллер переживает перебой питания → без резервного питания энкодер теряет абсолютную позицию оси (mastering) → на старте после планового ТО всплывает ALARM 1042. Симптом — на оси J2. Корень — в наряде CMMS.

6.5. Почему обычный RAG здесь провалится

Наряд WO-1185 по тексту почти не похож на аларм (replace encoder backup batteries против J2 position deviation / mastering lost), и случился он на 67 дней раньше. У чистой семантики он на последнем месте выдачи из девяти событий (см. расчёт ниже). Обычный RAG найдёт мануал по ошибке 1042 и пару прошлых похожих алармов — и уверенно посоветует «перемастерить». EventRAG идёт по причинному ребру разряд батареи → WO-1185 и вытягивает наряд наверх, несмотря на слабый sim и большой Δt.

6.6. Расчёт ре-ранкинга: все девять скоров руками

Это ключевой раздел — покажем формулу в работе на числах. Оценки sim (семантическая близость к запросу-аларму), causal (сила причинного пути в CKG) и Δt — условные, из интерактивного прототипа; они подобраны, чтобы показать логику, а не измерены на реальном стенде. Параметры — дефолт прототипа: α = 0,28, β = 0,50, γ = 0,22, λ = 0,040 сут⁻¹.

Считаем score = α·sim + β·causal + γ·exp(−λ·Δt) для каждого события (Δt в сутках):

Что здесь произошло:

• По одной семантике первопричина WO-1185 — последняя из девяти (sim = 0,16), а «отвлекающие» ток сервопривода и переналадка стоят на 4-м и 7-м местах: они текстуально или темпорально ближе к аларму.

• После ре-ранкинга топ-6 выдачи — это в точности причинная цепочка (разряд батареи, просадка питания, аларм, servo-fail, рестарт, отложенный наряд), а все три отвлекающих события ушли на места 7–9.

• У WO-1185 член времени почти обнулён (exp(−0,04·67) ≈ 0,069 → вклад 0,015) и семантика мизерная (0,045), но причинность даёт 0,480 — 89% его скора. Причинное ребро поднимает наряд выше всех отвлекающих сигналов — даже при слабом sim и большом Δt. Это и есть тезис статьи одним числом.

Поиграть ползунками можно в интерактивном разборе (ссылка в конце): выкрутите β в ноль или выключите CKG — и WO-1185 утонет на дно; поднимите λ — и всё старше пары недель станет невидимым, включая корень. Формула честно показывает, за счёт чего живёт.

6.7. Один инцидент — два исхода

Слева симптом снят и повторится при следующем отключении питания; MTTR не падает. Справа устранён корень: ЗИП ER6C поставлен, батареи заменены, мастеринг выполнен по регламенту, WO-1185 закрыт — останов по этой причине не повторяется.

6.8. Что видит инженер в HUD

В advisory-режиме инженер не отрывается от оборудования — ридаут появляется прямо в поле зрения на AR-линзе:

Текстом (как это формирует генератор под SOP):

▸ Вероятная первопричина (0.82): отложенная замена батарей энкодера (CMMS WO-1185, −67 д) → разряд J2/J3 (DIAG BLB, −9 д) → просадка 380 В + UPS (Historian, −3 ч 20) → рестарт контроллера (MES, −2 ч) → потеря мастеринга J2 (ALARM 1042, t₀). SOP-77 §6: НЕ просто перемастерить — установить ЗИП ER6C, заменить батареи (контроллер + манипулятор), затем мастеринг. Подтвердить?

Кнопки рабочие и в интерактивной версии: «Да» закрывает заявку и отправляет отчёт в дообучение (ребро графа батарея → мастеринг усиливается). «Другая причина» — инженер выбирает фактическую причину, CKG правит рёбра, событие переэмбеддивается. Каждый разбор делает следующий быстрее.

7. Железо: AR-очки как тонкий клиент и edge-сервер

Принцип разделения простой. «Мозг» (EventRAG) — on-prem backend; тяжёлый инференс (эмбеддинги, обход графа, LLM) выносится на цеховой edge-сервер. «Глаза и руки» — AR-очки как тонкий клиент: они ничего не считают, только показывают и слушают, поэтому остаются лёгкими и живут смену от одной зарядки.

Целевой профиль очков для этого сценария:

• дифракционный волновод с зелёным монохромным HUD — монохром здесь не компромисс, а фича: текстовый RCA-ридаут в одном цвете отлично читается при ярком цеховом освещении и не перегружает поле зрения;

• автономность на полную смену, зарядка USB-C;

• голосовой ввод (ASR/TTS) — руки инженера заняты инструментом;

• POV-стрим удалённому эксперту — режим remote co-pilot;

• фиксация действий обратно в CMMS — закрытие наряда прямо с линии.

Между очками и «мозгом» живёт edge/AR-шлюз — четыре сервиса, которые превращают очки из «второго монитора» в источник данных:

• Asset-resolution: visual-распознавание + BLE-маяк → asset_id оборудования, на которое смотрит инженер, плюс автоматическое временное окно для запроса. Инженер не вводит «шкаф A01-R1» руками — система понимает это из контекста взгляда.

• VLM (кадр → TEU): снимок панели, шильдика или дисплея контроллера превращается в мультимодальный TEU и попадает в общий индекс — камера очков становится ещё одним источником событий наравне с PLC.

• Voice I/O: голосовые правки и подтверждения hands-free («гипотеза один — принято»).

• HUD-renderer с safety-guard: панель рендерится вне рабочей зоны взгляда и не имеет права перекрывать движущиеся части оборудования. Бюджет задержки до HUD — < 50 мс от edge-узла.

On-prem здесь — требование, а не мода. 152-ФЗ ограничивает работу с персональными данными через зарубежные облака; чертежи, рецептуры и техрежимы — коммерческая тайна, и служба безопасности завода облако просто не согласует. Замкнутый контур + открытые модели + локальное железо = независимость от внешних сервисов — та самая резильентность из рамки Industry 5.0.

Честная оговорка про железо. Носимые AR-очки такого класса — предсерийная стадия: монохромный дисплей, ограниченная автономность, и главное — нет сертификации ATEX/IECEx для взрывоопасных зон. Для Ex-зон (нефтехимия, часть металлургии) сценарий дублируется сертифицированным классом носимых устройств — а «мозг» EventRAG остаётся неизменным: очки в архитектуре — заменяемый тонкий клиент.

8. Экономика: выводим каждую цифру

Все числа этого раздела — иллюстративная модель. Перед пилотом её нужно калибровать замером baseline MTTR на конкретной линии. Но модель полностью прозрачна — вот допущения и арифметика.

8.1. Допущения

1. Простой площадки ≈ 324 ч/год (27 ч/мес × 12 — средняя цифра Siemens/Senseye).

2. Стоимость часа простоя — консервативно 300 000 ₽/час (средний завод, одна линия).

3. Диагностическая доля в MTTR ≈ 35% (время до правильной гипотезы).

4. Снижение диагностического времени связкой «EventRAG + AR» — 25% (консервативно) … 40% (цель), в пределах подтверждённого AR-диапазона −10…−40% из индустриальных кейсов (эталонный named-кейс: Boeing, −25% времени сборочных операций и почти ноль ошибок с AR-инструкциями).

Важно: EventRAG экономит только диагностическую долю MTTR, а не весь простой — модель сознательно не приписывает себе чужие эффекты.

8.2. Расчёт на одну площадку в год

База простоя:            324 ч × 300 000 ₽/ч        = 97,2 млн ₽/год
Диагностическая часть:   97,2 млн × 35%             = 34,0 млн ₽/год
Экономия (консерв.):     34,0 млн × 25%             = 8,5 млн ₽/год
Экономия (цель):         34,0 млн × 40%             = 13,6 млн ₽/год

8.3. Горизонт 3 года против затрат клиента

Затраты клиента за 3 года (детали — в §9): внедрение 15 млн + поддержка 4 млн × 3 года + железо очков 0,3 млн = 27,3 млн ₽.

Откуда 19 месяцев: разовый вход = 15 + 0,3 = 15,3 млн; чистый месячный поток при цели = (13,6 − 4) / 12 = 0,8 млн/мес; 15,3 / 0,8 ≈ 19 мес. При консервативных −25% поток = (8,5 − 4) / 12 = 0,375 млн/мес → окупаемость ≈ 41 мес, то есть за горизонт 3 лет проект в минусе на 1,8 млн.

Вывод, который диктует стратегию: при консервативном сценарии проект выходит «в ноль» лишь к концу третьего года — поэтому первый пилот обязан быть в высокоинцидентном сегменте (FMCG), где выше шанс дотянуться до целевых −40% за счёт частых однотипных инцидентов и быстрого накопления обучающих событий.

8.4. Масштаб: почему «+13,5 млн» — нижняя граница

Чистый эффект +13,5 млн и ROI +49% посчитаны для консервативного среднего завода: одна линия, простой 300 тыс ₽/час. У крупного производства час простоя стоит 1–3 млн ₽ (глобальные бенчмарки: IDC ~$1 млн/час для Fortune-1000; автопром — до $2,3 млн/час), а площадка часто многолинейная. Экономия растёт линейно со стоимостью простоя и числом линий, тогда как цена внедрения почти не меняется — поэтому ROI кратно выше:

Проверка арифметики для строки «1 млн ₽/час»: 324 × 1 = 324 млн база → × 35% = 113,4 млн диагностика → × 40% = 45,4 млн/год. Для «3 млн ₽/час»: 972 → 340,2 → 136,1 млн/год. Сходится.

9. Юнит-экономика поставщика

Тоже модель, тоже ИЛЛЮСТРАТИВНО. Монетизация — проект внедрения (on-prem enterprise), рубли, горизонт 3 года.

Структура выручки на площадку:

Дальше простая арифметика:

LTV (валовая прибыль за 3 года) = 0,4×15 + 0,6×12 + 0,1×0,3 ≈ 13,2 млн ₽
CAC (enterprise-продажа: пилот, пресейл, цикл сделки) ≈ 3 млн ₽
LTV / CAC ≈ 13,2 / 3 ≈ 4,4×

Точка безубыточности компании: при постоянных затратах команды ~60–70 млн ₽/год — примерно 5–7 активных площадок в портфеле года (внедрения + поддержка). Модель чувствительна к трём параметрам: baseline MTTR (определяет достижимость −40%), число линий на площадке (масштабирует и эффект, и чек) и доля поддержки в портфеле (у неё маржа выше). Заметьте симметрию: чем крупнее производство клиента, тем лучше и его ROI (§8.4), и юнит-экономика поставщика — цена сделки растёт с числом линий при почти той же себестоимости внедрения.

10. Приоритизация: RICE по функциям и сегментам

Используем классический RICE = (Reach × Impact × Confidence) / Effort. Оценки экспертные, иллюстративные — но сама механика воспроизводима, все множители на столе.

10.1. Функции

Проверка на первой строке: 90 × 2.0 × 0.85 / 3 = 51.0. ✓

Вывод по приоритизации. V1 = Remote co-pilot + HUD-ридаут + Time-aware retrieval + SOP/Time-CoT. Причинный граф CKG — это V2: у него самый высокий потолок по Impact (3.0 — как раз он делает разбор из §6), но он дорог и рискован (Effort 6, Confidence 60% — качество зависит от данных и эксперта). Петля — V2/V3. То есть самое концептуально ценное (граф) сознательно отложено: MVP должен быстро дать измеримый эффект на дешёвых и уверенных функциях, а граф приезжает вторым эшелоном на уже собранные данные пилота.

10.2. Сегменты пилота

• FMCG/упаковка/пищёвка — приоритет №1. Высокая частота однотипных инцидентов даёт быстрый набор обучающих событий и быстрый ROI; среда не взрывоопасна — зелёного монохромного HUD и автономности «на смену» достаточно. Наш кейс с паллетайзером — ровно этот сегмент.

• Дискретное машиностроение/сборка — приоритет №2. Сложные многошаговые процедуры — там AR-инструкции и POV-эксперт дают наибольший эффект (аналогия Boeing), но инциденты реже, циклы длиннее, причинный граф копится медленнее.

• Непрерывное производство — поздний сегмент. Наивысшая цена простоя и сильнейший экономический аргумент (см. 408 млн в §8.4), но значительная часть площадок — Ex-зоны (ATEX/IECEx), где обычные AR-очки запрещены. Для не-Ex участков (диспетчерские, ремонтные цеха, открытые площадки) связка применима раньше; для Ex-зон — сертифицированный класс носимых устройств при неизменном «мозге».

10.3. Целевая аудитория

Узкая и конкретная: надёжностный инженер (reliability engineer) — главный пользователь и owner качества RCA; начальник смены — потребитель ридаута в реальном времени и эскалаций; главный механик — owner SOP, парка оборудования и приёмки рекомендаций; директор по производству — экономический спонсор (MTTR, простой, ROI). Для пилота достаточно 1–2 надёжностных инженеров и 3–5 начальников смен на площадку.

11. Дорожная карта, риски и план валидации

Дорожная карта.

• V1 (0–6 мес): Remote co-pilot + HUD-ридаут + time-aware retrieval + SOP/Time-CoT. Пилот в FMCG, замер baseline MTTR и цель −25% диагностики.

• V2 (6–12 мес): причинный граф CKG + обход назад + петля обратной связи. Расширение на дискретное машиностроение.

• V3 (12–24 мес): автономные гипотезы с обязательным подтверждением человеком, мульти-площадочное развёртывание, путь к Ex-сертифицированному носимому железу для непрерывного производства.

Ключевые риски — честно.

1. Перенос домена. Сильные RCA-цифры (§4.3) получены на cloud/microservices, не на OT: другой словарь, другая физика отказов, другой шум. Нужен собственный замер — без него все обещания недействительны.

2. Железо. Носимое AR — предсерийная стадия: монохром, автономность, нет ATEX. Митигируется архитектурно: очки — заменяемый тонкий клиент, для Ex-зон дублируются сертифицированным классом.

3. Качество графа. CKG зависит от качества троблшутинг-гайдов/FMEA и доступности эксперта; на greenfield-площадке без истории — cold start.

4. Экономика. Все числа §8–9 — модель; калибровать замером baseline на пилоте.

5. Латентность. Обход графа + LLM-инференс могут не уложиться в субминутную реакцию на аларм — поэтому EventRAG позиционируется как advisory-инструмент, а не замкнутый контур управления.

6. Безопасность генерации. SOP-ограничения снижают, но не устраняют риск галлюцинаций; для safety-критичных рекомендаций — обязательное подтверждение человеком (это зашито в advisory-режим).

План валидации (из статьи + продуктовый слой).

• Данные: (i) публичные process-mining-логи серии BPIC (Business Process Intelligence Challenge) с размеченными отклонениями, задачи в духе PM-LLM-Benchmark; (ii) симулированный цеховой корпус — PLC-алармы + MES-переходы + записи ТО с заложенными известными первопричинами, для контролируемой оценки.

• Бейзлайны: flat RAG · graph RAG без темпоральных партиций · rule-based FMEA-lookup · прямой промпт LLM.

• Метрики: top-1/top-3 RCA accuracy · mean time to root cause · temporal coherence · causal soundness (Likert 1–5) · hallucination rate.

• Абляции: по очереди выключаем CKG, темпоральные партиции, SOP-ограничения и Time-CoT — и смотрим вклад каждого механизма.

• Пилот: одна FMCG-площадка, 90 дней, A/B по MTTR (со связкой vs без), first-time-fix rate, доля корректных Top-1 первопричин, NPS инженеров, время онбординга новичка — и только потом масштабирование.

Отдельная честная строчка из статьи: стандартизованного бенчмарка для shop-floor event-stream RCA с LLM не существует — его создание само по себе исследовательский вклад.

12. Заключение

Стандартный RAG структурно не совпадает с временной, причинной и мультисорсной природой цеховых потоков событий. EventRAG закрывает этот разрыв тремя решениями: явный временной якорь в каждом TEU, двойной индекс с причинным графом и ре-ранкинг, который сшивает смысл, причинность и время в одну оценку и вытягивает первопричину из «хвоста» выдачи — в разборе §6 наряд WO-1185 поднялся с последнего, девятого места по семантике выше всех отвлекающих сигналов, набрав 89% скора за счёт причинного члена. На уровне цеха это разница между «перемастерьте ось» (симптом вернётся) и «поставьте ЗИП батареи» (корень устранён).

Архитектура пока не реализована — это position paper с конкретным планом валидации, с которым мы участвуем в ISPR 2026 (Сараево, 15–17 октября 2026), плюс продуктовая концепция с прозрачной (и потому проверяемой) экономикой. Направление вытекает прямо из рамки Industry 5.0: on-prem, человеко-центричный RCA-ассистент, который усиливает инженера, а не заменяет его. Augment the engineer — on-premise.

Буду рад критике в комментариях — особенно от тех, кто живёт в цеху: где эта постановка всё ещё оторвана от реальности?

Интерактив:

• Интерактивная схема архитектуры — покликать слои и прогнать трассировку инцидента

• Интерактивный разбор кейса Hyundai — 9 событий, ползунки α/β/γ/λ, рабочие кнопки «Да / Другая причина»

• ISPR 2026 — 26th International Symposium for Production Research — Сараево, 15–17 октября 2026, где мы представляем статью

Ключевые источники:

Siemens/Senseye «True Cost of Downtime 2024»; European Commission «Industry 5.0» (2021); Kusiak, «Generative AI in smart manufacturing» (J. Intelligent Manufacturing, 2025); DyG-RAG (arXiv:2507.13396); Flow-of-Action (WWW’25 Companion, arXiv:2502.08224); GALA (arXiv:2508.12472); Roy et al. (FSE’24 Companion, arXiv:2403.04123); ARCA (EuroMLSys’25, arXiv:2505.21419); MindRAG (arXiv:2506.09247); PM-LLM-Benchmark (ICPM 2024 Workshops); Knopp et al., RCA on object-centric event logs (ICPM 2024 Workshops); Okazaki et al., FMEA graph learning with LLMs (arXiv:2510.15428); Zhukova et al., link prediction for process-industry event logs (arXiv:2508.09096); TPP-Embedding (KnowledgeNLP @ NAACL 2025, arXiv:2410.14043); Narimani & Klarmann (IEOM 2024); Padella et al. (arXiv:2601.11468); RAG with Covariate Time Series (arXiv:2603.04951); HG-InsightLog (Findings of ACL 2025).