Автор Habr под ником PloAl 5 ноября 2026 года опубликовал результаты проверки Qwen3.6-27B, дообученной на справочных материалах по 1С. В шести прогонах по 100 случайных записей из датасета примерно на 20 тысяч записей модель получила не менее 95% корректных ответов по методике автора — вместо прежней субъективной оценки «на глаз».
Это не релиз новой базовой модели Qwen и не независимый бенчмарк платформы 1С. Это отчёт о конкретном файнтюнинге Qwen3.6-27B и попытка аккуратно измерить, какие знания из справочника действительно попали в модель без подключения внешнего поиска.
Автор отделил знания модели от правильных ответов RAG
Главный вопрос эксперимента был практическим: может ли LoRA-адаптер удержать синтаксис и справочную информацию по 1С. LoRA — это способ дообучения, при котором базовые веса языковой модели не переписываются полностью: к ним добавляется относительно небольшой набор обучаемых параметров. Это дешевле полноценного обучения, но не гарантирует, что модель запомнит весь датасет.
В предварительном исследовании автор получил оценку: при хорошем результате обучения адаптер усваивает около 94% синтаксических конструкций. Из этого возникла обратная задача — не просто доказать, что модель иногда отвечает правильно, а найти оставшиеся пробелы и понять, каким сведениям нельзя доверять без проверки.
Первый подход с RAG оказался слишком удобным для модели и потому малоинформативным. Автор подключил справочные материалы через MCP-сервер к Roo Code и сравнивал четыре варианта: Qwen3.6, Qwen3.6 с LoRA для 1С, Qwen3.6 с RAG и комбинацию LoRA с RAG. Все агенты давали правильные ответы, потому что могли добирать знания из доступных источников.
Для чистой проверки файнтюнинга этого недостаточно. Если агент нашёл нужную статью в векторной базе или прочитал файл через инструмент, нельзя утверждать, что требуемый факт хранится в параметрах модели. Поэтому автор ограничивал права агентов, отклонял запросы на чтение файлов и доступ в интернет, а затем перенёс тест в формат прямых вопросов к модели.
Шесть прогонов по 100 вопросов стали вместо проверки «на глаз»
Новый тест построен на случайной выборке из примерно 20 тысяч записей датасета. В каждом прогоне автор выбирал 100 вопросов с фиксированным зерном генератора случайных чисел. Это позволяет воспроизвести набор вопросов при тех же настройках, а сами вопросы между прогонами не повторяются: пересечение контролируется программно и должно быть нулевым.
Всего автор провёл шесть прогонов, то есть проверил 600 вопросов. По его данным, каждый прогон показал не менее 95% корректных ответов. Но у этой цифры есть важная особенность: в неё вошли не только полностью идентичные эталону ответы, но и ответы с некритичными потерями.
Например, отсутствие примера кода или перефразированное описание автор не считал равным ошибке в сигнатуре метода либо неверному типу параметра. Такая логика понятна для задач, где разработчику важнее не получить невалидный вызов или ложное описание API. Но при чтении процента стоит помнить: это не строгая метрика «всё совпало с документацией».
| Элемент проверки | Как он устроен в тесте автора |
|---|---|
| Размер одного прогона | 100 случайно отобранных записей датасета |
| Общий объём проверок | 6 прогонов по 100 вопросов |
| Размер исходного набора | Около 20 тысяч записей |
| Повтор вопросов | Исключён между прогонами программной проверкой |
| Оценка ответов | Два LLM-судьи и детерминированная проверка критичных полей |
| Заявленный итог | Во всех прогонах не ниже 95% корректных ответов |
Ранние замеры автор отбросил. Сначала он брал первые 100 записей, затем — 100 записей, распределённых по справочным материалам, но получал заметно различающиеся цифры. Причинами он называет одного LLM-судью, отсутствие классификации потерь и калибровки. Это сильная часть работы: автор не выдаёт первые удачные или неудачные замеры за финальный результат.
Два судьи полезнее одного, но не превращают тест в абсолютную истину
Для итоговой оценки автор использовал двух LLM-судей. Первый — OpenJev 27B; его процентные оценки отдельно калибровались. Второй судья нужен как контроль: один генеративный оценщик может неверно интерпретировать вопрос, принять неполный ответ или, наоборот, наказать модель за допустимую формулировку.
Помимо LLM-оценки, автор добавил детерминированную проверку критичных полей. В публикации в качестве примера критической ошибки упоминается неправильный тип параметра. Это разумное разделение: языковой судья может оценивать смысловой ответ, а программа — точно проверять части, где недопустима вольная интерпретация.
| Ошибка в ответе | Как её трактует методика |
|---|---|
| Неверный тип параметра или существенная ошибка сигнатуры | Критичная ошибка, способная сломать код |
| Отсутствующий пример кода при верной сигнатуре | Некритичная потеря в оценке автора |
| Переформулированное описание при сохранении смысла | Некритичная потеря в оценке автора |
| Правильный ответ, найденный через RAG | Не доказывает, что знание усвоил файнтюнинг |
На практике такой подход полезен разработчикам 1С, которые хотят собрать локального помощника по документации, внутренним стандартам или библиотекам. Модель может быстро подсказать сигнатуру, назначение объекта или типичный сценарий использования, не поднимая векторную базу и MCP-сервер на каждый запрос.
Но для production-разработки это не отменяет обычную проверку по документации и запуск кода в среде 1С. Даже авторская методика прямо строится вокруг поиска пробелов в усвоении данных. Показатель в 95% означает, что ошибки всё ещё есть, а не что они стали несущественными для любой задачи.
Файнтюнинг в итоге оказался единым файлом, а не LoRA на инференсе
В публикации есть техническая деталь, которая легко теряется из-за названия модели. Изначально автор работал с LoRA-адаптером, однако итоговый тест выполнялся уже на модели с объединёнными весами. При мёрдже параметры адаптера добавляются к весам базовой модели, и серверу не требуется отдельно подгружать и применять LoRA.
Тестовая модель названа Qwen3.6-27B-Q8_LoRA1C. Слово LoRA в имени, по объяснению автора, осталось историческим: на этапе инференса отдельный адаптер уже не используется. Для разработчика это значит более простое развёртывание, но не меняет происхождение дополнительных знаний — они были получены именно через LoRA-дообучение до объединения весов.
Автор также пытался ускорить полный перебор датасета через vLLM и NVFP4-версию Qwen3.8 27B. На GPU с 32 ГБ памяти запуск завершился ошибкой нехватки памяти, а на второй GPU с 48 ГБ ускорения не получилось. Поэтому вместо полного прохода по всем записям был выбран статистический подход со случайными выборками.
В отчёте не приведены точные промпты, параметры генерации, значения оценок для каждого из шести прогонов и полный список критичных полей. Также нет сравнения с базовой Qwen3.6 на том же наборе вопросов. Без этих данных нельзя определить, сколько именно качества добавил файнтюнинг по отношению к исходной модели.
Похоже, наиболее ценный результат работы не сама цифра 95%, а схема проверки. Если вы обучаете модель на корпоративной базе знаний, документации или API, недостаточно показать несколько удачных демо. Нужны непересекающиеся случайные выборки, воспроизводимый отбор, отдельный учёт критичных ошибок и хотя бы попытка проверить, не ошибается ли сам автоматический судья.