Почему нейросеть выдумывает реквизиты вашей конфигурации — и что показать ей, чтобы перестала
Просишь модель написать запрос по своей базе — получаешь уверенный ответ с регистром, которого нет, реквизитом, которого нет, и обращением к виртуальной таблице, которой у этого регистра не бывает в принципе. Причём ошибка не выглядит ошибкой: код красивый, имена правдоподобные, комментарии на месте. Разберём, почему так выходит, какие три ловушки не лечатся «просто дать модели список объектов», и сколько на самом деле весит конфигурация, если попробовать показать её целиком.
Модель знает «1С вообще», а не вашу базу
Обучающие данные — это документация, статьи, куски типовых. Оттуда модель усваивает, что в конфигурациях бывает Справочник.Контрагенты, Документ.РеализацияТоваровУслуг и РегистрНакопления.ТоварыНаСкладах. Дальше на любой вопрос она собирает правдоподобное среднее по всем виденным конфигурациям.
Иногда попадает. В «Рознице» документ называется РеализацияТоваров, без «Услуг» — и модель, обученная в основном на УТ и ERP, промахивается на ровном месте. А доработанная конфигурация с полусотней собственных объектов не совпадает с усреднённой картиной вообще нигде.
Вывод простой: структуру надо показывать. Дальше начинается интересное — что именно показывать.
Три ловушки, которые не лечатся списком объектов
Допустим, вы выгрузили модели все имена объектов и реквизитов. Она правильно назвала регистр, правильно назвала измерения — и запрос всё равно не собрался. Потому что метаданные описывают структуру хранения, а язык запросов работает с другими таблицами и другими именами полей. Этого знания в метаданных нет.
Ловушка первая: виртуальной таблицы может не быть
У регистра накопления вид бывает «Остатки» или «Обороты». Это не оттенок смысла, а разный набор доступных таблиц:
// регистр с видом «Остатки» — есть всё три РегистрНакопления.ТоварыНаСкладах.Остатки РегистрНакопления.ТоварыНаСкладах.Обороты РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты // регистр с видом «Обороты» — только обороты РегистрНакопления.Продажи.Обороты РегистрНакопления.Продажи.Остатки // ← такой таблицы НЕ существует
Последняя строка — самая частая поломка из всех. Запрос падает на компиляции с «Таблица не найдена», а модель до этого искренне считала, что остатки продаж — нормальная вещь. Вид регистра лежит в метаданных, но чтобы им воспользоваться, надо знать правило вывода. Модель его не знает, если ей не сказать.
Ловушка вторая: в виртуальной таблице ресурсы называются иначе
Вот эта ломает даже опытных, потому что выглядит как опечатка платформы. Ресурс регистра называется Количество. В таблице движений он Количество. А в виртуальных таблицах — нет:
// в .Обороты → <Ресурс>Оборот КоличествоОборот, СтоимостьОборот, НДСОборот // в .Остатки → <Ресурс>Остаток КоличествоОстаток, СуммаОстаток // в .ОстаткиИОбороты → четыре поля на каждый ресурс КоличествоНачальныйОстаток, КоличествоПриход, КоличествоРасход, КоличествоКонечныйОстаток
То есть выгрузка, честно написавшая «Ресурсы: Количество, Стоимость», модель дезинформирует: этих полей в той таблице, которую она собирается использовать, нет. Преобразование механическое и абсолютно детерминированное — тем обиднее на нём терять запрос.
Ловушка третья: через составной тип нельзя поставить точку
Классический вопрос «продажи по контрагентам». Открываем РегистрНакопления.Продажи и видим, что измерения Контрагент там нет вовсе. Есть такое:
ДокументПродажи: Документ.РеализацияТоваров | Документ.ЧекККМ | Документ.ОтчетОРозничныхПродажах
Составной тип. Модель, не задумываясь, пишет ДокументПродажи.Контрагент — и получает ошибку, потому что через составной тип разыменование запрещено. Правильно так:
ВЫБРАТЬ
ВЫРАЗИТЬ(Продажи.ДокументПродажи КАК Документ.РеализацияТоваров).Контрагент КАК Контрагент,
СУММА(Продажи.СтоимостьОборот) КАК Выручка
ИЗ
РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, , ) КАК Продажи
СГРУППИРОВАТЬ ПО
ВЫРАЗИТЬ(Продажи.ДокументПродажи КАК Документ.РеализацияТоваров).Контрагент
Обратите внимание: в этом коротком запросе сработали все три ловушки сразу. .Обороты, потому что регистр оборотный. СтоимостьОборот, а не Стоимость. И ВЫРАЗИТЬ вместо точки. Промахнись в любой из трёх — запрос не соберётся.
«Тогда выгрузим всё» — арифметика, которая это ломает
Идея напрашивается: выгрузить модели вообще всю конфигурацию и не думать. Считаем.
Типовая «Розница для Казахстана» 2.2 — 918 объектов метаданных. Если выгрузить их полностью, со всеми реквизитами, типами и табличными частями, получается около 2 миллионов символов. Для русского текста с длинными идентификаторами вроде РегистрСведений.БезопасноеХранилищеДанныхОбластейДанных это примерно 790 000 токенов.
Для сравнения — на типовой УПП обход даёт 2 666 объектов и 45 509 реквизитов, то есть раза в три больше.
Окно контекста у сегодняшних моделей — сотни тысяч токенов в лучшем случае, а реально работающий контекст, где модель ещё держит детали в голове, куда меньше. Плюс вы платите за каждый токен на каждом сообщении диалога. Полная выгрузка не помещается и не должна помещаться.
Значит задача не «выгрузить метаданные» — это тривиально. Задача — отобрать.
Что выбрасывать в первую очередь
Здесь легко ошибиться направлением. Первое, что приходит в голову, — понижать детальность по всей конфигурации: убрать синонимы, убрать квалификаторы типов, свернуть табличные части. Я это сделал и потом выбросил, потому что цифры оказались против.
Во-первых, потолок такого сжатия — примерно 2,2 раза. Из 790 тысяч токенов получается 350 тысяч, что всё равно не влезает. Во-вторых, что важнее, выбрасывается не то. Синоним — это мост между вопросом человека («продажи по контрагентам») и именем объекта в конфигураторе. Убрав синонимы, вы получаете справочник для того, кто и так знает все имена наизусть.
Работающий рычаг ровно один: сокращать не детальность, а число объектов. Человека почти никогда не интересует вся база — его интересует один документ и его окружение. Выгружаем подробно объект и всё, с чем он связан напрямую, а остальное сворачиваем в список имён.
Список имён, кстати, выбрасывать нельзя. Модель должна знать, что эти объекты существуют, иначе на вопрос «а есть ли у меня справочник Х» она уверенно ответит «нет».
Замер на той же «Рознице»:
- без отбора — 790 000 токенов;
- пропустить объекты, в которых нет ни одной записи, — 117 085 токенов (подробно 569 объектов из 918: в типовой конфигурации живёт заметно меньше половины);
- фокус на одном документе — 31 130 токенов, подробно 21 объект из 918.
Двадцать пять раз. Вот теперь это файл, который вставляется в чат вместе с вопросом.
Отдельно про «объекты без данных»
Приём дешёвый и недооценённый. В любой типовой половина объектов метаданных существует «на всякий случай»: механизмы, которые вы не используете, обмены, которые не настроены, регистры под функциональность, которую не включали. Для вопроса про вашу базу они шум.
Проверять наличие данных нужно правильно. Не КОЛИЧЕСТВО(*) — на многомиллионной таблице это полноценное сканирование, а вам нужен только факт:
ВЫБРАТЬ ПЕРВЫЕ 1 1 КАК Признак ИЗ Справочник.Номенклатура КАК Т
Мелкая, но обидная деталь: не называйте псевдоним Есть. ЕСТЬ — ключевое слово языка запросов (ЕСТЬ NULL), и запрос падает с «Ожидается имя». Я поймал это уже на боевом прогоне: весь фильтр молча не работал, а в логе стояло «не удалось проверить — 487» при 487 проверяемых объектах.
Ещё одна ловушка: «любая ссылка» уничтожает граф связей
Если вы решите добавить в выгрузку связи между объектами — «на этот справочник ссылаются вот такие документы», — вас ждёт сюрприз. В каждой конфигурации на БСП есть реквизиты типа «любая ссылка»: РегистрСведений.ВерсииОбъектов.Объект, НаборыЗначенийДоступа.Объект, Справочник.Заметки.Предмет.
Такой реквизит ссылается сразу на всё. Замер: 449 ссылочных типов в одном реквизите при 918 объектах в конфигурации. Если строить по ним рёбра, граф вырождается — каждый объект оказывается связан с каждым. Обход «на один шаг от документа» возвращает половину базы, а список «на него ссылаются» у всех объектов превращается в одинаковый перечень инфраструктуры БСП. То есть в шум, который модель принимает за факт.
Лечится отсечением по доле: если тип накрывает заметную часть всех ссылочных объектов конфигурации, это не связь, а «любая ссылка» — показываем свёрнуто и рёбер по ней не строим.
Общий вывод, который я вынес из этой истории: граф связей полезен ровно настолько, насколько он разрежен. Ребро, которое есть у всех, не несёт информации. Кстати, по той же причине почти бесполезен и список «на что ссылается этот объект» — на замере вышло, что у 404 объектов из 413 он дословно повторяет типы реквизитов, напечатанные строкой выше. Четверть файла на пересказ самого себя.
Что в итоге должно быть в файле
Собираю в чек-лист — пригодится, даже если будете делать выгрузку сами:
- Технические имена типов, а не синонимы. Тут легко попасться:
Строка(Тип)для ссылочного типа возвращает синоним («Пользователи»), с которым запрос не написать. Техническое имяСправочник.Пользователидаёт толькоМетаданные.НайтиПоТипу(Т).ПолноеИмя(). - Готовые имена таблиц и полей запроса по каждому объекту — три ловушки из начала статьи закрываются здесь.
- Значения перечислений целиком. Стоят копейки, а выдумывает их модель постоянно.
- Предопределённые элементы. В метаданных их нет — коллекции
ЭлементыПредопределенныхДанныхне существует, доставать надо запросомГДЕ Предопределенный. - Движения документов и регистраторы регистра — единственное ребро графа, которое модель не выведет из типов реквизитов.
- Синонимы — только осмысленные. Из 3 257 синонимов реквизитов 2 691 оказался именем, разбитым на слова: «МаксимальныйПроцентОплаты» → «Максимальный процент оплаты». Это налог. А вот
ИНН→ «БИН / ИИН» стоит сохранить. - Честный список того, что не попало. Обрезанный файл выглядит для модели как полный, и она уверенно рассуждает о том, чего не видела.
Как этим пользоваться на практике
Файл сам по себе ничего не чинит — половина результата в том, что вы напишете рядом с ним.
Начинайте с фокуса, а не с полной выгрузки. Соблазн вывалить всё и «пусть модель сама разберётся» понятен, но контекст — ресурс: чем больше в нём постороннего, тем хуже модель удерживает нужное. Вопрос про реализацию — выгружайте реализацию.
Скажите модели, чем является этот файл. По умолчанию она считает, что 1С знает, и её воспоминания конфликтуют с вашей выгрузкой. Формулировка, которая конфликт снимает:
Ниже — структура моей конфигурации 1С, выгруженная из базы. Это единственный источник истины: имён, которых нет в файле, в моей базе не существует. Если для ответа не хватает объекта — скажи какого, я выгружу отдельно и пришлю. Задача: <ваш вопрос> <файл>
Здесь важны две вещи. «Единственный источник истины» — без этой фразы модель подмешивает к вашему файлу типовую УТ. Разрешение попросить недостающее — без него, упёршись в отсутствующий объект, модель его придумает, вместо того чтобы сказать, что его не хватает.
Если запрос всё равно не собрался — покажите модели раздел «Таблицы запроса» того объекта, на котором она споткнулась, и попросите переписать. В девяти случаях из десяти ошибка именно там: не та виртуальная таблица или не то имя ресурса.
А не проще дать модели прямой доступ к базе?
Вопрос резонный: MCP-серверы к 1С уже есть, и модель может выполнять запросы прямо в базе. Это другой инструмент для другой задачи, и выгрузку он не отменяет.
Прямой доступ отвечает на вопрос «какие сейчас данные». Выгрузка отвечает на вопрос «как устроена конфигурация» — и отвечает один раз, а не на каждый запрос модели. Плюс структуру можно показать модели, у которой доступа к вашему контуру нет и не будет: служба безопасности не пустит, а ответ нужен сегодня. И, наконец, файл со структурой прикладывается к задаче для подрядчика, а доступ к базе — нет.
Инструмент
Всё описанное собрано в готовую внешнюю обработку — «Выгрузка структуры метаданных 1С для нейросети (LLM)». Обходит Метаданные, отдаёт Markdown или JSON, умеет фокус на объекте и пропуск пустых, печатает раздел «Таблицы запроса» по каждому объекту. Работает в любой конфигурации на 8.3.14+, только читает, к СУБД не обращается. Замеры из этой статьи сделаны ею же.
Если делаете своё решение — забирайте грабли из статьи, они честно оплачены прогонами. Вопросы и возражения пишите в комментарии, отвечаю.
Про масштаб. Здесь реестр метаданных выгружается из одной базы. Когда баз десять и они в разных странах, обходить их по очереди уже не выйдет: как мы свели их под один вход и почему в самих базах кода почти нет - в статье Один MCP управляет десятью базами.
Другие наши инструменты для связки 1С и нейросетей:
- Анонимизатор выгрузки - обезличивает данные перед отправкой в чат-модель и расшифровывает ответ обратно.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
