Разговорная аналитика: создайте дата-агента в BigQuery

Если вы работаете в дата-команде, этот сценарий наверняка знаком: ваш бэклог разрывается от разовых запросов. Бизнес-пользователям постоянно нужны простые вариации существующих отчётов: «Можете сгруппировать это по категории продукта?» или «Как это соотносится с прошлым месяцем?» Пока они ждут ответа в очереди, ваши дата-инженеры и аналитики погребены под повторяющимися SQL‑задачами.

С Conversational Analytics в BigQuery вы наконец-то можете снять это узкое место. Эта функция приносит движок логического вывода на базе ИИ прямо в BigQuery Studio, позволяя пользователям задавать вопросы на естественном языке и мгновенно получать данные, диаграммы и сгенерированный SQL. 

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

Что такое разговорная аналитика?

Разговорная аналитика переводит взаимодействие с данными от ручных SQL‑запросов к диалогу на естественном языке. Вместо написания операторов SELECT вы общаетесь с дата-агентом, который понимает контекст вашего бизнеса и возвращает ответы, основанные на ваших реальных таблицах.

Это не просто базовый преобразователь текста в SQL; это серьёзный шаг к настоящей демократизации данных. 

Это позволяет нетехническим пользователям самостоятельно получать оперативные инсайты, а специалистам по данным — быстро исследовать датасеты и автоматизировать отчётность.

Как Gemini помогает дата-агентам

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

• Интерпретация намерения: Агент сопоставляет запрос с пользовательскими инструкциями, метаданными и бизнес-глоссариями. Это обеспечивает понимание терминов вроде «эффективность в III квартале», привязанных к конкретным финансовым календарям и KPI.

• Генерация SQL с привязкой к схеме: ИИ переводит естественный язык в оптимизированный SQL. Код явно сопоставляется со схемами BigQuery и проверяется внутренней логикой для обеспечения точности.

• Безопасное выполнение: Агент запускает сгенерированный запрос непосредственно в вашей среде BigQuery. Это сохраняет существующие протоколы безопасности и IAM. Агент видит только то, к чему у вас есть доступ.

• Синтез инсайтов: Агент преобразует «сырые» строки в понятное резюме. Он предоставляет исходные данные и динамические визуализации (например, диаграммы) и поддерживает «нить» разговора для последующих вопросов.

BigQuery vs Looker: как выбрать точку входа

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

Какой путь выбрать?

• Выбирайте BigQuery, если вам нужно создавать кастомные AI‑приложения или напрямую анализировать неструктурированные данные.
• Выбирайте Looker, если вашей организации необходимы единые метрики через LookML.
• Выбирайте Data Studio, если вы хотите дать нетехническим пользователям простой способ задавать запросы существующим BigQuery Data Agents.

Это руководство сосредоточено на BigQuery как самом быстром способе для дата-команд прототипировать и вводить агентов в прод прямо там, где находятся данные.

Как работают дата-агенты в BigQuery

Важно понять архитектуру дата-агента до его настройки. В среде Google Cloud дата-агент — это центральный слой абстракции. Он объединяет активы BigQuery с возможностями рассуждения семейства моделей Gemini.

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

Источники знаний

Источники знаний — базовый слой любого дата-агента. Они точно определяют, к каким данным агент может получать доступ и что запрашивать.

• Типы активов: Таблицы, представления (Views) и пользовательские функции (UDF) можно подключать как источники знаний.

• Масштабируемость: К одному агенту можно подключить несколько источников знаний. Это позволяет агрегировать информацию из разных бизнес-областей.

• Контроль доступа: Определение конкретных источников знаний гарантирует, что агент работает только в рамках разрешённых данных.

Инструкции агента и метаданные

Интеллект агента зависит от предоставленного контекста. Это ключ к тому, чтобы сделать общую модель понимающей язык компании. 

Определяя пользовательские инструкции, синонимы и бизнес-глоссарии, вы «заземляете» агента в конкретной предметной области. Например, можно обучить агента, что «Top Customers» — это пользователи с пожизненной ценностью (LTV) свыше $1 000.

Ключевые элементы привязки:

• Пользовательские инструкции: Давайте общие директивы, например: «Всегда исключайте внутренние тестовые аккаунты из отчётов по выручке».

• Бизнес-глоссарии: Сопоставляйте технические термины с естественным языком, например, store_id — «Локация филиала».

• Метаданные полей: Описания, помогающие агенту понимать нюансы конкретных переменных, например, «Валовая выручка» против «Чистой прибыли».

Чем лучше ваши инструкции и метаданные, тем выше точность агента. 

Проверенные запросы

Проверенные запросы (ранее Golden Queries) — это предопределённые пары «вопрос–ответ», служащие источником истины. Сопоставляя конкретные вопросы со SQL, проверенным экспертами, агент использует корректные пути объединения и фильтры для критичных KPI.

Эти запросы могут включать функции BigQuery ML (BQML). Это позволяет агенту обрабатывать продвинутые запросы, такие как генерация прогнозов оттока или продаж, с использованием точных параметров моделей, заданных дата-сайентистами. После проверки эти активы управляются через Dataplex Universal Catalog, что обеспечивает единообразие по всей организации.

Теперь, когда вы понимаете строительные блоки, перейдём к созданию и настройке вашего первого дата-агента.

Настройка Conversational Analytics в BigQuery

Чтобы следовать нашему туториалу, убедитесь, что у вас есть следующие предпосылки:

• Проект Google Cloud с включённым BigQuery и активной оплатой.
• Базовое знакомство с SQL (писать придётся немного, но вы будете просматривать сгенерированные запросы).
• Роль IAM Gemini Data Analytics Data Agent Owner (или эквивалентная Creator/Editor).

Прежде чем создавать первого агента, необходимо настроить ваш проект Google Cloud и убедиться, что у вашей учётной записи есть необходимые разрешения. Дата-агенты работают как слой поверх ваших существующих данных, поэтому корректная настройка IAM (Identity and Access Management) критична и для безопасности, и для работоспособности.

Действуйте так:

1. Откройте консоль Google Cloud и назначьте себе роль Gemini Data Analytics Data Agent Owner:
• Перейдите в IAM & Admin → IAM.
• Нажмите Grant Access.
• Добавьте свой email и назначьте роль Gemini Data Analytics Data Agent Owner. Эта роль даёт права создавать, редактировать, делиться и удалять всех дата-агентов в проекте.

2. Используйте боковую навигацию или строку поиска вверху страницы, чтобы перейти в BigQuery.

3. В левой навигации нажмите Agents.

4. Если функция ещё не включена, вы увидите заметный баннер или кнопку Enable the Data Analytics API with Gemini. Нажмите её, затем включите API Gemini in BigQuery и Gemini for Google Cloud.

После включения страница Agents станет полностью функциональной. Вы должны увидеть новую страницу агента:

Навигация по каталогу агентов

Agent Catalog используется для создания, управления и версионирования дата-агентов в BigQuery Studio.

В каталоге агентов вы найдёте:

• Предопределённый пример агента — готовый к использованию агент, автоматически создаваемый для каждого проекта. Доступен только для просмотра и отлично подходит, чтобы изучить, как выглядит готовый агент, прежде чем вы создадите свой.
• My draft agents — агенты, которые вы начали, но ещё не опубликовали (идеально для экспериментов).
• My agents — агенты, которые вы создали и опубликовали.
• Shared by others — агенты, опубликованные коллегами в вашей организации (если они поделились ими с вами).

Жизненный цикл агента следует структуре (Draft → Created → Published):

• Draft — вы можете редактировать инструкции, добавлять источники знаний, тестировать запросы в панели живого предпросмотра и итеративно дорабатывать, не затрагивая других.
• Created — сохранённая версия, которая всё ещё приватна.
• Published — в проде, доступна всем с корректными ролями IAM. Опубликованные агенты можно использовать напрямую в BigQuery Studio, Data Studio Pro или через Conversational Analytics API.

Нажмите любую карточку агента, чтобы открыть её, просмотреть детали, начать диалог или отредактировать (если у вас есть права Owner). В интерфейсе также есть вкладка Conversations, где вы можете управлять прошлыми чатами с агентами или источниками данных.

Создание и настройка дата-агента в BigQuery

Теперь, когда фундамент заложен, создадим дата-агента с нуля. Мы используем датасет bigquery-public-data.austin_bikeshare, чтобы превратить «сырые» данные о поездках в разговорный интерфейс. Нам понадобятся две таблицы:

• bikeshare_trips — детализированные данные на уровне поездок

• bikeshare_stations — метаданные станций

Начало создания агента

1. Убедитесь, что вы на вкладке Agent Catalog.
2. Нажмите кнопку Create agent. Откроется страница нового агента с панелью редактора слева и живым предпросмотром справа.
3. В разделе Editor сначала заполните базовые поля (имя агента и описание).

Эти два поля помогут вам быстро находить агента позже. После их заполнения переходите к настройке трёх основных блоков, о которых мы говорили ранее: источников знаний, инструкций и (позже) проверенных запросов. 

Выбор источников знаний

Источники знаний определяют, к каким данным агент имеет доступ. Чем их меньше и чем они фокусированнее, тем выше точность и ниже стоимость. В разделе Knowledge sources редактора нажмите Add source. Найдите austin_bikeshare и выберите bikeshare_trips и bikeshare_stations как источники.

Для каждой добавленной таблицы нажмите Customize. 

Gemini автоматически сгенерирует описание и предложит метаданные столбцов. Проверьте всё, примите корректные предложения, внесите правки и нажмите Update.

Распространённая ошибка — добавить сразу 50 таблиц. Начните с 2–3 ключевых. Так проще отладить логику агента. Позже вы всегда сможете расширить знания, когда ядро запросов станет точным.

Как написать эффективные инструкции агенту

Далее нужно «заземлить» агента инструкциями. Вместо общего текстового промпта (например, «Отвечай на вопросы о продажах») интерфейс дата-агента BigQuery позволяет задать строго структурированный контекст, направляющий генерацию запросов ИИ. Думайте об этом как об онбординге нового аналитика с вашим точным дата-словарём.

Используйте поле Instructions, чтобы дать структурированный бизнес-контекст. Вот полный, готовый пример, который можно вставить:

• Синонимы: Определите альтернативные термины для ваших столбцов, чтобы агент понимал вариации естественного языка. Пример: «Journey», «Ride» и «Commute» — это запись в таблице bikeshare_trips. «Dock», «Hub» или «Station» — запись в таблице bikeshare_stations.

• Ключевые поля: Выделите наиболее важные поля для анализа. Это подскажет агенту, каким столбцам отдавать приоритет, когда вопрос пользователя общий. Пример: для общего репортинга приоритезируйте trip_id, start_station_name, end_station_name, subscriber_type, start_time и duration_minutes.

• Исключаемые поля: Укажите столбцы, которые агент должен строго избегать. Это крайне полезно для сокрытия устаревших столбцов или нерелевантных данных. Пример: не используйте столбец bike_id в таблице bikeshare_trips для большинства анализов, так как он редко нужен для бизнес-вопросов.

• Фильтрация и группировка: Дайте агенту инструкции о стандартных способах срезать данные. Пример: если не указано иное, всегда исключайте поездки, где duration_minutes < 1 (это ложные старты или тестовые поездки). По умолчанию группируйте данные по start_station_name, когда пользователь просит «по станциям» или «топ станций».

• Связи для объединения: Поскольку наш агент берёт данные из нескольких таблиц, явно определите, как они соединяются. Это не даст агенту угадать неправильные внешние ключи. Пример: соединяйте таблицу bikeshare_trips с таблицей bikeshare_stations, сопоставляя bikeshare_trips.start_station_id с bikeshare_stations.station_id (и аналогично для end_station_id).

Всё вышеперечисленное можно объединить в один аккуратный блок в поле Instructions. Вот отточенная, готовая к вставке версия со структурированными указаниями:

You are a senior transportation analyst for the Austin Bikeshare program.
Core rules and defaults:
- Always filter on start_time unless the user specifies a different time field.
- Default time range for any "trend", "recent", "last month", or similar = last 30 days.
- "Top stations" means stations with the highest ridership (highest number of trips started).
- Exclude false start rides/test rides: never include trips where duration_minutes < 1.
- Display station names in final results; use station_id only for joins.
- Prefer clear, readable visualizations: bar charts for rankings, line charts for time-based trends.
Key fields: Prioritize trip_id, start_station_name, end_station_name, subscriber_type, start_time, and duration_minutes for most analyses.
Join relationships: Join bikeshare_trips to bikeshare_stations on bikeshare_trips.start_station_id = bikeshare_stations.station_id (and similarly for end_station_id).
Persona framework (very effective): Begin your instructions with a clear persona statement. This sets the tone, depth of analysis, and output style (e.g., “You are a senior transportation analyst…”).

Почему это важно: Если оставить эти поля пустыми, неоднозначный вопрос вроде «Какие были наши топовые продажи?» может привести к тому, что агент соединит неверные таблицы, возьмёт данные из неактивных аккаунтов или включит устаревшие данные. Структурируя инструкции по этим пяти категориям, вы гарантируете, что сгенерированный SQL строго следует вашей устоявшейся бизнес-логике.

Определение терминов глоссария

Помимо инструкций, вы можете (и должны) определять термины глоссария прямо в агенте. Они помогают агенту последовательно интерпретировать бизнес-жаргон, аббревиатуры и производные понятия.

Нажмите Add term в разделе Glossary (обычно рядом с Instructions) и создайте термины: термин, определение и синонимы (через запятую).

Рекомендуемые термины глоссария для датасета Austin Bikeshare:

Вы можете добавлять и другие термины по мере необходимости (например, для start_station_name, end_station_name или производных метрик вроде «средней длительности поездки» или «длинной поездки»).

Благодаря глоссариям, если руководство решит со следующего квартала изменить официальное определение «Длинной поездки» на 45 минут, вашей команде по управлению данными нужно будет обновить это только один раз в Dataplex. Каждый дата-агент, подключённый к этому глоссарию, сразу примет новую логику, сохраняя консистентность по всей организации.

Тестирование агента запросами на естественном языке

После настройки источников знаний, инструкций и терминов глоссария пора протестировать агента до публикации.

Прокрутите вправо к панели Preview. Этот интерфейс живого чата позволяет взаимодействовать с агентом в реальном времени по мере его создания. Вы можете задавать вопросы, просматривать рассуждения агента, проверять сгенерированный SQL и быстро итератировать.

Панель Preview показывает:

• Имя и описание агента вверху
• Поле ввода в стиле чата внизу («Задайте вопрос»)
• Ответы в реальном времени с рассуждениями, SQL, результатами и визуализациями

Попробуйте эти четыре запроса с нарастающей сложностью (адаптируйте к диапазону данных датасета до 2024 года):

1. Простой поиск: Сколько поездок началось в июне 2024 года?
2. Агрегация с фильтром: Какие 5 станций были лидерами по числу поездок в последнем квартале 2024 года?
3. Многошаговый анализ: Сравните среднюю длительность поездки в будни и выходные в 2024 году.
4. Уточняющий вопрос (проверка «памяти»): Теперь покажите то же сравнение, но только для станции Zilker Park.

Что вы увидите в ответе агента:

• Summary — объяснение результатов на естественном языке.

• Query result — аккуратная таблица с данными (например, общее число поездок, топ станций или средняя длительность).

• Insights — маркированные выводы, интерпретирующие результаты в бизнес-контексте.

• Generated SQL — нажмите Open in Editor, чтобы посмотреть полный SQL‑запрос, созданный агентом (вы увидите корректную фильтрацию по start_time и применение duration_minutes >= 1 для исключения ложных стартов).

• Suggested follow-up questions — полезные подсказки внизу (например, «Какие 10 стартовых станций были топовыми в июне 2024?» или «Спрогнозируй дневное число поездок…» и т. п.).

• Visualization — автоматически сгенерированная диаграмма (столбчатая для рейтингов, как в примере с топ‑5 станций).

Память в диалоге на практике

Ваш четвёртый запрос («Теперь покажите то же сравнение, но только для станции Zilker Park») демонстрирует умение агента сохранять контекст предыдущего вопроса. 

Как видно на следующем скриншоте, он корректно сужает сравнение длительности в будни/выходные до Zilker Park без повторения полного запроса.

Советы по тестированию:

• Используйте точные бизнес-термины, определённые в инструкциях и глоссарии (например, «ridership», «false start»).
• Внимательно следите за тем, как агент обрабатывает фильтрацию по датам и исключения — именно здесь хорошие инструкции особенно важны.
• Если ответ неточен, уточните инструкции или глоссарий, сохраните и протестируйте снова.
• Регулярно просматривайте сгенерированный SQL — это один из лучших способов отладки и повышения точности агента.

Когда агент стабильно даёт чёткие, точные и хорошо структурированные ответы, нажмите Save вверху, затем Publish. Ваш агент Austin Bikeshare Analyst готов к использованию!

Повышение точности с помощью проверенных запросов

Даже при хороших инструкциях и глоссариях ваш агент может время от времени неверно трактовать бизнес-правила или давать непоследовательные ответы.

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

Они служат высококачественными примерами, закрепляющими логику агента, и являются одним из самых эффективных способов перейти от «в целом неплохо» к продакшен-уровню.

Создание вашего первого проверенного запроса

В редакторе агента прокрутите до раздела Verified Queries. Есть два простых способа добавить проверенные запросы:

Вариант 1: создать вручную

Нажмите Add query. Вы увидите экран Add verified query, где можно:

• Ввести вопрос на естественном языке
• Написать или вставить корректный SQL в редакторе
• Нажать Run для теста
• Нажать Add для сохранения

Вариант 2: использовать предложения Gemini (рекомендуется для быстрого старта)

Нажмите View Gemini-generated suggestions. Откроется экран «Review suggested verified queries», где Gemini предложит релевантные вопросы на основе ваших источников знаний.

Вы можете:

• Просмотреть предложенные вопросы
• Проверить связанные таблицы
• Выбрать понравившиеся
• Отредактировать вопрос или SQL при необходимости (очень рекомендуется — некоторые предложения могут использовать устаревшие даты или логику)
• Нажать Add, чтобы добавить их агенту

Хороший проверенный запрос для датасета Austin Bikeshare может быть таким:

Вопрос:

What were the top 5 stations by ridership in Q2 2024?

SQL:

WITH
 QuarterlyRidership AS (
   -- Count trips starting at each station
   SELECT start_station_id AS station_id, COUNT(trip_id) AS ridership_count
   FROM bigquery-public-data.austin_bikeshare.bikeshare_trips
   WHERE TIMESTAMP_TRUNC(start_time, QUARTER) = TIMESTAMP '2024-04-01 00:00:00'
   GROUP BY start_station_id
   UNION ALL
   -- Count trips ending at each station
   SELECT
     CAST(end_station_id AS INT64) AS station_id,
     COUNT(trip_id) AS ridership_count
   FROM bigquery-public-data.austin_bikeshare.bikeshare_trips
   WHERE
     TIMESTAMP_TRUNC(start_time, QUARTER) = TIMESTAMP '2024-04-01 00:00:00'
     AND end_station_id IS NOT NULL
   GROUP BY CAST(end_station_id AS INT64)
 )
SELECT stations.name AS station_name, SUM(qr.ridership_count) AS total_ridership
FROM QuarterlyRidership AS qr
INNER JOIN
 bigquery-public-data.austin_bikeshare.bikeshare_stations AS stations
 ON qr.station_id = stations.station_id
GROUP BY stations.name
ORDER BY SUM(qr.ridership_count) DESC
LIMIT 5;

Итерации для повышения точности агента

Даже если агент дал разумный ответ с первой попытки, вы можете заметно повысить его точность и стабильность, проверяя сгенерированный SQL и добавляя проверенные запросы.

Следуйте практичному рабочему процессу:

1. Задайте вопрос в панели Preview.
2. Просмотрите сгенерированный SQL (нажмите на блок SQL, затем Open in Editor, чтобы увидеть полный запрос).
3. Определите, где агент ошибся или где логику можно улучшить.
4. Исправьте, добавив проверенный запрос (или уточнив инструкции).
5. Повторно протестируйте тот же вопрос и оцените улучшение.

Допустим, вы спросили: «Какова была средняя длительность поездки в июне 2024?» В изначальном ответе агент вернул 26,68 минуты и корректно исключил поездки короче 1 минуты. Теперь предположим, что стандартное бизнес-правило команды — исключать любые поездки короче 5 минут.

Когда вы открываете сгенерированный SQL (через Open in Editor), видите, что фильтр — только duration_minutes >= 1.

Исправление: добавьте проверенный запрос

Нажмите Add query в разделе Verified Queries и создайте следующую запись:

Вопрос: 

What was the average trip duration in June 2024?

SQL:

SELECT 
  ROUND(AVG(duration_minutes), 2) AS avg_trip_duration_minutes
FROM 
  bigquery-public-data.austin_bikeshare.bikeshare_trips
WHERE 
  start_time BETWEEN '2024-06-01' AND '2024-06-30'
  AND duration_minutes >= 5;     -- stricter rule: exclude trips under 5 minutes

После сохранения проверенного запроса снова задайте тот же вопрос в панели Preview. Теперь агент стабильно возвращает ~32,08 минуты и применяет более жёсткий порог в 5 минут. Результаты лучше согласуются с вашим бизнес-пониманием «содержательных» поездок.

Продвинутые возможности Conversational Analytics в BigQuery

Разговорная аналитика BigQuery выделяется среди простых инструментов «текст в SQL» за счёт нативной поддержки функций BigQuery ML, неструктурированных данных и простого шаринга по экосистеме Google Cloud.

Машинное обучение

Одно из ключевых отличий — способность агента вызывать функции BigQuery ML напрямую из естественного языка, переходя от ретроспективной отчётности к прогнозной аналитике.

Предиктивная аналитика

Например, вы можете попросить агента спрогнозировать дневное число поездок на следующие 30 дней на основе трендов 2024 года. Он вызовет AI.FORECAST и построит прогноз на июль 2024 года вместе с наглядной диаграммой, показывающей исторические дневные поездки (синяя линия) и 30‑дневный прогноз (оранжевая линия) с заштрихованным 95% доверительным интервалом.

Обнаружение аномалий

Ещё один полезный сценарий применения алгоритмов — выявление сбоев в данных. Если, например, вы попросите агента найти аномалии в дневном количестве поездок в июне 2024 года, он вызовет AI.DETECT_ANOMALIES, сравнит июнь 2024 с предыдущими месяцами и вернёт таблицу временного ряда плюс линейную диаграмму. 

В данном случае формальных аномалий на уровне доверия 95% не обнаружено, но 19 июня отмечен как «почти аномалия» (вероятность 92,1%) с заметным падением числа поездок.

Запросы к неструктурированным данным

Большинство разговорных BI‑инструментов «ломаются», как только данные выходят за рамки строк и столбцов. BigQuery поддерживает Object Tables, что позволяет анализировать неструктурированные данные (PDF, изображения, «сырые» текстовые логи) в Google Cloud Storage.

Поскольку дата-агент работает на мультимодальных возможностях Gemini, он может рассуждать одновременно по вашим структурированным метрикам и неструктурированным файлам. Это серьёзное и уникальное преимущество BigQuery.

Если у вас есть PDF‑опросы райдеров или изображения инспекций станций в объектной таблице, просто спросите: «Суммируйте основные жалобы из PDF‑опросов райдеров за II квартал 2024 года». Агент прочитает неструктурированные файлы и объединит информацию с вашими структурированными данными о поездках

Общий доступ к агентам через Data Studio Pro и Conversational Analytics API

Ваша дата-команда создаёт и тестирует дата-агентов в BigQuery Studio, но конечные пользователи работают в других приложениях. Google позволяет легко «отвязать» агента от консоли GCP, чтобы вы могли прийти к бизнес-пользователям там, где они уже работают.

• Data Studio Pro: Вы можете легко вывести опубликованных дата-агентов BigQuery прямо в Data Studio Pro. Это позволяет нетехническим стейкхолдерам общаться с тем же управляемым агентом рядом с привычными BI‑дашбордами.
• Conversational Analytics API & ADK: Если вы хотите встроить агента в кастомное веб-приложение, внутреннего бота в Slack или клиентский портал, разработчики могут использовать Conversational Analytics API и Agent Development Kit (ADK). Это позволяет строить высококастомизированные, «состояниесохраняющие» чат‑опыты на базе ваших данных BigQuery.

Если вы хотите попробовать создать кастомное чат‑приложение самостоятельно, вы также можете прочитать больше в официальном руководстве Introduction to Conversational Analytics in BigQuery.

Заключение

Если вынести один главный принцип, то вот он: разговорная аналитика снимает аналитическое узкое место — вместо ожидания дата-команды достаточно просто задать правильный вопрос.

Это «расширение прав и возможностей» не означает, что дата-команды больше не нужны, но их роль меняется. Агент ИИ настолько умён, насколько надёжны ограждения, которые вы вокруг него построили. Точность и безопасность ваших дата-агентов полностью зависят от инструкций, контекста и архитектуры схем, которые вы предоставляете.

Чтобы создать максимально эффективных разговорных агентов, всё ещё нужна сильная экспертиза в базовом дата-warehouse. Если вы или ваша команда хотите прокачать эти ядровые навыки и освоить платформу, на которой работают эти AI‑функции, загляните на курс DataCamp Introduction to BigQuery уже сегодня!