Агентная аналитика использует ИИ-агентов для интерпретации бизнес-вопросов, планирования анализа, выполнения запросов к источникам данных и итеративной работы над уточнениями. В этой статье объясняется, чем она отличается от простого чат-бота и традиционной бизнес-аналитики (BI). Также рассматривается, почему агенты иногда дают уверенные, но неверные ответы, если они неправильно настроены, и как помогает надежная основа данных. Вы узнаете, чем агентная аналитика отличается от агентных данных и почему отсутствие контекста приводит к сбоям.

Основные выводы

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

Что означает агентная аналитика

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

Ключевое различие между простым чат-ботом и аналитическим агентом заключается в автономности выполнения. Чат-бот просто переводит запрос в один SQL-запрос. Агент активно планирует, обнаруживает релевантные таблицы, перекрестно проверяет результаты в разных системах и даже запускает последующие рабочие процессы при наличии соответствующих полномочий.

Например, чтобы ответить на вопрос «Была ли прибыльной акция на яйца на прошлой неделе?», нужно связать три отдельные системы:

Транзакции продаж
Погашение бонусов по программе лояльности
Оптовые затраты поставщиков.

Аналитический агент находит эти наборы данных, объединяет их между границами источников и проверяет итоговый расчет маржи перед предоставлением результата.

Агентная аналитика против агентных данных

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

Чем агентная аналитика отличается от традиционной BI

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

Второй сдвиг — от информирования к действию. Традиционная BI работает только на чтение, но автономные агенты могут обновлять записи, открывать тикеты или запускать последующие рабочие процессы. Это меняет вашу модель управления. SQL-контроль «только для чтения» обеспечивает безопасность на пути запроса данных, в то время как операционные действия требуют отдельной плоскости управления записью, регулируемой на своих условиях. Контроль доступа больше не является вопросом только чтения.

Что остается неизменным

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

Почему агенты дают уверенные, но неверные ответы

Агенты без уровня контекста выбирают источник и рассуждают на полной скорости, не имея каталога для проверки и коллег, у которых можно спросить. Если этот источник неверный, ответ будет неверным, но он все равно будет звучать уверенно. Рассмотрим отток клиентов. Ваша команда определяет «отток» как отмену подписки в течение 30 дней. Агент, у которого нет этого определения, запрашивает таблицу поддержки вместо канонической таблицы подписок. Запрос выполняется, цифры выглядят правдоподобно, но ответ неверный. Определения вызывают те же проблемы и в других областях. Выручка может означать признанную выручку, забронированную годовую регулярную выручку (ARR) или валовые счета. Все три варианта верны, но они разные. «Активный клиент» работает так же. Аналитик-человек спросит, что вы имеете в виду, а агент часто будет угадывать. Часто причина кроется в отсутствии обоснования. Критерии успеха для производственных агентов — точность, согласованность и проверяемость. Лучшие модели не исправляют отсутствие определений. Семантический слой и встроенное управление — вот решение.

Уровень контекста и обоснование агента

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

Продукты данных как единица потребления агентами

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

Что нужно уровню данных для агентной аналитики

Начните с уровня контекста, описанного выше. Требуются еще четыре возможности: федеративный доступ, открытый data lakehouse, управление на уровне доступа и плоскость управления.

Давайте рассмотрим их по очереди.

Федеративный доступ вместо централизации

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

Основа открытого data lakehouse

В то время как федерация соединяет удаленные источники, открытый data lakehouse обеспечивает высокопроизводительный уровень хранения для аналитических наборов данных, размещенных локально. Использование открытых табличных форматов, таких как Apache Iceberg, дает платформенным командам функции таблиц уровня хранилища поверх объектного хранилища, гарантируя, что данные остаются свежими, доступными для запросов и воспроизводимыми для рабочих нагрузок ИИ.

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

Наконец, открытый формат гарантирует интероперабельность. Хранение аналитических таблиц в Apache Iceberg предотвращает привязку к поставщику, гарантируя, что ваши базовые данные останутся доступными для различных аналитических движков, внешних инструментов обработки данных и развивающихся стеков моделей ИИ.

Управление на уровне доступа

Управление должно осуществляться непосредственно в точке подключения агентов к данным. Это означает принудительное ограничение доступа только для чтения на пути выполнения запросов, применение политик на основе ролей (RBAC) и атрибутов (ABAC), а также ведение журналов аудита с первого дня. Подробные журналы аудита позволяют командам платформы восстанавливать точные SQL-запросы и вызовы инструментов, сгенерированные в ответ на запрос агента.

Такое принудительное применение на стороне сервера критически важно при работе со стандартами, такими как Model Context Protocol (MCP). MCP предоставляет открытый интерфейс между агентами ИИ и инструментами обработки данных, но его сигналы «только для чтения» на уровне протокола носят исключительно рекомендательный характер. Истинная безопасность полностью зависит от того, что именно обеспечивает сервер.

Вместо того чтобы полагаться на взаимодействие на стороне клиента, Starburst обеспечивает доступ только для чтения на стороне сервера, анализируя входящие запросы непосредственно через парсер Trino SQL и отклоняя любые операции записи или неавторизованные типы операторов до их выполнения.

Агентская плоскость управления

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

Что AIDA показывает о паттерне на практике

AIDA — это агент Starburst для аналитики на естественном языке на основе управляемых данных. Он стал общедоступным ранее в этом году как в Starburst Galaxy, так и в Starburst Enterprise, поэтому гибридные и локальные команды также могут его использовать. Он располагается на уровне управляемого контекста поверх федеративных данных. Мы также предоставляем этот же уровень внешним агентам через конечную точку MCP. Рассматривайте это как одну из иллюстраций паттерна. Вы задаете вопрос, и агент обращается к уровню контекста, включая его семантический слой, чтобы понять ваш бизнес, поэтому его ответы используют ваши определения. Управление ограничивает агента данными, которые пользователю разрешено видеть. Это может снизить зависимость от статических дашбордов, предлагая интерактивный, управляемый анализ.

Как оценить свою готовность

Используйте этот чек-лист для проверки вашей текущей среды.

Может ли агент получить доступ ко всем соответствующим источникам посредством федерации или путем размещения данных в Iceberg там, где это уместнее?
Закодированы ли бизнес-определения там, где агент может их прочитать?
Является ли доступ к запросам только для чтения и регулируется ли он политиками, при этом любые действия по записи выполняются по отдельному управляемому пути?
Можете ли вы восстановить запросы и инструменты, стоящие за ответом?
Автоматически ли поддерживаются ваши таблицы Iceberg?
Есть ли у вас набор «золотых» вопросов с известными правильными ответами, которые вы повторно запускаете по мере изменения определений, данных и моделей?

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

Следующие шаги

Стройте на основе корпоративного фундамента данных, попробуйте этот паттерн в бесплатной пробной версии и используйте другие руководства и семинары по мере расширения.

Часто задаваемые вопросы

Агентская аналитика — это аналитика, в которой агент интерпретирует вопрос, планирует анализ, выполняет запросы к источникам и итерирует последующие действия. Там, где вы это разрешаете, агент также может принимать меры. Человек направляет работу, вместо того чтобы писать каждый запрос.

Чем агентская аналитика отличается от традиционной бизнес-аналитики (BI) и дашбордов?

Традиционный путь идет от вопроса к аналитику, затем к SQL и дашборду. С агентами фильтр аналитика исчезает, поэтому уровень данных должен обеспечивать выбор таблиц, диапазоны дат и определения. Аналитика также переходит от информирования к действию, поэтому управление должно охватывать как действия, так и чтение. AIDA, например, может снизить зависимость от статических дашбордов, предлагая интерактивный, управляемый анализ.

Почему агенты ИИ иногда дают неверные ответы, используя корпоративные данные?

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

Нужно ли мне централизовать данные перед включением агентской аналитики?

Не обязательно перед началом. Агенты могут запрашивать данные там, где они находятся, на месте, в рамках вашей существующей безопасности. Копирование всего в одно хранилище — это медленно, дорого и сложно масштабировать. Федеративный, управляемый доступ к данным позволяет одному агенту объединять источники без их копирования. Федерация увеличивает нагрузку на источник и стоимость объединения, поэтому размещайте часто запрашиваемые или критически важные для производительности наборы данных в Iceberg, когда эти затраты начинают иметь значение.

Как вписывается MCP и как обеспечить управляемость доступа агентов?

MCP — это открытый протокол между агентами и инструментами обработки данных. Сам по себе он не гарантирует управление, поскольку его сигнал «только для чтения» носит рекомендательный характер, а принудительное исполнение зависит от каждой реализации. Установите доступ «только для чтения» на пути запроса с помощью RBAC, ABAC, безопасности на уровне строк и журналов аудита на уровне доступа.