Как дать нейросети структуру вашей 1С, чтобы она перестала выдумывать реквизиты

Если вы просили ChatGPT или другую модель написать запрос по вашей базе, вы это видели: код выглядит уверенно, а реквизита Контрагент.ОсновнойМенеджер в вашей конфигурации нет, есть ОтветственныйМенеджер. Модель знает “1С вообще”, усреднённую по тысячам конфигураций, но не знает именно вашу. И вместо честного “в вашей базе не уверена” выдаёт правдоподобное имя.

Лечится это не сменой модели. Достаточно дать ей структуру вашей конфигурации прямо в запросе. Ниже разбираем, как эту структуру выгрузить в вид, который модель понимает и в который она влезает, потому что “выгрузить всё” не работает, и объясним почему на цифрах с боевой базы.

Короткая версия про то, откуда берутся выдуманные реквизиты, у нас есть на Инфостарте.

Почему модель ошибается именно в вашей базе

Языковая модель обучалась на публичном коде: типовые конфигурации, статьи, форумы. Оттуда она знает общие имена и паттерны. Но ваша база это типовая плюс годы доработок: свои реквизиты, свои регистры, переименованные реквизиты типовых объектов. Ничего из этого в обучении модели не было.

Поэтому на вопрос “напиши запрос по остаткам с разбивкой по вашему аналитическому разрезу” модель делает единственное, что умеет без данных: берёт наиболее вероятное имя из своего опыта. В типовой это имя есть, у вас его переименовали, и запрос падает или, хуже, молча возвращает не то. Без проверки по структуре конкретной базы такой ответ остаётся предположением. Запрос с правдоподобными именами нужно сверять и проверять на тестовых данных.

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

”Тогда выгрузим всё” и почему это не влезает

Сначала измерьте полную выгрузку и сравните её с доступным контекстом выбранной модели. Вот результат нашего замера.

Полная выгрузка структуры боевой УПП, которую мы гоняли, это 918 объектов конфигурации, около 790 000 токенов. Это размер конкретного замера, а не предел возможностей любой модели. Доступное окно и стоимость зависят от выбранного сервиса; перед отправкой сверяйте его условия и размер своего среза.

Ключевая цифра ради контраста: если взять только структуру вокруг одного документа с его реквизитами, движениями и ближайшими связями, получается около 31 130 токенов. Это сжатие примерно в 25 раз. Модель получает ровно то, что нужно для задачи по этому документу, и ничего лишнего.

Значит задача не “выгрузить структуру”, а “выгрузить релевантный срез структуры под конкретную задачу”. А для этого надо понимать, что включать, а что выбрасывать.

Что включать

Минимум, без которого модель бесполезна:

• имена объектов и их синонимы (справочники, документы, регистры), причём техническое имя, а не представление, потому что запрос пишется по техническому;
• реквизиты объекта с типами, чтобы модель не путала строку с ссылкой и не сравнивала несравнимое;
• табличные части с их реквизитами: половина ошибок модели в том, что она кладёт реквизит шапки в табличную часть и наоборот;
• для документов движения по регистрам: какой документ какой регистр двигает, иначе модель не построит корректный запрос к остаткам или оборотам;
• ведущие измерения и владельцев для справочников, чтобы понимать иерархию и подчинение.

Что выбрасывать в первую очередь

Полнота здесь враг. Выбрасываем то, что раздувает выгрузку и не помогает писать запрос:

• стандартные реквизиты, которые есть у всех объектов (Код, Наименование, Ссылка, ПометкаУдаления): модель их и так знает, они одинаковы везде;
• служебные и неиспользуемые объекты: если реквизит в конфигурации есть, но нигде не заполняется, он только шумит;
• формы, макеты, командный интерфейс: к структуре данных отношения не имеют, зато весят прилично;
• длинные описания и комментарии из конфигуратора: модели нужен скелет, а не документация.

Практический критерий: если удаление поля из выгрузки не мешает написать корректный запрос, поле лишнее.

Граф связей полезен ровно настолько, насколько он разрежен

Это главный вывод, который экономит больше всего места и который неочевиден. Модели сильно помогает граф связей: этот документ ссылается на этот справочник, этот регистр двигается этими документами. По графу модель строит корректные соединения в запросе.

Но есть ловушка. В типовых конфигурациях, особенно на БСП, встречаются реквизиты составного типа “любая ссылка”. Один такой реквизит ссылается сразу на всё: в нашем замере один реквизит тянул за собой 449 типов. Если тащить эти связи в граф как есть, граф вырождается в шум: всё связано со всем, полезной информации ноль, а токены съедены.

Поэтому реквизиты-”приёмники всего” из графа связей надо исключать или сворачивать в одну пометку “составной тип, много вариантов”. Граф связей ценен, только пока он разрежен и показывает реальные, а не формально возможные связи.

В каком виде отдавать: Markdown или JSON

Оба формата модель понимает, выбор зависит от задачи:

• Markdown компактнее и читается человеком, удобно, когда вы сами смотрите выгрузку перед вставкой в чат;
• JSON строже и удобнее, если выгрузку потом обрабатывает код (например, ваш собственный конвейер с моделью через API).

Важнее формата другое: структура должна быть плоской и предсказуемой. Модель лучше держит внимание на ровной таблице “объект, реквизит, тип”, чем на глубоко вложенном дереве.

Как это выглядит на практике

Ручная выгрузка структуры под каждую задачу это отдельная работа: обойти метаданные, отфильтровать стандартные реквизиты, собрать граф связей, свернуть “любые ссылки”, уложиться в бюджет токенов. На боевой УПП полный обход это 2 666 объектов и десятки тысяч реквизитов, руками это не собрать.

Чтобы не делать это каждый раз, мы собрали обработку “Выгрузка структуры метаданных 1С для нейросети”. Она обходит метаданные, собирает компактное дерево в Markdown или JSON, умеет фокус на одном объекте с подграфом связей на несколько шагов и режет стандартные реквизиты и “любые ссылки”. Универсальна по построению: работает с системной коллекцией Метаданные, без привязки к прикладным объектам конкретной конфигурации, поэтому запускается на любой базе.

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

Почему модель вообще выдумывает вместо признания незнания, видно, если разобрать её изнутри. Мы посчитали настоящий трансформер на встроенном языке 1С и выложили с открытым кодом: локальная LLM на BSL на каждом символе показывает вероятности по всему алфавиту сразу. Ответа “не знаю” в этом распределении нет по устройству: есть только более и менее вероятные продолжения, и одно из них модель обязана выбрать. Обработка учебная, прикладной пользы не несёт, но объясняет ограничение нагляднее любого текста. А на каком шаге обучения модель начинает уверенно собирать несуществующие методы, видно по двенадцати стадиям обучения одной модели: вопрос один, снимки весов разные.

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

Если баз несколько, ту же структуру приходится держать не файлом на диске, а записями в служебной базе, иначе она устаревает быстрее, чем вы её выгружаете. Мы такой реестр ведём как услугу: технологический реестр 1С хранит метаданные, код и интеграции всего парка баз и обновляет их каждую ночь, поэтому срез под модель всегда снимается с актуального состояния. Схема с ночной выгрузкой по хэшу и реестром описана в статье “MCP для 1С: один сервер на десять баз”.

Как проверить выгрузку до передачи модели

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

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

После получения запроса выполните его на тестовой копии с известным результатом. Проверьте не только отсутствие ошибки, но и состав строк, отборы и итоги. Выгрузка структуры помогает писать код, но сама не выполняет его проверку.

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