Investigation Module — расследование инцидентов
Зачем
Сейчас Opus подхватывает запросы вида «расследование/RCA» по триггерам и выдаёт LLM-ответ — это ad-hoc разговор, а не структурированное расследование. HSE-специалисту нужно по факту инцидента провести формальное расследование по методологии (5 Why / Fishbone / Bow-tie / TapRoot), собрать таймлайн, причины, контрмеры, защитить отчёт перед комиссией.
Validation идеи: KROT AI (Сколково, 25 лет опыт расследований у founder'а) строит точно эту фичу для enterprise-сегмента РФ за 1.2 млн руб/год. Lyumi делает lightweight-версию для индивидуального HSE-специалиста.
Кому
- HSE-специалисту нефтегаза/промышленности РК
- На площадке после инцидента
- Когда нужно быстро собрать данные и оформить отчёт
User flow
/incident → бот: «опиши что случилось — текст или voice»
→ юзер: текст / voice (Whisper уже работает)
→ бот извлекает: тип инцидента, дата/время, объект, последствия
→ бот ведёт по методологии (выбор пользователя или auto):
├── 5 Why — короткие инциденты, near-miss
├── Fishbone (Ishikawa) — средние, multi-cause
├── Bow-tie — major hazard, для CEO/совета
└── TapRoot — крупные с regulatory exposure
→ бот собирает таймлайн через диалог («что было до? кто присутствовал?»)
→ бот извлекает immediate causes (что конкретно отказало) и root causes (почему)
→ бот предлагает corrective + preventive actions, связывает с НПА из SQL
→ output: структурированный отчёт (.docx) + диаграмма (SVG/Mermaid)
Что собираем
| Поле | Источник |
|---|---|
| Тип инцидента | классификация: травма / near-miss / property damage / spill / fire / выброс |
| Severity | Sonnet оценивает по описанию |
| Дата, время, объект | extraction из описания |
| Свидетели | voice INPUT — каждый свидетель отдельно |
| Таймлайн событий | диалог с уточняющими вопросами |
| Immediate causes | unsafe acts + unsafe conditions |
| Root causes | через 5 Why / Fishbone branches |
| Контрмеры | corrective (фиксят что произошло) + preventive (предотвращают повтор) |
| Привязка к НПА | через SQL lookup — какие статьи ТК / приказы нарушены |
Технический стек
- Команда:
/incidentили/rca - State management: диалоговое состояние в FSM (aiogram уже умеет) — собираем поля поэтапно
- LLM: Opus 4 (force через
extra_bodyкак у /pack), thinking 8000-12000 для глубокого анализа - Voice INPUT: существующий
voice_handler.py(Groq Whisper, бесплатно) — для свидетельских показаний - Methodology prompts: отдельный файл
investigation_prompts.pyс шаблонами для каждой методологии - Diagram generation: SVG через python (Fishbone), Mermaid (Bow-tie), таблица (5 Why)
- Output: .docx через существующий ms-office-suite skill, шаблон в
templates/incident_report.docx - SQL integration: lookup_npa для поиска нарушенных статей ТК РК / приказов МТСЗН по типу инцидента
Output artifacts
incident_report_<id>_<date>.docx— формальный отчёт с подписямиfishbone_<id>.svgили5why_<id>.png— визуализация причинно-следственнойcorrective_actions_<id>.xlsx— план мероприятий с дедлайнами и ответственными (xlsx skill)
Integration с существующей Lyumi
- Reuse: voice_handler, ms-office-suite (docx), lookup_npa (SQL), Opus thinking, Reflection layer
- Reuse: правила гендерные (Люми о себе в женском, к собеседнику в мужском), no_company_names
- Новое: investigation_prompts.py, FSM states, шаблоны .docx, diagram generators
Phasing
MVP (sprint 1, ~3-4 дня):
- /incident команда
- 5 Why методология (самая простая)
- Сбор через текст
- Output: .docx с пунктами + Markdown в Telegram
- Integration с SQL lookup для привязки к статьям
v2 (sprint 2): - Fishbone (с SVG диаграммой) - Voice INPUT для свидетельских показаний - xlsx с corrective actions
v3 (sprint 3): - Bow-tie (для major hazards) - TapRoot (для regulatory cases) - Integration с recurring patterns (если 3+ инцидента похожи — alert)
Open questions
- Хранение инцидентов: локально у юзера (telegram chat history) или в БД на сервере? Если БД — приватность данных, GDPR-like вопросы. Простой ответ для MVP: ничего не храним, отчёт = output документ, юзер сам сохраняет.
- Какой default методологии? Для MVP — 5 Why (cover 80% случаев индивидуального расследования).
- Фото с места инцидента — отдельный input (existing photo analysis) или часть workflow?
Не делаем
- НЕ строим enterprise-продукт типа KROT AI (90 дней внедрения, on-prem, 1.2 млн руб). Lyumi остаётся lightweight.
- НЕ делаем интеграцию с ERP/HR — это для крупных клиентов, не для индивидуала.
- НЕ делаем «AI-интервьюер для свидетелей через звонки» — слишком сложно и invasive. Voice INPUT через Telegram достаточно.
Reference
- KROT AI deck:
lyumi/research/krot_ai_reference(планируется) - 5 Why methodology: Toyota Production System
- Fishbone: Kaoru Ishikawa, 1968
- TapRoot: System Improvements Inc, used by major US chemical/oil companies
- Bow-tie: industry standard для hazard management в нефтегазе (CCPS, IOGP)