Запрос от бизнеса звучит одинаково: «Хотим чат, который отвечает на вопросы по нашей 1С». Дальше обычно берут популярную схему — выгружают данные, кладут в векторную базу, подключают модель. На демо это работает. В эксплуатации разваливается на первой же неделе.
Разберём, почему так и какая архитектура переживает контакт с реальной базой.
Почему наивный RAG здесь не работает
Классический RAG рассчитан на текст: документы, регламенты, статьи. Вы режете их на фрагменты, считаете векторы, находите похожее по смыслу и отдаёте модели как контекст.
Учётные данные так себя не ведут, и вот почему.
Ответа нет в тексте. Остаток по номенклатуре не лежит нигде готовой строкой. Он вычисляется по регистру накопления на дату, с учётом всех движений. Векторный поиск по выгруженным документам не найдёт остаток, потому что остатка как текста не существует.
Данные меняются постоянно. Индекс, собранный ночью, к обеду устарел. Для регламента это неважно, для дебиторки — критично. Ассистент, уверенно называющий вчерашнюю сумму долга, хуже, чем отсутствие ассистента.
Числа не ищутся по смыслу. Векторная близость работает для формулировок, но не для «покажи заказы свыше миллиона за июль». Это условие отбора, а не смысловое сходство.
Права доступа. Выгрузили в индекс — потеряли ограничения. Менеджер, который в 1С видит только своих контрагентов, спросит у ассистента про чужих и получит ответ.
Последний пункт обычно всплывает позже всех и стоит дороже всех.
Три класса вопросов
Работающая схема начинается не с выбора модели, а с разделения вопросов на классы. Их три, и обрабатываются они принципиально по-разному.
Вопросы к текстам. «Какой порядок согласования договора со скидкой больше 15%?», «Что делать при возврате брака от розничного покупателя?» Ответ лежит в регламентах, инструкциях, приказах, переписке. Здесь классический RAG уместен и работает хорошо: данные меняются редко, ответ по своей природе текстовый.
Вопросы к учётным данным. «Сколько осталось на складе в Подольске?», «Какая дебиторка у контрагента на сегодня?», «Что отгрузили этому клиенту в июле?» Здесь никакого RAG быть не должно. Модель нужна только чтобы превратить фразу человека в параметры запроса: что спрашивают, по какому объекту, на какую дату, в каком разрезе. Дальше отрабатывает обычный запрос к базе, и цифру отдаёт 1С, а не модель.
Смешанные. «Почему клиенту не отгрузили заказ?» — тут и статус документа, и правило из регламента. Такие вопросы разбираются на подзапросы: часть уходит в базу, часть в поиск по текстам, ответ собирается из обоих источников.
Практический вывод: первое, что делает система, — определяет класс вопроса. Не находит ответ, а решает, куда идти. Если этого шага нет, вы получаете ассистента, который на вопрос об остатках уверенно цитирует прошлогоднюю инструкцию.
Как устроен запрос к учётным данным
Здесь важна деталь, которую часто пропускают: модель не должна генерировать текст запроса к базе напрямую.
Соблазн понятен — пусть модель напишет запрос, выполним его, вернём результат. Но такая схема означает, что внешний компонент формирует произвольные обращения к вашей базе. Ошибка в условии даст неверную цифру, которую никто не заметит, а неудачная формулировка — тяжёлый запрос на всю таблицу движений.
Рабочая схема другая. На стороне 1С делается ограниченный набор параметризованных операций: остатки по номенклатуре и складу на дату, взаиморасчёты по контрагенту, отгрузки за период, статус документа. Каждая — отдельный HTTP-сервис с понятными параметрами и предсказуемым планом выполнения.
Модель в этой схеме занимается только распознаванием: какой из операций соответствует вопрос и какие параметры из фразы вытащить. Всё остальное делает 1С своими средствами — своими запросами, своими правами, своей логикой.
Побочный, но важный эффект: набор операций легко тестировать. Их конечное число, у каждой известны входы и выходы.
Права доступа
Это то место, где проекты чаще всего ломаются на приёмке, причём ломаются громко.
Правило простое и не обсуждается: ассистент не должен показывать пользователю то, чего тот не видит в 1С.
Отсюда следствие: запрос к данным должен выполняться от имени конкретного пользователя, а не от служебной учётной записи с полными правами. Тогда ограничения на уровне записей, ролевая модель и все настроенные ограничения применяются сами собой — это уже работает в конфигурации, и дублировать эту логику снаружи не нужно и опасно.
Ошибка, которую видно постоянно: интеграция ходит в базу под одним техническим пользователем, а разграничение пытаются сделать на стороне ассистента фильтрацией результата. Это работает ровно до первого сценария, который не предусмотрели.
С текстовой частью сложнее: у регламентов и инструкций прав в 1С нет. Значит, разграничение придётся заводить на уровне источников — помечать, какие документы кому доступны, и учитывать это при поиске. Проще всего начинать с тех текстов, которые открыты всем сотрудникам, и расширять состав постепенно.
Актуальность и ссылка на источник
Для учётных вопросов ответ должен считаться в момент запроса. Никакого кеша: цена ошибки в остатках и долгах слишком высока, а выигрыш в скорости незаметен.
Для текстов кеш допустим, но у каждого фрагмента должна храниться версия и дата. Регламенты обновляются, а старая редакция в индексе живёт годами и продолжает отвечать.
И главное требование, которое стоит поставить с самого начала: ответ без ссылки на источник считается неготовым. Для учётных данных — что за операция и с какими параметрами отработала. Для текстов — какой документ, какая редакция, какой раздел.
Причина не в красоте. Ответ со ссылкой можно проверить и переслать дальше. Ответ без ссылки нельзя ни проверить, ни использовать в разговоре с клиентом — а значит, им не будут пользоваться.
Локальная модель и контур
Вопрос «облако или локально» в проектах вокруг 1С решается не качеством моделей, а тем, кто в компании согласует передачу данных наружу.
Практическое наблюдение: для распознавания намерения и извлечения параметров из фразы больших моделей не требуется. Это задача, с которой открытые модели среднего размера справляются на русскоязычных формулировках, и её вполне можно держать внутри периметра.
Отсюда рекомендация по архитектуре: слой распознавания и слой доступа к данным должны быть отделены от конкретной модели. Тогда решение «облако или локально» принимается по ходу проекта и меняется без переписывания системы — а не блокирует старт на этапе согласований.
Что закладывать сразу
Классификация вопроса до поиска ответа. Ограниченный набор параметризованных операций на стороне 1С вместо генерации запросов моделью. Выполнение от имени пользователя, чтобы права работали сами. Обязательная ссылка на источник в каждом ответе. Версионирование текстовых источников. Отделение слоя доступа к данным от конкретной модели.
И ещё одно, не техническое: заранее договоритесь, на какие вопросы система отвечать не должна. Ассистент, который честно отвечает «не знаю, спросите у бухгалтерии», полезнее того, который отвечает всегда.
Итог
Ассистент по данным 1С — это не поиск по выгрузке. Это маршрутизатор, который отличает вопрос к регламенту от вопроса к регистру, и в первом случае идёт в текстовый поиск, а во втором — в учётную систему, от имени пользователя и с проверяемым ответом.
Модель здесь занимает куда меньше места, чем принято думать: она понимает вопрос и формулирует ответ. Цифры считает 1С.
Николай Мазур, MZR Digital.
Вступайте в нашу телеграмм-группу Инфостарт
