Вопрос «сколько мы отгрузили этому клиенту за квартал в разрезе складов» живет в бэклоге программиста три дня. Сам запрос пишется за двадцать минут: семьдесят один час сорок минут из семидесяти двух уходят в очередь. Раз в неделю такое терпимо. Десять раз в день — узкое место, на котором решения начинают приниматься по памяти, потому что ждать дольше, чем прикинуть в уме.
Отсюда идея, которую на предпроектном разговоре обычно приносит сам заказчик: пусть руководитель спрашивает базу словами. Идея рабочая. Только между вопросом и цифрой в ответе стоит инженерный слой, от которого зависит ровно одно — будет цифра верной или только уверенной. Про этот слой и текст: с чего начинать, чем проверять и по каким пунктам принимать.
Модель пишет запрос, считает по-прежнему база
Первое, что стоит зафиксировать в техническом задании: языковая модель не складывает суммы. Если она «посчитала» вам оборот в уме — вы уже в беде. Ее работа заканчивается на тексте запроса, дальше арифметику делает платформа.
Конвейер выглядит так:
- Разбор вопроса. Из формулировки достаются сущности: период, организация, склад, контрагент, показатель, разрез.
- Подбор объектов схемы. Из описания данных выбираются те несколько таблиц и реквизитов, которые относятся к вопросу.
- Генерация запроса. Текст на языке запросов 1С или SQL по витрине.
- Статическая проверка до исполнения. Белый список таблиц, обязательное условие по периоду, обязательный предел на число строк.
- Исполнение под правами спрашивающего. С таймаутом и лимитом выборки.
- Сборка ответа. Число, разрез, единица, период, отметка актуальности данных, текст выполненного запроса и переход к документам-источникам.
Каждый шаг проверяется отдельно и ломается отдельно. Дальше — по шагам, начиная с того, который в проектах недооценивают сильнее всего.
Паспорт данных: то, чего модель про вашу базу знать не может
В типовой конфигурации управления торговлей несколько тысяч объектов метаданных. Выгрузить их все и отдать модели — прямой путь к мусору: она выберет похоже названную таблицу и уверенно посчитает по ней.
Работает обратное движение. Маленький курируемый словарь: двадцать-шестьдесят объектов, которые закрывают подавляющую часть вопросов, и по каждому — человеческое описание.
- Что это за таблица словами. «Регистр накопления „Продажи": движения по отгрузкам, период движения равен дате документа-регистратора».
- Реквизиты и единицы. Где сумма без НДС, где с НДС, в каких единицах количество — в базовых или в единицах документа.
- Синонимы бизнес-терминов. «Выручка», «продажи», «отгрузка», «реализация» — какое поле какого регистра имеется в виду именно у вас.
- Разрезы. Организация, склад, номенклатура, характеристика, менеджер, а также партнер и контрагент по отдельности: в управлении торговлей это два разных справочника, и вопрос «топ клиентов» без уточнения имеет два разных ответа.
- Примеры «вопрос → запрос». Двадцать-тридцать пар, которые подмешиваются в контекст. Дают больше, чем любое описание прозой.
Отдельная строка словаря — то, что из метаданных не выводится вообще. «Продали» у вас с возвратами или без? Период считается по дате документа или по дате проведения? Это методология, и живет она в головах у финансовой службы, за пределами конфигуратора. Пока эти определения не записаны на бумаге, приемка не кончится никогда: любой ответ можно объявить неверным задним числом.
Чтобы в контекст модели попадали только релевантные объекты, описания таблиц и примеры вопросов кладут в векторный индекс и достают три-пять кандидатов вместо всего справочника метаданных. Механика такого поиска — на странице векторного поиска.
Пять барьеров между моделью и рабочей базой
Пускать генератор запросов напрямую в продуктивную базу — плохая идея по двум причинам сразу. Сгенерированный запрос без ограничений спокойно займет соединение на десять минут в разгар рабочего дня. И рабочая база — последнее место, где стоит заводить нового субъекта с неочевидными правами.
| Барьер | Что ставят | Что ловит |
|---|---|---|
| Витрина | Отдельная база с плоскими таблицами, наполняемая регламентным заданием | Тяжелый запрос не касается контура, в котором работают люди |
| Только чтение | Отдельный пользователь информационной базы с ролью без прав записи | Любую попытку изменить или удалить данные |
| Белый список объектов | Явный перечень таблиц и полей, доступных генератору | Обращение к зарплате, персональным данным, служебным регистрам |
| Лимит выборки | Обязательное ограничение числа строк и обязательная группировка | Выгрузку половины базы одним невинным вопросом |
| Таймаут | Предел времени выполнения: секунды, не минуты | Соединение таблиц без условия — декартово произведение на миллионах строк |
Шестой элемент контура — журнал. Кто спросил, что спросил, какой запрос сгенерировался, сколько выполнялся, сколько строк вернул. Без журнала первый же спор «система показала другое число» разбирать нечем.
Витрина: что в нее кладут и как часто обновляют
Первый соблазн — читать таблицы СУБД под базой 1С напрямую. Не надо. Имена там сгенерированы платформой, вида _Document123_VT456 и _Fld12345, состав меняется при обновлении конфигурации, а сопоставление полей приходится восстанавливать заново после каждого релиза. Витрину наполняют штатными механизмами платформы.
Что в нее имеет смысл класть:
- обороты и остатки из регистров накопления с фиксированной периодичностью — день или месяц, в зависимости от того, какие вопросы задают;
- справочники-разрезы плоскими таблицами с человеческими именами колонок и стабильными идентификаторами;
- курсы валют и цены из периодических регистров сведений — срезом на дату;
- ссылку на документ-регистратор: это тот самый ключ, по которому потом строится переход от числа к первичным документам.
Частота обновления — договоренность, которую фиксируют письменно и выводят в интерфейсе. Ночная перезаливка проще и дешевле, но тогда рядом с каждым ответом обязана стоять отметка «данные на 03:40 сегодня». Без нее руководитель увидит вчерашние остатки и примет их за текущие, а виноватой окажется система.
Отдельная засада учетных данных: документ, проведенный задним числом, меняет обороты прошлого периода. Один и тот же вопрос вчера и сегодня законно дает разные ответы. Это надо не чинить, а объяснять: показывать дату и время среза и не удивляться. Как выгружать данные без просадки учетной системы и почему регламентное задание в рабочие часы — плохая идея, разобрано в интеграции ИИ с 1С и ERP.
На чем генерировать запрос
Три варианта, и выбор определяет половину проекта.
Стандартный интерфейс OData. Хорош для точечного чтения объектов. Для аналитики слаб: агрегатов на стороне сервера нет, и вопрос «обороты за год» превращается в выкачивание всех документов наружу с последующим суммированием на своей стороне. На больших объемах это неприемлемо по времени и по нагрузке.
Язык запросов 1С. Родные виртуальные таблицы остатков, оборотов и срезов последних, честная работа периодичности и итогов, права учитываются платформенным механизмом ограничения доступа на уровне записей. Минус один: модели пишут на нем заметно хуже, чем на SQL — в открытых данных его почти нет. Лечится примерами и шаблонами, где модель заполняет параметры заранее написанного запроса вместо свободного сочинения текста.
SQL по витрине. Модель пишет уверенно, валидатор разбирает дерево запроса, ограничения накладываются условиями. Плата за удобство — права доступа приходится переносить в витрину и поддерживать руками.
Практичный компромисс: библиотека параметризованных запросов на частые вопросы плюс свободная генерация на редкие. Первое покрывает основную часть потока и не ошибается по построению, второе спасает от «а можно то же самое, но в разрезе менеджеров».
Что бы вы ни выбрали, валидатор из таблицы выше стоит между генерацией и исполнением всегда. Запрос, не прошедший разбор, до базы не доходит: ассистент честно говорит, что не смог. Отдельная головная боль начинается на базе с историей и переписанным типовым функционалом — что там ломается, разобрано в разборе граблей конфигурации.
Уверенно неверная цифра — главный риск
Ассистент, который отвечает «не знаю», безобиден. Ассистент, который назвал сумму мимо на несколько миллионов ровным тоном и с аккуратным форматированием, превращается в решение о закупке, принятое по выдуманным данным.
Общая теория того, как заставить модель держаться источников, разобрана отдельно — в статье про галлюцинации. Специфика учетных данных в другом: у выдуманного текста есть стилистические признаки, у выдуманного числа их нет. Оно выглядит ровно так же, как настоящее. Значит, полагаться на впечатление читателя нельзя, нужны механизмы.
- Запрос показывается рядом с ответом. Свернутый блок «как посчитано» с текстом запроса и подставленными параметрами. Руководитель туда обычно не заглядывает. Зато 1С-ник или финансовый контролер прочитает его за минуту и подтвердит методику. Один раз подтвержденный запрос переезжает в библиотеку шаблонов.
- Переход к документам-источникам. Из итоговой суммы должен открываться список реализаций, которые в нее сложились. Ключ для этого — ссылка на регистратор, которую вы положили в витрину на предыдущем шаге.
- Отказ при неоднозначности. Ассистент, который угадывает смысл вопроса, опаснее ассистента, который переспрашивает.
- Регулярная сверка агрегатов с типовым отчетом. Про нее ниже отдельно, потому что это самая недооцененная часть системы.
Ночная сверка с типовым отчетом
Механизм дешевый в разработке и почти всегда пропущенный в смете. Берется тот самый набор из сорока-шестидесяти контрольных вопросов с известными ответами, который вы собираете по чек-листу в конце статьи. Ночью робот задает их ассистенту и сравнивает результат с эталоном, который считает штатный отчет платформы: оборотно-сальдовая ведомость, ведомость по товарам на складах, валовая прибыль, задолженность клиентов.
Расхождение больше копейки — письмо ответственному до того, как цифру увидит человек. Такой набор ловит три класса поломок: обновление конфигурации сломало сопоставление полей витрины, смена версии модели изменила формулировки запросов, кто-то поправил методику в настройках отчета и не поправил в словаре данных.
Подход тот же, что и в регулярной проверке агентов: набор фиксируется до запуска и живет вместе с системой. Побочный эффект — общий язык на приемке. Вместо «нам кажется, оно врет» появляется «семнадцать контрольных вопросов из пятидесяти расходятся с оборотно-сальдовой ведомостью, вот список».
Когда ассистент обязан переспросить
Формулировки, за которыми менеджер и финансовый директор видят разное. Так устроен деловой язык, и чинить это бесполезно.
| Формулировка | Что в ней скрыто | Что уточняет ассистент |
|---|---|---|
| «Продажи за июль» | Отгрузки или поступление денег; считать ли возвраты | По реализациям или по оплатам, возвраты вычитать |
| «За прошлый месяц» | Дата документа или дата проведения; закрыт ли период регламентными операциями | Период по дате документа, месяц еще не закрыт — себестоимость предварительная |
| «Топ клиентов» | Партнер или контрагент; по обороту или по прибыли | В разрезе партнеров или контрагентов, ранжировать по выручке или по валовой прибыли |
| «Наша выручка» | Одна организация или группа компаний; с НДС или без | По какой организации, суммы с НДС или без |
| «Остатки на складе» | На текущий момент или на дату; вычитать ли резервы | На дату среза витрины или на конец периода, свободный остаток или физический |
| «Маржа по проекту» | Правило распределения косвенных затрат | Отказ: правила распределения в базе нет |
Уточнение обязано быть коротким и с вариантами в один клик. Ассистент, задающий три встречных вопроса на каждый запрос, умирает за неделю использования: люди возвращаются к программисту. Механика того, как система решает, переспросить или отвечать, разобрана в агентном RAG.
Права доступа: ответ зависит от того, кто спрашивает
Самая частая архитектурная ошибка пилота выглядит невинно: сервисная учетная запись с полными правами читает витрину, ассистент отвечает всем одинаково. В демо это незаметно. В промышленной эксплуатации это означает, что руководитель одного направления узнает выручку соседнего, себестоимость своих же сделок и — при небрежном белом списке — фонд оплаты труда.
Правило простое: запрос исполняется от имени спрашивающего. В контуре платформы это механизм ограничения доступа на уровне записей и профили групп доступа. В витрине то же самое воспроизводится руками: у каждой строки лежат организация, подразделение, склад и менеджер, а на каждый запрос автоматически навешивается условие по правам пользователя.
Три места, где утечка проскакивает мимо аккуратной архитектуры:
- Кэш ответов. Ключ кэша обязан включать роль или набор прав. Общий кэш по тексту вопроса выдаст финансовый ответ второму спрашивающему, у которого доступа к нему нет.
- Журнал вопросов. В нем оседают и формулировки, и результаты. Доступ к журналу — отдельное право со своим списком получателей.
- Тексты ошибок. Сообщение «нет доступа к регистру взаиморасчетов» уже раскрывает, что такой регистр есть и что в нем лежит. Отказ формулируется нейтрально.
И граница ответственности: аналитик читает и никогда не пишет. Как только появляется желание дать ему право создавать и проводить документы, это другой проект с другой ценой ошибки и другой приемкой — разобран в статье про ИИ-агента с правом записи в 1С.
Что закрывается хорошо, а что нет
| Класс вопроса | Пример | Результат |
|---|---|---|
| Обороты за период в разрезе | «Отгрузки за июль по складам» | Хорошо: прямой запрос к регистру накопления |
| Остатки на дату | «Что лежит на складе в Твери по этой товарной группе» | Хорошо при честной отметке актуальности витрины |
| Ранжирование | «Двадцать контрагентов с наибольшей задолженностью» | Хорошо: сортировка плюс предел строк |
| Динамика и сравнение периодов | «Июль к июню по направлениям» | Хорошо, если периодичность витрины совпадает с шагом сравнения |
| Поиск документа по описанию | «Реализация этому покупателю на прошлой неделе примерно на полмиллиона» | Хорошо, если реквизиты поиска попали в витрину |
| Управленческая методика | «Наша EBITDA за квартал» | Плохо: правила сборки показателя в учетной базе нет |
| Распределение косвенных | «Себестоимость этого заказа с учетом аренды и логистики» | Плохо: база распределения живет вне учетной системы, часто в таблице у финансиста |
| Вопрос с неявным допущением | «Почему упали продажи» | Плохо: нужна гипотеза, у ассистента ее нет |
| Прогноз | «Сколько продадим в августе» | Другая задача: к отчетности отношения не имеет |
Граница проходит по одному признаку. Если однозначный ответ лежит в данных — ассистент его достанет и покажет запрос. Если ответ требует методики, которой в базе нет, он обязан сказать об этом прямо. Худший из возможных сценариев — когда система подставляет ближайшую похожую цифру и называет ее EBITDA.
Когда не надо
Пять ситуаций, в которых честный ответ — «оставьте как есть».
- Меньше десятка нестандартных вопросов в неделю. Программист успевает. Арифметика считается на салфетке: два часа ожидания в неделю — это сто часов в год, при внутренней стоимости часа 1500 ₽ выходит 150 000 ₽ в год. Против первого процесса от 250 000 ₽ это почти два года окупаемости без учета сопровождения. Подставьте свои часы и свою ставку.
- Управленческая методика не зафиксирована. Если два финансиста в компании считают маржу по-разному, ассистент этого не решит. Он только быстрее покажет расхождение. Сначала регламент, потом инструмент.
- Справочники в беспорядке. Три карточки одного контрагента, номенклатура «Товар без названия 3». Ответ будет технически верным и практически бесполезным.
- Нужна регламентированная отчетность. Формы для регулятора считает платформа, и переизобретать их языковой моделью незачем и рискованно.
- У вас уже есть работающая BI-система с проверенной моделью данных. Тогда задача сужается до текстового интерфейса поверх готовой модели, и это дешевле в разы.
Чек-лист приемки
Одиннадцать пунктов. Первые два делаются до старта работ и стоят день-два финансовой службы вместе с 1С-ником, остальные проверяются на демонстрации.
- Собрать сорок-шестьдесят реальных вопросов от тех, кто будет спрашивать. Дословно, с их сокращениями и жаргоном.
- Для каждого зафиксировать эталонный ответ, посчитанный типовым отчетом или руками 1С-ника. Это приемочная выборка и одновременно контрольный набор для ночной сверки.
- Проверить, что текст выполненного запроса и параметры видны рядом с ответом.
- Проверить переход от числа к документам-источникам хотя бы на трех вопросах разных классов.
- Задать один и тот же вопрос от трех пользователей с разными правами. Ответы обязаны различаться.
- Задать заведомо неоднозначный вопрос. Ассистент обязан уточнить формулировку; угаданный ответ засчитывается как непройденный пункт.
- Задать вопрос про данные, которых в витрине нет. Ассистент обязан отказать словами и не подставить похожую таблицу.
- Убедиться, что на каждом ответе стоит отметка актуальности данных.
- Проверить лимит и таймаут: запрос без периода и без ограничения строк не должен доходить до базы.
- Посмотреть журнал: пользователь, вопрос, сгенерированный запрос, время выполнения, число строк.
- Договориться о регламенте обновления конфигурации: кто и когда перезапускает контрольный набор после релиза.
Что дальше
Порядок работ, сроки и вилки — на странице ИИ в 1С: первый процесс от 250 000 ₽, три-пять недель до пилота. Разумный первый шаг — один класс вопросов: обороты и остатки по одному регистру, десяток контрольных вопросов, ночная сверка с типовым отчетом. Расширять словарь данных потом дешево, переделывать контур доступа задним числом дорого.
Если хотите проверить идею до бюджета — соберите те самые сорок-шестьдесят вопросов из первого пункта чек-листа и разложите их на две стопки: закрывается запросом к регистру и упирается в методику, которой в базе нет. Соотношение стопок и есть граница будущего проекта.