Агентський аналіз на практиці: Slack-бот, семантичний шар та варіанти — купити чи створити.
Аналітика на основі агентів у технологічній компанії: Slackbot, який спілкується з вашими даними, семантичний шар, який потрібно було масштабувати, рішення про купівлю Omni та причина, чому саме прийняття цих технологій мало найбільше значення.
Джерела: My Experience Building Agentic Analytics at a Tech Company (And Shipping It to Stakeholders)
Аналітика на основі агентів присутня скрізь у презентаціях постачальників: спілкування з даними, BI з використанням ШІ, семантичні шари, аналітика з самообслуговуванням другої версії. Майже кожен продукт з аналітики намагається впровадити ШІ в кожен куточок. Думки щодо майбутнього цього напрямку є поширеними, але приклади його впровадження в реальних компаніях зустрічаються рідко, як і чесні відповіді на складніше запитання: чи витримав він реальних користувачів та їхні очікування?
Нижче наведений один із таких описів, складений на основі роботи фахівця з даних у середній компанії з підпискою, яка розпочала свою діяльність наприкінці 2025 року. У ньому розповідається про створення з нуля першого Slack-бота для роботи з даними, про впровадження його серед справжніх користувачів, про труднощі, пов’язані з розширенням семантичного шару та його інфраструктури, а також про рішення щодо створення власного інструменту чи його придбання після того, як команда почала шукати корпоративний інструмент для аналізу даних. З того часу ця людина перейшла на роботу консультантом, і майже кожна компанія, з якою вона співпрацює, намагається вирішити подібні проблеми, що свідчить про реальні можливості для фахівців з даних.
Рішення, яке мало значення ще до появи ШІ
На початку 2025 року сталося щось, що на той момент здавалося не пов’язаним із ШІ. Керівник відділу даних усвідомив необхідність створення першої інформаційної моделі компанії, і був запрошений досвідчений консультант з інженерії даних, щоб керувати цим процесом, причому на кожному етапі брали участь два фахівці з даних.
Модель інформації — це шар, який визначає, як структуровані дані, як пов’язані таблиці та, що найважливіше, що означають певні показники. Уявіть собі її як спільну мову, якою мають користуватися всі в компанії під час обговорення даних.
Технічна частина досить проста. Складність полягає у тому, щоб усі погодилися щодо цієї мови. Якщо запитати, хто вважається активним користувачем, кожна команда дасть різну відповідь. У відділі маркетингу є своє визначення, у відділі продуктів — інше, у фінансовому відділі — ще одне, і кожен переконаний, що саме його визначення є правильним. Досягнення згоди відбувалося повільно та складно, проте саме ця робота стала основою всього, що було створено пізніше. Без моделі інформації створення семантичної моделі на основі даних майже напевно завдало б більше шкоди, ніж користі.
Створення інсайтів за потребою
Поки формувався інформаційний модель, цей самий науковець у сфері даних переживав особисті зміни. Дослідження ринку праці показали, що все більше компаній шукають фахівців з технологій ШІ, що спонукало його навчитися автоматизувати окремі аспекти щоденної роботи: інструменти для очищення даних, процеси експлораційного аналізу та зв’язки між технологіями ШІ, даними та їхнім контекстом.
Те, що починалося як спосіб підвищення продуктивності, перетворилося на щось більше — частину ширшого руху до агентних аналітичних систем (термін, який тоді ще не використовувався), у яких традиційних методів аналізу вже було недостатньо. Одним із найбільших проектів, що виникли в результаті цього, став Slackbot.
Ідея полягала у створенні даних продукту, який би знаходився між панелями керування та науковцями у сфері даних для відповідей на запитання, які мали б бути легкими для вирішення, але не вимагали створення нової панелі керування чи переробки існуючої. Не кожне запитання заслуговує на створення заявки у Jira.
Ніхто не просив про це. Не було необхідності чекати дозволу чи схвалення. Більша частина була створена самостійно як прототип із схемою проектування системи та короткою демонстрацією для команди. Вирішальним кроком стало представлення цього як чогось вже створеного, а не як прохання про схвалення для початку роботи. Це звело ризики для команди майже до нуля та дало творцю можливість показати роботу з справжньою цінністю, що було достатньо для отримання необхідної підтримки.
Впровадження та вивчення того, як люди формулюють запити
Першими користувачами була одна команда — маркетингова. Це було навмисно: контрольоване впровадження замість загальнокорпоративного запуску, під час якого речі могли піти не так, що було б складно контролювати.
Очікуваною вигодою було лише безпечніше запуск. Насправді це розкрило багато чого про те, як неаналітики ставлять запитання. Маркетологи формулюють запитання з точки зору бізнес-проблеми, а не з точки зору таблиць чи визначень показників, тому системі доводилося здійснювати переклад між цими двома підходами. Аналітики у цьому випадку часто залишаються сліпими через власні звички.
З самого початку було зрозуміло, що це продукт на основі даних, а не просто інструмент, тому документація, внутрішній маркетинг та процес адаптації користувачів потребували уваги, адже саме вони визначають, чи будуть люди справді використовувати створене. Перші кілька місяців були переважно присвятовані тестуванню, причому дуже інтенсивному.
Що було далі
Результатом став MVP, тож потрібно було вирішити, чи заслуговує продукт на подальші інвестиції та які будуть вимоги до наступної версії. Створення системи на основі даних не було найскладнішою частиною. Коли постало питання про те, що зробить її кориснішою, розмова звернулась до обсягу даних, до яких міг би дістатися бот, що означало необхідність розширення семантичного шару.
Потім команда поставила собі низку запитань. Перший семантичний шар зберігався у вигляді файлів YAML за Slackbotом, тож як він міг би розширюватися? Як кілька людей могли б працювати над ним? Чи всі взагалі погоджувалися щодо визначень?
Ці запитання з’явилися у зручний момент, адже вже розглядалося нове інструмент BI, оскільки існуючий вже не здавався достатньо сучасним. Дискусія перейшла від покращення Slackbot до питання про необхідність належного семантичного шару та про те, чи він має бути вбудованим у інструмент BI чи існувати окремо.
Багато корпоративних продуктів BI, таких як Looker чи Omni, містять семантичний шар. Для цієї команди існувала одна умова: якщо інструмент BI матиме семантичний шар, цей шар не міг бути закріпленим, і його потрібно було зробити портабельним для використання в інших інструментах. Саме тому оголошення про Open Semantic Interchange у вересні 2025 року, яке обіцяло універсальний стандарт для семантичних шарів, мало таке велике значення.
Створювати чи купувати, і чому це має менше значення, ніж здається
Компанія врешті-решт вирішила купити готовий інструмент. Вибір припав на Omni, який поєднував у собі функції Tableau, Looker та деякі можливості таблиць. У листопаді та грудні 2025 року було перевірено кілька інструментів, а Omni почав використовуватися на початку 2026 року.
Це може здатися невтішним: історія про Slack-бота, створеного з нуля, яка закінчується покупкою готового рішення. Важливий момент, який багато фахівців з даних ігнорують, полягає у тому, що отримані навички залишаються актуальними навіть під час купівлі готового інструменту. Створення бота дало важливий досвід, який був використаний під час інтеграції Omni: практики розробки запитів, процедури оцінки, технологія MCP та глибоке розуміння функцій семантичного шару.
Інженерія контексту — це гарний приклад. Це означає контроль над тією інформацією, яку бачить модель під час обробки запиту: які таблиці, які визначення метрик, які бізнес-правила. Створивши все з нуля, розробник знав, що потрібно покласти перед моделлю, а що, що найважливіше, залишити осторонь. Ці знання формуються під час розробки, а не шляхом читання документації.
Ці навички також трапляються під час співбесід. З моменту переходу у сферу консалтингу з’являється багато компаній, які віддають перевагу внутрішній розробці, переважно тому, що хочуть індивідуальне рішення. Тому запитання про те, чи варто вивчати цю навичку, є неправильним. Вивчіть її незалежно від рішення компанії, адже це підготує вас до будь-яких викликів у будь-якій системі обробки даних.
Де не вистачило купленого інструменту
Omni — це потужний продукт молодої компанії, яка швидко розвивається, і він приніс значну користь. Найчастішою проблемою був MCP.
Велика частина співробітників компанії досі працює з Google Sheets та Excel, і це незабаром не зміниться. Метою було також поєднати ці дані, використовуючи ту саму семантичну модель, що й для всього іншого, щоб число в чиїйсь таблиці означало точно те саме, що й в інших місцях. Ідеально було б зробити це через MCP, але це було неможливо.
Команда хотіла мати більше контролю над етапом між семантичною моделлю та тим, що її використовує: що повертається та які інструменти можуть до неї під’єднуватися. Окремий семантичний шар із рештою компонентами, розробленими власноруч, дозволив би повністю контролювати API. Це і є компроміс, і для багатьох компаній саме він вирішує всю справу. Там, де важливі гнучкість та повний контроль, просто купівля може виявитися недостатньою. Там, де важлива швидкість та готовий до використання продукт, такий як Omni, дуже допомагає.
Прийняття вирішує все
Ця тема заслуговує окремої статті. Навіть найскладніша у світі система не має жодної цінності, якщо люди не включать її до своєї робочої процедури та не довірятимуть їй, і саме тут багато фахівців з даних провалюються. Для невеликої команди знайти час на це було справжньою проблемою, але прийняття цього інструменту сприймалося серйозно. Інвестиції були наступними:
- серія відео для швидкого ознайомлення,
- кілька презентацій для всієї компанії,
- спеціалізовані онлайн-семінари для ключових команд, таких як фінанси.
Кожен, хто впроваджує інструмент ШІ всередині компанії, повинен ставитися до його прийняття як до запуску продукту. Це означає внутрішній маркетинг, навчання та наявність прихильників у кожній команді, які вірять у цей інструмент. Інакше місяці наполегливої роботи закінчуються ще одним інструментом, яким ніхто не користується. Ця робота є нудною, і її результати не відображаються на панелі керування, проте саме вона робить усі зусилля значущими для кар’єри.
Вплив на кар’єру
Slackbot, його впровадження та провідна роль у переході до агентського аналітики принесли конкретний результат — можливість торгуватися. Цей досвід допоміг у поданні заявки на підвищення, і воно було надане.
Суперечка стосувалася не стільки Slackbot, скільки кмітливості та постійного перебування на передовій у цій галузі, а потім використання цього для створення чогось, що покращить компанію — у цьому випадку інсайтів щодо попиту. Найсильнішою стороною було те, що не потребувало пояснень: ніхто нічого не просив, і ніхто не мусив керувати роботою. Менеджери сприймають це як ознаку високого статусу.
Людина, яка може створювати такі системи, розуміє дані та водночас розуміє бізнес, — це рідкісне поєднання, і компанії це усвідомлюють. Це також пояснює подальший перехід у консалтинг, адже попит на датасайентів, які мислять про ШІ на рівні систем, а не лише через спонтанні чат-розмови, стрімко зростає.
Висновок
Аналітика з використанням агентів вже існує та не є чимось майбутнім. Компанії експериментують, впроваджують її та з’ясовують, що є ефективним. Фахівці з даних повинні брати участь у цьому процесі. Незалежно від того, чи створює компанія ці рішення самостійно, чи купує їх, ці навички застосовуються скрізь: вони підвищують цінність працівника на поточній посаді, сприяють просуванню та допомагають виділитися під час співбесід.
Усе почалося з прототипу, створеного у вільний час, схеми проектування системи та швидкої демонстрації для команди. Чекати, поки хтось попросить виконати цю роботу, — це помилка. Кращим шляхом є самостійне керування власним розвитком.
Пов’язана література
- Практичні нотатки: створення системи виявлення шахрайств з використанням агентів, готової до експлуатації — Детальний огляд Практичних нотаток: створення системи виявлення шахрайств з використанням агентів, готової до експлуатації: контракти, перевірки та шаблони коду для команд, які реалізують цю модель.
- Веб-стек для стартапів у епоху AI-агентів: Next.js, MUI та Firebase — Які інструменти є ефективними під час розробки, коли агенти пишуть більшу частину коду: Next.js, MUI, Firebase, Vercel, PostHog та мінімальна налаштування агента, з поясненням причин вибору кожного з них.