Привет, это команда Далее. На одном из проектов у нас есть терабайты данных о рекламных кампаниях, которые хранятся на десятках площадок. Это множество таблиц, агрегаций, расчетных метрик и формул.

Big Data обрабатывают аналитики и дата-инженеры: приводят в нормальный вид, следят за качеством, рассчитывают дополнительные метрики. В конце концов, все приходит в BI-систему, где менеджеры делают отчеты и визуализируют информацию на дашбордах.

Несмотря на неоспоримую пользу BI, с таким количеством разрастающихся данных все-таки остаются сложности:

1. Отчетов может быть несколько десятков. Руководителю, который их смотрит, неудобно навигироваться между ними.

2. Не каждый может получить нужные данные самостоятельно. Если речь о сложных запросах, без аналитика не обойтись. Менеджеру нужно знать SQL, подключаться к базе, формулировать запрос, запускать его. SQL вернет цифры, но сам процесс для менеджера трудный.

3. Нельзя нормально переиспользовать данные. Перенос информации в другую AI-систему придется делать вручную: скринить дашборды или парсить HTML. Это нерабочая история, не про автоматизацию.

Внедрение AI в BI решило сразу все три задачи. Теперь пользователь получает доступ ко всей информации в одном диалоговом окне. Может запросить трактовку показателей, сравнение и тут же все визуализировать.

Внедрение AI в BI: правильная инфраструктура = 90% успеха

Модель искусственного интеллекта важна. Еще важнее — инфраструктура, на которой она работает.

Главная ценность разработки решения именно в том:

• как хранятся данные, 

• какие инструменты используются для их обработки,

• как они подаются на выход. 

Нам еще до реализации AI-агента удалось выстроить такую систему, с которой он будет работать эффективно.

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

Например, у нас есть поле CPC в таблице. Мы указываем формулу расчета и добавляем метаданные: описание и пояснения для ИИ.

Мы используем удобный механизм запроса данных, включая сложные запросы. Здесь есть разделение ответственности:

1. Аналитик формирует витрину, пишет сложный SQL, агрегирует данные, рассчитывает метрики. В семантическом слое он добавляет описание, документацию и дополнительные параметры для AI-агента. 

2. После этого данные лежат в структурированном виде. Разработчик может получить их без написания 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 месяца