Практическое применение агентного анализа: Slack-бот, семантический слой и выбор между покупкой и самостоятельным разработкой.
Аналитика с использованием агентов в технологической компании: Slack-бот, способный общаться с данными, семантический слой, требовавший масштабирования, решение о покупке 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, сколько изобретательности и стремления оставаться в авангарде отрасли, а затем использования этого для создания чего-то, что улучшит компанию — в данном случае аналитики по спросу. Самым очевидным было то, что не требовало объяснений: никто ничего не просил, и никто не нуждался в руководстве при выполнении работы. Руководитель воспринимает это как признак высокого статуса.
Человек, способный создавать такие системы, понимающий данные и в то же время разбирающийся в бизнесе, — это редкое сочетание, и компании это знают. Это также объясняет последующий переход в консалтинг, поскольку быстро растёт спрос на специалистов по данным, которые мыслят о ИИ на уровне систем, а не только через импровизированные чат-беседы.
Вывод
Аналитика с использованием агентных технологий уже существует и не является чем-то будущим. Компании экспериментируют с ней, внедряют её и выясняют, что работает эффективно. Учёные-данные также должны участвовать в этом процессе. Независимо от того, создаёт ли компания такие решения самостоятельно или покупает их, соответствующие навыки применимы везде: они повышают ценность специалиста на текущей должности, усиливают шансы на повышение и помогают выделиться на собеседованиях.
Всё началось с прототипа, созданного в свободное время, схемы проектирования системы и краткой демонстрации для команды. Ожидание, пока кто-то попросит выполнить эту работу, — ошибка. Лучший путь — брать на себя ответственность за собственное развитие.
Связанные материалы
- Практические рекомендации: создание системы обнаружения мошенничества на основе агентов, готовой к использованию в производстве — Подробное руководство по созданию такой системы: информация о контрактах, проверках и готовых фрагментах кода для команд, разрабатывающих подобные решения.
- Веб-фреймворки для стартапов в эпоху ИИ-агентов: Next.js, MUI и Firebase — Какие инструменты оказываются наиболее эффективными, когда агенты пишут большую часть кода: Next.js, MUI, Firebase, Vercel, PostHog, а также минимальная настройка агента с обоснованием выбора каждого инструмента.