Fine-Tuning GPT-4 и GPT-4o: кастомизация LLM под бизнес-задачи

Fine-tuning GPT-4: почему базовая модель не решает задачу

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

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

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

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

Разбираем, какие задачи действительно требуют дообучения, где хватает настройки подсказок и как измерять эффект до вывода модели к пользователям.

Что даёт fine-tuning: точность и управляемость

Дообучение на размеченном наборе меняет поведение модели там, где инструкции в запросе уже не помогают. Эффект видно на отложенной части данных, которую модель не видела при обучении: доля верных ответов растёт с 70–75% до 90–95%, а разброс между запусками сокращается до единиц процентов. Fine-tuning GPT-4 на стороне OpenAI даёт точность на вашей предметной области, а не на усреднённом наборе из открытых источников.

Терминология — первое, что ломает базовая модель: внутренние названия продуктов, кодовые обозначения услуг, сокращения подразделений она пересказывает по-своему. Разметка на 300–1000 реальных диалогов это закрывает — модель воспроизводит вашу лексику и одинаково отвечает на перефразировки одного вопроса: расхождение между пятью формулировками падает с 20–30% до 5%.

Единый формат вывода — отдельный измеримый эффект. Жёсткая схема ответа (поля, их порядок, значения из справочников, отсутствие вступлений) снимает слой постобработки: ответы разбираются кодом напрямую, а доля обращений, которые сотрудник проверяет вручную, падает с 30–40% до 5–10%.

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

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

Режим адаптации выбирают по трём вводным: сколько размеченных примеров есть сейчас, насколько узкая предметная область и как часто будет меняться задача. Это не взаимоисключающие опции, а разные по ресурсам и риску способы дообучить GPT-4 — от правки поведения до перестройки самой модели.

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

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

Этапы внедрения: от аудита данных до передачи

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

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

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

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

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

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

Кейс: автоматическая классификация обращений

Точка старта

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

Что изменили и что стало

Мы разметили архив обращений по фактическим маршрутам, отбросили спорные и повторные и оставили многоклассовую схему с отдельным классом «требует человека». Дообучили GPT-4o на этом корпусе и добавили порог уверенности: ниже порога классификация отдаёт обращение оператору вместе с подсказкой модели, а не в случайный отдел. Качество проверяли на отложенной части архива, которую модель не видела при обучении, — чтобы метрики считались по незнакомым текстам, а не по заученным.

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

Чем дообучение отличается от подсказок в промпте?

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

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

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

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

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

Технические сомнения перед стартом работ

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

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

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

Модель не потеряет общие навыки?

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

Как часто нужно повторное обучение?

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

Обсудим задачу: что нужно с вашей стороны

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

• Постановку задачи — какой процесс автоматизируем, кто им пользуется и как выглядит успешный ответ.
• Примеры «вход → правильный ответ»: даже 50–100 размеченных случаев показывают, нужна ли дообучение GPT-4 на ваших данных или достаточно точной настройки инструкций.
• Критерии приёмки — доля верных ответов на отложенной выборке, допустимая задержка ответа, формат вывода.
• Ограничения по данным: что можно выносить за периметр, что остаётся на вашей стороне, какие требования безопасности действуют.
• Текущие наработки — промпты, ранее дообученные модели, логи обращений: часто часть работы уже сделана.
• Контакт инженера с вашей стороны для уточнений по разметке и спорным примерам.

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

Опишите задачу в удобном виде — вернёмся с оценкой и планом работ.