Почему быстрый ответ может быть неправильным

Маркетинговое агентство Convert Human Digital Business из Бразилии столкнулось не с нехваткой графиков, а с разными ответами на один и тот же вопрос клиента. Данные о рекламе, продажах и CRM были доступны, но определения метрик, правила сегментации и привычные сокращения часто оставались в головах аналитиков. Если один сотрудник считал выручку после возвратов, а другой — до них, генеративная модель могла уверенно ускорить оба несовместимых ответа.

В опубликованном Google Cloud кейсе команда Convert рассказывает, что сначала пробовала агентов, которые напрямую задавали SQL-запросы и толковали результат. Простые вопросы они обрабатывали, но для сложных не хватало смысла бизнес-показателей. Это важное различие для любой компании, которая хочет «спрашивать базу данных по-русски»: доступ к таблице не равен знанию, что означает её колонка и какие исключения должны учитываться.

Что построила компания

Согласно описанию проекта, маркетинговые и транзакционные данные клиентов собраны в BigQuery. Над хранилищем работает семантический слой Looker/LookML: в нём документированы метрики, измерения, синонимы и правила отдельных клиентов. Затем пять специализированных агентов отвечают за разные области — эффективность медиа, темп расходования рекламного бюджета, поиск, креативы и электронную коммерцию. Это роли внутри одной аналитической системы, а не пять независимых источников истины.

Практический маршрут запроса выглядит так:

  • человек задаёт вопрос о кампании или продажах;
  • система определяет нужную предметную область и обращается к согласованному определению метрики;
  • запрос исполняется над разрешёнными данными нужного клиента;
  • ответ с источником и расчётом проверяет аналитик перед отправкой клиенту, если ошибка может повлиять на бюджет или отчётность.

Последний пункт — редакционный вывод о безопасном применении, а не утверждение, что Convert устроила именно такой этап согласования. В кейсе не описаны права доступа к каждому набору данных, процедура проверки спорных ответов и частота ошибок. Поэтому нельзя переносить его схему в собственную организацию без этих решений.

Что подтверждено, а что остаётся заявлением

Google Cloud приводит слова команды Convert: время подготовки отчётов сократилось на 65%, сложный анализ стал выполняться в 8,4 раза быстрее, операционные затраты снизились на 32%. Это показатели конкретной компании в публикации её технологического поставщика. Не раскрыты базовый период, объём задач, состав затрат, стоимость лицензий и способ независимой проверки. Называть эти проценты гарантированной экономией для российского агентства было бы неверно.

Сильнее сам механизм. Семантический слой задаёт правило расчёта один раз и делает его общим для BI и агентов. Независимые исследования задач «вопрос к базе — SQL», например BIRD, показывают, почему реальные значения и предметный контекст усложняют переход от фразы пользователя к корректному запросу. Но наличие словаря тоже не магия: неверно определённая метрика будет ошибаться последовательно. За определение выручки, лида или маржи должен отвечать владелец процесса, а не модель.

Что понадобится малому и среднему бизнесу

Не стоит начинать с пяти агентов и нового хранилища. Для первого пилота достаточно одной болезненной группы вопросов: например, еженедельный отчёт по рекламным расходам и подтверждённым заказам. Нужны доступные выгрузки из рекламного кабинета, CRM и учётной системы; единый ключ клиента или заказа; словарь из 10–20 показателей с формулой, периодом, валютой, исключениями и ответственным; а также контрольные примеры уже проверенных ответов.

Если компания уже пользуется BI и собственным SQL-хранилищем, семантические определения можно сначала закрепить там. Локальная языковая модель может разбирать вопрос и готовить черновик объяснения внутри своего контура, но её расположение не исправляет несовпадающие данные. RAG уместен для текстовых правил, регламентов и комментариев к показателям; числовой итог следует получать из проверяемого запроса, а не из найденного фрагмента текста. Агент с правом менять бюджет кампании — отдельный этап с ограничением полномочий и подтверждением человеком.

Как считать пользу без чужих процентов

Перед запуском возьмите 30–50 типичных вопросов за прошедший месяц и зафиксируйте текущие время подготовки, долю исправлений и стоимость проверки. Две недели сравнивайте ответы системы с согласованными аналитиком: правильны ли фильтры и периоды, совпадают ли суммы с отчётом, есть ли ссылка на источник. Засчитывайте только принятый без существенной переделки ответ.

В экономике учитывайте не только вызовы модели, но и подготовку данных, лицензии, хранение, поддержку словаря, время проверки и исправление ошибок. Единица сравнения — стоимость принятого ответа или готового отчёта, а не цена миллиона токенов. Если освобождённые часы нельзя направить на оплачиваемую или действительно нужную работу, это рост ёмкости команды, а не автоматически денежная экономия. Такой пилот даст свой ответ на вопрос об окупаемости без покупки всей архитектуры Convert.

Первоисточник: https://cloud.google.com/customers/convert-human-digital-business