Перейти к содержанию

Glarus AI: подключение к Glarus BI и возможности платформы

Документ описывает как получить доступ к Glarus AI — self-hosted платформе для работы с ИИ-агентами, интегрированной с Glarus BI через MCP — и какие встроенные инструменты она предоставляет для построения ИИ-решений под конкретные бизнес-цели.

Для клиентов из РФ

Glarus AI поддерживает два рекомендуемых класса LLM-провайдеров: российский облачный MWS GPT (152-ФЗ, УЗ-1) и локально развёрнутые модели (Ollama и совместимые серверы). Иностранные облачные LLM (Claude, OpenAI, Gemini) технически подключаются через российские прокси, но для сценариев с персональными данными не рекомендуются.

Выбор провайдера определяет юрисдикцию данных и применимость 152-ФЗ — см. "Соответствие требованиям РФ: 152-ФЗ, DPA". Полный список провайдеров и параметры подключения — на странице "Поддерживаемые LLM-провайдеры".


Что такое Glarus AI

Glarus AI — корпоративная платформа для разработки, координации и эксплуатации ИИ-агентов, развёрнутая на инфраструктуре заказчика. Построена на базе open-source LibreChat с брендингом и расширениями Glarus Digital. Ключевые свойства:

  • Мульти-LLM из коробки: подключение моделей разных провайдеров, переключение в один клик в окне чата.
  • Встроенный MCP-клиент: Glarus BI с набором инструментов, разрешённым администратором; дополнительные MCP-серверы подключаются по настройке.
  • Multi-tenant с RLS/CLS: агенты наследуют права доступа пользователя в Glarus BI.
  • Администрирование: регистрация закрыта, пользователей создаёт администратор; весь журнал запросов хранится в MongoDB.
  • Русскоязычный интерфейс и поддержка запросов на русском; отдельные элементы могут оставаться на английском.

В отличие от Claude Desktop, пользователю не нужно самому настраивать MCP-конфиг — платформа делает это централизованно.

Поддерживаемые LLM-модели

Glarus AI модельно-агностичен. Регистрация провайдеров и выдача доступа к моделям выполняются инженером поддержки Glarus при установке системы.

Класс Примеры Юрисдикция данных Когда выбирать
Российские облачные MWS GPT (70+ моделей — DeepSeek, Qwen, Llama, GigaChat, Cotype и др.) РФ работа с ПД, соответствие 152-ФЗ без дополнительных мер, SLA в РФ
Локальные (on-prem) Ollama и совместимые серверы (Llama 3.3, Qwen 2.5, DeepSeek-R1, T-Pro) периметр заказчика максимальная изоляция, закрытые контуры
Иностранные облачные через российский прокси Claude 4.6, GPT-4o, Gemini 2.5 Pro США / ЕС ограниченно, только для данных без ПД

Полная инструкция по подключению каждого класса — на странице "Поддерживаемые LLM-провайдеры".


Шаг 1. Получить доступ

  1. Запросите у администратора URL инстанса (например https://url.glarus-ai.ru) и учётные данные.
  2. Войдите через веб-браузер.
  3. В боковой панели выберите агента из предустановленных или создайте нового (см. ниже).

Шаг 2. MCP уже подключён

Подключение настраивается администратором в серверном librechat.yaml. Основной режим — per-request: MCP-клиент передаёт сессию текущего пользователя, а общий ключ API в конфигурации не используется. Режим данных необходимо задать явно: metadata ограничивает ответы метаданными; full разрешает возврат данных в пределах прав пользователя. Пример режима «только метаданные»:

mcpServers:
  glarusbi-demo:
    command: java
    args:
      - "-jar"
      - "/app/custom-assets/glarusbi-mcp-server.jar"
      - "--glarusbi.license.file=/app/custom-assets/glarusbi.lic"
      - "--glarusbi.api.url=https://url.glarus-analytics.ru"
      - "--glarusbi.mcp.authMode=per-request"
      - "--glarusbi.mcp.dataMode=metadata"
      - "--glarusbi.mcp.mode=extended"
      - "--glarusbi.mcp.maxRows=10000"
      - "--glarusbi.mcp.maxFields=1000"
      - "--glarusbi.mcp.maxItems=500"

Пользователь получает инструменты, разрешённые администратором и режимом данных: работа со схемой, запросами, моделями, карточками и дашбордами. В metadata строки результатов не возвращаются, а часть инструментов публикации и выгрузки недоступна. Загрузка Excel через MCP отключена. Локальный MCP-конфиг пользователю не требуется.


Встроенные инструменты для разработки, координации и управления ИИ-агентами

1. UI-конструктор агентов

Администратор или продвинутый пользователь создаёт агента прямо в интерфейсе:

  • Инструкции конкретного агента — основная инструкция, бизнес-контекст и тон ответа.
  • Выбор модели — любая из подключённых LLM.
  • Подключаемые MCP-серверы — Glarus BI, плюс любые дополнительные (OData 1С, документация, внутренние API).
  • Skills — многократно используемые блоки знаний (глоссарий, финансовый календарь, правила расчёта метрик), подключаемые к нескольким агентам.
  • Файлы-контекст — PDF, DOCX, XLSX, TXT, которые агент использует как справочный материал или RAG-источник.

2. Мультиагентность и специализация под роли

Несколько агентов с разными промптами работают над общими данными. Пример:

Агент Фокус Типовые вопросы
glarus-expert Универсальный аналитик над данными портфеля «Какова брутто-премия за 2024?»
Финансовый директор Loss ratio, combined ratio, P&L, рентабельность «Какие классы покрытия генерируют прибыль?»
Андеррайтер Концентрация рисков, лимиты, дедактиблы, спецакцептансы «Какие территории наиболее рискованные?»
Операционист Статусы договоров, документооборот, сроки, незакрытые убытки «Какие договоры истекают в ближайший месяц?»

Один и тот же вопрос («Какие риски ты видишь в портфеле за 2024 год?»), заданный разным агентам, даёт разные ответы в терминах соответствующей роли.

3. BYOM: выбор и замена LLM

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

4. Координация: полный цикл insight → action

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

  • выполнить запрос к данным (executeGlarusBIQuery);
  • создать карточку с визуализацией (createGlarusBIQueryCard);
  • собрать дашборд (createGlarusBIDashboard, addCardToDashboardTab);
  • опубликовать публичную ссылку (createPublicDashboardLink);
  • настроить подписку с e-mail рассылкой (createDashboardSubscription);
  • создать бизнес-метрику или модель (createGlarusBIMetric, createGlarusBIModel).

Пример промпта: «Создай дашборд "Обзор портфеля 2024" с 4 карточками: динамика брутто-премии, распределение по классам покрытия, убыточность по территориям, число активных договоров» — агент выполняет всю цепочку автономно.

5. Наблюдаемость и аудит

Все сообщения пишутся в MongoDB коллекции messages. Пример:

docker exec chat-mongodb mongosh --eval \
  "db.messages.find({sender:'User'},{text:1,user:1,createdAt:1}).sort({createdAt:-1}).limit(5).pretty()"

Видны: кто, когда, что спросил, какой был ответ, какие MCP tool calls сделаны (SQL, параметры). Администратор может подготовить ручные выборки по журналу и учёту токенов; отдельного встроенного дашборда аналитики использования нет.

Что именно логируется и где хранится

  • Содержимое логов: текст промпта пользователя, цепочка вызовов MCP-инструментов, текст ответа модели, временные метки, идентификатор пользователя.
  • Место хранения: MongoDB, развёрнутый в контуре заказчика. Передача контекста модели зависит от выбранного провайдера и конфигурации подключения.
  • Хранение: сроки хранения и удаление переписки настраиваются администратором развёртывания; фиксированный срок 90 дней не гарантируется.
  • Режим данных MCP: dataMode=metadata ограничивает содержимое ответов инструментов, но не отключает запись переписки в MongoDB.

Выбор режима логирования должен быть согласован с ИБ-службой заказчика. Детали — в "Соответствие требованиям РФ: 152-ФЗ, DPA".

6. Наследование прав (RLS/CLS)

В режиме glarusbi.mcp.authMode=per-request MCP-клиент передаёт сессию пользователя в каждом вызове; Glarus BI проверяет его права доступа. Если настроены ограничения строк и столбцов, они применяются на стороне Glarus BI. Общий ключ API означает другой, статический режим: он не обеспечивает выполнение от имени каждого пользователя. Администратор отдельно задаёт dataMode и перечень инструментов, доступных агенту.


Работа с неструктурированными данными

Glarus AI поддерживает несколько классов неструктурированных источников:

Ad-hoc загрузка Excel / CSV

Инструмент loadExcelToDatabase в текущем MCP-сервере отключён: он возвращает UNSUPPORTED и не загружает файл. Загрузите Excel через интерфейс Glarus BI, затем сообщите агенту имя созданной таблицы. Анализ данных возможен при разрешённых инструментах и режиме full. Примеры дальнейшего анализа:

  • Проверка качества данных: загружен список сотрудников с дублями ФИО+должность+отдел. Промпт: «Проанализируй данные по сотрудникам, всё ли корректно?» — агент находит дубликаты и предупреждает.
  • Пропущенные колонки: загружен список заказов без поля «Сумма». Промпт: «Посчитай суммарный объём продаж за Q1» — агент сообщает, что данных по суммам нет, запрос невыполним.
  • Проверка на предвзятость: загружен датасет зарплат по возрастным группам. Промпт: «Спрогнозируй динамику роста зарплат для каждой возрастной группы. Есть ли различия в прогнозах?»

Анализ текстовых полей БД

Многие таблицы содержат свободный текст (описания, комментарии). Пример:

«Проанализируй описания убытков и найди наиболее частые причины.»

Агент выполняет запрос к текстовому полю (например losses.description), кластеризует причины и возвращает сводку.

Файлы-контекст в чате

В переписку можно загружать PDF, DOCX, TXT как справочный контекст. Поиск по файлам настраивается администратором: используется сервис rag_api и отдельное векторное хранилище PostgreSQL с расширением pgvector. Обработка файлов и поиск зависят от конфигурации этих сервисов.

Русский язык по всей цепочке

Язык запроса и желаемого ответа задаёт пользователь. Расшифровки жаргона и аббревиатур лучше явно внести в инструкции агента или запрос: например, «Какой ЛР по карго за 24й?» → ЛР = loss ratio, карго = Грузы, 24й = 2024.


Комментирование дашбордов и виджетов

Агент может подготовить комментарий по всему дашборду или отдельному виджету. Для числового анализа администратор настраивает glarusbi.mcp.dataMode=full и разрешает нужные инструменты; пользователь должен иметь доступ к данным. В dataMode=metadata строки результатов модели не передаются, поэтому комментарий с фактическими значениями невозможен.

Сначала агент читает состав и вкладки через getGlarusBIDashboard и getGlarusBIDashboardCards, затем выполняет выбранные карточки через executeGlarusBICard. Укажите период и фильтры: при выполнении карточек их параметры нужно передать явно. Для вывода о динамике нужны сопоставимые периоды, а не только текущее значение.

«Прокомментируй дашборд „Продажи“ за сентябрь в деловом стиле для правления. Сравни с августом, приведи значения и изменения. Отдельно отметь ограничения данных».

Для одного виджета: «Опиши только виджет „Выручка“ тезисно» или «Объясни его динамику разговорно». Постоянный стиль задайте в поле инструкций конкретного агента; для повторных запросов можно сохранить пресет с нужной инструкцией, если пресеты включены администратором. Это сценарий чата, отдельная кнопка описания дашборда в BI не требуется. Проверяйте цифры по результатам вызовов инструментов.

Текстовые выводы агента на дашборде

После выполнения карточек агент формулирует выводы и добавляет Markdown через addTextCardToDashboard. Нужны права редактирования дашборда и разрешённый инструмент; для анализа чисел — режим full. Укажите дашборд и вкладку: инструмент принимает tabId, а без него выбирает первую вкладку, если она есть.

«Проанализируй дашборд „Продажи“ за сентябрь. Добавь на вкладку „Итоги“ текстовую карточку с тремя выводами, числовым обоснованием и датой анализа».

Текст сохраняется на дашборде и включается в письмо его подписки. Это статический Markdown: изменение данных не запускает новый анализ и не переписывает выводы. Повторно попросите агента выполнить актуальные запросы и обновить текстовый блок; проверьте дату и период в нём. Для настройки отправки см. регулярный бриф по KPI.

Анализ причин изменения показателя

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

«Почему выручка сентября ниже августа? Сравни суммы по территориям, покажи разницу в рублях и вклад каждой территории в общее снижение. Сохрани диаграмму-водопад. Отдели наблюдения от гипотез».

Учебный пример, вымышленные данные: «Выручка снизилась со 100 до 85 млн ₽, на 15%. Территория А: 60 → 48 млн ₽, изменение −12 млн ₽; территория Б: 40 → 37 млн ₽, −3 млн ₽. Это соответственно 80% и 20% общего снижения».

Для визуализации агент может сохранить результат SQL через createGlarusBIQueryCard с visualization=waterfall; см. диаграмму-водопад. Разложение показывает, где изменились суммы, и само по себе не доказывает причину. Отдельного движка статистической атрибуции Shapley или дерева причин нет; причинные объяснения требуют дополнительных проверок.

Рекомендации на основе данных

По результатам запросов агент предлагает действия и обосновывает их числами. Попросите для каждого действия показать исходные значения, SQL-расчёт «что если» на истории и допущения. Числа получает движок Glarus BI через executeGlarusBIQuery или executeGlarusBICard; нужны режим full, разрешённые инструменты и права на данные.

«Предложи действия для повышения маржинального дохода. На данных прошлого месяца рассчитай перенос 100 продаж из сегмента Б в А при неизменных объёме и марже единицы. Покажи расчёт и ограничения».

Учебный пример, вымышленные данные: «А: 600 единиц × 20 ₽; Б: 400 × 10 ₽. Итого 16 000 ₽. При переносе 100 единиц: 700 × 20 + 300 × 10 = 17 000 ₽, разница +1 000 ₽. Можно проверить возможность такого изменения структуры продаж».

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

Поиск аномалий и мониторинг по расписанию

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

«Найди аномалии в суммах убытков за квартал отдельно по классам. Покажи строки выше среднего на 3σ, период и метод расчёта. Сохрани правило и настрой ежедневное письмо только при найденных выбросах».

  1. В режиме full агент проверяет SQL через executeGlarusBIQuery и сохраняет запрос карточкой createGlarusBIQueryCard. Запрос должен возвращать сами строки выбросов, а при их отсутствии — ноль строк, не строку со счётчиком 0.
  2. Разместите карточку на отдельном дашборде через addCardToDashboardTab. Используйте относительный период в SQL, чтобы правило работало на новых данных.
  3. Через createDashboardSubscription задайте расписание, получателей и skipIfEmpty=true — «не отправлять, если результатов нет». Нужны разрешённые инструменты, права на создание подписки и настроенная администратором почта.

Отправка пропускается, когда пусты все карточки с данными: другая непустая KPI-карточка вызовет письмо даже без выбросов. Текстовые блоки считаются пустыми и этому не мешают. По расписанию BI выполняет сохранённый запрос и отправляет таблицу выбросов, а не новую сводку ИИ. В metadata подписки через MCP недоступны. ML-модели обнаружения аномалий и автономного агента-монитора нет.

Регулярный бриф по KPI

Агент может собрать дашборд KPI из сохранённых карточек, выполнить их, добавить выводы через addTextCardToDashboard и создать подписку через createDashboardSubscription. Для этого администратор разрешает инструменты и режим full, настраивает отправку; пользователю нужны права на данные, редактирование дашборда и создание подписок.

«Собери дашборд „Еженедельные KPI“: выручка, число заказов и маржинальный доход. Добавь текст с выводами за выбранную неделю и датой анализа. Настрой письмо по понедельникам в 09:00 для согласованных получателей».

У подписки указываются канал, расписание и получатели; проверьте часовой пояс и список адресов. В BI доступны подписки по email и в Telegram при настроенном администратором канале. Текстовая карточка входит в письмо email-подписки. Подробнее: подписки на дашборды.

По расписанию обновляются результаты запросов к данным, но текст выводов остаётся сохранённым. Повторно запросите анализ и обновление текста у агента. Планировщика повторных запросов к ИИ в чате нет; подписка BI сама его не вызывает. Так можно рассылать регулярный отчёт с датированным комментарием, но не автоматически пересчитанный AI-бриф.


Персональные права пользователя в запросах ассистента

Для многопользовательской установки администратор включает вход в Glarus AI через учётную запись Glarus BI и режим MCP glarusbi.mcp.authMode=per-request. Сервер чата получает сессию вошедшего пользователя и подставляет её в каждый вызов настроенного MCP-сервера BI. Аргументы сессии и идентификатора, предложенные моделью, предварительно отбрасываются. Без сессии сервер MCP отклоняет вызов с AUTH_REQUIRED.

Включите интеграцию входа GLARUS_BI_AUTH_ENABLED=true и согласуйте список BI MCP-серверов в конфигурации чата. В аргументах MCP используйте, например:

--glarusbi.mcp.authMode=per-request
--glarusbi.mcp.dataMode=full

Общий --glarusbi.api.key в этом режиме не нужен. full разрешает возврат данных в пределах прав; metadata ограничивает результат метаданными. Полный пример подключения — в разделе «Шаг 2. MCP уже подключён».

До передачи результата модели доступ проверяет Glarus BI: режим «Изолированный доступ» задаёт фильтр по атрибуту пользователя либо представление через сохранённый вопрос; режим «Через роль БД» использует настроенную роль источника при поддержке драйвером; «Заблокирован» закрывает соответствующий доступ. Администратор отдельно настраивает права на данные, коллекции, карточки и дашборды. SQL не получает расширенных прав от формулировки запроса. См. права на данные и выполнение через роль БД.

Управление доступом к ассистенту

Подключение MCP-сервера Glarus BI настраивается администратором установки Glarus AI. Удаление этого подключения закрывает данный путь к данным BI; отдельно проверьте другие инструменты и источники, разрешённые агенту. В режиме glarusbi.mcp.dataMode=metadata вызовы запросов не возвращают модели строки и точные значения, а инструменты публикации и рассылки, выносящие данные, отклоняются. Запрос при этом может выполняться в BI; режим не отключает переписку и её хранение.

Чтобы скрыть переход из BI в чат, очистите настройку «URL Glarus AI» в администрировании BI. Это скрывает ссылку, но само приложение чата и уже известный пользователю адрес продолжат существовать. Для отключения доступа к приложению требуются настройки его развёртывания и аутентификации.

В per-request объекты, закрытые пользователю в BI, закрыты и для вызовов ассистента под его сессией. Отдельного переключателя AI у конкретного дашборда нет. Разрешение создавать или публиковать MCP-серверы в интерфейсе чата не является запретом использовать сервер, заданный администратором в конфигурации.

Защита от prompt injection

Инструкции конкретного агента задают допустимое поведение, однако границу доступа обеспечивают серверные механизмы. Чат безусловно удаляет предложенные моделью аргументы _gbiSessionToken и _userId, затем подставляет собственные данные вошедшего пользователя. Промпт «выполни запрос от имени администратора» не является способом выбрать другую сессию.

Glarus BI проверяет права пользователя при выполнении запросов. MCP дополнительно проверяет аргументы и значения на пути записи; при сохранении запроса выполняются предусмотренные проверки и предварительное выполнение поддерживаемой формы, либо возвращается отказ. Это не универсальный анализ произвольного SQL: отдельные формы не проходят предварительное выполнение, поэтому его отсутствие нельзя считать подтверждением корректности запроса.

Режим metadata ограничивает выдачу данных этим MCP-сервером, но не очищает уже введённый текст чата и не закрывает другие источники. Отдельный фильтр prompt injection и опубликованный набор испытаний adversarial-промптов для этого сценария не заявляются. Системные инструкции не дают гарантии неуязвимости и не заменяют настройки прав и перечня инструментов.

Изоляция сессий пользователей

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

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

MCP-сервер BI может быть общим процессом. В per-request сессия передаётся заново на каждом вызове, хранится в локальном контексте потока и очищается в finally, в том числе при исключении. В наборе проверок MCP есть тест параллельных вызовов двадцати пользователей и тест очистки после ошибки аутентификации. Это описание проверок кода, а не отчёт о выполненном здесь прогоне пользователей на вашей установке.

Опубликованные агенты, доступные нескольким пользователям Skills и общий граф знаний предназначены для совместного контекста. Если администратор подключил общий граф, не рассматривайте его как личную память. Не помещайте туда персональные сведения и закрытые результаты под видом индивидуального контекста.

Учёт обращений и расхода токенов

В сообщениях сохраняются пользователь, диалог и модель. При включённом учёте транзакций отдельно записываются тип токенов prompt/completion, количество rawAmount, коэффициент rate и расчётный расход tokenValue. Доступность этих значений зависит от учёта и сведений о расходе, возвращённых провайдером. tokenValue выражен во внутренних расчётных единицах и не является готовым счётом в рублях.

MCP журналирует начало вызова с пользователем, результат и длительность выполнения; формат записи зависит от исхода. Администратор может включить защищённый endpoint /metrics, задав METRICS_SECRET: доступны http_requests_total по методу, пути и статусу и generation_jobs_total по хранилищу и результату. HTTP-запрос, генерация и вопрос пользователя — разные единицы учёта. Готового дашборда внедрения и разбивки по подразделениям нет.

Пример месячного отчёта по пользователям

Администратор с разрешённым доступом только для чтения к MongoDB может выполнить две выборки. Здесь обращение — сохранённое сообщение пользователя, а расход — сохранённые списания токенов; записи credits исключены. Сопоставьте выгрузки по идентификатору пользователя.

const start = ISODate("2026-09-01T00:00:00Z");
const end = ISODate("2026-10-01T00:00:00Z");
db.messages.aggregate([
  {$match: {isCreatedByUser: true,
    createdAt: {$gte: start, $lt: end}}},
  {$group: {_id: "$user", requests: {$sum: 1}}}
]);
db.transactions.aggregate([
  {$match: {createdAt: {$gte: start, $lt: end},
    tokenType: {$in: ["prompt", "completion"]},
    rawAmount: {$lt: 0}}},
  {$group: {_id: {user: {$toString: "$user"},
                  type: "$tokenType"},
    tokens: {$sum: {$abs: "$rawAmount"}},
    calculatedUsage: {$sum: {$abs:
      {$ifNull: ["$tokenValue", 0]}}}}}
]);

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

Библиотека преднастроенных промптов

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

В проверенной демо-библиотеке доступен один преднастроенный промпт: «Список источников данных», категория «Исследование». Он помогает получить перечень доступных подключений и их описание через MCP-инструменты Glarus BI. Состав библиотеки зависит от загрузки шаблонов и прав вашей учётной записи.

  1. Откройте Промты и выберите доступный сценарий. Проверьте его описание, рабочую версию и требуемые параметры.
  2. В чате введите / и выберите доступный промпт по названию или настроенной команде. В проверенном примере список предлагает «Список источников данных».
  3. Если шаблон содержит переменные вида {{DATABASE_ID}} или {{COLLECTION_ID}}, заполните их перед отправкой. Укажите нужные источник данных, коллекцию, показатели и период. В проверенном промпте списка источников таких переменных нет. Перед выбором проверьте настройку автоматической отправки промпта.
  4. Проверьте предложенные запросы и созданные объекты. Промпт задаёт порядок работы, а доступность MCP-инструментов определяется настройками и правами пользователя.

Вызов доступного библиотечного промпта по символу / в чате

Поставка включает русскоязычные и англоязычные материалы для подготовки промптов. Администратор выбирает язык и загружает нужные версии. Шаблон системных инструкций «Glarus BI — Архитектор платформы» задаёт порядок работы с MCP-инструментами и проверки результата. Чтобы использовать его, администратор создаёт или настраивает соответствующего агента; имя шаблона не означает, что такой агент уже создан в каждой установке.

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

Системные промпты: редактирование, доступ и версии

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

Сохранённые изменения настроек агента доступны в Истории версий. Выберите нужную версию, нажмите Восстановить и подтвердите действие. Повторное сохранение одинаковых настроек не обязано создавать новую версию: одинаковые версии могут объединяться.

Учебный агент: история двух версий после восстановления первой

У библиотечного промпта есть собственные версии внутри группы. Можно добавить новую версию текста, просмотреть предыдущие и назначить выбранную рабочей. При вызове библиотечного промпта используется рабочая версия; выбор предыдущего текста позволяет вернуть ранее согласованную инструкцию.

Доступ к агентам и группам промптов выдаётся пользователям, группам и ролям Glarus AI. Различаются просмотр и использование, редактирование, удаление и общий доступ. Настройки роли определяют, разрешено ли пользователю создавать ресурсы и делиться ими; права на конкретный ресурс дополнительно ограничивают действия с ним.

Типовая рольИспользование и созданиеОбщий доступ
ПользовательВ настройках по умолчанию может использовать доступные промпты и агенты и создавать свои.По умолчанию не разрешён ролью; доступ настраивается администратором.
АдминистраторУправляет доступными возможностями и ресурсами.Может выдавать доступ в пределах настроек установки.

Если учётная запись Glarus AI создаётся при первом успешном входе через Glarus BI, суперпользователь Glarus BI получает роль администратора Glarus AI. Для уже существующей учётной записи роль не пересчитывается автоматически при каждом входе; последующие изменения проверяйте в администрировании Glarus AI.

Расширение агентов: MCP-серверы, действия и навыки

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

  • MCP-серверы. Администратор подключает сервер в конфигурации установки или создаёт подключение в интерфейсе, если оно разрешено настройками. Затем сервер или его инструменты выбираются для агента. Собственные совместимые серверы можно разрабатывать с помощью MCP SDK; сервер Glarus BI и сервер документации используют этот же способ интеграции. Создание подключений MCP по умолчанию разрешено администраторам.
  • Действия (Actions). Добавьте описание внутреннего REST API в формате OpenAPI, проверьте адрес сервера и настройте требуемую авторизацию. Из описания формируется набор действий агента. Вызов выполняет операцию внешнего API, поэтому её результат определяется самим сервисом и выданными ему правами.
  • Навыки. Импортируйте файл Markdown или пакет .zip/.skill с SKILL.md и дополнительными материалами. Архив содержит SKILL.md в корне или в одном вложенном каталоге. Размер архива ограничен 50 МБ, распакованных данных — 500 МБ, число файлов — 500, размер одного файла — 10 МБ. Затем подключите навык к агенту и настройте доступ к нему. Использование, создание и общий доступ дополнительно регулируются ролью пользователя.
  • Связи между агентами. Настройте передачу задачи выбранным исполнителям или последовательную цепочку. Инструменты и инструкции каждого участника задаются в его собственных настройках.

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

Оркестратор и передача задач между агентами

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

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

Оркестратор
  → Поиск контента: найти документацию и определения
  → SQL-аналитик: исследовать схему и подготовить запрос
  → Визуализатор: оформить проверенный результат
  → Рекомендации: сформулировать выводы по результатам анализа

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

Настоящая передача учебного запроса от оркестратора аналитику и ответ исполнителя

Учебный диалог: оркестратор передал задачу аналитику, который вернул «Проверка передачи завершена». В этом примере аргументы передачи пусты; изолированный субагент не запускался.

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

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

Поиск по контенту Glarus BI как источник контекста

Чтобы ответ опирался на существующие аналитические объекты, попросите агента сначала найти их в Glarus BI. Инструмент searchGlarusBI обращается к поиску Glarus BI и возвращает подходящие дашборды, вопросы, модели, метрики, сегменты, таблицы, базы данных и коллекции. Можно ограничить поиск типом объекта.

Индекс использует названия и описания объектов; для таблиц учитывается также отображаемое имя. В режиме MCP full найденные объекты передаются с доступными описаниями и сведениями о коллекции. В режиме metadata описания скрываются: агент получает разрешённые идентификаторы и структурные сведения. Объём передаваемой информации настраивается администратором.

В режиме аутентификации per-request поиск выполняется с сессией текущего пользователя. Glarus BI отбирает результаты с учётом его прав; подключение по общему ключу использует права владельца этого ключа. Наличие объекта в поиске не отменяет последующие проверки доступа при открытии карточки или выполнении запроса.

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

Попросите, например: «Какие дашборды есть про продажи? Сначала найди существующие объекты и покажи, на какие результаты поиска ты опираешься». Дополнительно агент может искать справочные статьи через MCP-сервер документации, если он подключён администратором. Это отдельный источник справки. Поиск по файлам чата использует отдельно настроенный сервис обработки файлов и векторное хранилище.

Порядок уточнения запроса и проверки найденных объектов приведён в разделе «Поиск дашбордов и карточек на естественном языке».

Помощь в написании формул и SQL

Опишите показатель словами: какие данные использовать, что считать, по каким измерениям группировать и за какой период. Например: «Подготовь SQL для суммы продаж по месяцам и регионам, исключи отменённые заказы. Сначала проверь названия и типы полей». Агент может исследовать доступную схему, предложить SQL или текст выражения для конструктора и свериться со справкой по функциям через подключённый MCP-сервер документации.

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

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

У SQL-карточки признак query_validated: true подтверждает выполненную проверку. Значение false или отсутствие признака не подтверждает успешный запуск. После создания проверьте карточку с нужными параметрами и результатом: сохранение само по себе не доказывает корректность бизнес-формулы.

Если пробный запуск выявил ошибку запроса, агент может исправить формулу и повторить проверку. В режиме full ответ может содержать текст ошибки СУБД; в режиме metadata текст драйвера скрыт и возвращается ограниченная классификация ошибки. Поэтому доступные агенту сведения для исправления зависят от режима данных и характера ошибки.

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

Диалоги, история и память

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

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

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

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

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

Multi-turn с контекстом

Ниже — выполненный учебный диалог из шести сообщений. В нём используются только четыре заданных числа; условия уточняются в истории разговора. Этот пример показывает уточнения и возврат к истории. SQL здесь предложен текстом; пробный запуск, обращение к MCP и запись в долговременную память в этом примере не выполнялись.

  1. Задайте исходные данные. «Январь 2026: Север — 100, Юг — 80; февраль: Север — 130, Юг — 100. Составь таблицу по месяцам и регионам с итогом за каждый месяц». Агент вернул суммы 180 и 230.
  2. Уточните выбранный объект. «Оставь только Север. Какие значения выручки получились за январь и февраль?» В ответе остались 100 и 130.

Учебный диалог, шаги 1–2: исходная таблица и выбор региона Север

  1. Продолжите расчёт без повторения чисел. «Для выбранного региона сравни февраль с январём: назови абсолютное и процентное изменение, покажи формулу процента». Агент сохранил выбранный регион и вычислил прирост 30, или 30%.
  2. Попросите SQL для тех же условий. «Предложи PostgreSQL SQL для этого сравнения в учебной таблице demo_sales(month, region, revenue). Используй выбранный регион, январь и февраль 2026. Только текст SQL». Проверьте условия, типы колонок и формулу; предложение запроса ещё не подтверждает его выполнение. Для целочисленной выручки деление должно использовать дробное значение или приведение к числовому типу.

Учебный диалог, шаги 3–4: прирост выбранного региона и текст SQL

  1. Уточните особый случай. «Напиши одной строкой выбранный регион, январскую и февральскую выручку, прирост и процент. Как обработать нулевую базу?» Проверьте, что деление на ноль не превращается в произвольный процент: его можно оставить неопределённым.
  2. Вернитесь после перезагрузки. Перезагрузите страницу, откройте тот же разговор из истории и спросите: «Вспомни выбранный регион и значения за январь и февраль. Каким был прирост? Уточнение: revenue — целое число. Покажи процентную формулу PostgreSQL без целочисленного деления.» В проверенном диалоге агент снова назвал Север, 100, 130 и прирост 30 и добавил приведение к numeric для дробного деления.

Учебный диалог, шаги 5–6: нулевая база и восстановление контекста после перезагрузки

После шестого ответа можно открыть меню ответвления и выбрать Только видимые сообщения. В проверенном примере отдельная копия появилась в истории без отправки нового сообщения. Изменение прошлого вопроса и переключение вариантов ответа также относятся к выбранной ветви; для временных диалогов и просмотра результатов поиска доступность элементов может отличаться.

История учебного разговора и его отдельное ответвление с видимыми сообщениями

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

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

  1. Поиск searchGlarusBI находит кандидатов по названиям и описаниям доступных дашбордов, вопросов, моделей, метрик и таблиц.
  2. Агент может открыть найденный дашборд через getGlarusBIDashboardCards и проверить отдельные карточки через getGlarusBICard. В режиме full доступен сохранённый SQL в пределах прав пользователя; в metadata его текст скрывается.
  3. В ответе агент приводит ссылки на подходящие объекты и объясняет связь с показателем, разрезом и периодом. Если состав карточек не подтверждает задачу, попросите продолжить поиск или уточните критерии.

Понимание формулировки и подбор синонимов выполняет языковая модель. Сам поиск Glarus BI в описанном сценарии — полнотекстовый по контентному индексу. Переформулирование запроса не добавляет в него векторный индекс или встроенный гибридный поиск.

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

Прозрачность ответа: SQL, поля и ссылка на источник

Если агент вызвал инструмент Glarus BI, раскройте блок этого вызова в ответе чата. Внутри доступны результат и кнопка Parameters («Параметры») с переданными аргументами; её название может оставаться на английском и в русскоязычном интерфейсе. У executeGlarusBIQuery в них находится SQL: выбранные таблицы и колонки, фильтры и агрегаты. У executeGlarusBICard передаются идентификатор карточки и параметры, а сохранённый запрос читается отдельно через getGlarusBICard.

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

Инструкция агента: «Для числового ответа выполни запрос. Назови использованные таблицы и поля, объясни формулу показателя, период и фильтры. Приведи SQL или ссылку на сохранённый источник. Не придумывай ссылку».

Для существующей доступной карточки агент получает адрес через getCardUrl, для дашборда — через getDashboardUrl. Ссылка открывает объект с проверкой прав пользователя; сам дашборд не является SQL-редактором. Образец структуры ответа: «Выручка = SUM(сумма) из указанной таблицы за выбранный период; исключены отменённые записи; источник: <ссылка, возвращённая getCardUrl>». Это шаблон, а не результат выполненного запроса.

Для результатов с числами администратор настраивает glarusbi.mcp.dataMode=full и разрешает инструменты. В metadata строки результата и сохранённый SQL карточки модели не возвращаются; SQL, который агент сам передал в параметрах вызова, от этого не исчезает.

В учебном примере ниже запрос передан агенту целиком. В раскрытом вызове видны результат 300 и параметры; getCardUrl вернул ссылку на созданную учебную карточку, и агент включил её в ответ. Длинный SQL в кратком представлении параметров усечён; полный запрос доступен в сообщении и в протоколе ниже.

Настоящий учебный ответ: выполненный SQL, число 300, параметры и ссылка на карточку

Откуда берутся числа в ответах

executeGlarusBIQuery выполняет SQL через Glarus BI, а executeGlarusBICard выполняет сохранённую карточку. В режиме full агент получает столбцы и строки результата. При настроенном администратором glarusbi.mcp.authMode=per-request в вызове передаётся сессия пользователя; Glarus BI проверяет его права. Ограничения доступа и настроенные правила строк и столбцов действуют на стороне BI в пределах поддерживаемого типа запроса; общий ключ API не заменяет этот режим.

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

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

Учебный протокол пяти вопросов

Прогон выполнен 22 октября 2026 года: PostgreSQL, агент с моделью deepseek-v4-flash, temperature=0, лимит ответа 1024 токена. В каждом сообщении агент получил точный SQL над шестью строками, заданными внутри CTE demo_orders. Рабочие таблицы не использовались. Каждый эталонный запрос отдельно выполнен через BI, затем передан в чат для выполнения через MCP. На вопрос о среднем чеке агент дважды выполнил один и тот же полный SQL; оба результата совпали. Оба вызова сохранены в протоколе, таблица ниже показывает полученное число. Эта проверка сопоставляет переданные числа; она не измеряет самостоятельную генерацию SQL или точность на произвольных данных.

ВопросЭталон BI и результат MCPЧисло в ответе агента
Какова сумма учебной выручки за январь 2026?300300,00
Какова доля Севера в учебной выручке за февраль 2026, %?77,5 %77,50 %
Каков средний учебный чек за февраль 2026?133,33333333333334133,33
Сколько уникальных учебных заказов за февраль 2026?33
Как изменилась учебная выручка февраля 2026 к январю, в единицах и процентах?100; 33,333333333333336 %100,00; 33,33 %

Единица выручки — условная; для долей показан процент. В SQL доля и среднее вычисляются до округления; NULLIF защищает от деления на ноль. Округление до двух знаков применяется только в тексте ответа. Один заказ представлен одной строкой, поэтому средний чек считается как сумма / число уникальных заказов. Периоды заданы полуоткрытыми границами дат.

Полный SQL: Какова сумма учебной выручки за январь 2026?
WITH demo_orders AS (
SELECT 1 AS order_id, DATE '2026-01-10' AS order_date, 'Север' AS region, 120.00 AS amount
UNION ALL
SELECT 2 AS order_id, DATE '2026-01-15' AS order_date, 'Юг' AS region, 80.00 AS amount
UNION ALL
SELECT 3 AS order_id, DATE '2026-01-20' AS order_date, 'Север' AS region, 100.00 AS amount
UNION ALL
SELECT 4 AS order_id, DATE '2026-02-10' AS order_date, 'Север' AS region, 150.00 AS amount
UNION ALL
SELECT 5 AS order_id, DATE '2026-02-15' AS order_date, 'Юг' AS region, 90.00 AS amount
UNION ALL
SELECT 6 AS order_id, DATE '2026-02-20' AS order_date, 'Север' AS region, 160.00 AS amount
)
SELECT SUM(amount) AS total FROM demo_orders WHERE order_date >= DATE '2026-01-01' AND order_date < DATE '2026-02-01'
Полный SQL: Какова доля Севера в учебной выручке за февраль 2026, %?
WITH demo_orders AS (
SELECT 1 AS order_id, DATE '2026-01-10' AS order_date, 'Север' AS region, 120.00 AS amount
UNION ALL
SELECT 2 AS order_id, DATE '2026-01-15' AS order_date, 'Юг' AS region, 80.00 AS amount
UNION ALL
SELECT 3 AS order_id, DATE '2026-01-20' AS order_date, 'Север' AS region, 100.00 AS amount
UNION ALL
SELECT 4 AS order_id, DATE '2026-02-10' AS order_date, 'Север' AS region, 150.00 AS amount
UNION ALL
SELECT 5 AS order_id, DATE '2026-02-15' AS order_date, 'Юг' AS region, 90.00 AS amount
UNION ALL
SELECT 6 AS order_id, DATE '2026-02-20' AS order_date, 'Север' AS region, 160.00 AS amount
)
SELECT 100.0 * SUM(CASE WHEN region = 'Север' THEN amount ELSE 0 END) / NULLIF(SUM(amount), 0) AS share_percent FROM demo_orders WHERE order_date >= DATE '2026-02-01' AND order_date < DATE '2026-03-01'
Полный SQL: Каков средний учебный чек за февраль 2026?
WITH demo_orders AS (
SELECT 1 AS order_id, DATE '2026-01-10' AS order_date, 'Север' AS region, 120.00 AS amount
UNION ALL
SELECT 2 AS order_id, DATE '2026-01-15' AS order_date, 'Юг' AS region, 80.00 AS amount
UNION ALL
SELECT 3 AS order_id, DATE '2026-01-20' AS order_date, 'Север' AS region, 100.00 AS amount
UNION ALL
SELECT 4 AS order_id, DATE '2026-02-10' AS order_date, 'Север' AS region, 150.00 AS amount
UNION ALL
SELECT 5 AS order_id, DATE '2026-02-15' AS order_date, 'Юг' AS region, 90.00 AS amount
UNION ALL
SELECT 6 AS order_id, DATE '2026-02-20' AS order_date, 'Север' AS region, 160.00 AS amount
)
SELECT SUM(amount) / NULLIF(COUNT(DISTINCT order_id), 0) AS average_order FROM demo_orders WHERE order_date >= DATE '2026-02-01' AND order_date < DATE '2026-03-01'
Полный SQL: Сколько уникальных учебных заказов за февраль 2026?
WITH demo_orders AS (
SELECT 1 AS order_id, DATE '2026-01-10' AS order_date, 'Север' AS region, 120.00 AS amount
UNION ALL
SELECT 2 AS order_id, DATE '2026-01-15' AS order_date, 'Юг' AS region, 80.00 AS amount
UNION ALL
SELECT 3 AS order_id, DATE '2026-01-20' AS order_date, 'Север' AS region, 100.00 AS amount
UNION ALL
SELECT 4 AS order_id, DATE '2026-02-10' AS order_date, 'Север' AS region, 150.00 AS amount
UNION ALL
SELECT 5 AS order_id, DATE '2026-02-15' AS order_date, 'Юг' AS region, 90.00 AS amount
UNION ALL
SELECT 6 AS order_id, DATE '2026-02-20' AS order_date, 'Север' AS region, 160.00 AS amount
)
SELECT COUNT(DISTINCT order_id) AS order_count FROM demo_orders WHERE order_date >= DATE '2026-02-01' AND order_date < DATE '2026-03-01'
Полный SQL: Как изменилась учебная выручка февраля 2026 к январю, в единицах и процентах?
WITH demo_orders AS (
SELECT 1 AS order_id, DATE '2026-01-10' AS order_date, 'Север' AS region, 120.00 AS amount
UNION ALL
SELECT 2 AS order_id, DATE '2026-01-15' AS order_date, 'Юг' AS region, 80.00 AS amount
UNION ALL
SELECT 3 AS order_id, DATE '2026-01-20' AS order_date, 'Север' AS region, 100.00 AS amount
UNION ALL
SELECT 4 AS order_id, DATE '2026-02-10' AS order_date, 'Север' AS region, 150.00 AS amount
UNION ALL
SELECT 5 AS order_id, DATE '2026-02-15' AS order_date, 'Юг' AS region, 90.00 AS amount
UNION ALL
SELECT 6 AS order_id, DATE '2026-02-20' AS order_date, 'Север' AS region, 160.00 AS amount
)
SELECT feb - jan AS absolute_change, 100.0 * (feb - jan) / NULLIF(jan, 0) AS percent_change FROM (SELECT SUM(CASE WHEN order_date >= DATE '2026-01-01' AND order_date < DATE '2026-02-01' THEN amount ELSE 0 END) AS jan, SUM(CASE WHEN order_date >= DATE '2026-02-01' AND order_date < DATE '2026-03-01' THEN amount ELSE 0 END) AS feb FROM demo_orders) p

Пятый учебный запрос: абсолютный и процентный прирост из результата SQL

Стабильность ответов и параметры модели

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

Параметр temperature доступен в панели параметров чата и в параметрах модели агента, если его поддерживает выбранная модель и провайдер и панель разрешена администратором. Для аналитики можно начать с 0 или 0,1–0,2, если модель принимает эти значения. Это рекомендация, а не гарантия детерминированности. Отдельного поля seed в этой панели нет; формулировки текста и выбор вызовов инструментов могут меняться даже при низкой temperature.

Настройки учебного агента: модель deepseek-v4-flash, температура 0, лимит 1024 токена

Пять повторов одного вопроса

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

ПовторSQL и параметрыBI / MCP / ответ агента
1Один запрос суммы за январь; без параметров300 / 300 / 300,00
2Один запрос суммы за январь; без параметров300 / 300 / 300,00
3Один запрос суммы за январь; без параметров300 / 300 / 300,00
4Один запрос суммы за январь; без параметров300 / 300 / 300,00
5Один запрос суммы за январь; без параметров300 / 300 / 300,00

В четвёртом повторе ассистент сообщил об опечатке и повторил вызов. Сохранённые аргументы обоих вызовов содержали одинаковый полный SQL; текстовое объяснение проверялось отдельно от самого запроса.

Формулировки пояснений различались. Во всех пяти наблюдениях значение составило 300. Это наблюдение для заданного SQL и учебных данных, а не гарантия одинакового запроса или текста при повторе произвольного вопроса.

Пятый ответ на тот же учебный вопрос: повторный вызов SQL и значение 300

Поведение ассистента при отсутствии данных

Настройте правила в инструкциях конкретного агента: если за период нет данных, проверить MAX(поле_даты) и назвать последнюю доступную дату; при неизвестном классе или территории перечислить доступные значения; при неоднозначности уточнить вопрос; причинные объяснения обозначать гипотезами до проверки. Максимальная дата события не является автоматически датой обновления источника — для последней нужен отдельный подтверждённый признак загрузки.

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

Проверяйте разные сигналы MCP:

  • NOT_FOUND и isError=true обозначают ошибку чтения объекта; сообщение называет объект и, где это предусмотрено, следующий инструмент или доступные варианты. Отказ в доступе не доказывает, что объект отсутствует у всех пользователей.
  • Успешное выполнение с нулём строк означает пустую выборку. В metadata отсутствие строк отражается через has_rows=false; значения и точный счётчик там не выдаются.
  • В full при ограничении ответа объект truncation сообщает число возвращённых элементов, известный итог либо его нижнюю границу, источник ограничения и подсказку. Нельзя считать фрагмент полной выборкой.

Инструкции направляют ответ модели, но не гарантируют отказ на любую провокацию. Отдельный испытанный слой защиты от jailbreak для этого сценария не заявляется.

Периоды, срезы и финансовый календарь

Определения периодов, сегментов и сокращений задайте в инструкциях конкретного агента или в доступном ему Skill. Использование Skills настраивается администратором и включается у агента; убедитесь, что нужный Skill выбран или применён. Текст правил в общей серверной конфигурации не подтверждает, что они поступили используемой модели.

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

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

Учебный прогон: пять явных и три неявных фильтра

22 октября 2026 года выполнен один разговор из восьми вопросов на десяти вымышленных строках перестрахования. Правила глоссария, календаря и сам набор demo_reinsurance сохранены в инструкциях отдельного агента. Модель deepseek-v4-flash, температура 0, лимит ответа 2048 токенов; Skills отключены, доступен только executeGlarusBIQuery. Опорная дата — 22 октября 2026, 00:00 UTC; финансовый год календарный, текущий неполный день исключён. Каждый вопрос задан как самостоятельный, без наследования фильтров, но история разговора между вопросами увеличивалась.

Эталонные запросы заранее выполнены через BI. В чат отправлены вопросы на естественном языке; формулы и условия SELECT агент составил сам по инструкциям и выполнил через MCP. Во всех восьми вызовах десять исходных строк остались неизменными; рабочих таблиц в запросах нет. Показатель из результата MCP и число в ответе совпали с соответствующим эталоном BI. Это наблюдение для этих вопросов и заданных правил; оно не гарантирует корректность произвольного запроса.

ФильтрВопросЭталон BI / MCP / ответ
ЯвныйКакова учебная премия в рублях с 1 июля 2026 включительно до 1 октября 2026 исключительно?1150 / 1150 / 1150 руб.
ЯвныйКакова учебная премия в рублях по классу Грузы за весь учебный набор?2430 / 2430 / 2430 руб.
ЯвныйКакова учебная премия в рублях только по действующим договорам за весь учебный набор?3000 / 3000 / 3000 руб.
ЯвныйКакова учебная премия в рублях по территории Север за весь учебный набор?2000 / 2000 / 2000 руб.
ЯвныйКакова учебная премия в валюте оригинала USD за весь учебный набор?17 / 17 / 17 USD
НеявныйКакова учебная премия за прошлый квартал?1150 / 1150 / 1150 руб.
НеявныйКакой ЛР по карго за 24й?50 / 50 / 50 %
НеявныйКакова учебная премия по факам с начала года?1520 / 1520 / 1520 руб.

Сопоставлялся именованный столбец показателя. Агент добавил COUNT(*), а для ЛР — также суммы выплат и нетто-премии: полные строки результата отличаются от одночисловых эталонов. Ниже приведён фактический SQL каждого вызова, включая эти дополнительные столбцы.

SQL после прогона: Какова учебная премия в рублях с 1 июля 2026 включительно до 1 октября 2026 исключительно?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_rub) AS premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE event_date >= DATE '2026-07-01'
  AND event_date <  DATE '2026-10-01'
SQL после прогона: Какова учебная премия в рублях по классу Грузы за весь учебный набор?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_rub) AS premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE coverage_class = 'Грузы'
SQL после прогона: Какова учебная премия в рублях только по действующим договорам за весь учебный набор?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_rub) AS premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE status IN ('active','renewed')
SQL после прогона: Какова учебная премия в рублях по территории Север за весь учебный набор?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_rub) AS premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE territory = 'Север'
SQL после прогона: Какова учебная премия в валюте оригинала USD за весь учебный набор?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_val) AS premium_sum_val,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE currency_code = 'USD'
SQL после прогона: Какова учебная премия за прошлый квартал?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_rub) AS premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE event_date >= DATE '2026-07-01'
  AND event_date <  DATE '2026-10-01'
SQL после прогона: Какой ЛР по карго за 24й?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT 100.0 * SUM(claims_rub) / NULLIF(SUM(net_premium_rub),0) AS loss_ratio_pct,
       SUM(claims_rub) AS claims_sum_rub,
       SUM(net_premium_rub) AS net_premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE coverage_class = 'Грузы'
  AND event_date >= DATE '2024-01-01'
  AND event_date <  DATE '2025-01-01'
SQL после прогона: Какова учебная премия по факам с начала года?
WITH demo_reinsurance(id,event_date,coverage_class,status,territory,contract_type,currency_code,premium_rub,premium_val,net_premium_rub,claims_rub) AS (VALUES
(1,DATE '2024-03-15','Грузы','active','Север','facultative','RUB',100.0,100.0,80.0,40.0),
(2,DATE '2024-07-20','Грузы','closed','Юг','treaty','USD',180.0,2.0,120.0,60.0),
(3,DATE '2024-09-10','Имущество','active','Север','facultative','RUB',200.0,200.0,160.0,32.0),
(4,DATE '2026-01-15','Грузы','active','Север','facultative','USD',270.0,3.0,216.0,54.0),
(5,DATE '2026-07-15','Грузы','active','Север','facultative','RUB',300.0,300.0,240.0,60.0),
(6,DATE '2026-08-10','Имущество','renewed','Юг','treaty','EUR',400.0,4.0,320.0,64.0),
(7,DATE '2026-09-20','Грузы','closed','Юг','facultative','USD',450.0,5.0,360.0,90.0),
(8,DATE '2026-10-10','Грузы','renewed','Север','facultative','RUB',500.0,500.0,400.0,100.0),
(9,DATE '2026-10-21','Имущество','active','Юг','treaty','RUB',600.0,600.0,480.0,48.0),
(10,DATE '2026-10-22','Грузы','active','Север','facultative','USD',630.0,7.0,504.0,126.0)
)
SELECT SUM(premium_rub) AS premium_sum_rub,
       COUNT(*) AS cnt
FROM demo_reinsurance
WHERE contract_type = 'facultative'
  AND event_date >= DATE '2026-01-01'
  AND event_date <  DATE '2026-10-22'

Учебный явный период: даты в SQL и результат 1150 рублей

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

Глоссарий и рекомендации по именованию

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

Пример термина для перестрахованияЧто закрепить в глоссарии
«ЛР», loss ratio, убыточностьСогласованная формула: 100 × сумма выплат / нетто-премия; конкретные поля и соединения, период и обработка нулевой премии.
«Факи», факультативные договорыПоле формы договора и точное значение из доступного справочника.
«Карго»Поле класса покрытия и согласованное значение «Грузы».
«Маржиналка»Уточнить определение: разговорный термин может означать разные показатели. Если выбран combined ratio, записать именно его согласованную формулу; не подменять маржинальный доход.

В учебном демо-прогоне выше глоссарий закреплял карго → coverage_class = 'Грузы', факи → contract_type = 'facultative', действующие договоры → status IN ('active','renewed'), ЛР → 100.0 * SUM(claims_rub) / NULLIF(SUM(net_premium_rub), 0). Это отдельный вымышленный набор, созданный для проверки; такие значения и определения не появляются автоматически в других данных. На вопрос «Какой ЛР по карго за 24й?» агент применил класс «Грузы», период с 1 января 2024 включительно до 1 января 2025 исключительно и получил 50%: 100 рублей выплат / 200 рублей нетто-премии.

Учебный глоссарий: ЛР по карго за 2024 год, явная формула и результат 50 процентов

Используйте понятные отображаемые названия на русском, описания с синонимами и единицами, отдельные имена для разных валют. Одному показателю назначьте одно согласованное определение. Названия и описания редактируются в модели данных BI; для изменения нужны соответствующие права. MCP может получать описания полей через getDatabaseFields и getTableQueryMetadata в full; в metadata свободные описания скрываются.

Периоды и финансовый календарь в ответах ассистента

Для календарного финансового года задайте в инструкциях или Skill определения: MTD — от начала месяца, QTD — от начала квартала, YTD — от 1 января до согласованной даты среза. Q1 — январь–март, Q2 — апрель–июнь, Q3 — июль–сентябрь, Q4 — октябрь–декабрь. Уточните, включён ли текущий неполный день и какой часовой пояс используется.

Для LFL/YoY задайте правила сопоставимости: равные части периодов, состав объектов, високосный день и нужные исключения. «LFL» и «год к году» не следует считать взаимозаменяемыми без договорённости. Агент может развернуть эти правила в явные границы SQL; проверьте их в фактическом вызове инструмента.

В BI есть относительные фильтры дат, настройка первого дня недели и функция week. Режим week([Дата], "ISO") использует ISO-недели с понедельника; режим Instance учитывает настройку экземпляра. Настройка начала недели влияет на фильтры и группировки конструктора и обычно не меняет произвольный SQL; учитывайте особенности СУБД.

В выполненном учебном прогоне «прошлый квартал» развёрнут в event_date >= DATE '2026-07-01' AND event_date < DATE '2026-10-01': итог 1150 рублей. «Премия по факам с начала года» дала условие contract_type = 'facultative' и даты от 1 января 2026 включительно до 22 октября исключительно: итог 1520 рублей. Опорная дата и исключение неполного дня были заданы заранее; автоматическое определение неизвестного финансового календаря этим не проверялось.

Учебный относительный период: прошлый квартал превращён в явные границы SQL

Отдельной поддержки сдвинутого финансового года и календаря 4-4-5 в семантическом слое нет. Если они нужны, подготовьте явную таблицу календаря или SQL-модель и согласуйте формулы; одна инструкция модели не добавляет такой календарь в BI.

Валюты, единицы и часовые пояса в ответах ассистента

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

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

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

Администратор задаёт часовой пояс отчётов; report-timezone используется как часовой пояс соединения при выполнении запросов, если это поддерживает драйвер. Это может влиять на границы дат и группировки. Функция convertTimezone переводит дату-время между поясами при поддержке источником; она не конвертирует валюту. Согласуйте пояс исходных временных меток, отчёта и явных SQL-границ.

В учебном вопросе о премии в USD агент выбрал SUM(premium_val) с currency_code = 'USD' и получил 17 USD, совпадающие с эталоном BI. Рублёвые и евро-строки не суммировались с долларами, курс не применялся. Данные содержали календарные даты; преобразование временных меток между поясами в этом прогоне не проверялось.

Учебная сумма в валюте оригинала: фильтр USD и результат 17 долларов

Оценка ответов пользователями

Под ответом ассистента используйте «Обожаю это» или «Требует улучшения». Выберите причину, например «Неточный или неправильный ответ». Пункт для другого отзыва открывает поле комментария; дополнительный текст также можно отредактировать для уже оставленного отзыва. Оценка сохраняется в поле feedback сообщения: rating, tag, text. Изменение отзыва в чате проверяется для текущего пользователя.

Выборка отрицательных оценок

Администратор с разрешённым доступом к журналу может выбрать отрицательные оценки для ручного разбора:

db.messages.find(
  {"feedback.rating": "thumbsDown"},
  {user: 1, conversationId: 1, messageId: 1,
   model: 1, feedback: 1, createdAt: 1}
).sort({createdAt: -1}).limit(50);

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


Типовые сценарии использования

Сценарий Промпт Что демонстрирует
Точность числовых ответов «Какова суммарная брутто-премия по всем договорам за 2024 год в рублях?» Сверка результата с эталонным SQL; точность ответа проверяется пользователем
NL2Viz «Покажи динамику брутто-премии по кварталам за 2023–2024» Автоматическое построение line chart
Multi-turn с контекстом Цепочка из 5 шагов с уточнениями («добавь убыточность», «убери ДМС», «покажи графиком», «а за 2023?») Сохранение контекста между шагами
Page-level reasoning «Какие проблемы ты видишь на этом дашборде?» Анализ всех виджетов сразу
Автономные цепочки «Найди все убытки за Q4 2024, сравни с Q4 2023, визуализируй» 4–5 автономных MCP-шагов без подсказок
Insight → action «Создай публичную ссылку на этот дашборд и отправь на email X@Y» Связка createPublicDashboardLink + createDashboardSubscription
RLS Пользователь в sandbox «только РФ» vs пользователь с полным доступом Разные ответы на один вопрос в соответствии с правами