Привет, Хабр! Меня зовут Стас Золотарев, я автор на курсах «Аналитик данных» и «Специалист по Data Science» в Яндекс Практикуме. В первой части статьи мы выяснили, как аналитик может использовать ИИ в своей повседневной работе и какие навыки в принципе нужны для этого.
Теперь поговорим про бизнес-пользователей, разговорную аналитику, а также возможные проблемы и ограничения в её применении. В этой статье я расскажу:
что такое семантический слой данных и почему без него невозможна разговорная аналитика,
порассуждаю о том, заменят ли ИИ-агенты привычные способы взаимодействия с данными — дашборды и таблицы.
Лирических отступлений сегодня не будет, поэтому сразу к делу.
ИИ для бизнес-пользователей: разговорная аналитика
Что такое разговорная аналитика и как её используют
Аналитики используют ИИ не только для оптимизации своих внутренних процессов, но и чтобы создавать инструменты для бизнес‑пользователей (заказчиков). Одно из наиболее заметных проявлений этого подхода — разговорная аналитика.
В рамках неё сотрудники компании (условно, топ-менеджмент и руководители отделов) взаимодействуют с данными через ИИ-агентов. Работает это примерно так:
пользователь задаёт агенту вопрос на естественном языке,
агент анализирует задачу, планирует шаги решения,
после этого обращается к данным и вызывает свои инструменты для работы с ними
и возвращает результат в удобной для человека форме — в виде числа, таблицы или графика.
Задача аналитика здесь — собирать, дополнять и настраивать все данные и механизмы их обработки, чтобы агенты как можно лучше решали свои задачи.
Крупные технологические компании активно инвестируют в это направление. Google, например, развивает разговорную аналитику внутри BigQuery и Looker, встраивая LLM‑модели непосредственно в BI‑инструменты. Общий вектор очевиден: разговорный интерфейс становится ещё одним слоем доступа к данным.
В аналитическом контексте это означает переход от статичных отчётов и интерактивных дашбордов к диалоговому взаимодействию с данными.
Типичные вопросы к ИИ-агентам звучат максимально по‑бизнесовому, например: «Как изменилась выручка по клиентам из Москвы за последний квартал?» или «Какие продукты дали наибольший рост retention в этом месяце?».
В успешных сценариях ИИ корректно распознаёт метрику, период и фильтры, возвращая, например, процентное изменение выручки с графиком по месяцам или таблицу п��одуктов с приростом retention и визуальным ранжированием. Такие запросы хорошо работают, потому что опираются на чётко формализованные показатели и простую аналитическую логику.
Лучше всего разговорная аналитика показывает себя в описательных сценариях — когда нужно понять, что произошло, а не почему это произошло и что будет дальше. Она снижает порог входа в аналитику для менеджеров и операционных ролей, ускоряет работу с данными и, что важно, вынуждает команды чётче формализовывать метрики и бизнес‑логику.
Плюсы и ограничения разговорной аналитики
Главное преимущество разговорной аналитики — пользователям не нужно понимать, как устроены отчёты, какие таблицы лежат в основе дашборда и где именно считается нужная метрика (за всё это отвечают аналитики). Достаточно сформулировать вопрос привычным языком — и ИИ сгенерирует ответ. Это подходит для одноразовых запросов: быстро посмотреть динамику показателя, сравнить сегменты или уточнить цифру, не погружаясь в BI-интерфейс.
На практике это снижает нагрузку на аналитиков в рутинных ситуациях. Вместо серии однотипных вопросов вроде «А можешь посмотреть выручку по этому сегменту?», бизнес получает инструмент самообслуживания. Аналитик при этом остаётся в контуре — он задаёт правила, описывает метрики и контролирует модель данных, — но меньше времени тратит на ручную поддержку.
Однако границы применимости проявляются довольно быстро. Если в данных существует несколько определений одной и той же метрики (например, gross и net revenue), либо бизнес‑термины интерпретируются неоднозначно («клиенты из Москвы» — это по юридическому или фактическому адресу?), система либо требует уточнения, либо молча делает допущение и даёт неполный или однобокий ответ.
Неочевидная проблема — сложность контроля корректности ответов
После ответа ИИ-агента, пользователь видит итоговое число или график, но не всегда понимает, какие именно фильтры и допущения были применены. В отличие от дашборда, где структура расчётов зафиксирована визуально, разговорная аналитика требует дополнительных механизмов прозрачности: пояснений, расшифровок и явного указания логики расчёта.
Наконец, разговорная аналитика часто отвечает на конкретный вопрос, но почти не даёт «общей картины». Бизнес получает ответ, не всегда видя контекст: как клиенты ведут себя в других сегментах, какие метрики связаны между собой и где находятся аномалии.
Из-за этого на практике разговорная аналитика пока распространена ограниченно. В продакшене такие решения чаще всего работают поверх строго заданного набора метрик — выручки, DAU/MAU, retention, churn — с заранее определёнными периодами, фильтрами и разрезами.
Сейчас разговорная аналитика не заменяет дашборды, а дополняет их. Дашборды по‑прежнему остаются основным инструментом мониторинга и регулярного контроля показателей, а ИИ‑агенты — инструментом исследования, уточнения и быстрого доступа к данным. Это скорее аккуратное дополнение к классической аналитике, чем её полноценная замена — по крайней мере на текущем этапе развития ИИ-агентов.
И здесь мы подходим к ключевому элементу, без которого разговорная аналитика просто не работает.
Семантический слой данных
Что такое семантический слой?
Семантический слой — это перевод сырых данных в понятный бизнесу язык. Он объясняет, что именно означают цифры, и служит единым источником правды, чтобы все пользователи работали с одинаковыми метриками и понятиями.
Для аналитика наличие семантического слоя радикально меняет характер работы. Вместо того чтобы каждый раз пересобирать метрики и объяснять, почему цифры «не сходятся», он опирается на зафиксированные определения. Это снижает количество конфликтов между командами по поводу корректности расчётов и освобождает время для интерпретации результатов, а не для их пересчёта.
Инструменты для создания семантического слоя
Неважно, какое ПО вы используете. Семантический слой — это прежде всего функция, которая превращает сырые данные в понятные для бизнеса термины. К примеру, за это отвечают такие инструменты, как dbt или Looker.
dbt (data build tool) — это инструмент для трансформации данных внутри хранилища. Он описывает модели данных, метрики и зависимости между ними в виде кода, позволяет хранить их в Git, тестировать и следить за контролем версий. В контексте семантического слоя dbt часто используется для построения витрин данных и централизованного слоя метрик, где бизнес-логика формализована и проверяема. По сути, dbt помогает превратить SQL-скрипты в управляемый продукт с документацией и тестами.
Семантический слой данных может быть реализован и в BI решениях. Например, Looker — это BI-платформа, в которой семантический слой реализуется через язык моделирования LookML. В Looker аналитик заранее описывает сущности, связи между таблицами, допустимые агрегации и бизнес-метрики. В Looker (и в экосистеме Google Cloud) ещё в 2024 году появились ИИ-функции, которые позволяют формулировать вопросы вроде «Покажи выручку по сегментам за последний квартал и сравни с прошлым годом» без написания SQL. Но ключевой момент в том, что такие ИИ-агенты не обращаются напрямую к таблицам хранилища. Они работают через описанную модель LookML — то есть через семантический слой, которым как раз и занимаются аналитики.
Что может пойти не так в разговоре с нейросетью
Если коротко — почти всё ¯\_(ツ)_/¯
С развитием разговорной аналитики и ИИ-интерфейсов значение семантического слоя становится критическим. Искусственный интеллект не «понимает» данные в человеческом смысле, а опирается на доступные поля, связи и описания. Если эти правила не заданы жёстко, модель начинает принимать решения самостоятельно — и не всегда корректно.
Представим простой вопрос: «Какая у нас выручка за квартал?» В базе могут существовать поля gross_revenue, net_revenue, recognized_revenue и booked_revenue. Без явного определения модель выберет одно из них — возможно, первое по алфавиту или наиболее часто используемое. Ответ будет выглядеть логично, цифра будет аккуратной, но бизнес-метрика может оказаться не той, что используется в отчётности. Ошибка будет не синтаксической, а смысловой.
Временные окна также становятся источником ошибок. Вопрос «Сколько активных пользователей в марте?» кажется очевидным, но что значит «активных»? Это пользователи с хотя бы одним визитом в марте? Или это MAU за март, рассчитанный как скользящее окно в 30 дней? Или пользователи, зарегистрированные в марте и совершившие действие? Если временные рамки не зафиксированы, ответ может быть логически последовательным, но фактически неверным.
Чаще всего проблемы начинаются с разночтений в определениях. Например, «активный пользователь» для маркетинга — это тот, кто хотя бы раз зашёл в продукт. Для продуктовой команды — тот, кто совершил целевое действие. Для финансов — тот, кто заплатил. Если эти различия не отражены в модели, каждая команда будет оперировать своей правдой. Это влияет на оценку retention, на маркетинговые бюджеты и на стратегические решения.
Подобные расхождения редко выглядят как сбой системы. Они вы��лядят как уверенный и очень аккуратный ответ — именно поэтому они опасны. Когда бизнес обнаруживает несоответствие цифр, доверие к инструменту падает. Разговорная аналитика, вместо того чтобы стать ускорителем принятия решений, превращается в дорогостоящий эксперимент.
Если аналитик не понимает устройство семантического слоя, он не способен валидировать ответы системы. В итоге он может принять «разумно звучащую» цифру за истину — и ошибка будет обнаружена уже на уровне управленческих решений.
Рекомендации по работе с семантическим слоем
Зрелая работа с данными требует дисциплины. Можно выделить несколько принципов, применение которые в работе над семантическим слоем данных помогает превратить разговорную аналитику в инструмент, на который можно опираться при принятии решений:
Метрики должны быть явно задокументированы: с определением, временным окном, уровнем агрегации и списком исключений. Формулы не должны содержать «магии» — скрытых коэффициентов и неочевидных корректировок без объяснения. Логика расчётов должна быть прозрачной и проверяемой.
Критически важно версионирование семантического слоя. Метрики меняются: появляются новые источники данных, обновляется бизнес-логика, корректируются правила отчётности. Если изменения не отслеживаются, невозможно понять, почему цифра сегодня отличается от цифры месяц назад. Хранение моделей в системе контроля версий и автоматическое тестирование инвариантов — например, что выручка не становится отрицательной или что суммы по сегментам сходятся с общим итогом — превращают слой в управляемый продукт, а не в набор скриптов.
Наконец, в системах разговорной аналитики важно осознанно ограничивать свободу модели там, где цена ошибки высока. Финансовые показатели, показатели отчётности или юридически значимые метрики должны браться только из утверждённого списка и рассчитываться строго по заданной логике. Чем больше свободы у пользователя задавать произвольные вопросы, тем строже должны быть правила, ограничивающие интерпретацию.
Что в итоге
ИИ уже стал частью повседневной работы аналитика данных — прежде всего как инструмент ускорения и автоматизации. Разговорная аналитика открывает новые возможности для бизнеса, но не отменяет классические дашборды и отчёты. ИИ не меняет фундамент аналитики, но резко повышает требования к качеству данных, метрик и моделей.
А значит, роль аналитика смещается от «человека, который пишет запросы» к архитектору смыслов, определений и правил работы с данными. И именно в этом, а не в генерации SQL, сегодня заключается его основная ценность.
