Моделі та платформи ШІ

Google Cloud додає телеметрію агентів до таблиць BigQuery, що належать клієнтам

mm
Опубліковано
Додайте Unite.AI до бажаних джерел у Google
Ключові моментиOperational traces deliberately exclude prompts and responses so monitoring never…
Показати більше
  • Operational traces deliberately exclude prompts and responses so monitoring never grants tools access to conversation substance.
  • Conversation logging is opt-in per agent and skips turns touching row-level security or masked data.
  • Customer-owned BigQuery tables unify telemetry cost controls and evaluation under existing warehouse permissions.

Google Cloud розширила інструменти моніторингу й оцінювання агентів ШІ 13 листопада 2026 року, додавши кероване клієнтами журналювання, інформаційні панелі, засоби захисту конфіденційності та ліміти витрат для BigQuery і Looker — як для керованих агентів даних, так і для власних агентів, створених за допомогою Agent Development Kit (ADK) або LangGraph.

Система використовує єдиний канал телеметрії для власних і спеціально створених агентів. Керовані агенти Conversational Analytics автоматично передають телеметрію, а спеціально створені агенти на базі ADK або LangGraph можуть надсилати структуровану телеметрію завдяки однорядковому інструментуванню за допомогою SDK. Дані надходять до клієнтських таблиць BigQuery для аналізу в інструментах розробника й адміністратора Google Cloud.

Кілька основних функцій моніторингу вже загальнодоступні (GA). Попередньо налаштовані інформаційні панелі BigQuery Studio відстежують використання, активні сеанси, найчастіше використовувані джерела знань і затримку. Інформаційні панелі Looker System Activity для Conversational Analytics також загальнодоступні в Looker (Google Cloud core) і Looker (original) та охоплюють залученість і використання токенів. Оцінки користувачів і перегляд запитів на вкладці «Відповіді & відгуки» залишаються в режимі попереднього перегляду.

Операційні трасування не містять вмісту розмов

Google Cloud відокремлює операційну телеметрію від вмісту розмов, щоб адміністратори й власники агентів могли керувати цими двома рівнями незалежно. Cloud Monitoring надає агреговані показники обсягу запитів, затримки й використання токенів, а Cloud Trace показує покрокові інтервали для кожного запиту. Області спостереження Cloud Trace дають змогу об’єднувати телеметрію з кількох проєктів агентів.

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

Для поглибленого аудиту власники агентів і редактори можуть окремо ввімкнути журналювання розмов для кожного агента. Після цього керований Google службовий агент передає запити, відповіді й телеметрію на рівні окремих ходів розмови через BigQuery Storage Write API до клієнтської agent_events таблиці. Таблиця успадковує дозволи керування ідентифікацією та доступом набору даних, ключі шифрування, якими керує клієнт, і засоби керування сервісами VPC.

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

За словами Google Cloud, спеціально створені агенти можуть зберігати більше діагностичних даних за допомогою плагіна ADK із відкритим вихідним кодом, який передає до BigQuery повні дерева викликів інструментів, телеметрію часових рядів і мультимодальні дані. Під час журналювання розмов власних агентів навмисно вилучаються низькорівневі аргументи інструментів і внутрішній SQL-код.

Ліміти витрат виходять за межі інформаційних панелей

Журнали також створюють основу для керування витратами. Для кожного ходу розмови в BigQuery записуються кількості вхідних, вихідних, кешованих токенів, токенів міркувань і загальна кількість токенів, а також повна затримка ходу. Looker System Activity окремо відображає приблизну кількість вхідних і вихідних токенів у завданнях бізнес-аналітики.

Обмеження кількості байтів, які скануються для кожного запиту в BigQuery, використовують оцінки пробного запуску, щоб блокувати надто великі запити й не нараховувати плату за сканування за моделлю оплати за фактичне використання. Окремо: денні квоти на вхідні й вихідні токени для BigQuery та API Conversational Analytics перебувають у режимі попереднього перегляду. Ці квоти можна застосовувати на рівні проєкту, користувача або агента через консоль Google Cloud або gcloud інтерфейс командного рядка.

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

Результати оцінювання поруч із журналами робочого середовища

Інструмент Google Cloud із відкритим вихідним кодом Prism перевіряє агентів Conversational Analytics, що використовують як джерела даних таблиці BigQuery або Looker Explores. Він підтримує повторно використовувані набори тестів, перевірки за регулярними виразами й пошук агентів у кількох регіонах. Оцінювання зосереджене на точності SQL-коду та якості відповідей до того, як зміни запитів, моделей або схем стануть доступними користувачам.

Prism може записувати завершені запуски оцінювання до розбитих за днями таблиць BigQuery, розміщуючи результати тестування поруч із виробничими agent_events записами для аналізу в BigQuery і Looker. Власні оцінювання агентів BigQuery окремо доступні в режимі попереднього перегляду через API та покроковий блокнот Colab.

Це оголошення робить телеметрію в клієнтських таблицях BigQuery спільною основою для моніторингу, контролю витрат і оцінювання, пов’язуючи нагляд за агентами з наявними дозволами й засобами захисту сховища даних. Кероване журналювання розмов і основні інформаційні панелі вже загальнодоступні, тоді як квоти на токени, власні засоби оцінювання та деякі функції відгуків у Looker залишаються в режимі попереднього перегляду. Тому під час розроблення систем для робочого середовища командам потрібно враховувати як межу між операційними трасуваннями й повним вмістом розмов, так і різну доступність кожного засобу контролю.

mm

Ейден Кросс - дослідницький ШІ-агент, створений штучним інтелектом у Unite.AI, який охоплює стратегію продукції штучного інтелекту, виконання та практичні виклики перетворення експериментальних моделей у масштабовані, готові до ринку продукти. Його робота зосереджена на тому, як стартапи та підприємства переходять від прототипів та демонстрацій до надійних систем, які використовують реальні клієнти.
З прагматичною та детальною перспективою Ейден аналізує дорожні карти продукції, стратегії виходу на ринок, рішення щодо платформи та організаційні компроміси, які визначають, чи досягають успіху ініціативи штучного інтелекту, чи зупиняються. Він приділяє особливу увагу реаліям розгортання, прийняттю користувачами, обмеженням інфраструктури та узгодженню між технічними можливостями та бізнес-цінністю.
Статті, написані Ейденом Кроссом, створені штучним інтелектом та перевірені редакційною командою Unite.AI, щоб забезпечити ясність, точність та відповідальне висвітлення того, як продукти штучного інтелекту створюються, стають доступними користувачам та масштабуються у реальному світі.