В крупных компаниях доступ к данным часто формально открыт всем, а фактически — только аналитикам и частично продактам, которые знают SQL, структуру данных, названия полей, бизнес-логику расчёта метрик. В результате маркетинг, продукт, продажи и финансы зависят от ad-hoc запросов, а аналитики превращаются в бутылочное горлышко.
В OLX (европейский классифайд), компании, где я работаю, одна из моих зон ответственности — это эффективность привлечения трафика. Мы тратим многомилионные бюджеты на маркетинг, делаем SEO, контент и бренд-кампании. У меня больше десятка маркетинговых стейкхолдеров, которым нужна аналитика. Многие их запросы решаются с помощью имеющихся дашбордов, но есть и регулярный поток ad-hoc задач, требующих ресурсы дата-инжинеров и аналитиков. Мы хотели сократить эту зависимость и дать бизнес-пользователям удобный интерфейс для получения ответов из уже существующего аналитического контура.
Так появилась идея Talk2Data, внутреннего AI-ассистента в Slack, который позволяет задавать вопросы к данным на естественном языке и получать ответы без написания SQL. Снаружи это выглядит как чат-интерфейс. На практике за ним стоит инженерная система с ограничениями, правилами и отдельным процессом оценки качества.
В этой статье расскажу, как мы подошли к задаче, и что на самом деле нужно, чтобы self-service analytics на базе AI оказался полезным для бизнеса.
Обо мне: Меня зовут Яна Доценко — я продакт, занимаюсь ростом и монетизацией, управляла продуктовыми командами в VK, лидила рост в Европейском AI стартапе Voicemod, сейчас занимаюсь ростом крупнейшего европейского классифайда OLX. Пишу про рост и монетизацию продуктов здесь и в канал: t.me/o_product
Как работает фича?
Сценарий использования выглядит так:
пользователь задаёт вопрос в Slack;
система интерпретирует намерение;
сопоставляет запрос с доступными метриками и измерениями;
генерирует SQL;
отправляет запрос в хранилище;
возвращает результат обратно пользователю.
Пользователь может задавать вопросы в духе:
сколько активных пользователей было за период;
как изменилась метрика по странам;
как выглядит динамика по платформам;
что происходило на конкретном рынке в заданный промежуток времени.
С точки зрения пользователя это похоже на разговор с аналитиком. Но с точки зрения архитектуры это не свободный чат с LLM, а ограниченный слой поверх существующей аналитической модели. Именно эта разница оказалась критичной для качества.
Почему нельзя просто дать LLM схему базы
Казалось бы можно было показать модели схему таблиц, и она сама разберётся, как отвечать на вопросы. На практике такой подход очень быстро упирается в ограничения.
Первая проблема в том, что бизнес-метрики почти никогда не равны полям в таблицах. Метрика — это не просто колонка, а определение, логика расчёта и контекст использования. Если пользователь спрашивает про активных пользователей, выручку, core leads или другую бизнес-сущность, за этим почти всегда стоит договорённость внутри компании о том, как именно это считается и интерпретируется.
Вторая проблема - язык пользователя неоднозначен. Люди пишут “покажи пользователей за прошлый месяц”, “что с выручкой на mobile”, “сравни с прошлой неделей”. Для человека такие формулировки звучат естественно, но системе нужно превратить их в очень конкретный запрос: понять метрику, период, платформу, страну, агрегацию, иногда ещё и доменные ограничения.
Третья проблема - даже технически правильный SQL не гарантирует правильного бизнес-ответа. Модель может построить запрос, который синтаксически корректен, но использует не ту таблицу, не ту версию определения метрики или не тот уровень агрегации.
Поэтому рабочая система должна опираться не просто на LLM, а на слой заранее определённых метрик, измерений и правил интерпретации.
Архитектура: от вопроса в Slack до ответа из хранилища
Высокоуровнево пайплайн выглядел так:
Slack → интерпретация запроса → слой метрик и измерений → генерация SQL → DWH → ответ пользователю
Ключевой элемент здесь — слой метрик.
Именно он ограничивает пространство, в котором работает система. Вместо того, чтобы пытаться понять всю схему хранилища, бот знает:
какие метрики доступны
как они называются
какие у них есть допустимые измерения
какие формулировки считаются валидными
какие временные разрезы и платформы поддерживаются
как эти сущности должны переводиться в SQL
Это делает систему значительно более предсказуемой.
Почему без качественных данных всё это не работает
Один из самых важных выводов проекта — AI не исправляет проблемы с данными. Он их усиливает. Если у вас плохо и описаны определения метрик, если разные команды используют разные источники истины, если есть дубли, конфликты или неочевидные трактовки, то natural language interface только сделает это заметнее.
Чтобы Talk2Data начал давать качественные ответы, командам пришлось проделать подготовительную работу:
привести к более строгому виду определения метрик
договориться об источниках истины
описать допустимые измерения и словарь сущностей
Вообще, значимая часть такого проекта не про prompt engineering, а про knowledge engineering, data governance и стандартизацию аналитики.
Evaluation process или как мы контролировали качество ответов
Мы выстроили отдельный evaluation process, чтобы быть уверенными в качестве ответов.
Первый уровень — системная проверка, unit- и integration-тесты для основных компонентов.
Второй уровень — эксперименты на заранее подготовленном наборе репрезентативных вопросов. Такой набор позволял сравнивать изменения не по интуиции, а по повторяемым сценариям.
Третий уровень — live monitoring уже на реальных вопросах пользователей в проде.
Вам нужно будет составить список 15–30 тестовых вопросов, покрывающих разные дименишены, агрегации и тд. И под них написать SQL-запросы. Далее вы запускаете тестирование, где сравниваете результаты исполнения SQL-кода и ответы агента. Логируете Pass/Fail результат по каждому кейсу. Бенчмарк прохождения тестов +95%.
В продакшене также желательно провести раунд тестирования, но уже на реальных запросах ваших коллег, чтобы убедиться, что в реальности фича используется так как проектировалась и имеет такую же точность, что и в тестах.
Почему пользователям всё равно пришлось учиться
Даже хороший AI-интерфейс лучше работает, когда пользователь соблюдает несколько правил:
использует точные названия метрик
явно указывает период
не смешивает несколько вопросов в одном сообщении
уточняет платформу, страну или другой нужный срез
Поэтому необходимо подготовить ваших стейкхолдеров к запуску. Сделать демо и написать документацию, дать примеры хороших и плохих запросов.
Что дало внедрение
Talk2Data дал нам два практических эффекта.
Во-первых, сократил нагрузку на повторяющиеся ad-hoc запросы. Пользователи получили возможность самостоятельно находить ответы на типовые вопросы, не дожидаясь аналитика.
Во-вторых, в целом сократил время на работу с аналитикой для стейкхолдеров. По запросам, которые закрывали дашборды много времени могло уходить на фильтрацию, сбор метрик, подготовку отчетов, поиск "инсайтов" для оптимизации и так далее. Сейчас с помощью четко-сформулированного запроса в Talk2Data можно получить ответ в нужном формате за секунды.
Интересным следствием внедрения стало то, что продукт стал полезен и команде финансов, которые много работают с данными, но часто имеют очень ограниченный ресурс аналитической поддержки, поэтому обращаются к продактам, маркетологам, аналитикам.
Что я бы посоветовала тем, кто хочет повторить такой проект
Начать с определения бизнес-кейсов и метрик. Если внутри компании нет согласованных определений, AI только усилит хаос.
Настроить evaluation process.
Заложить обучение пользователей. Чтобы self-service давал хорошие результаты, вам нужно заонбордить стейкхолдеров в использование фичи и научить их корректной постановке вопросов агенту.
Вывод
Главный урок проекта для меня в том, что чтобы получить эффективный аналитический self-service на базе AI, нужно иметь качественные и стандартизированные данные, semantic/metric layer, полноценный evaluation process и онбординг команды. Тогда такой инструмент сможет снизить нагрузку на аналитиков и упростит жизнь бизнес-стейкхолдерам.
Сейчас наша команда маркетинга использует агента на ежедневной основе. Агент помогает решать множество рутиных задач — репортинг, поиск инсайтов по маркетинговым кампаниям. А также стратегических — рекомендации по оптимизации кампаний, сбор более глубокой аналитики до уровня продукта и так делее.
