Контур, в котором руководитель пишет вопрос по-русски и получает таблицу, устроен без всякой магии. Языковая модель не «понимает бизнес» — она получает на вход текст вопроса, схему витрины данных и словарь метрик с формулами, а на выходе выдаёт запрос к базе. Дальше этот запрос проверяется по формальным правилам, выполняется у вас и возвращается вместе с ответом, чтобы его можно было прочитать глазами.
Из такого устройства следует всё остальное, включая границы применимости. Если в словаре метрик написано, что активный клиент — это покупавший за 90 дней, ответ будет верным. Если не написано ничего, модель выберет определение сама, ответит уверенно и не сообщит, что выбирала. Опасен здесь не неправильный ответ, а правдоподобный неправильный ответ — его никто не проверяет, потому что он выглядит нормально.
Ниже — пять шагов контура, разбор роли словаря метрик, три класса вопросов с разной надёжностью, приёмочная процедура на 50 контрольных вопросах, разбор вариантов модели с точки зрения 152-ФЗ и расчёт порога, ниже которого пять обычных отчётов дешевле и честнее. Состав самого решения и его цены — на странице аналитики обычным языком; здесь про механику и границы. Модельная компания та же: оптовик, 40 человек, 1С:Управление торговлей 11, amoCRM, выручка 18,4 млн ₽ в месяц.
Как это устроено внутри: пять шагов от вопроса до ответа
- 1Вопрос на русском языке
«Покажи выручку и маржу по категориям за август против июля, только опт». Никакой специальной формы: контур живёт в мессенджере или в виджете внутри BI, потому что отдельный портал для вопросов никто не открывает.
- 2Подстановка словаря и схемы витрины
К вопросу автоматически прикладываются описание доступных таблиц и словарь метрик: что такое выручка, маржа, опт, активный клиент — с формулами и владельцами. Это и есть главный актив контура, а не модель.
- 3Сборка запроса
Модель формирует SQL к витрине. Она выбирает показатели, разрезы и фильтры из разрешённого списка, но не придумывает формулы: формула лежит в словаре и подставляется как есть.
- 4Проверка до выполнения
Формальный контроль по четырём правилам: запрос обращается только к разрешённым таблицам, содержит фильтр прав доступа текущего пользователя, ограничен по числу строк и не содержит изменяющих операций. Не прошедший проверку запрос не выполняется, а возвращается на переформулировку.
- 5Ответ вместе с запросом
Пользователь получает таблицу, график, показанный SQL и дату актуальности данных. Показ запроса — не украшение для айтишников: это единственный способ отличить верный ответ от правдоподобного, и убирать его из интерфейса нельзя.
Горизонтальная блок-схема из пяти блоков со стрелками. Блоки: «1. Вопрос на русском», «2. Словарь метрик и схема витрины», «3. Языковая модель собирает SQL», «4. Проверка: разрешённые таблицы, права доступа, лимит строк, только чтение», «5. Ответ: таблица, график, показанный запрос, дата актуальности». От блока 4 вниз отходит стрелка возврата с подписью «не прошёл — на переформулировку». Блок 3 обведён тонкой рамкой с подписью «единственное место, где работает модель». Приглушённая палитра, чертёжная штриховка, подписи по-русски.
Словарь метрик: почему без него контур опасен
Обычный дашборд с нечёткими определениями просто вызывает споры на планёрке. Контур вопросов ведёт себя иначе: он отвечает на любую формулировку и каждый раз выбирает определение заново. Спросили «сколько у нас клиентов» — получите 12 000 контрагентов из базы. Спросили «сколько активных клиентов» — получите число, которое зависит от того, какое окно модель посчитала разумным в этот раз. Оба ответа выглядят одинаково уверенно, и различить их можно только по показанному запросу.
Если один и тот же клиент заведён в базе трижды, а номенклатура ведётся свободным текстом, дашборд покажет неверную цифру один раз в одном месте. Контур вопросов будет выдавать неверные цифры на каждый новый вопрос, в новой формулировке и без предупреждения. Поэтому порядок работ жёсткий: сначала справочники и определения, потом витрины, и только потом вопросы словами — этот порядок разобран в материале про дашборд, который начинается со справочников.
Практическое следствие для сметы: словарь метрик — это не документация, а отдельная работа с участием финансового директора и коммерческого. В модельном проекте на 22 показателя она занимает 44 часа подрядчика плюс несколько встреч на стороне заказчика, и её нельзя сократить за счёт более сильной модели. Механика того, почему модель отвечает уверенно даже там, где не знает, разобрана в материале про галлюцинации нейросети.
Три класса вопросов: где надёжно, где с оговорками, где нельзя
Разделение вопросов по классам стоит утвердить до запуска и повесить рядом с контуром. Оно экономит больше, чем любая техническая настройка: пользователи перестают задавать вопросы, на которые контур в принципе не может ответить честно.
| Класс вопроса | Примеры | Насколько надёжно |
|---|---|---|
| Агрегаты и срезы | Сколько отгрузили за август; топ-10 клиентов по марже; сколько заказов просрочено и на какую сумму | Надёжно. Это прямой перевод вопроса в запрос по описанным метрикам |
| Сравнение периодов | Август к июлю; год к году; неделя к предыдущей | С оговорками. Нужны календарная таблица, правило неполного периода и учёт документов, проведённых задним числом |
| Причины и объяснения | Почему упала маржа; из-за чего вырос отток; что повлияло на просрочку | Ненадёжно. Модель выдаст правдоподобную версию, не проверив её. Такие вопросы контур должен разбивать на срезы, а вывод делает человек |
| Прогнозы и рекомендации | Сколько продадим в декабре; какую цену поставить; кому дать отсрочку | Не этот контур. Это отдельные модели прогнозирования со своей приёмкой и своей ответственностью |
Сравнительная схема из четырёх горизонтальных полос, сверху вниз по убыванию надёжности. Полоса 1 «агрегаты и срезы — надёжно», пример «топ-10 клиентов по марже за август». Полоса 2 «сравнение периодов — с оговорками», пример «август к июлю», сноска «календарь, неполный период, проводки задним числом». Полоса 3 «причины — ненадёжно», пример «почему упала маржа», сноска «разбивать на срезы, вывод делает человек». Полоса 4 «прогнозы — не этот контур», пример «сколько продадим в декабре». Полосы различаются плотностью штриховки от плотной к разреженной. Подписи по-русски.
Приёмка: 50 вопросов с заранее известными ответами
Контур нельзя принять по демонстрации: на показе задают удобные вопросы, и всё работает. Единственная рабочая процедура — заранее составленный набор контрольных вопросов, на которые правильные ответы посчитаны вручную и подписаны финансистом. Пятидесяти достаточно для компании этого размера.
- 1Состав набора. 25 вопросов первого класса, 15 на сравнение периодов, 5 с намеренно неоднозначной формулировкой и 5 таких, на которые ответа в данных нет вообще. Последние две группы — самые важные: они проверяют не знание, а поведение при незнании.
- 2Правильный ответ считается заранее руками. По каждому вопросу — число, период и способ расчёта, зафиксированные до первого прогона. Иначе приёмка превращается в спор о том, какой ответ считать верным.
- 3Порог запуска. Не меньше 45 верных ответов из 50 и ноль уверенных неверных. Все пять вопросов без данных должны получить честное «в модели нет такого показателя», а не приблизительную догадку. Уверенный неверный ответ — блокирующий дефект, сколько бы правильных ни было рядом.
- 4Первый прогон всегда плохой. Типичный результат до доработки — 31 из 50, и почти все ошибки лежат не в модели, а в описании: не хватает синонимов в словаре, нет календарной таблицы, две метрики названы почти одинаково. После правок словаря и витрин выходит 46 из 50, и это рабочее состояние.
- 5Регресс после каждого изменения. Тот же набор прогоняется заново при смене модели, добавлении источника или правке словаря. Без регресса контур тихо деградирует; как это измерять постоянно, разобрано в материале про качество ИИ на своих данных.
Контур, который на любой вопрос выдаёт число, вреднее ручных выгрузок: он снимает у людей привычку сомневаться. Правильный ответ на вопрос про показатель, которого нет в модели, звучит так: такого показателя в витрине нет, ближайшее из имеющегося — вот это. Проверять это надо на приёмке отдельной группой вопросов, потому что «сговорчивость» модели по умолчанию выше, чем хотелось бы.
152-ФЗ и выбор модели: облако или свой сервер
Важная деталь, которую обычно понимают неправильно: в модель уходит не база данных. Наружу отправляются текст вопроса и описание витрины — названия таблиц, полей и метрик. Сам запрос выполняется на вашей стороне, строки данных модель не видит. Но текст вопроса тоже бывает персональными данными: «покажи долг ИП Иванова по договору такому-то» — это уже имя контрагента-физлица в чужом сервисе.
| Вариант | Что уходит за периметр | Когда подходит |
|---|---|---|
| GigaChat или Yandex AI Studio, российское облако | Текст вопроса и описание витрины. Строки данных — нет | Большинству коммерческих компаний: данные остаются в РФ, договор и счёт в рублях |
| GigaChat Enterprise в своём контуре или гибрид | Ничего: модель работает внутри периметра | Есть требование не выпускать наружу даже формулировки вопросов |
| Локальная модель на своём сервере: Qwen 3, Llama, через Ollama | Ничего | Персональные данные в самих вопросах, значимые объекты КИИ, требования регулятора к размещению |
| Зарубежные модели через посредников | Текст вопроса и описание витрины уходят за пределы РФ | Рабочей рекомендацией не является: прямой оплаты из РФ нет, трансграничная передача требует отдельных оснований |
Практический ориентир: облачная российская модель закрывает задачу у компании, которая не работает с гостайной и не имеет в договорах требований к размещению обработки. Локальная модель добавляет к проекту сервер и сопровождение — когда это оправдано, посчитано в материале про модель в своём контуре. Расход на саму модель при этом скромный: 350 вопросов в месяц при 4,5 ₽ за вопрос — меньше 2 000 ₽, то есть в смете эксплуатации это не та строка, вокруг которой стоит спорить.
Когда дешевле пять фиксированных отчётов
Самый частый честный ответ на запрос «хотим спрашивать данные словами» — «вам хватит пяти отчётов». Разница в смете большая, и её стоит увидеть до начала обследования.
Считать окупаемость надо по разовым запросам, которые контур снимает с аналитика. В модельной компании таких запросов 26 в месяц, каждый занимает около 2,4 часа с учётом уточнений и очереди. По полной стоимости часа 1 400 ₽ это 87 360 ₽ в месяц. Из них вычитаются 22 000 ₽ эксплуатации — поддержка контура и расход на модель, — остаётся 65 360 ₽. Вложение 693 000 ₽ возвращается за 11 месяцев, и это долго.
Порог, начиная с которого контур становится осмысленным, — примерно 41 разовый запрос в месяц: тогда чистая экономия достигает 115 760 ₽ и срок окупаемости падает до 6 месяцев. Столько запросов бывает у компании, где над данными работает несколько человек и решения принимаются ежедневно. У оптовика на 40 человек с одним аналитиком таких вопросов обычно нет, и пять фиксированных отчётов на BI-дашбордах закрывают ту же потребность за 140 000 ₽.
Двухосевой график. По горизонтали — число разовых запросов в месяц от 10 до 80, по вертикали — срок окупаемости в месяцах от 0 до 24. Одна убывающая кривая. Отмечены и подписаны две точки: «26 запросов — 11 месяцев» и «41 запрос — 6 месяцев». Горизонтальная штриховая линия на уровне 6 месяцев с подписью «порог разумности», область левее точки 41 залита светлой штриховкой с подписью «дешевле пять отчётов за 140 000 ₽». Подписи по-русски.
Поставьте сюда своё: сколько человек тратит время на разовые запросы, сколько часов в день это занимает и какая у них полная стоимость часа. Вложение и эксплуатация подставлены из модельной сметы — 693 000 ₽ и 22 000 ₽ в месяц.
Сколько стоит ручная работа в вашем процессе
Расчёт учитывает только время сотрудников. Возвращённые продажи, снятые ошибки и штрафы, скорость реакции — сверх этой модели. На диагностике считаем по вашим фактическим цифрам.
И три ситуации, в которых контур вопросов не надо строить вообще, сколько бы запросов ни было. Первая: витрин ещё нет, есть только выгрузки из 1С и CRM — тогда сначала данные, иначе вы платите за красивый интерфейс к беспорядку. Вторая: вопросы, которые задают чаще всего, повторяются почти дословно — их место в подписке на регулярный отчёт, это дешевле в разы. Третья: ответы нужны для внешней отчётности или для решений с юридическими последствиями — там нужен воспроизводимый регламентированный отчёт, а не диалог, каждый раз собирающий запрос заново.
Контур запросов не отвечает на вопросы. Он переводит их в SQL по вашему словарю — и стоит ровно столько, сколько стоит этот словарь.
