Автоматична narrative для дашбордів

AI-агент читає дашборди та сховище даних, знаходить значущі зміни метрик і пише текстовий коментар мовою бізнесу. Замість "що сталося з цим графіком" керівництво одразу отримує пояснення. Аналітики звільняють час, який раніше витрачали на повторювані звітні коментарі, і переключаються на глибокий розбір причин.

Процес роботи покроково:

1. Агент підключається до BI-інструменту (Looker, Tableau, Power BI) або безпосередньо до сховища даних (Snowflake, BigQuery, ClickHouse, Redshift)
2. Витягує свіжі значення метрик за звітний період і порівнює з попередніми — тиждень до тижня, місяць до місяця або відносно плану
3. Визначає значущі зрушення: зростання, падіння, аномалії, відхилення від прогнозу, перевищення заздалегідь заданих порогів
4. Класифікує зміни за бізнес-логікою — рутинна сезонність, реальний тренд, разова аномалія або структурне зрушення
5. Формує narrative-чернетку російською або англійською: що сталося, наскільки це значущо, з якими метриками та сегментами пов'язано
6. Публікує результат у вибраному форматі — Slack-пост, email-розсилка, сторінка в Confluence або Notion, слайд PowerPoint поруч із графіком

Executive reporting перетворюється з тижневого проєкту на одноденний. Аналітики отримують готову чернетку, яку потрібно дочитати та скоригувати, а не писати з нуля до кожного понеділка.

Що автоматизація НЕ робить

• Не замінює глибокого аналізу причин — AI-агент фіксує факт зміни, але розслідування "чому саме так" залишається за аналітиком і потребує доменного контексту
• Не приймає управлінських рішень — narrative дає опис та гіпотези, а висновки та дії робить менеджмент
• Не працює без якісних даних — якщо метрики у сховищі рахуються з помилками або схема недокументована, narrative повторить і посилить ці помилки

Технічна архітектура рішення на custom-code: Python- або Node.js-сервіс з доступом до сховища даних та до LLM-API. AI-агент працює за розкладом або тригером і перетворює числові зсуви на текст бізнес-мовою команди.

Покрокова реалізація:

1. Підключення до джерел даних — SQL-конектор до сховища (Snowflake, BigQuery, Redshift, ClickHouse) або до API BI-інструменту (Looker, Tableau, Power BI)
2. Налаштування шару семантики — список ключових метрик із зрозумілими бізнес-назвами, одиницями вимірювання, напрямком "зростання добре / погано" та допустимими порогами
3. Детектор змін — алгоритм, що порівнює поточні значення з історією, враховує сезонність і статистичну значущість, фільтрує шум
4. Генератор narrative — LLM (AI-модель або порівнянна модель) отримує на вхід таблицю змін і пише текст за шаблоном промпту з урахуванням корпоративного тону
5. Шаблони під формат — окремий промпт для Slack-повідомлення, окремий для email-розсилки, окремий для слайда PowerPoint або сторінки Confluence
6. Доставка — інтеграція з CMS/content системою та BI-інструментом: публікація narrative поряд із дашбордом або у корпоративний месенджер за розкладом

Компоненти системи

Безпека та compliance

Агенту потрібен read-only доступ до сховища та BI-інструментів — запис і зміна схем не потрібні. Секрети та токени зберігаються у менеджері на кшталт AWS Secrets Manager або Doppler, а не в коді. Якщо в метриках трапляється PII, фільтрація та агрегація відбуваються до передачі даних у LLM. Аудит-лог записує, які числа пішли в модель і який narrative вийшов — це допомагає розбирати помилки, перевіряти фактологію та відповідати на запити служби compliance.

Альтернативні підходи

• Готові BI-аддони з AI-коментарями (Tableau Pulse, ThoughtSpot Sage) — простіший запуск, але менше гнучкості під внутрішню мову компанії та специфіку звітності
• No-code рішення на workflow-рушії + LLM API — швидша перша версія, але обмежені в роботі з великою кількістю метрик і складною логікою детектора
• Чистий custom-code на Python — максимальна кастомізація під специфіку звітності та інтеграцій, але потребує більше часу на збирання

Можливі підводні камені

• Погано розмічена семантика метрик призводить до того, що narrative плутає причини і наслідки
• Нестача історії — якщо у компанії мало даних за минулі періоди, детектор не відрізнить нормальний зсув від аномалії
• Без рев'ю чернеток у перші тижні промпти не встигають відкалібруватися під реальний тон керівництва

Що потрібно для запуску:

• Структуроване джерело даних — сховище з регулярно оновлюваними метриками (Snowflake, BigQuery, ClickHouse, Redshift) або BI-інструмент з API
• Список ключових метрик з бізнес-визначеннями — без цього narrative не зможе відрізнити "виручка впала" від "виручка по одному сегменту повернулась до норми"
• Доступ до LLM API — Anthropic, OpenAI або локально розгорнута модель з достатньою довжиною контексту
• Канал публікації — Slack, Confluence, email-шаблон або сторінка Notion, куди агент кладе готовий narrative

Готовність команди

• Один інженер з досвідом Python або Node.js та SQL — щоб побудувати конектори, детектор змін та інтеграції з каналами доставки
• Один аналітик або data-engineer — щоб визначити значущість метрик, написати промпт-шаблони та калібрувати тон narrative
• Стейкхолдер з боку керівництва — щоб валідувати перші narrative та коригувати стиль і рівень деталізації

Терміни

Для складності week збірка займає 2-4 тижні. Перший тиждень іде на підключення джерел та розмітку ключових метрик. Другий — на збірку narrative-пайплайну та детектора змін. Третій-четвертий — на ітерації з пілотними звітами, калібрування промптів та налаштування доставки в Slack, Confluence або Notion.