Разбор от сообщества: ИИ-помощник по данным 1С: архитектура вместо RAG

11 августа 2026 · infolimp.ru

Почему классический RAG не работает с данными 1С

Стандартный RAG-пайплайн: берём документы, режем на чанки, индексируем в векторной базе, по запросу ищем семантически близкие куски и скормиваем их LLM как контекст. Для 1С это ломается о три фундаментальные проблемы.

Проблема №1: Данные ≠ Текст

В 1С данные живут в таблицах, а не в PDF. Оборотно-сальдовая ведомость, остатки по складам, цепочка документов — это структурированные наборы записей. RAG, обученный на тексте, не понимает, что «дебет 90.01.1» и «кредит 90.02» — это не просто слова, а проводки с корреспонденцией. Попытка скормить LLM плоскую выгрузку из регистра бухгалтерии даст мусор на выходе.

Проблема №2: Контекстная связанность

Вопрос «Почему не закрылся 20-й счёт в январе?» требует не поиска фразы, а построения цепочки: сальдо на начало → обороты по дебету/кредиту → закрытие месяца → анализ субконто. RAG выдаст куски инструкций по закрытию месяца, но не сможет собрать фактические данные из базы.

Проблема №3: Актуальность данных

Векторная база живёт своей жизнью. Пока вы переиндексируете документы, в базу уже провели 500 новых документов. RAG будет отвечать на вопрос «сколько товара на складе?» по вчерашнему слепку, а не по текущим остаткам.

Ключевой тезис: RAG хорош для поиска по нормативной документации (как провести переоценку валюты). Для работы с оперативными данными 1С нужен не поисковик по тексту, а агент, умеющий выполнять запросы к метаданным и регистрам.

Архитектура ИИ-помощника: от RAG к Data Agent

Автор статьи предлагает архитектуру, где LLM выступает не как генератор ответа по найденным чанкам, а как планировщик запросов к данным 1С. Вместо векторной базы — слой описания метаданных (схема конфигурации), а вместо поиска — генерация и исполнение запросов.

Компоненты архитектуры

1. Мета-описатель конфигурации — JSON-схема, описывающая структуру метаданных: справочники, документы, регистры, реквизиты, измерения, ресурсы. Это статический слой, который обновляется при изменении конфигурации.
2. Планировщик запросов (LLM) — получает естественно-языковой вопрос пользователя и преобразует его в последовательность действий: «Найти справочник Номенклатура → Получить остатки по регистру ТоварыНаСкладах → Сгруппировать по складу». Планировщик не лезет в данные, он только строит план.
3. Исполнитель (Executor) — модуль на 1С, который принимает план (например, в формате JSON) и выполняет его через реальные объекты метаданных: РегистрыНакопления.ТоварыНаСкладах.Остатки().
4. Формирователь ответа — второй вызов LLM, который получает результат выполнения (таблицу значений) и формулирует ответ на русском языке.

Пример работы

Пользователь пишет: «Покажи топ-5 товаров по остаткам на центральном складе».

Планировщик генерирует план:

{
  "action": "query_register",
  "register": "ТоварыНаСкладах",
  "type": "Остатки",
  "filters": [
    {"field": "Склад", "value": "Центральный"}
  ],
  "group_by": "Номенклатура",
  "order_by": {"field": "КоличествоОстаток", "direction": "desc"},
  "limit": 5
}

Исполнитель на 1С выполняет:

Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ ПЕРВЫЕ 5
 |  ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
 |  ТоварыНаСкладахОстатки.КоличествоОстаток КАК Остаток
 |ИЗ
 |  РегистрНакопления.ТоварыНаСкладах.Остатки(, , Склад = &Склад) КАК ТоварыНаСкладахОстатки
 |УПОРЯДОЧИТЬ ПО
 |  Остаток УБЫВ";
Запрос.УстановитьПараметр("Склад", Справочники.Склады.НайтиПоНаименованию("Центральный"));
Результат = Запрос.Выполнить().Выгрузить();

Формирователь ответа получает таблицу значений и пишет: «На центральном складе больше всего остатков по товару "Шуруповёрт Bosch" — 45 шт., далее "Перфоратор Makita" — 32 шт...»

Отличие от RAG: LLM никогда не видит сырых данных. Она оперирует только схемой и планом. Это исключает галлюцинации на уровне цифр — ответ всегда основан на реальном запросе к базе.

Практическая реализация: что нужно сделать прямо сейчас

Архитектура не требует внедрения сложных ML-моделей на стороне 1С. Всё, что нужно — это HTTP-сервис, который принимает план и возвращает результат. LLM (GPT, YandexGPT, GigaChat) работает снаружи.

Чек-лист для внедрения

1. Создать мета-описатель конфигурации. Напишите обработку, которая обходит метаданные и выгружает их в JSON: имена справочников, реквизиты, типы, связи. Это будет «словарь» для LLM.
2. Разработать HTTP-сервис-исполнитель. Один метод: принимает JSON-план, выполняет запрос, возвращает результат в JSON. Используйте HTTPСервис в конфигурации.
3. Настроить промпт для планировщика. В системное сообщение LLM передавайте мета-описание конфигурации и инструкцию: «Ты — планировщик запросов к 1С. На вход получаешь вопрос пользователя, на выход — JSON-план. Не выдумывай поля, используй только те, что есть в схеме».
4. Реализовать формирователь ответа. Второй промпт: «Ты — аналитик. Получил результат запроса в виде таблицы. Сформулируй понятный ответ на русском языке. Не добавляй цифр, которых нет в данных».

Типичные ошибки

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

Когда RAG всё-таки нужен, а когда — нет

Не демонизируем RAG. У каждого подхода своя ниша.

Рекомендация редакции: Если ваш сценарий — «дай справку по проводкам» — используйте RAG по документации 1С. Если «почему у меня сальдо по 60-му счёту не сходится» — стройте Data Agent. Комбинируйте: RAG для нормативки, Agent для данных.

Что делать прямо сейчас

Не пытайтесь сразу построить полноценного агента. Начните с малого:

• Напишите обработку, которая выгружает метаданные конфигурации в JSON. Это займёт 2-3 часа.
• Сделайте простой HTTP-сервис, который принимает текст запроса на языке 1С и возвращает результат. Протестируйте с одним регистром.
• Попробуйте отправить в GPT промпт: «Вот схема конфигурации: [JSON]. Ответь на вопрос пользователя, сгенерировав план запроса». Увидите, как LLM справляется с планированием.

Архитектура, предложенная сообществом, — это не серебряная пуля, но элегантный способ обойти ограничения RAG там, где важна оперативность и точность данных. И главное — она реализуема на текущей платформе 1С без доработок типовых конфигураций.