Даем глаза локальной модели Qwen 3.6 27B. Обучаем под домен разработки 1С

Где складируется модель

Готовая модель опубликована на Hugging Face под названием sweetand/qwen3.6-27b-1C. В репозитории размещены варианты модели для локального запуска GGUF-квантизации. Основное назначение модели — работа с bsl, xml структурой объектов конфигураций и разработке на платформе 1С.

Для чего это нужно

Основная цель - приватность разработки. Побочная - поиграться и посмотреть что из этого получится, способна ли маленькая локальная модель быть на уровне с фронтир моделями в разработке на 1С.

Как проходило обучение и составление датасетов

Самый простой вариант подготовки данных — собрать тысячи процедур и функций и показать их модели. Но такой датасет учит в основном продолжать код. Он почти не учит решать задачу целиком.

В реальной работе запрос разработчика выглядит иначе:

Задача: Настроить в отчете Анализ субконто по Виду Субконто Контрагенты возможность массового отбора контрагентов из файла эксель по ИНН, по коду контрагента в 1С.

Функционал: На вкладке Отбор и выбранного поля Контрагенты + вид сравнения = в списке:

1.  Сделать список выбора: подбор из файла, подбор по справочнику.
2. Для подбора из файла вызывать форму загрузки данных из файла xls. Загрузку из xls осуществить типовыми методами БСП.
3. Поиск контрагентов осуществлять по ИНН, по коду 1С.
4. Для подбора из справочника оставить стандартную реализацию.

Чтобы ответить, модель должна выполнить несколько действий:

1. Найти подходящие файлы.
2. Отсеять нерелевантные совпадения.
3. Прочитать модули и xml объекты.
4. Сопоставить обработчики, подписки и движения регистров.
5. Объяснить найденную причину.
6. Подготовить изменение.
7. Проверить, что исправление не затрагивает лишние объекты.

Поэтому значительная часть датасета была построена не как обычная пара «вопрос — ответ», а как последовательность действий с инструментами.

Устройство датасетов

Каждая запись хранится в формате диалога. В ней могут присутствовать следующие роли:

• system — правила работы модели;
• user — задача разработчика;
• assistant — объяснение следующего действия или вызов инструмента;
• tool — результат поиска, чтения файла, запуска команды или внесения изменений.

На скриншотах видны примеры таких цепочек. Сначала модель получает задачу, затем выполняет Glob для поиска файлов, использует Read для чтения содержимого, запускает проверки через Shell и при необходимости применяет изменение через ApplyPatch.

Например, учебный сценарий для CI/CD состоит примерно из такой последовательности:

1. Найти файлы pipeline и журнал ошибки.
2. Прочитать конфигурацию и нужный участок лога.
3. Воспроизвести ошибку проверочной командой.
4. Изменить только файлы, связанные с причиной.
5. Проверить артефакт и возможность отката.
6. Выполнить итоговый тест.
7. Сформировать отчёт с доказательствами.

Тот же подход применяется к задачам 1С.

Примеры построения трассы sft датасетов.

Датасет для понимания структуры проекта 1С

Один из основных наборов содержит 48 тысяч SFT-примеров по работе с проектами в формате BSL и XML. В записях используются длинные трассы, состоящие из нескольких последовательных действий.

В датасет вошли задачи нескольких типов:

Навигация по конфигурации

Модель учится находить объекты по структуре XML-выгрузки:

• модуль объекта справочника;
• модуль менеджера;
• форму документа;
• команду;
• общий модуль;
• подписку на событие;
• регламентное задание;
• веб-сервис;
• схему XDTO.

Анализ BSL-кода

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

• где формируются движения регистра;
• где заполняются реквизиты;
• какая процедура вызывается при записи;
• где выполняется сериализация XML или JSON;
• какой запрос формирует результат;
• какие модули участвуют в одном механизме.

Поиск примеров внутри проекта

Отдельный класс задач обучает сначала искать готовые реализации, а уже затем писать новый код.

Это важно для 1С. Внутри большой конфигурации обычно уже есть принятые шаблоны:

• оформление запросов;
• работа с временными таблицами;
• создание фоновых заданий;
• обмен данными;
• обработка ошибок;
• запись регистров;
• работа с расширениями.

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

Работа со справочными материалами

Помимо кода, в обучающую выборку включены записи по справочному описанию встроенного языка и объектов платформы.

На одном из скриншотов показан вопрос о практическом смысле свойства НаправлениеПорядкаСхемыЗапроса. Ответ объясняет назначение свойства нормальным языком и связывает его с сортировкой выражений языка запросов.

Такие примеры нужны, чтобы модель умела не только генерировать BSL, но и объяснять разработчику особенности платформы.

Датасет для имён в коде naming_1c

Имена процедур, функций и переменных должны отражать их назначение.

В отдельном наборе модель получает слишком общее или неточное имя и должна предложить более понятный вариант с учётом контекста.

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

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

Этот датасет полезен для:

• переименования процедур и функций;
• улучшения имён переменных;
• приведения к единому стилю;
• code review;
• устранения слишком общих названий.

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

Что приходится контролировать особенно внимательно

У длинных инструментальных диалогов есть несколько типичных проблем.

Пустой content у вызовов инструментов

На скриншотах некоторые сообщения assistant не содержат текста, но имеют заполненное поле tool_calls. Это допустимая структура, если используемый шаблон чата поддерживает отдельные вызовы инструментов.

Нельзя удалять такие сообщения только потому, что визуально поле содержимого пустое. Иначе результат инструмента потеряет связанный с ним вызов.

Соответствие вызова и ответа инструмента

После Glob должен идти результат Glob, после Read — результат Read. Ошибки в именах инструментов или нарушение последовательности превращают пример в противоречивый.

Реалистичность результатов

Результат инструмента должен содержать информацию, которую он действительно мог вернуть. Например, Glob может вернуть список файлов, но не содержимое процедуры. Read может показать участок файла, но не должен самовольно сообщать результат тестов.

Отсутствие лишних шагов

Длинная трасса не обязательно является хорошей. Если задача решается одним чтением файла, нет смысла искусственно добавлять десять вызовов.

Модель должна учиться делать столько действий, сколько требуется для получения надёжного ответа.

Разнообразие финальных ответов

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

• какие файлы были найдены;
• в чём состояла причина;
• что изменено;
• чем подтверждена корректность;
• какие ограничения остались.

Как проходило обучение

На одном из скриншотов показан фрагмент журнала начала эпохи. Значение loss колеблется примерно от 0,11 до 0,19, а grad_norm находится в районе 0,12–0,16.

Такое поведение выглядит стабильным:

• нет резких выбросов loss;
• норма градиента не растёт;
• не видно значений NaN;
• скорость обучения плавно уменьшается после разогрева.

На более позднем участке графика loss продолжает колебаться около 0,08–0,15. Само по себе низкое значение ещё не доказывает качество модели. Оно может означать как хорошее усвоение данных, так и наличие слишком похожих примеров.

Поэтому после обучения необходима отдельная проверка на задачах, которых не было в train-наборе.

Загрузка оборудования

Обучение выполнялось на NVIDIA GB10.

На скриншоте панели мониторинга видны следующие показатели:

• загрузка GPU — 96%;
• температура — 84 °C;
• используемая общая память CPU и GPU — около 97,5 ГБ;

Планы на развитие

SFT учит модель воспроизводить правильные примеры, но этого недостаточно для устойчивого поведения.

Следующие этапы развития:

Preference-обучение (DPO)

Для одной задачи создаются два ответа:

• хороший;
• ошибочный или менее предпочтительный.

Так модель учится выбирать:

• минимальное изменение вместо переписывания модуля;
• поиск примера в проекте вместо выдуманного API;
• проверку результата вместо неподтверждённого вывода;
• точный ответ вместо общего текста.

Заключение

Бенчмарков нет, т.к. нормальных под домен 1С в сети не нашел. Если у Вас есть хорошие бенчмарки - поделитесь.

Буду рад комментариям кто попробует модель и отпишется что модель делает хорошо, что плохо, чего не хватает, какие датасеты добавить в обучающую выборку.

ПЫСЫ

Статья написана с использованием нейрослопа.