AI для BI: как AI-агенты сделали из обычного BI генеративный

Введение

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

Возникают разные вопросы, например:

• Как быстро найти нужный дашборд среди множества отчётов?
• Как понять, откуда взялось конкретное поле в базе данных?
• Как оперативно написать SQL-запрос, учитывая сложность и специфику корпоративных данных?
• И многие другие

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

Автоматизация SQL-запросов с AI: ожидания и реальность

С появлением больших языковых моделей (LLM, Large Language Models) возникла возможность автоматически генерировать SQL-запросы на основе пользовательских запросов на естественном языке.

Это вызвало большие ожидания и надежды: казалось, что искусственный интеллект (AI, Artificial Intelligence) упростит бизнес-аналитику (BI, Business Intelligence), сделает её доступнее и позволит бизнес-пользователям получать отчёты и анализировать данные самостоятельно, без участия технических специалистов.

Однако на практике в корпоративном ландшафте большие языковые модели часто оказываются неэффективными для Text2SQL-решений. Они знают синтаксис SQL, но:

• не учитывают бизнес-контекст и специфику данных компании;
• могут генерировать логически некорректные запросы, приводящие к искажённым результатам;
• не адаптируются к изменениям в данных и не могут гарантировать точность и безопасность SQL-кода.

Например, AI может неправильно интерпретировать терминологию бизнеса, составить запрос с неверными JOIN’ами или некорректно агрегировать данные, что приведёт к неточным выводам и рискам для принятия решений.

Мы в Эпсилон Метрикс решаем проблему «последней мили» внедрения LLM в продакшн. Объединив наши НИОКР (научно-исследовательские и опытно-конструкторские работы) и опыт работы с крупными компаниями, мы разработали Epsilon Workspace — платформу, которая учитывает бизнес-контекст, обеспечивает валидацию SQL-запросов, самостоятельно планирует и выполняет действия и снижает нагрузку на аналитиков.

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

В этой статье мы подробно рассмотрим основные возможности и применение генеративного AI в области BI, разберёмся, как построить AI-архитектуру для аналитики, используя большие языковые модели (LLM) в комплексе с Retrieval-Augmented Generation (RAG) и AI-агентами. Рассмотрим реальный кейс создания SQL-агента и AI-агента создания диаграмм и графиков.

На примере платформы Epsilon Workspace — no-code платформы для разработки AI-агентов, AI-приложений и конвейеров обработки и аналитики данных, мы продемонстрируем, как AI может:

• Автоматизировать поиск данных и предоставлять ответы на запросы пользователей.
• Генерировать SQL-запросы на основе запросов на естественном языке c учётом специфики компании.
• Структурировать данные в удобном формате для презентаций, дашбордов, отчётов, писем и сообщений в мессенджерах.

Кроме того, мы разберем архитектурные принципы, обеспечивающие корректную работу AI в BI-среде.

Эта статья поможет вам понять, как современные AI-агенты и мультиагентные системы могут упростить аналитические процессы и повысить эффективность работы с данными.

Как устроена платформа для AI-агентов для BI

Архитектура платформы включает три основных слоя:

1. Слой AI-агентов

Этот слой координирует работу различных AI-агентов, обрабатывающих запросы пользователей на естественном языке. В его состав входят обычно AI-Агенты следующих типов:

• Поисковые агенты, осуществляющие поиск по аналитической инфраструктуре – от отчётов и файлов до схем баз данных и документации – для предоставления персонализированных результатов.
• Аналитические агенты для генерации и выполнения SQL-запросов, построения графиков и диаграмм и проведения анализа данных.
• Агенты-инструменты, объединяющие рабочие процессы различных систем через API-вызовы, например, для автоматической отправки отчётов в мессенджеры.

2. Слой Retrieval: извлечение информации

Этот слой отвечает за извлечение актуальной информации из различных источников. Используя RAG, он осуществляет поиск данных в BI-системах, SQL-хранилищах, CRM, ERP и корпоративной документации. При необходимости Retrieval Layer может инициировать дополнительные запросы. Этот слой обеспечивает анализ данных с использованием актуальной и релевантной информации.

3. Слой знаний: единое пространство корпоративных и внешних данных

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

Эти три слоя позволяют пользователям самостоятельно работать с аналитикой, минимизировать вовлечённость аналитиков и дата-инженеров и значительно ускорять принятие решений.

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

Пример работы AI-агентов в аналитике данных и BI

Рассмотрим, как система AI-агентов работает на практике, чтобы обеспечить оперативное получение аналитической информации.

1. Вопрос на естественном языке

Пользователь задаёт вопрос: «Где можно посмотреть ключевые показатели за третий квартал 2024 года?»

На этом этапе поисковый агент анализирует все доступные источники: отчёты, дашборды, схемы баз данных и документацию. Он находит два дашборда и формирует ответ пользователю на естественном языке:

• Первая панель предназначена для финансовой команды за весь 2024 год.
• Вторая панель содержит квартальные маркетинговые отчёты OKR.

2. Уточнение запроса и генерация SQL-запроса

Пользователь уточняет свой запрос: «Мне нужны только финансовые отчёты OKR за этот конкретный квартал».

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

3. Получение результатов выполнения запросов в заданном формате и отправка их коллегам, клиентам или партнёрам

Полученные данные передаются мессенджер-агентом в корпоративный канал, например, в Telegram или Slack. Таким образом, команда Finance получает оперативно готовый отчёт, который можно сразу использовать для принятия решений.

Построение SQL-агента для автоматизации процессов аналитики данных

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

Первый и самый простой вариант: использование LLM только для генерации SQL-запросов

Самый простой создания SQL-агента — использование LLM только для генерации запросов, и больше не для чего. Этот процесс включает в себя следующие шаги:

1. Формирование запроса к LLM. В промпт передаются: инструкция, например, «Напиши SQL-запрос для следующего вопроса», текст запроса пользователя (промпт), описание структуры данных (таблицы, колонки, связи).
2. Генерация SQL-кода на основании промпта. LLM получает промпт, анализирует входные данные и формирует SQL-запрос в соответствии с промптом.
3. Пользователь получает код SQL-запроса. Модель возвращает готовый SQL-код, который можно использовать для выполнения запроса в хранилище данных.

Ограничения первого варианта

Этот метод простой и понятный, но имеет ряд недостатков:

1. SQL-запросы выполняются вручную. Пользователь копирует и вставляет код в SQL-редактор.
2. Ошибки не исправляются автоматически. Если SQL-запрос не работает, его нужно корректировать вручную.
3. LLM не учитывает бизнес-правила и специфику компании. Запросы строятся на основе описанной в промпте схемы данных, но без учета специфики показателей и аналитики компании.

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

Второй вариант: Генерация SQL-запроса + Выполнение SQL-запроса

Первый подход с использованием LLM (с few-shot или zero-shot обучением) позволяет генерировать SQL-код, но после этого всё — работа SQL-агента заканчивается. Как правило, такие системы (например, стандартная интеграция ChatGPT) требуют от пользователя вручную копировать полученный SQL-код, вставлять его в SQL-редактор и запускать выполнение уже за периметром работы SQL-агента.

Чтобы решить эту проблему, предлагается интегрировать в конвейер SQL-агента специальный инструмент для выполнения SQL-запросов. Схема работы следующая SQL-агента в этом случае будет такая: 1. генерация запроса → 2. выполнение запроса → 3. возврат результата выполнения запроса.

1. Генерация SQL-запроса: LLM генерирует SQL-код на основании сформированного промпта.

2. Автоматическое выполнение SQL-запроса: сгенерированный SQL-код автоматически передается в инструмент, отвечающий за выполнение запросов. Этот инструмент отправляет запрос в хранилище данных или базу данных.

3. Получение результатов выполнения SQL-запроса: после выполнения запроса система получает результат и возвращает его пользователю.

Теперь наш SQL-агент не просто генерирует SQL-запрос, а самостоятельно выполняет его и предоставляет результат.

Ограничения второго варианта (Генерация SQL-запроса + Выполнение SQL-запроса)

Несмотря на улучшение по сравнению с ручным копированием сгенерированного SQL-запроса, этот метод имеет свои недостатки:

1. Нет обработки ошибок. Если сгенерированный SQL-код содержит ошибку (например, неверное название таблицы или ошибку синтаксиса), процесс останавливается, и пользователю результат не возвращается.
2. Жёстко заданный поток выполнения. Такой подход требует от разработчиков заранее прописывать все возможные сценарии ошибок и логику их обработки. Это усложняет поддержку системы и снижает её масштабируемость.

В следующих разделах рассмотрим решения, которые позволят улучшить управление потоком выполнения.

Третий вариант: LLM + действия + решения

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

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

Использование вызовов инструментов (Tools)

В зависимости от ситуации AI-агент может принимать решение о том, какие действия предпринять – от выполнения запроса до обращения к другим инструментам для проверки данных или исправления ошибок.

Процесс выполнения

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

Автоматическая корректировка ошибок

Если первый сгенерированный SQL-запрос не компилируется, AI-агент анализирует сообщение об ошибке, вносит необходимые исправления в запрос и автоматически повторяет его выполнение.

Ограничения третьего варианта

LLM ничего не знает о внутренней структуре данных и бизнес-правилах организации. Но написание SQL требует глубокого понимания контекста, в котором выполняется запрос, например, знания того, какие таблицы и столбцы следует использовать, понимания взаимосвязей, соединений и многого другого.

Поэтому она может создать запрос, который не отражает реальные бизнес-процессы и агентный подход все еще может сталкиваться с рядом проблем:

• Логические ошибки. Хотя модель может исправлять синтаксические ошибки, это не гарантирует корректности итогового запроса. Он может не учитывать специфику бизнес-логики.

• Ограниченные знания о бизнес-правилах. LLM не обладает встроенной информацией о структуре данных в компании, а значит, не всегда может корректно интерпретировать запрос и построить SQL с учетом корпоративных стандартов. Если модель не знает точных определений, таких как, например, критерии для «активных пользователей», запрос может использовать неверные условия.

• Необходимость валидации данных. Для повышения надежности работы SQL-агента требуется механизм проверки качества сгенерированных SQL-запросов. Он должен обеспечивать контроль точности результатов и соответствие бизнес-задачам и бизнес-контексту.

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

Принцип работы RAG

RAG (Retrieval-Augmented Generation) извлекает из слоя знаний релевантную информацию перед генерацией SQL-запроса, обеспечивая его соответствие внутренним бизнес-правилам.

Чтобы SQL-агент учитывал специфику компании, он использует унифицированный слой знаний, содержащий:

• Структуру данных – описание таблиц, полей и связей между ними.
• Определения ключевых метрик и бизнес-правил – точные формулировки показателей (например, как рассчитывается «выручка» или кто считается «активным пользователем»).
• Внутреннюю документацию – отчёты, корпоративные чаты, инструкции, описания бизнес-процессов и другие документы.

Эти данные индексируются для быстрого поиска. Индекс создается в текстовом и векторном представлении, что позволяет находить информацию по семантическому сходству.

Процесс работы RAG включает в себя три этапа:

1. Создание индекса. Все данные из унифицированного слоя знаний индексируются для быстрого поиска. Векторное представление обеспечивает поиск по смысловой близости.

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

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

SQL-агент: основные компоненты реализации с использованием RAG

SQL-агент строится на основе трех ключевых компонентов:

1. LLM как управляющий механизм

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

2. Инструменты (Tools)

Для выполнения задач SQL-агенту необходим доступ к специализированным инструментам:

1. Механизм выполнения SQL-запросов: автоматически передает сгенерированный SQL-код в хранилище данных и осуществляет его выполнение через API-вызовы.
2. Инструмент поиска в слое знаний (RAG): извлекает релевантный бизнес-контекст, определения метрик, структуру базы данных и бизнес-правила из унифицированного слоя знаний. Данные предварительно индексируются (с использованием текстового и/или векторного поиска) для обеспечения быстрого доступа.

3. Агентная логика (Agentic Reasoning)

Этот компонент позволяет LLM самостоятельно выбирать последовательность действий. Вместо заданного порядка операций модель способна анализировать ситуацию и принимать решения:

1. Если сгенерированный SQL-запрос выполняется без ошибок — возвращать результат.
2. В случае ошибки — анализировать сообщение об ошибке, корректировать запрос и повторять попытку.
3. При необходимости инициировать дополнительное извлечение контекста через RAG, если есть недостаток информации.

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

Полный цикл работы SQL-агента выглядит следующим образом:

1. Пользователь задает вопрос. Например, «Сколько у нас активных клиентов в Санкт-Петербурге?»
2. Извлечение контекста через RAG. Система ищет в слое знаний релевантное определение понятия «активный клиент», которое может включать, например, условие «closed ≠ 0».
3. LLM генерирует SQL-запрос. Получив необходимый контекст, LLM формирует SQL-запрос, учитывая специфику базы данных и бизнес-правила.
4. Автоматическое выполнение запроса. Сформированный SQL-код передается в инструмент выполнения SQL-запросов (SQL Tool), который отправляет SQL-запрос в хранилище данных.
5. Обработка результата и коррекция ошибок. Если запрос выполнен успешно, результат возвращается пользователю. В случае возникновения ошибки AI-Агент анализирует ее, корректирует запрос и повторяет попытку.

Преимущества применения AI-агентов в BI

Агентный подход демонстрирует существенные улучшения в следующих аспектах:

1. Использование слоя знаний. Интеграция унифицированного слоя знаний позволяет учитывать специфику корпоративных данных. SQL-запросы формируются с учетом актуальных бизнес-правил и метрик, что снижает вероятность логических и синтаксических ошибок, а также делает запросы более релевантными специфике организации.
2. Агентное управление процессом. Благодаря динамическому управлению потоком выполнения система способна автоматически анализировать ошибки, корректировать сгенерированный SQL-код и повторять попытки выполнения запроса без вмешательства пользователя. Такой механизм обеспечивает непрерывность работы даже в условиях возникновения ошибок.
3. Более высокая точность. Бенчмарки, проведенные на основе реальных сценариев клиентов, демонстрируют значительное улучшение качества SQL-генерации по сравнению с традиционными LLM-подходами. Агентный метод позволяет учитывать контекст и бизнес-логику, что приводит к более корректным и точным результатам.

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

Агентный подход в генерации SQL-запросов обеспечивает повышение точности.

1. Интеграция слоя знаний и бизнес-логики

Агентные системы используют унифицированный слой знаний, который может включать:

• Графы знаний (Knowledge Graph), описывающий связи между объектами корпоративных данных.
• Метаданные, содержащие информацию о схемах, ограничениях и зависимостях.
• Правила RAG (Retrieval-Augmented Generation), позволяющие LLM учитывать бизнес-контекст при генерации SQL.

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

2. Агентное управление процессом генерации и выполнения SQL (Agentic Reasoning)

Agentic Reasoning использует контроль выполнения запроса, включая:

• Планирование (Hierarchical Planning), где агент разбивает сложный SQL-запрос на последовательность подзадач.
• Анализ ошибок и адаптация (Self-Correction), позволяющий системе автоматически исправлять ошибки в сгенерированном SQL-коде, включая:
  • Логические несоответствия (например, попытка использовать агрегатную функцию без GROUP BY).
  • Синтаксические ошибки (например, отсутствие JOIN при запросе из нескольких таблиц).
  • Ошибки выполнения (например, обращение к несуществующему столбцу).
• Итеративную генерацию с обратной связью (ReAct, Tree of Thoughts и другие), позволяющую системе корректировать SQL при взаимодействии с базой данных.

Подробнее о фреймворках для рассуждений в AI-агентах можно почитать у нас в блоге.

Agentic Reasoning делает SQL-агента более устойчивым к ошибкам и адаптивным к изменениям схем данных, чем обычные (не-агентные) Text2SQL-решения, основанные на LLM.

3. Точность и релевантность SQL-запросов

Агентный подход демонстрирует существенное улучшение качества генерации SQL-запросов по сравнению с традиционными LLM-методами. Согласно бенчмаркам BIRD и Dr.Spider:

• Учет бизнес-логики повышает точность SQL-запросов на 20-35% по метрике execution accuracy (по сравнению с базовыми LLM).
• Использование динамической адаптации снижает вероятность ошибок на 15-30% при работе с изменяющимися схемами данных.
• Генерация SQL с учетом пользовательского контекста улучшает semantic match на 25-40%, что означает более точное соответствие бизнес-требованиям.

Agentic Reasoning особенно эффективен для корпоративной аналитики, где данные сложны, а SQL-запросы требуют глубокого понимания контекста. Интеграция слоя знаний, адаптивное исправление ошибок и динамическое управление процессом делают этот подход ключевым инструментом для повышения эффективности AI-анализа данных.

AI-агент визуализации данных (Charting Agent)

Charting AI-Agent дополняет SQL-агента, обеспечивает автоматическое построение графиков и визуальных отчетов. Несмотря на то, что Charting Agent работает по принципам, схожим с SQL-агентом, у него есть ряд особенностей:

Использование Python-кода вместо SQL

Вместо генерации и выполнения SQL-запросов, Charting Agent формирует и выполняет Python-код для построения графиков. Это позволяет использовать разные библиотеки визуализации, такие как Matplotlib, Seaborn или Plotly.

Исторические примеры визуализаций

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

Механизм поиска документации

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

Процесс работы Charting Agent

Работа агента визуализации данных включает следующие шаги:

1. Пользовательский запрос. Пользователь задает запрос, например: «Построй диаграмму продаж за последний год».
2. Анализ запроса. Агент анализирует поступивший запрос и определяет, требуется ли обратиться к документации для уточнения структуры данных или шаблонов визуализаций.
3. Формирование Python-кода. Исходя из анализа запроса и полученного контекста, Charting Agent генерирует Python-код, который отвечает за построение нужной визуализации. Код может включать вызовы библиотек визуализации и настройки оформления графика.
4. Выполнение кода. Сгенерированный код передается на выполнение, и агент получает изображение графика или диаграммы.
5. Возврат результата. Полученная визуализация возвращается пользователю в виде изображения или встроенного отчета.

Управление потоком выполнения

Как и SQL-агент, Charting Agent работает в недетерминированном режиме:

1. Запрос дополнительных примеров. Если AI-агент не уверен, как именно должен выглядеть график, он может инициировать запрос примеров из документации, чтобы уточнить оптимальный шаблон визуализации.
2. Непосредственная генерация и выполнение. В случаях, когда контекст однозначен, агент сразу генерирует и выполняет Python-код без дополнительных шагов.
3. Динамическая корректировка визуализации. При необходимости агент может вносить изменения в параметры визуализации – изменять цвета, оси, формат отображения и прочие настройки, чтобы результат максимально соответствовал ожиданиям пользователя.

Мультиагентные системы

Несмотря на очевидные преимущества, один SQL-агент не способен охватить все аналитические потребности современной компании. Помимо формирования SQL-запросов, пользователи ожидают от системы возможности:

1. Быстрого поиска и нахождения релевантных отчетов и дашбордов.
2. Автоматической генерации диаграмм и визуализаций на основе данных.
3. Подготовки аналитических материалов и презентаций.

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

AI-Агент поиска отчётов и дашбордов

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

AI-Агент визуализации данных

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

AI-Агент подготовки аналитических и презентационных материалов

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

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

Создание мультиагентной системы

Интеграция Charting Agent в единую мультиагентную систему открывает новые возможности для комплексной аналитики:

В рамках единой системы SQL-агент отвечает за генерацию и выполнение запросов к базе данных, а затем передает полученные данные Charting Agent. Например, SQL-агент формирует запрос для извлечения данных о продажах, а Charting Agent строит на его основе диаграмму.

Помимо агентов для работы с SQL и визуализацией, в будущем могут быть добавлены и другие специализированные агенты, такие как:

• Агент поиска отчетов, который помогает находить релевантные дашборды.
• Агент подготовки аналитических материалов, создающий текстовые выводы и презентации.

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

Подходы к коммуникации между агентами

Существует несколько схем взаимодействия агентов в мультиагентных системах:

1. Групповой чат. Все агенты общаются как равноправные участники, свободно обмениваясь информацией.
2. Парное взаимодействие (pairwise chat). Агенты взаимодействуют друг с другом через последовательные запросы, где один агент инициирует запрос, а другой отвечает.
3. Иерархическая структура (hierarchical chat). Один агент выполняет роль планировщика (planner) и координирует работу подчинённых агентов. Он разбивает общий запрос на подзадачи и назначает их выполнение соответствующим специализированным агентам.

Для решения сложных аналитических задач выбран именно иерархический подход. В этой модели планировщик отвечает за:

1. Разбиение пользовательского запроса на отдельные этапы.
2. Определение, какой специализированный агент должен обработать каждую подзадачу.
3. Координацию взаимодействия между агентами для последовательного и согласованного выполнения задачи.

Принцип работы иерархической мультиагентной системы

Работа системы организована следующим образом:

Пользовательский запрос. Пользователь задает комплексный аналитический вопрос, например: «Создай мне аналитический отчет с графиками по продажам».

Разбиение задачи. Планировщик (Planner) получает запрос и делит его на несколько подзадач:

1. Поиск релевантных данных в отчетах.
2. Генерация SQL-запроса (задача для SQL-агента).
3. Построение диаграмм (задача для Charting Agent).
4. Формирование презентации (задача для Slide Deck Agent).

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

1. SQL-агент получает запрос, формирует и выполняет SQL-запрос, после чего передает полученные данные Charting Agent.
2. Charting Agent создает график или диаграмму на основе данных и отправляет его Slide Deck Agent.
3. Slide Deck Agent собирает все элементы отчета, включая текстовые выводы и визуализации.
4. Сбор итогового результата. Планировщик агрегирует результаты всех подзадач и формирует финальный отчет, который затем передается пользователю или агенту, который использует мессенджеры или почту для рассылки результатов и готовых материалов заинтересованным пользователям.

Преимущества иерархической структуры

Использование иерархического управления в мультиагентной системе дает несколько ключевых преимуществ:

1. Гибкость. Возможность добавлять новые специализированные агенты без изменения общей логики системы. При необходимости можно интегрировать дополнительные модули для решения узкоспециализированных задач.
2. Координация. Планировщик управляет распределением подзадач, предотвращая дублирование работы и обеспечивая правильную последовательность выполнения операций.
3. Единая история взаимодействий. Агенты обмениваются данными, что позволяет сохранять контекст и обеспечивает логичность и согласованность всего процесса обработки запроса.
4. Автоматическое переключение агентов. Если комплексный запрос требует участия нескольких агентов, система автоматически передает задачи между ними без участия пользователя, что снижает нагрузку на конечного пользователя и ускоряет процесс.

Расширение возможностей мультиагентной системы

Построенная архитектура легко масштабируется и может быть расширена путем добавления новых агентов, таких как:

1. Агент поиска по корпоративным письмам. Анализирует электронную почту для извлечения релевантной информации.
2. Агент написания отчетов. Формирует текстовые аналитические выводы, объединяя результаты работы других агентов.
3. Агент автоматического создания презентаций. Собирает данные, визуализации и текстовые выводы в единый документ, готовый для демонстрации на встречах.

Заключение

Мы рассмотрели, как современные AI-технологии могут использоваться в аналитике данных и BI. Использование LLM, RAG, AI-агентов и мультиагентных систем позволяет автоматизировать сложные процессы — от генерации SQL-запросов до создания визуализаций.

Платформа Epsilon Workspace, как no-code решение, демонстрирует, что AI-инструменты могут стать доступными каждому, сократить время и затраты на обработку запросов и снизить нагрузку на аналитиков данных и дата-инженеров.

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

 Запишитесь к нам на демонстрацию, и мы расскажем, как быстро внедрить AI-агентов и сделать вашу BI-систему ещё более удобной и полезной.