Як налаштувати Conversational Analytics у BigQuery: створення та тестування власного data-агента

Екосистема хмарної аналітики змінюється дуже стрімко. Ще декілька місяців тому ми обговорювали, як подружити Claude чи ChatGPT із BigQuery через MCP (Model Context Protocol), а вже сьогодні Google має офіційне рішення безпосередньо в інтерфейсі BigQuery — Conversational Analytics.

Якщо ви завітаєте у свій хмарний кабінет BigQuery Studio, то в лівій панелі помітите новий розділ — Agents.

Саме тут на вас чекає ШІ-агент на базі Gemini, який глибоко інтегрується у ваші датасети, розуміє бізнес-контекст компанії та вміє писати валідні SQL-запити на основі вашої внутрішньої логіки.

І саме для того, щоб ви змогли скористатися цією можливістю, я й підготував цей матеріал. Сьогодні ми детально розберемо:

• Що таке Conversational Analytics та в чому особливість агентів;
• Архітектура data-агентів;
• Покрокове налаштування кастомного агента під ваш бізнес;
  • Крок 1. Надайте необхідні доступи та ролі;
  • Крок 2. Створіть агента та підключіть Knowledge sources;
  • Крок 3. Перевірте описи таблиць і полів усередині агента;
  • Крок 4. Додайте Instructions;
  • Крок 5. Додайте Verified queries;
  • Крок 6. Створіть глосарій у Manage terms;
  • Крок 7. Виберіть модель і встановіть Maximum bytes billed;
  • Крок 8. Протестуйте агента;
  • Крок 9. Опублікуйте агента та надайте доступ команді;
• Використання BigQuery ML та даних із Google Cloud Storage у Conversational Analytics
• Що ще вам потрібно знати про Conversational Analytics
  • Інтеграція з Data Studio (Looker Studio)
  • Безпека даних та моніторинг (Jobs Explorer)
• Висновок.

Що таке Conversational Analytics та в чому особливість дата-агентів

Якщо коротко, то Conversational Analytics — це повноцінний чат із вашими даними. Ви ставите запитання звичайною людською мовою (наприклад: «Які товари найкраще продавалися за останні 10 днів?» або «Який середній чек у нових клієнтів?»), а система повертає відповідь.

Залежно від запитання відповідь може містити:

• текстове пояснення;
• таблицю;
• SQL-запит;
• візуалізацію (графіки, діаграми);
• висновки;
• пропозиції щодо подальшого аналізу (Follow-up questions).

Conversational Analytics працює на моделях Gemini. Однак основна цінність рішення не просто в тому, що Google додав ще один AI-чат. Значно важливіше те, як цей чат підключається до даних і отримує контекст вашого бізнесу.

Коли ви намагаєтеся подружити сторонній ШІ з BigQuery напряму, ви фактично будуєте власний велосипед. Вам потрібно самостійно налаштовувати Python-середовище, вручну передавати бізнес-контекст, формувати CLAUDE.md чи подібні файли з деталями проєкту, пояснювати йому в інструкціях основні бізнес-показники і їхні формули і т. д. Натомість Google створив готовий інструмент усередині GCP, заточений саме під аналітику, і веде вас за руку, допомагаючи все одразу зробити правильно. На виході така система працює як ваш колега-аналітик, з яким ви можете спілкуватися однією мовою.

Наприклад, я ставлю просте запитання: «Що таке новий клієнт?»

І агент не просто дав загальне визначення цього поняття. Він звернувся до глосарію та пояснив, що новий клієнт — це покупець, який здійснив своє перше замовлення в магазині.

Більше того, агент сам пов’язав цей бізнес-термін зі структурою даних і вказав, що таких клієнтів можна визначити за допомогою поля is_new_client у таблиці orders_t:

• якщо is_new_client = 1, замовлення належить новому клієнту;
• якщо is_new_client = 0, це повторна покупка наявного клієнта.

Тут добре видно різницю між звичайним AI-чатом і data-агентом. Вам не потрібно знати назву таблиці, шукати потрібне поле або формулювати запитання технічною мовою. Можна використати звичний бізнес-термін, а агент сам пов’яже його з вашими даними.

І повне розуміння бізнес-контексту — не єдина перевага data-агента порівняно зі звичайним чатом з LLM. Створеним агентом можна в один клік поділитися з колегами, просто надавши доступ на email. І, звісно, не потрібно передавати ніякі конфігураційні файли між комп’ютерами. Ну, але про все по порядку.

Архітектура data-агентів

Звісно, детальне розуміння бізнес-контексту агентом не виникає саме по собі. Воно залежить від того, наскільки якісно ви його налаштували.

У попередньому прикладі ми поставили просте запитання: «Що таке новий клієнт?». Агент не лише навів визначення терміна, а й сам пов’язав його з таблицею orders_t та відповідним полем у базі даних.

Таке розуміння формується завдяки налаштуванням агента, у яких поєднуються чотири основні складові:

• Knowledge sources — джерела даних, доступні агенту;
• Instructions — правила роботи з таблицями та бізнес-логікою;
• Verified queries — перевірені SQL-запити;
• Manage terms — бізнес-терміни та їх визначення.

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

Покрокове налаштування кастомного агента під ваш бізнес

Тепер пройдемо повний шлях створення власного data-агента з нуля.

Крок 1. Необхідні доступи та ролі

Якщо ви працюєте у власному тестовому проєкті та маєте широкі права на рівні Owner або Editor, найімовірніше, окремо налаштовувати більшість дозволів не доведеться, і ви можете пропустити цей пункт та одразу перейти до створення агента й підключення Knowledge Sources.

У корпоративному проєкті все може бути складніше, тому краще одразу перевірити наявність точних IAM-ролей:

• Gemini Data Analytics Data Agent Creator — для створення нового агента. Користувач, який створив агента, автоматично отримує для нього роль Data Agent Owner;
• Gemini Data Analytics Data Agent Owner — для редагування, поширення та видалення агента;
• Data Catalog Viewer — для додавання джерел знань;
• BigQuery Data Viewer — для доступу до таблиць, наборів даних або представлень, які використовує агент;
• BigQuery Job User — для виконання SQL-запитів від імені користувача.

Для колег, які мають лише спілкуватися з готовим агентом, достатньо ролі Gemini Data Analytics Data Agent User. Ролі Data Agent Editor і Data Agent Viewer відповідно дають право редагувати або лише переглядати його налаштування. Окремо зверніть увагу на роль Stateless Chat User (Gemini Data Analytics Stateless Chat User) — вона потрібна не лише для прямого чату з даними без збереженого агента, а й для створення та редагування самого агента, тож не пропускайте її під час надання доступів.

Крок 2. Створення агента та підключення Knowledge Sources

1. Зайдіть у BigQuery Studio → розділ Agents → натисніть Create agent.

2. Спочатку вкажіть назву та опис. Тут усе досить просто: назва потрібна, щоб користувачі могли швидко знайти потрібного агента, а опис — щоб зрозуміти, з якими даними він працює та для яких завдань його варто використовувати.

3. У блоці Knowledge sources натисніть Add та вкажіть заздалегідь підготовлені вітрини даних.

Knowledge sources, або джерела знань, визначають, до яких даних агент може звертатися під час підготовки відповіді. Це можуть бути:

• таблиці BigQuery;
• представлення;
• користувацькі функції;
• інші підтримувані ресурси.

У нашому простому сценарії ми підключаємо дві основні сутності:

• таблицю замовлень із CRM, яка містить статус угоди, дату створення, суму та ідентифікатор клієнта;
• таблиці маркетингових витрат із рекламних кабінетів.

Крок 3. Перевірте описи таблиць і полів усередині агента

Після додавання джерела натисніть Customize біля потрібної таблиці. Система запропонує:

• опис самої таблиці;
• описи її полів;
• пояснення того, як Gemini розуміє структуру даних.

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

Обов’язково уважно продокументуйте кожну колонку, яка:

• використовується для поєднання таблиць;
• визначає статуси;
• містить дати;
• бере участь у розрахунках;
• має неоднозначні назви.

Крок 4. Створіть інструкції

У блоці Instructions описується бізнес-логіка, яку агент не може однозначно визначити зі схеми таблиць. Наприклад, в агенті можна додати правило:

«Якщо в запитанні не зазначено інше, враховуй лише успішні замовлення зі статусом success».

Після збереження цієї інструкції агент застосовуватиме відповідний фільтр, навіть якщо користувач не повторює його в кожному запитанні.

У Instructions варто фіксувати:

• стандартні фільтри;
• правила роботи з датами;
• нестандартні формули;
• внутрішні винятки;
• важливі обмеження;
• бізнес-логіку, яку неможливо зрозуміти лише з назви поля.

Наприклад, у PROANALYTICS.ACADEMY історично залишилася колонка, яка мала показувати, чи отримав студент сертифікат із відзнакою. Але зараз команда вже не використовує це поле. За актуальним правилом сертифікат вважається сертифікатом із відзнакою, якщо студент набрав щонайменше 90% балів.

Тому в інструкції агенту потрібно прямо пояснити:

«Для визначення сертифіката з відзнакою використовуй поле з підсумковою оцінкою. Якщо оцінка становить 90% або більше, сертифікат вважається сертифікатом із відзнакою. Не використовуй застаріле поле статусу сертифіката».

Самостійно агент цього не зрозуміє. Навпаки, стара колонка з відповідною назвою може здатися йому найбільш очевидним варіантом. Саме для таких історичних змін, винятків і внутрішніх домовленостей інструкції й потрібні найбільше.

Інструкції не обов’язково писати всі одразу. Якщо ви створюєте агента для себе, можна поступово доповнювати їх після кожного тесту. Якщо агент призначений для клієнта або окремого відділу, я рекомендую спочатку провести коротке інтерв’ю із замовниками: з’ясувати, які запитання вони ставитимуть найчастіше та які внутрішні нюанси потрібно враховувати.

Порада щодо мови: інструкції, глосарій та перевірені запити рекомендується прописувати тією ж мовою, якою користувачі будуть спілкуватися з чатом.

Крок 5. Додайте Verified queries (Перевірені запити)

Verified queries — верифіковані, або «золоті», запити. Це SQL-запити, які вже перевірив аналітик і визнав правильними. Вони показують агенту:

• які таблиці використовувати під час відповіді на певне питання;
• як їх (таблиці) поєднувати між собою;
• які фільтри застосовувати і коли;
• як рахувати метрики;
• яку структуру має правильна відповідь.

Якщо запитання користувача відповідає одному з перевірених запитів, агент може виконати його без змін. Якщо повного збігу немає, SQL із Verified queries усе одно використовується як орієнтир для побудови нового запиту.

Якщо ви вже будуєте звіти в Power BI, Data Studio, Tableau чи іншій системі, найкраще почати із запитів, які використовуються у вашому чинному репортингу. Вони вже перевірені, працюють на реальних даних і містять правильну логіку розрахунків.

Натисніть Add query, сформулюйте запитання, на яке відповідає SQL, вставте сам запит і виконайте його через Run and verify. Додавати запит до агента варто лише після того, як ви переконалися, що він повертає очікуваний результат.

Якщо готових SQL-запитів немає, можна натиснути Review suggestions або попросити Gemini згенерувати запит. Але автоматично створений SQL усе одно потрібно перевірити перед збереженням.

Крок 6. Створіть глосарій (Manage terms)

У блоці Glossary натисніть Add term, а потім Create term. Для кожного поняття потрібно вказати:

• назву терміна;
• точне визначення;
• за потреби — синоніми.

Наприклад:

Термін: Успішне замовлення

Визначення: Замовлення, у якому поле status дорівнює success.

Синоніми: продаж, завершене замовлення.

Крок 7. Виберіть модель для агента і встановіть Maximum bytes billed (Запобіжник бюджету)

У блоці Settings можна вибрати моделі Gemini, доступні користувачам агента. На старті я б не витрачав багато часу на цей пункт: спочатку значно важливіше правильно підготувати дані, описи, інструкції та перевірені запити.

За потреби також можна додати Labels для внутрішньої організації ресурсів.

А от поле Maximum bytes billed я рекомендую не пропускати. Коли агент відповідає на запитання, він створює та виконує SQL-запит у BigQuery. Відповідно, для отримання відповіді може бути оброблений певний обсяг даних.

Через Maximum bytes billed ви встановлюєте максимальний обсяг даних, який дозволено обробити для одного запиту. Наприклад, можна обмежити одну відповідь одним або десятьма гігабайтами — залежно від розміру ваших таблиць.

Для малого або середнього проєкту навіть 1 GB на один запит може бути достатньо. Для великого бізнесу значення може становити 10 GB або кілька десятків гігабайтів. Тут немає універсальної цифри — усе залежить від ваших даних і типових запитань.

Для орієнтиру: BigQuery за стандартним тарифом коштує $6,25 за оброблений тебібайт (TiB) даних, а перший тебібайт (TiB) щомісяця — безкоштовний. Тобто ліміт у 1 GB на одну відповідь агента — це приблизно 0,006 долара (трохи більше пів цента) за повідомлення; і при цьому перша тисяча таких запитів на місяць вкладається в безкоштовний ліміт BigQuery.

Інтерфейс очікує значення в байтах. Мінімально дозволене значення — 10485760, тобто 10 MB; менше поставити не вийде — система поверне помилку. Якщо очікуваний обсяг перевищує встановлений ліміт, запит не виконується та не створює витрат. Якщо ж поле залишити порожнім, ліміт за замовчуванням підтягується з денної квоти проєкту на запити — тобто обмеження все одно існує, просто ви його не контролюєте напряму. Тому краще виставляти значення свідомо.

Крок 8. Протестуйте агента

Перед публікацією поставте кілька контрольних запитань, відповіді на які ви вже знаєте. Наприклад:

• Скільки було успішних замовлень?
• Яке джерело привело найбільше продажів?
• Яка кампанія принесла найбільший дохід?
• Що означає «успішне замовлення»?
• За яким полем поєднуються CRM і сесії Google Analytics?

Перевіряйте не лише фінальну відповідь, а й:

• використані таблиці;
• поля для JOIN;
• фільтри;
• формули;
• дати;
• згенерований SQL.

Якщо результат неправильний, це не означає, що тест провалено. Подумайте, якої саме інформації агенту не вистачило. Можливо, потрібно уточнити опис поля, додати правило в інструкції, створити термін або зберегти ще один перевірений запит.

Крок 9. Опублікуйте агента та надайте доступ команді

Коли базове тестування завершено, натисніть Save, а потім Publish.

Якщо ви лише зберегли агента й повернулися до каталогу, він залишиться в розділі My draft agents. Після публікації агент стане доступним для повноцінних розмов у BigQuery Studio.

За потреби натисніть Share, додайте електронні адреси користувачів і виберіть роль:

• Data Agent User — може спілкуватися з агентом;
• Data Agent Editor — може редагувати його;
• Data Agent Viewer — може переглядати конфігурацію.

Не забувайте, що кожен користувач також повинен мати доступ до таблиць, які використовує агент, і право виконувати запити в BigQuery.

На цьому базове налаштування завершено. Як бачите, першу MVP-версію агента справді можна зібрати досить швидко. Вона не буде ідеальною з першої спроби — і це нормально.

Далі логіка проста: тестуєте, знаходите слабке місце, уточнюєте опис або бізнес-правило, додаєте термін чи перевірений запит і перевіряєте ще раз. Саме так агент поступово перетворюється з простого чату біля таблиць на інструмент, який справді розуміє логіку вашого бізнесу.

Сприймайте процес доналаштування такого чату як онбординг нового колеги до вашої команди — він теж не відбувається за один день.

Використання BigQuery ML та даних із Google Cloud Storage у Conversational Analytics

Data-агенти у BigQuery виходять далеко за межі базових запитів. Наприклад, вони підтримують BigQuery ML.

Ви можете використовувати алгоритми машинного навчання прямо в чаті:

• Пошук аномалій (AI.DETECT_ANOMALIES): «Знайдіть викиди в кількості замовлень на день за 2026 рік, використовуючи 2025 рік як базовий показник».
• Прогнозування (AI.FORECAST): «Спрогнозуйте кількість замовлень на наступний місяць».
• Генерація висновків (AI.GENERATE): «Підсумуйте основний вміст текстового поля в 1–2 реченнях».

Більше того, завдяки зв’язці BigQuery із Google Cloud Storage агент може аналізувати навіть текстові PDF-документи, посилаючись на зовнішні таблиці.

Що ще вам потрібно знати про Conversational Analytics

Інтеграція з Data Studio (Looker Studio)

Вам не потрібно давати всім маркетологам чи керівникам доступ до технічної консолі BigQuery у GCP і знайомити їх із цим інтерфейсом. Налаштованого агента можна відкрити за посиланням у Data Studio. Користувачі отримують зручний чат поруч із дашбордами.

Зробити це максимально просто: коли будете копіювати посилання колегам, оберіть варіант із Data Studio.

Безпека даних та моніторинг (Jobs Explorer)

На роботу агента повністю поширюються ваші корпоративні налаштування Google Workspace / GCP. У корпоративних пакетах ваші дані не використовуються для навчання публічних моделей Gemini.

Для моніторингу витрат та дебагу всі запити агента в системному журналі Jobs Explorer позначаються спеціальною міткою:

ca-bq-job: true

Висновок

Conversational Analytics у BigQuery — дійсно класний інструмент, і я однозначно рекомендую вам його протестувати, допоки є можливість не платити за токени: зібрати MVP-агента можна за годину-дві, а результат уже на старті економить купу часу на рутинних питаннях до даних.

При цьому, звісно, не забувайте про одне важливе правило: AI не виправляє погані дані. Він лише робить результат швидшим і автономнішим — але якщо на вході брудні, неструктуровані чи погано описані таблиці, на виході ви отримаєте ту саму неякісну відповідь, тільки красиво оформлену і з упевненим тоном.