Привет, это команда Далее. На одном из проектов у нас есть терабайты данных о рекламных кампаниях, которые хранятся на десятках площадок. Это множество таблиц, агрегаций, расчетных метрик и формул.
Big Data обрабатывают аналитики и дата-инженеры: приводят в нормальный вид, следят за качеством, рассчитывают дополнительные метрики. В конце концов, все приходит в BI-систему, где менеджеры делают отчеты и визуализируют информацию на дашбордах.
Несмотря на неоспоримую пользу BI, с таким количеством разрастающихся данных все-таки остаются сложности:
Отчетов может быть несколько десятков. Руководителю, который их смотрит, неудобно навигироваться между ними.
Не каждый может получить нужные данные самостоятельно. Если речь о сложных запросах, без аналитика не обойтись. Менеджеру нужно знать SQL, подключаться к базе, формулировать запрос, запускать его. SQL вернет цифры, но сам процесс для менеджера трудный.
Нельзя нормально переиспользовать данные. Перенос информации в другую AI-систему придется делать вручную: скринить дашборды или парсить HTML. Это нерабочая история, не про автоматизацию.
Внедрение AI в BI решило сразу все три задачи. Теперь пользователь получает доступ ко всей информации в одном диалоговом окне. Может запросить трактовку показателей, сравнение и тут же все визуализировать.
Внедрение AI в BI: правильная инфраструктура = 90% успеха
Модель искусственного интеллекта важна. Еще важнее — инфраструктура, на которой она работает.
Главная ценность разработки решения именно в том:
как хранятся данные,
какие инструменты используются для их обработки,
как они подаются на выход.
Нам еще до реализации AI-агента удалось выстроить такую систему, с которой он будет работать эффективно.
В основе нашей структуры — семантический слой. Это отдельный сервис, который обогащает данные бизнес-логикой. Мы можем задать метаинформацию о датасете и о каждом его поле, в том числе описание для AI-агента. Можем формировать целые датасеты с конкретными формулами расчета.
Например, у нас есть поле CPC в таблице. Мы указываем формулу расчета и добавляем метаданные: описание и пояснения для ИИ.
Мы используем удобный механизм запроса данных, включая сложные запросы. Здесь есть разделение ответственности:
Аналитик формирует витрину, пишет сложный SQL, агрегирует данные, рассчитывает метрики. В семантическом слое он добавляет описание, документацию и дополнительные параметры для AI-агента.
После этого данные лежат в структурированном виде. Разработчик может получить их без написания SQL — достаточно передать несколько параметров. Вся сложная логика уже зафиксирована аналитиком.
Если аналитику нужно написать 12 строк SQL для расчета поля, то разработчику достаточно указать пару параметров, чтобы получить результат. И да, мы уверены, что нейросеть не должна генерить SQL. Это плохо контролируемый процесс, а вольности тут недопустимы.
Дальше появляется сам AI-агент с тулзами, через которые он взаимодействует с данными.
Внедрение AI в BI: процесс и архитектура
Трек внедрения AI в BI:
1. Data Agent
Реализовали инструменты, через которые AI получает метаданные, формирует структурированные запросы к аналитической модели и возвращает агрегированные данные.
2. Insight Agent
Обогатили семантический слой метаданными для AI-агента: дали краткое описание бизнес-логики каждой метрики и группировки.
3. Visualization Agent
Сделали API для работы AI-агента с BI-системой. Научили AI создавать графики и размещать их на интерактивном холсте в реальном времени.
4. Интеграция с аналитической платформой
Создали пользовательский интерфейс для AI. Настроили корпоративную авторизацию и обеспечили прозрачность работы AI.
5. Развертывание MCP-коннектора
Поднимаем сервер, который позволяет обращаться к агенту из внешних AI-клиентов с авторизацией и соблюдением прав доступа.
С точки зрения экономики, выбор одной модели под все задачи — невыгоден. Тяжелая модель может быть «умнее», но она дольше отвечает и дороже в эксплуатации. Ее разумно использовать там, где требуется сложная логика.
Если задача — просто определить тип запроса пользователя, то решать ее лучше через более легковесную модель, которая быстрее и дешевле справится с классификацией.
Наша архитектура построена так, чтобы на разных этапах использовались наиболее подходящие модели.
Data Agent работает с кубом и семантическим слоем.
Может:
Получить информацию о датасете: что это за набор данных, какому клиенту он принадлежит. Это важно для разграничения доступа, чтобы один клиент не мог запросить данные другого.
Запросить структуру датасета: какие там есть измерения и метрики. Например, клики, план-факт, разные статистические показатели по рекламным кампаниям. Он видит, какие поля доступны, и на основе этого принимает решение, использовать этот датасет или выбрать другой.
Уточнять значения измерений. Пользователи часто упрощают названия, а агент проверяет допустимые значения, находит корректное наименование и делает правильный запрос.
Кроме того, Data Agent выполняет запросы с фильтрацией по строкам, времени и другим параметрам.
Insight Agent отвечает за интерпретацию данных.
В семантическом слое хранится метаинформация по каждому полю — в том числе описание для AI. Если пользователь просит не просто цифры, а объяснение, этот агент может интерпретировать показатели.
Например, AI может сказать: «CPC у вас ниже среднего. Это означает, что кампания работает эффективно». Или наоборот — объяснить, что показатель ухудшился и с чем это связано. Он работает уже с полученными данными и добавляет контекст.
Visualization Agent нужен для визуализации.
Он интегрирован непосредственно с BI-системой, создает и размещает виджеты прямо на интерактивном холсте. Здесь же пользователь может доработать сгенерированный график или таблицу.
Допустим, менеджер запросил динамику количества показов и кликов по месяцам. Система получила данные, интерпретировала их, а дальше пользователь может сказать: «Визуализируй это на дашборде». И агент создаст нужный виджет.
Таким образом, мы разделяем ответственность: один AI-агент работает с кубом и данными, другой — с интерпретацией, третий — с визуализацией.
Какие инструменты писать, чтобы это работало
dataset_meta — список полей с описаниями;
dimension_values — поиск группируемых значений;
get_date — запрос актуальной даты;
dataset_query — формирование JSON-запроса в семантический слой данных;
методы для выбора и построения графиков, расчета позиции спавна виджетов и прочего визуального.
Пример того, как это выглядит:
import { createMcpHandler } from '@vercel/mcp-handler'
import { z } from 'zod'
const handler = createMcpHandler(
(server) => {
server.tool(
'dataset_query',
'Get data with Cube query',
{
measures: z.array(z.string()),
dimensions: z.optional(
z.array(z.string())
),
filters: z.optional(
z.array(
z.object({
member: z.string(),
operator: z.string(),
values: z.array(z.string()),
})
)
),
// ...
})
})Внедрение AI в BI: что надо учесть
Модель — это по сути черный ящик. Если задать ей один и тот же вопрос сейчас и через пару часов с теми же вводными, ответ может отличаться. Это оборачивается челленджами в тестировании и контроле качества.
В классической разработке есть детерминированный результат, а здесь — вероятностный. У нас был набор сценариев: несколько типов запросов, реальные вопросы и ожидаемые ответы. Мы смотрели, насколько корректно агент формирует запрос и выбирает инструменты, а также соответствует ли ответ ожиданиям.
За AI всегда нужно проверять. В неудачных дублях скринкаста он дергал функцию генерации конфига виджета дважды, потому что первое изделие не прошло сертификацию.
Мультитенантность и RLS тоже не стоит доверять нейросети, для этого потребуются низкоуровневые методы.
Тестировали AI-агента на демо-датасетах с моделями Qwen и OpenAI. Сейчас продукт доступен в формате A/B-тестирования ограниченной группе пользователей внутри компании клиента.
MCP-коннектор для интеграции с другими агентами
MCP — это узел в нашей системе, который позволяет взаимодействовать с другими AI-системами. Мы публикуем через него инструменты нашего AI-агента. Любой клиент при наличии авторизации может подключиться к ним и использовать либо напрямую, либо через своего AI-агента.
Например, если у какого-то подразделения есть собственная модель, то ее можно подключить к нашему MCP-серверу. В этом случае модель будет работать с нашими инструментами и брать нужную информацию в соответствии с политиками безопасности внутри приложения.
Теоретически можно подключиться даже из внешнего клиента — условно, из GigaChat или Алиса AI — указав токен авторизации и получив доступ. Но это скорее возможность архитектуры, чем основной сценарий использования.
Главное — MCP позволяет настраивать взаимодействие с любой корпоративной моделью в соответствии с политикой безопасности.
Что имеем на данный момент
Система постепенно дорабатывается. Основной фокус сейчас — усиление безопасности. Мы дополнительно укрепляем защиту, учитывая обновления технологий и новые требования.
Со стороны функциональности кардинальных изменений нет, базовый набор возможностей уже реализован.
AI-агент объединяет разные отчеты и витрины в одной точке входа — человек задает вопрос и получает ответ.
Не нужно привлекать аналитика на каждый кастомный запрос менеджера.
Есть возможность интеграции с другими AI-агентами — наше решение может стать частью более широкой агентской сети.
Параллельно развивается рыночный продукт — Subquery. В нем планируем более расширенную версию AI-агента с дополнительным функционалом. Кстати, вы можете оставить в комментариях сценарии, которые хотели бы в нем видеть.
А если вам интересно, как мы разрабатывали саму BI-систему с динамичными дашбордами и реактивностью, то велком в статью Дмитрия Дина:
Как приручить сигналы или BI-система на графовой реактивности за 2 месяца