LLM в бизнес-аналитике: SQL, отчёты и проверка результатов

Обновлено 3 сентября 2026 года.

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

Какие задачи можно передать LLM

Разделяйте генерацию решения и его исполнение. Модель может предложить код преобразования, а обработка выполняется проверяемым скриптом. Аналогично суммы и статистические показатели удобнее вычислять в SQL, Python или BI-модели, а LLM поручать объяснение полученных результатов.

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

Как устроить запросы к базе на естественном языке

Рабочая схема: вопрос пользователя → описание показателя и разрешённой модели → предложение запроса → проверка в приложении → исполнение в СУБД → таблица результата → пояснение. Само по себе подключение чата к PostgreSQL эту цепочку не создаёт.

Модели нужны не только названия таблиц. В контекст включают значение одной строки, связи, ключи, определения показателей, допустимые статусы, валюту, часовой пояс и доступный исторический период. Слова «продажи» могут означать сумму сделок, отгрузки, выручку или оплаты. Если определения нет, сначала требуется уточнение.

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

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

Как ограничить доступ и нагрузку

• Проверяйте права конкретного пользователя до запроса к данным. Общая учётная запись бота не должна превращать закрытые таблицы в доступные всем.
• Используйте отдельную роль базы с минимальными правами, разрешённые схемы и представления. Для аналитического сценария не нужны права владельца или администратора.
• Ограничивайте время исполнения, число одновременных запросов и объём выдачи. Маленький результат может потребовать большого сканирования или тяжёлого соединения.
• Не считайте проверку первого слова SELECT достаточной защитой: выражение может вызвать функции, обратиться к лишним данным или создать высокую нагрузку.
• Передавайте секреты средствами приложения. Пароли и токены не должны попадать в текст вопроса или вывод модели.
• Сохраняйте для разбора ошибок вопрос, версию модели данных, выполненный запрос, параметры и время загрузки источника с учётом принятой политики хранения.

Ограничения должны действовать в приложении и базе. Инструкция в промпте «не показывать финансовые данные» не заменяет разграничение прав.

Объяснение графиков: наблюдение и причина — разные выводы

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

Если выручка выросла с 100 до 120 тыс. ₽, наблюдаемое изменение составляет 20%. Сам график не доказывает, что рост вызван рекламной кампанией. Для такого вывода нужны дополнительные данные и подход к оценке эффекта: например, корректно организованный эксперимент или обоснованная аналитическая модель.

Полезный ответ показывает период, значение, сравнение, источник и ограничения. Например: «Выручка за полный август выросла на 20% к июлю; расходы на рекламу не переданы, поэтому влияние кампании не оценено». Неполный текущий месяц нельзя без оговорки сравнивать с полным предыдущим.

Актуальные возможности BI-платформ

Power BI Copilot

Copilot помогает создавать и объяснять отчёты и работать с моделью. Доступ зависит от сценария, прав и настроек организации. Для Power BI Desktop Microsoft указывает доступ к рабочей области на оплачиваемой Fabric capacity F2 или выше либо Power BI Premium P1 или выше с включённым Copilot. Также важна настройка Copilot на уровне tenant. Одна персональная лицензия не означает доступность всех AI-функций. См. текущие требования Desktop.

Универсальное описание «Copilot всегда работает на GPT-4» быстро устаревает и не определяет поведение продукта. Для проекта важнее проверить поддерживаемые действия, языки, регион, ограничения и качество на своей семантической модели.

Apache Superset и Preset

Preset — отдельный продукт на основе Superset. Его AI-возможности нельзя автоматически приписывать любой самостоятельной установке Apache Superset.

В официальной документации Superset ветки Next описана интеграция с AI-клиентами через MCP: изучение наборов данных, SQL, графики и дашборды. Страница указывает Superset 5.0+ и необходимость включить и развернуть MCP-сервер администратором. Это повод проверить совместимость своей установленной версии, доступный пакет и конфигурацию, а не обещание, что чат уже есть в каждом интерфейсе. См. Using AI with Superset.

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

Tableau

Tableau Data Stories закрыт в Tableau Desktop, Cloud и Server в январе 2025 года, в версии 2025.1. Строить новое решение на этой функции не следует. Вендор направляет пользователей к развитию Tableau Pulse и Tableau AI; конкретные возможности и условия нужно проверять для выбранной поставки. Источник — официальное уведомление Tableau.

LLM в Битрикс24: работа с коммуникациями

AI-помощник, ранее называвшийся CoPilot, в актуальной справке называется BitrixGPT. Он используется для работы с текстом и задачами, а AI в CRM — для расшифровки, резюме и обработки коммуникаций. Названия в отдельных инструкциях и интерфейсах могут различаться. См. справку по инструментам Битрикс24.

В сценарии обработки звонка возможны расшифровка, резюме, заполнение полей CRM и оценка разговора по скрипту. Автоматическая обработка требует подписки BitrixGPT + Маркетплейс. Это не гарантия заполнения произвольных полей без ошибок: результат зависит от записи, содержания разговора и настройки карточки. Описания полей должны быть понятны, а извлечённые суммы и договорённости стоит сверять. См. речевую аналитику.

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

RAG, обучение и доступ к свежим данным

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

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

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

Конфиденциальность и prompt injection

Условия обработки зависят от продукта, тарифа, региона и настроек. «Данные не используются для обучения» не означает «ничего нигде не хранится». Отдельно проверяют историю чатов, журналы, сроки удаления, внешних обработчиков и передачу между сервисами. Например, у Fabric есть настройки обработки и хранения за пределами географической области capacity и отдельные правила для истории разговоров. См. настройки Copilot и агентов.

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

Prompt injection — попытка изменить поведение помощника инструкциями внутри входных данных. Например, текст обращения может требовать выгрузить другие записи или изменить правила ответа. Данные из CRM, документов и сайтов следует рассматривать как данные, а разрешения на действия контролировать вне модели. RAG и дообучение полностью эту угрозу не устраняют. См. описание OWASP.

Как оценить пилот

1. Выберите ограниченную задачу: например, ответы по одной проверенной витрине продаж.
2. Подготовьте вопросы и эталонные результаты, включая неоднозначные запросы, пустые выборки, возвраты, смену периода и ограничения доступа.
3. Отдельно измеряйте корректность SQL, совпадение чисел и достоверность текстового объяснения.
4. Проверяйте уместные уточнения и отказы при недостатке данных. Ответ любой ценой не является хорошим результатом.
5. Измеряйте время до проверенного ответа, стоимость запросов и трудозатраты на исправления.
6. Повторяйте проверку после смены модели, промптов, инструментов или схемы данных.

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