Почему нейросеть врёт в запросах к 1С (СКД, GUID, имена полей) и как это чинить

Конец месяца, пятница. Аналитик отдела продаж собирает для коммерческого директора сводку по отгрузкам в 1С:Управление торговлей 11. Программист занят релизом, ждать некогда. Аналитик открывает публичный чат нейросети и просит: «Напиши запрос на языке 1С: продажи по клиентам за месяц с остатками на складах». Через пару секунд приходит аккуратный текст с ВЫБРАТЬ, СГРУППИРОВАТЬ ПО, обращением к виртуальной таблице регистра. Выглядит убедительно. Аналитик вставляет его в консоль запросов, отчёт открывается, суммы складываются.

Проблема всплывает через неделю, когда финансовая служба сверяет цифры. Модель сгруппировала продажи по реквизиту Контрагент, а в этой базе аналитика ведётся в разрезе Партнёров (в УТ 11 Партнёр и Контрагент это две разные сущности, и одному партнёру может соответствовать несколько контрагентов). Отчёт не упал с ошибкой. Он тихо посчитал не то. Вдобавок отбор по статусу заказа не сработал: модель подставила GUID предопределённого значения перечисления, которого в этой конфигурации нет, поэтому фильтр молча вернул пустой результат вместо отфильтрованных строк.

Это не редкая осечка и не «плохая модель». Так ведёт себя любая языковая модель, и у этого есть понятная причина.

Что именно выдумывает модель

Разберём по типам: выглядят они по-разному, а лечатся одинаково.

Имена полей и реквизитов. Модель уверенно пишет Номенклатура.Артикул или Контрагент.ИНН, но в конкретной, да ещё и доработанной конфигурации реквизит может называться иначе, лежать в другом объекте или вообще отсутствовать. Она путает реквизит шапки документа с реквизитом табличной части, придумывает несуществующее измерение регистра сведений, обращается к плану обмена по имени, которого в вашей базе нет. Отсюда классическое «Поле не найдено».

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

СКД. ИИ ошибается в СКД по той же логике: он не видит реальную схему компоновки данных, поэтому придумывает имена полей набора, параметры и роли. Схема открывается, а поля не бьются с данными, связи наборов повисают в пустоту.

Язык запросов. Модель тянет привычки из SQL: пишет JOIN вместо СОЕДИНЕНИЕ, TOP вместо ПЕРВЫЕ, путает виртуальные таблицы регистров (Остатки, ОстаткиИОбороты, СрезПоследних) и их параметры, обращается к несуществующим таблицам.

Синтаксис при этом валиден, а смысл нет. Это и есть галлюцинации LLM в 1С.

Почему это не лечится «промптом получше»

Причина в том, где модель берёт ответ. Обучали её на общих материалах: статьи, типовые примеры, обрывки с форумов. Метаданных вашей базы там не было. А каждая конфигурация уникальна: доработки переименовывают реквизиты и добавляют свои регистры, Бухгалтерия отличается от УТ, УТ от ЗУП, и даже две УТ после разных внедрений это разные базы.

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

Дальше работает простая механика. Языковая модель работает как вероятностная машина: она выдаёт наиболее правдоподобное продолжение текста. Когда истинного имени поля или GUID у неё нет, она не останавливается и не говорит «я не знаю». Она подставляет самую вероятную на вид строку, и выдумка звучит с той же уверенностью, что и факт. В структурированном домене вроде метаданных 1С это почти всегда даёт правдоподобный, но неверный идентификатор. Поэтому, когда нейросеть выдаёт неправильный запрос 1С, дело не в формулировке промпта, а в отсутствии у неё доступа к правде. По той же причине ChatGPT или другой ассистент пишет неверный код для 1С там, где для типового Python выдал бы рабочий.

Чем это опасно на самом деле

Явная ошибка это полбеды: запрос упал, вы увидели и переписали. Опаснее тихо неверный результат, как в истории выше. Отчёт открылся, числа похожи на правду, решение принято на кривых данных, а расхождение всплывает через неделю на сверке.

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

Третий момент про периметр. Чтобы «помочь» модели, в облачный чат выгружают куски схемы метаданных и реальные данные с ФИО, ИНН, договорами. Это и утечка, и обработка персональных данных за пределами контура, которую регулирует 152-ФЗ. С 30 мая 2025 года ответственность за утечку ПДн в России резко выросла: штрафы за первую утечку доходят до 15 млн рублей, а за повторную введены оборотные, до 3 процентов годовой выручки. Парадокс в том, что дамп схемы на несколько тысяч символов не только уводит данные наружу, но и не спасает от галлюцинаций: такой объём модель всё равно держит ненадёжно.

Как это чинить: заземление, а не уговоры

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

Что это значит на практике.

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

Валидация до выполнения. Синтаксис, существование полей и таблиц, антипаттерны производительности проверяются заранее. Битая ссылка на поле, несуществующая виртуальная таблица, кривая схема СКД отсекаются до консоли и до прода, а не на живых данных.

Обратная связь по ошибке. Когда база отвечает «поле не найдено», этот реальный текст вместе с реальным списком доступных полей возвращается модели. Готовое она правит заметно лучше, чем сочиняет с нуля: получив настоящую структуру, ассистент чинит собственный запрос за одну-две итерации. Ошибка перестаёт быть тупиком и становится подсказкой.

Только чтение на проде, fail-closed. Даже если модель придумает операцию записи, на боевой базе она не выполнится: доступ закрыт на шлюзе, а не в тексте промпта.

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

Роли. Модель видит лишь то, что положено роли, и поверхность и для ошибки, и для утечки сразу сужается.

Отсюда понятно, чем плохи полумеры. Сырые MCP-серверы без governance-слоя и решения с execute_code за грубым списком разрешений расширяют доступ, но никак не заземляют модель: галлюцинация просто выполняется с полными правами. Наборы из нескольких Docker-контейнеров с правилами на стороне клиента не дают границы, потому что правило на клиенте это не защита базы. А выгрузка схемы в браузерный чат и утекает, и корень не лечит.

Где здесь Feenlace MCP-1C

Feenlace MCP-1C это управляемый MCP-шлюз для 1С:Предприятия. Он ставится в вашем контуре одним самодостаточным бинарником рядом с базой (как устроена локальная граница, подробно в разборе про локальный контур для 1С) и работает как слой политик доступа между ИИ-ассистентом (Claude, ChatGPT и другими) и инфобазами.

Вместо угадывания шлюз отдаёт ассистенту реальную структуру базы: дерево метаданных, состав объектов, граф зависимостей. Модель читает схему, а не сочиняет её, а генератор и оптимизатор запросов ловят антипаттерны ещё до исполнения. На проде включается жёсткий read-only с fail-closed, поэтому выдуманная операция записи блокируется на самом шлюзе. Каждое обращение ИИ пишется в журнал, доступ раздаётся по ролевым профилям, запросы к разным базам маршрутизируются с отдельными квотами. Для разработки в комплекте статический анализ BSL (с оценкой уязвимостей по CVSS 3.1 и выгрузкой отчётов SARIF), сравнение конфигураций и расширений (CF и EDT) и генерация тестов YAxUnit и Vanessa.

Честно про границы: заземление не делает модель непогрешимой. Галлюцинации это свойство самой генерации, полностью убрать их нельзя. Но заземление на живые метаданные резко снижает долю выдуманных полей и GUID, а read-only, аудит и роли добивают остальное: оставшаяся ошибка не превращается ни в порчу боевых данных, ни в утечку.

Открытая редакция бесплатна и с открытым кодом: на ней удобно поднять сервер рядом с тестовой базой, включить чтение метаданных и увидеть, как ассистент перестаёт выдумывать поля и GUID на вашей конфигурации. Полный контур управления доступом (ролевые профили, аудит обращений, жёсткий read-only на проде, квоты по базам) работает в Корпоративной редакции, между ними есть Расширенная и Профессиональная для задач разработки. Продукт и редакции на feenlace.ru.