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

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

И посмотрим, что из этого выходит.

Разрыв с реальностью

Новый дивный мир LLM привил многим из нас любовь к различным бенчмаркам, и индустрию аналитических решений бенчмарк-мания не обошла стороной: вот и мы давайте возьмем популярный «бенч» BIRD, используемый для оценки качества text2SQL, - видим, что лидер российского сегмента рынка там Sber Text2SQL показывает результаты по execution accuracy на уровне 81,33 %( это третий результат бенчмарка), который уже сравним с человеческим «бейзлайном» в 92,96 %. И с одной стороны звучит так, будто задача Text2SQL уже почти решена.

Но если посмотреть не на ситуацию «сферического коня», а на ту, что диктуется реальностью и сложностями практического трансфера технологий в бизнес, где датасеты взяты из реальных корпоративных хранилищ, а запросы из живой истории обращений, то видится явный разрыв между ожиданиями и реальностью. Построенный по принципу эмуляции реальности BEAVER бенчмарк показывает, что даже наиболее прогрессивный «ванильный» агентский подход даёт лишь 11,4 % execution accuracy.

Получаем такой шок разрыв :)

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

Размер схемы. В базах BEAVER в среднем 101,5 таблицы и 869,4 колонки. В BIRD — 6,8 таблицы и 72,5 колонки.

Проблемы именования. Корпоративные схемы состоят из всяких нечленораздельных SIS_SUBJECT_CODE и FCLT_ROOMS, а не из красивых и понятных orders и customers. Семантика не заложена в наименование таблиц и полей.

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

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

Таким образом, видим, что умение аналитического решения поддерживать отраслевой и корпоративный контекст выходит на первый план при выборе вендора аналитического AI-powered решения:

• «У нас закупки живут по внутреннему регламенту на 90 страниц»

• «У нас операционные цифры по производству и запасам 1С, продажи и промо раскиданы по двум другим системам, витрин пока нет»

• «Наше ИБ не выпустит ничего наружу»

• «Коммерческий не будет залезать на BI-портал - нужна понятная картинка в месссенджере»

• Сможет ваша система такое поддержать?

«Близость к клиенту» становится must have.

Если переложить это в набор архитектурных требований к решению, то платформа должна принимать в себя чужую специфику, не распадаясь на форк под каждого заказчика - выделим 5 блоков, в разрезе которых рассмотрим «идеальное» аналитическое решение 2026:

Чем ответил российский рынок

К 2026 году ИИ-слой появился почти у каждой российской BI-платформы. Заходят вендоры с разных сторон, и разложить их удобно по тем же пяти осям — видно, где каждый считает узкое место.

Luxms BI в версии 12 добавил «ИИ-аналитика», который создаёт кубы и аналитические модели данных, формирует дашборды и отчёты по запросу пользователя и объясняет полученные результаты, а общение идёт на естественном языке без специальных промптов. Отдельно заявлена поддержка локальных моделей, когда данные остаются внутри корпоративного контура. Форма поставки ИИ: как расширение платформы, которое требует отдельного лицензирования.

Modus BI зашёл через MCP. Команда написала собственный сервер modusbi-mcp и поставила эксперимент: человек без опыта в SQL и статистике за четыре часа собирал дашборды по базе из сотен тысяч записей. Ценно, что ребята подсветили не только возможности, но и точки роста системы: тип диаграммы не всегда угадывался с первого раза, подписи осей и сортировку приходилось уточнять, а на сложных взаимосвязях, по их формулировке, «человек все равно необходим». Ускорение разведки данных они оценивают в 5–10 раз, а готовые дашборды, по их же выводу, удобнее крутить фильтрами в BI-платформе, чем перегенерировать через LLM на каждый вопрос.

Raft AI4BI - наша команда по пути локализации и доработки проверенной временем открытой платформы Apache Superset, фокусируясь на доступности аналитики для клиента: мультиагентной обвязке решения, дающей возможность поддержать отраслевую и бизнес-функциональную специфику за счет ансамбля моделей с возможностью подключения к решению RAG слоя и предиктивов, на интеграционном слое, позволяющем стартовать с «низкой» базы из разрозненных информационных систем, не сведенных в моменте в единый аналитический слой, гибком формате поставки - от облака до ПАКа, поддержке формата работы, близкого конечному пользователю - с подстройкой ролевой модели и интерфейса взаимодействия с решением.

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

Крупные игроки также закрывают потребность «близости к клиенту» внутри своих решений: Visiology встроил собственную LLM Visiology Cortex поверх аналитического движка DanKo, Yandex DataLens недвано представил обновленного ассистента «Нейроаналитик 2.0».

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

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

Отраслевая специфика

Любая аналитическая платформа по своей природе отрасль-агностик: она не знает, что такое «выход годного», «оборачиваемость по SKU» или «xG» - это состояние по умолчанию, т.к. отраслевую логику, зашитую в код продукта, невозможно ни отладить, ни перенести на следующего заказчика.

Есть два пути добавления нужного отраслевого контекста в решение.

Семантический слой

Семантический слой сам по себе не новость: dbt Semantic Layer, Cube, LookML, семантические модели Power BI, AtScale - этот класс инструментов сложился еще до всякого генеративного ИИ для согласованности метрик между отчётами. С приходом LLM в аналитику он из удобства превратился в условие работоспособности, потому что сообщает модели ровно то, чего ей не хватает: расшифровку имён, определения метрик и доменные правила.

В платформах с ИИ-ассистентом это обычно каталог витрин: карточки датасетов, где у каждой колонки есть человекочитаемое название, у каждой метрики готовая формула, а у бизнес-терминов список синонимов. Модель при формировании SQL получает не голую схему t_sls_fct(dt, sku_id, qty, amt), а описание на языке организации.

Схематично карточка выглядит так:

dataset: sales_fact
title: Продажи, факт
description: Отгрузки по завершённым заказам, без возвратов
columns:
  - name: amt
    title: Выручка
    unit: RUB
    vat: excluded
    synonyms: [оборот, товарооборот, revenue, продажи в деньгах]
  - name: dt
    title: Дата отгрузки
    role: time
metrics:
  - name: gmv
    title: GMV
    expression: SUM(amt)
    filters: "status = 'completed' AND is_test = false"
  - name: turnover_days
    title: Оборачиваемость, дни
    expression: AVG(stock_qty) / NULLIF(SUM(qty) / 30, 0)
calendar:
  fiscal_year_start: "04-01"
  periods: [MTD, QTD, YTD]

Три вещи из этого фрагмента объясняют, почему каталог работает лучше, чем «умный промпт».

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

Во-вторых, единицы измерения, валюта, НДС и часовые пояса, заданные в метаданных.

В-третьих, описанный явно финансовый календарь. Если финансовый год в компании начинается с апреля, то «первый квартал» означает апрель–июнь, и LLM не догадается об этом самостоятельно.

Ансамбль моделей

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

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

Шаг распознавания намерения самый чувствительный к отраслевому глоссарию и самый дешёвый по контексту - именно в него подключается отраслевая модель: в металлургии, например, недавно вышла отраслевая модель MetalML от Норникеля, помогающая точнее распознать, о чём именно спросил пользователь, и передать дальше нормализованный интент.

Генерация SQL и выбор визуализации остаются на общих шагах конвейера.

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

Бизнес-функциональная специфика

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

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

Разница видна на одном примере.

FMCG компания, направление непрямых закупок.

Вопрос пользователя: «Покажи закупки по категории "ремонт оборудования" за второй квартал и отметь проблемные».

Без базы знаний ассистент отвечает корректно, но не слишком полезно: 47 закупок на 62 миллиона рублей, топ поставщиков, распределение по месяцам, аномально крупная позиция на 11 миллионов. Ответ верный, а что с ним делать непонятно: «проблему» система определила статистически, по отклонению от среднего.

С подключённым регламентом ассистент сначала подтягивает из базы знаний правила: пороги конкурентных процедур, срок публикации извещения, требования к обоснованию единственного поставщика, лимит на дробление закупки. И возвращает уже список нарушений конкретных пунктов — пять договоров с одним поставщиком по 480 тысяч рублей внутри месяца при пороге 500 тысяч, закупка на 11 миллионов у единственного поставщика без обоснования, три процедуры с сокращённым сроком публикации.

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

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

Механизм от предметной области не зависит. В нашей практике он одинаково отработал в закупках, продажах, маркетинге, управлении запасами, производстве и финансах: меняется наполнение базы знаний, конвейер остаётся прежним.

IT ландшафт организации

Источники данных

Классические BI-платформы рассчитаны на структурированные витрины и подключаются на чтение к реляционным СУБД — PostgreSQL, MS SQL, ClickHouse, Greenplum и другим; учётная запись только на чтение, набор доступных таблиц и строк ограничивается представлениями на стороне источника.

Схема работает у заказчиков с построенным хранилищем, но у среднестатистического предприятия в России хранилища нет, а есть условный 1С, в которой лежит всё: продажи, закупки, склад, взаиморасчёты. Просить такого заказчика сначала выстроить DWH значит отодвинуть сроки пилота на полгода-год, поэтому в интеграционном слое каждого решения появляется экстрактор из 1С: он забирает регистры и справочники и раскладывает их в плоские витрины на стороне платформы, чтобы дать возможность построить в точке Proof-of-Concept решение с полной перезаливкой витрин, без инкрементального обновления. Этого хватает, чтобы апробировать систему и точечно подтвердить эффекты, чтобы пойти в более глубокую проработку промышленного варианта системы и бесшовный переход к масштабированию.

Интерфейс пользователя

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

Поэтому ассистент живёт и ввеб-интерфейсе платформы, и там, где у компании уже идёт рабочая переписка: в корпоративном мессенджере:

1. Пользователь пишет боту в личный чат или упоминает его в канале.

2. Мост определяет пользователя по учётной записи и подставляет его права - RBAC и ограничения на уровне строк и полей работают ровно так же, как в вебе.

3. Вопрос уходит в конвейер ассистента; SQL исполняется внутри контура.

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

Инфраструктура

Ограничения инфраструктуры приходят от ИБ и от ИТ служб, формируя набор «нельзя»: нельзя запускаться в облаке, нельзя выпускать данные за периметр, нельзя закупить отдельно GPU и т.д.

Рынок к 2026 году сходится на четырёх форматах поставки, покрывающих основные «нельзя»:

Для сценариев полной изоляции модель разворачивается локально, и исходящий трафик пропадает совсем. В остальных случаях поставщик выбирается - в примере AI4BI, например, это пратнерское облако Cloud.ru Foundation Models, OpenRouter, локальная модель, - а переключение между ними задаётся настройкой, поэтому смена провайдера не превращается в переписывание приложения.

Отдельный слой требований - регуляторный. Соответствие 152-ФЗ (УЗ-1), 187-ФЗ, ГОСТ Р 57580.1 и аттестаты ФСТЭК и ФСБ России подтверждаются обычно на уровне инфраструктурного провайдера, а сама платформа наследует их от площадки. Архитектура добавляет к этому одно свойство: за периметр уходят только заголовки и токенизированные агрегаты, поэтому персональные данные и содержимое витрин внешняя модель не видит.

Команда

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

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

Возьмём один и тот же вопрос - «что с закупками в этом квартале» - и посмотрим, что получают разные роли.

Коммерческий директор. Три-четыре цифры и вывод: отклонение от плана в процентах и в деньгах, направление тренда, главная причина отклонения, одна рекомендация с оценкой эффекта. Горизонт — квартал к кварталу, визуализация — один чарт, читаемый с телефона. Ответ приходит в мессенджер, потому что в веб-интерфейс он не пойдёт.

Бизнес-аналитик направления закупок. Тот же вопрос разворачивается в разбор: динамика по номенклатурным группам, вклад каждой в отклонение, цены по поставщикам, отклонение срока поставки от договорного, позиции с ростом цены выше порога. И SQL под каждой цифрой — первое, что аналитик делает с ответом ассистента, это перепроверяет его.

Категорийный менеджер. Конкретные SKU и поставщики своей категории, остатки, заявки, ближайшие поставки, и ничего за пределами категории: так настроен RLS.

Здесь важно разделить два механизма, которые легко перепутать. Права доступа — RBAC плюс разграничение на уровне строк и полей: они определяют, что пользователь может увидеть, работают на уровне запроса и одинаковы во всех каналах. Ассистент физически не вернёт данные вне сегмента пользователя, потому что их нет в результате SQL. Сценарий роли — описание того, что пользователю полезно увидеть из доступного: он влияет на глубину, разрез и форму ответа, но прав не расширяет и не сужает.

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

Из этого же растёт требование, которое в идеале нужно готовить до старта любого внедрения: утверждённое описание бизнес-сценария с пояснением, какие вопросы и как должен обрабатывать ассистент и примеры пар «вопрос - ожидаемый ответ» по каждой роли.

Что пока не решено

Ниже приведем набор ограничений и требований, под которые дотсупные на рынке платформы пока не подстраивается:

Неструктурированные источники. Документы, переписка и изображения остаются за границами BI-платформы: она рассчитана на структурированные витрины и справочники, а RAG-контур принимает регламенты как контекст интерпретации, но не как источник цифр. Сценарии вида «проанализируй сканы актов» требуют отдельного решения.

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

Поиск закономерностей без наводки. Прямой запрос на поиск проблем отрабатывает надёжнее, чем открытое «найди что-нибудь интересное». Формулировка гипотезы пока остаётся за человеком: об этом и цифра 30,1 % на BEAVER с подсказанной декомпозицией, и вывод команды Modus про сложные взаимосвязи.

Заключение

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

В открывшемся в 2022 году вакууме и развернувшейся конкурентной борьбе за пользователя многие отечественные вендоры оказались готовы пройти «extra mile» для того, чтобы обеспечить организации-клиенту возможность пройти наиболее короткой дорогой от внедрения аналитики до получения первых значимых бизнес-эффектов. Растет доступность решений - причем, как экономическая, так и экспертная: теперь, чтобы получать полноценную отдачу от системы, нет необходимости в большом штате аналитиков, большая часть ответов на типовые запросы может быть получена «гражданскими» бизнес-пользователями напрямую из системы.

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

Алексей Бобок,
AI‑трансформация, Рафт
Делюсь опытом внедрения ИИ в бизнес через поиск максимальной ценности:
Не ИИ мозги https://t.me/aibobok