Дообучение (Fine-Tuning) языковой модели GigaChat

Дообучение GigaChat: где базовая модель ломается на данных

Дообучение GigaChat нужно там, где базовая модель уверенно отвечает на общие вопросы и рассыпается на внутренних данных компании. Номенклатура, сокращения подразделений, названия тарифов и регламентов для неё — набор символов без устойчивых связей: похожие слова она видела в открытых текстах, но не видела, как они соотносятся между собой именно в вашем контуре.

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

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

Дообучение переносит знание в саму модель: она учится на ваших парах «вопрос — верный ответ», на номенклатуре, переписке поддержки и внутренних регламентах, а не на их описании. Разбираем, как это устроено и где проходит граница между тем, что закрывается дообучением, и тем, что честнее решать поиском по документам.

Что даёт адаптация модели под предметную область

Дообучение меняет не стиль ответов, а их распределение. На пилотной выборке из реальных обращений мы сравниваем две версии модели на одних и тех же вопросах: базовая GigaChat на узкой предметной области заметно «плывёт», дообученная — держит принятую в отрасли терминологию и структуру ответа.

Ключевая метрика адаптации — доля корректных ответов на отраслевых вопросах и её практическое следствие: доля ответов, принятых оператором без правок. Считаем её не средним баллом по всему набору, а срезом по категориям — нормативный вопрос, расчёт, справочный запрос, разбор ситуации: усреднение скрывает провалы в отдельных категориях, а именно они решают, войдёт ли инструмент в рабочий процесс.

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

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

Способы адаптации модели: сравнение подходов

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

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

Дообучение GigaChat: этапы инженерной работы

Дообучение GigaChat — это последовательность с контрольными точками, а не одиночный запуск обучения. Критерии приёмки фиксируем до первой правки данных: если метрику нельзя посчитать на отложенной выборке, этап не закрыт.

1. Разбор задачи и критериев приёмки — определяем, что модель должна делать иначе базовой: формат ответа, доменные термины, корректные отказы. Сразу выбираем метрики и порог, ниже которого результат не принимаем.
2. Аудит данных — смотрим логи обращений, регламенты, базу знаний. Оцениваем объём, дубли, персональные данные, расхождения в терминах; лишнее отсеиваем, остальное приводим к единому виду.
3. Разметка обучающего набора — готовим правила разметки и эталонные пары «запрос — ответ», размечаем пилотный блок и проверяем согласованность между разметчиками. Расходится — правим инструкцию, а не данные.
4. Обучение — подбираем режим и параметры по валидационной части и следим, чтобы модель не теряла общие навыки ради доменных. Контрольные точки сохраняем: нужен путь отката.
5. Проверка на отложенной выборке — считаем метрики из первого шага на примерах, не участвовавших в обучении, и сравниваем с базовой моделью.
6. Приёмка по метрикам качества — сводим результаты в отчёт: где прирост, где паритет, что уходит в продуктив.
7. Передача и обучение команды — отдаём конфигурации, инструкцию по разметке и порядок дообучения на новых данных.

Этапы внедрения модели идут в одном порядке — от критериев приёмки до передачи команде. Обновление на новых данных проходит тот же цикл, а качество сравнивается с уже принятой версией.

Артефакты передачи: веса, схемы, регламенты

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

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

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

Кейс: разбор обращений в поддержку после адаптации

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

Что было до

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

Что изменили

Собрали корпус закрытых обращений, свели темы к фиксированному списку и выборочно перепроверили разметку: спорные случаи разводили письменным правилом, а не решением отдельного оператора. На этом корпусе прошло дообучение модели на базе GigaChat — она определяет тему и предлагает черновик ответа, который оператор правит перед отправкой.

Что стало

Финальное слово осталось за человеком: на нетиповых темах модель помечает ответ как требующий проверки и сама его не отправляет. Метрики до и после внедрения считали на одном и том же списке категорий — иначе сравнение разъезжается из-за переразметки.

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

Что делать, если модель уже развёрнута в контуре компании

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

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

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

Дообучение GigaChat в таком сценарии — управляемая замена ядра: сервис продолжает отвечать, а качество растёт на тех же сценариях.

Технические сомнения: данные, объёмы, риски, сроки

Перед стартом дообучения GigaChat заказчики задают одни и те же вопросы — они касаются не модели, а управляемости процесса: объёма примеров, качества разметки, проверки результата, риска потерять общие знания и работы в закрытом контуре.

Что делать, если разметка слабая?

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

Как проверяется качество модели?

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

Не потеряет ли модель общие знания?

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

Можно ли работать в закрытом контуре?

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

Обсудим задачу: с чего начинается проект

Чтобы обсудить задачу дообучения предметно, готовый технический документ не нужен — достаточно описания процесса. Расскажите, какие обращения модель должна обрабатывать, на каких ошибается сейчас и что считается правильным ответом в спорных случаях.

• Где проходит граница: какие запросы модель закрывает сама, а какие обязана передать оператору.
• Какие данные уже есть — переписка поддержки, база знаний, регламенты, выгрузки — и в каком они виде.
• Что считается ошибкой: неточный ответ, выдуманная ссылка на документ, отказ отвечать, смена тона.
• Ограничения по отклику: сколько секунд допустимо ждать ответа и какой объём обращений нужно выдержать.
• Кто на вашей стороне принимает результат и по каким примерам будет проверять качество.
• Куда решение встраивается — сайт, чат поддержки, внутренняя система — и как получит доступ к данным.

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

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