Conversational BI: Архитектура двухслойного LLM-агента с семантическим слоем

Внедрение генеративного AI в корпоративную аналитику долгое время шло по тупиковому пути прямой генерации кода (Text-to-SQL) одной монолитной языковой моделью. На практике этот подход сталкивается с тремя барьерами: галлюцинации в enterprise-метриках, риск SQL-инъекций и высокая стоимость запросов при обработке простых диалоговых фраз дорогой моделью.

Эффективное решение этих проблем — переход к мультиагентным системам с разделением ответственности и детерминированным контрактом данных. Ниже представлена архитектура Conversational BI, построенная по схеме Intent LLM, Smart LLM, Semantic Layer и Data Analysis Layer. Диалог поверх BI упирается в слой моделей, который предсказывает, а не только читает данные. Разработка систем предиктивной аналитики.

Обзор концептуальной архитектуры

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

       [ Пользователь ]
               │
               ▼ (1. Живой язык: "Какая выручка по застройщику YoY?")
┌──────────────────────────────────────────────┐
│          1. Слой Диспетчеризации             │
│                (Intent LLM)                  │
├──────────────────────────────────────────────┤
│ • Память контекста и сессии пользователя     │
│ • Бизнес-ограничения темы (Локальный RAG)    │
│ • Реестр возможностей (Capabilities)         │
└──────────────────────┬───────────────────────┘
                       │
                       ▼ (2. Маршрутизация: только аналитический интент)
┌──────────────────────────────────────────────┐
│            2. Слой Аналитики                 │
│                (Smart LLM)                   │
├──────────────────────────────────────────────┤
│ • Валидация входных сущностей                │
│ • Выделение метрик, разрезов, фильтров       │
│ • Генерация Structured Output (Strict JSON)  │
└──────────────────────┬───────────────────────┘
                       │
                       ▼ (3. Детерминированный JSON-контракт)
┌──────────────────────────────────────────────┐
│           3. Семантический слой              │
│            (Semantic Layer / API)            │
├──────────────────────────────────────────────┤
│ • Валидация комбинаций параметров            │
│ • Динамическая сборка безопасного запроса    │
│ • Оркестрация Data Analysis Layer            │
└──────────────────────┬───────────────────────┘
                       │
                       ▼ (4. Безопасный SQL / Выполнение в DWH)
┌──────────────────────────────────────────────┐
│         4. Слой хранения и расчета           │
│             (Data Storage & OLAP)            │
└──────────────────────────────────────────────┘

Детальный разбор слоев и зон ответственности

1. Слой диспетчеризации (Intent LLM)

Этот слой работает как фронт-офис системы: он фильтрует входящий поток запросов и удерживает контекст беседы. Подходит легковесная модель с низкой ценой токена (GPT-4o-mini или Llama-3-8B). Она хранит историю переписки, поэтому если пользователь сначала спросил про Москву, а потом написал «а по застройщику?», слой соединяет оба запроса в один контекст. В локальной базе знаний лежат инструкции о темах, на которые система отвечать не должна, а реестр возможностей держит верхнеуровневый список инструментов: модель знает, что система работает с аналитикой, но не видит имён таблиц и колонок. На приветствии или смолл-токе слой отвечает сам, а при аналитическом интенте вызывает инструмент (Tool Calling) и передаёт задачу на второй слой.

2. Слой аналитики (Smart LLM)

Это бэк-офис системы, изолированный от пользователя. Его единственная задача — переводить живую речь в жёсткую структуру данных. Здесь работает тяжёлая модель с развитым логическим мышлением (GPT-4o или DeepSeek-V3), настроенная на Structured Output. Запрос делится на четыре части куба данных: метрики (выручка, прибыль, EBITDA, продажи), разрезы (город, регион, застройщик), фильтры (метро рядом, дата стройки, статус сдачи) и сравнения (год к году, месяц к месяцу). На выходе — только валидный JSON по строгой схеме, без свободного текста.

3. Семантический слой (Semantic Layer)

Это критический компонент на классическом бэкенд-коде, без ИИ. Он отвечает за безопасность и бизнес-логику. При старте бэкенд сканирует базу данных и загружает матрицу разрешённых параметров. Полученный от Smart LLM JSON проверяется на совместимость параметров: если метрику выручки пытаются посчитать в неверном разрезе, слой прерывает запрос до обращения к базе. Доступ модели к структуре базы закрыт, она оперирует абстрактными терминами, а безопасный параметризованный SQL собирает сам слой.

4. Слой анализа и хранения данных (Data Analysis Layer)

Финальный этап агрегации. Семантический слой отправляет безопасный запрос в DWH или OLAP-куб (ClickHouse, PostgreSQL, Greenplum) и получает сырой массив данных. Метрики живут в ERP, а не в BI-кубе; интеграция решает, откуда их брать. Интеграция ИИ с ERP.

Жизненный цикл одного запроса (Data Flow)

Рассмотрим обработку аналитического запроса в динамике:

Пользователь пишет в чат: «Какая выручка по застройщику в Москве в сравнении год к году?»
Intent LLM определяет аналитический интент, собирает контекст и передает очищенный запрос на второй слой.

Smart LLM анализирует текст и выдает JSON:

{
  "metrics": "Revenue",
  "dimensions": ["zastroyshik"],
  "filters": [
    {"field": "city", "operator": "EQUALS", "value": "Moskva"}
  ],
  "comparison": "YoY"
}

Семантический слой проверяет JSON по матрице правил, собирает безопасный SQL-шаблон и отправляет его в базу данных.
База данных выполняет расчет и возвращает цифры: [{zastroyshik: "ПИК", revenue_2025: 100M, revenue_2026: 112M, change: +12%}].
Обратный поток:
- Данные возвращаются в Smart LLM, которая формулирует текстовый инсайт («В Москве выручка застройщика ПИК выросла на 12% год к году…») и указывает тип UI-компонента ({"ui_component": "LineChart"}).
- Intent LLM отправляет пользователю готовый виджет с графиком и пояснением.

Архитектурные преимущества

Модель передаёт семантическому слою параметры выборки и не вычисляет значения сама, поэтому цифры предсказуемы, а неверный запрос возвращает ошибку вместо галлюцинации. По нашим логам, около трети сообщений в корпоративных чатах — это приветствия, уточнения или опечатки, и маршрутизация их в дешёвый Intent LLM экономит до 60% бюджета на токены. Прямой доступ языковой модели к командам СУБД закрыт, что снимает риск SQL-инъекций. При изменении схемы базы не нужно переобучать модель: достаточно обновить маппинг в семантическом слое. Двухслойная схема — это проект разработки: семантический слой, API и оркестрация запросов. Разработка программного обеспечения.

Ограничения

Семантический слой не настраивается один раз и навсегда. При изменении структуры DWH маппинг обновляют вручную, и без владельца слоя он устаревает за несколько релизов. Набор доступных запросов ограничен описанной матрицей: ad-hoc-вопрос вне неё система не выполнит, даже если данные в базе есть.

Классификатор интентов ошибается на новых формулировках метрик. Если пользователи начинают называть выручку «оборотом», часть запросов уходит не в тот слой, и их приходится размечать заново. Две модели вместо одной дают два счёта. Дешёвый Intent LLM не отменяет расход на Smart LLM для сложных запросов, и экономия появляется только на потоках, где простых фраз около трети.