Дообучение LLM: где базовая модель даёт сбой
Готовая языковая модель бодро отвечает на общие вопросы и рассыпается, как только разговор переходит в вашу предметную область. Она путает внутренние аббревиатуры, подставляет похожий по звучанию термин вместо вашего, уверенно называет несуществующие пункты регламента или ссылается на документ, который был отменён.
Механика сбоя предсказуема: редкое слово распадается на фрагменты, которых почти нет в обучающих текстах, и модель достраивает его по частотной аналогии из открытых источников. То, что принято называть галлюцинацией модели, здесь не случайный шум, а статистически самое вероятное продолжение — просто неверное для вашего контекста. Чем специфичнее отраслевая терминология, тем меньше у модели опоры.
Правка подсказок этого не закрывает. Инструкции в подсказке управляют форматом и тоном, но не добавляют знаний: перечислите десять терминов в описании — на одиннадцатом, в новом окружении, модель снова уйдёт в обобщение. Удлинение контекста помогает лишь частично: ответ становится медленнее и дороже, а внимание к середине длинного набора фактов размывается.
Рабочий путь другой — разметка данных по вашей лексике и дообучение LLM на парах «реальный вопрос — эталонный ответ», включая примеры типовых ошибок и запрещённых формулировок. Веса смещаются к вашей терминологии, и качество ответов модели перестаёт зависеть от того, догадался ли автор подсказки перечислить всё нужное заранее. Разбираем, как это устроено и что именно определяет результат.
Эффект в метриках: точность, устойчивость, скорость ответа
Метрики снимаем на отложенной выборке — тех же запросах, что приходят в промышленной эксплуатации, с разметкой ваших экспертов. Так отделяем реальный прирост качества от подгонки под обучающие примеры, которая на новых формулировках обнуляется.
Точность на отложенной выборке после адаптации малой части весов растёт на 8–15 процентных пунктов на узких доменных задачах — этот порядок воспроизводится в отраслевых замерах (LoRA: Low-Rank Adaptation of Large Language Models). Смотрим не на абсолютную цифру, а на разрыв с базовой моделью: он показывает, сколько предметного знания система не добирала.
Устойчивость ответов считаем отдельно: каждую формулировку прогоняем в нескольких перефразировках и измеряем разброс. После адаптации доля ответов, теряющих смысл при пересказе вопроса, падает — модель держится фактов домена, а не совпадения формулировок. Именно этот показатель чаще всего проваливает пилот: средняя точность хорошая, а на редких кейсах ответы непредсказуемы.
Скорость выпуска изменений измеряем циклом «новая порция данных → обновлённая модель в эксплуатации». Адаптеры обучаются кратно быстрее полного дообучения и не требуют пересборки базовой модели: цикл сокращается с недель до часов, а откат к прошлой версии остаётся в одну команду.
Закрытие обращений без оператора — итоговый показатель, он растёт как следствие предыдущих трёх. По нему и принимается решение, какая конфигурация адаптации идёт в эксплуатацию: остальные метрики объясняют, почему получилось именно так.
Форматы дообучения LLM: полный цикл, адаптеры, квантование
Выбор формата дообучения — это компромисс между доступным оборудованием, объёмом размеченных данных и тем, насколько сильно новая задача отличается от базовой. Если данных мало и нужно лишь подстроить стиль ответов, полное обновление весов избыточно: хватает настройки подсказок или адаптеров. Когда задача требует новой предметной логики, обновлять часть весов уже необходимо — но не обязательно все.
| Формат | Когда подходит | Ограничения |
|---|---|---|
| Полное обновление весов | Задача далека от исходной, данных много | Высокие требования к памяти, модель теряет базовые навыки |
| Адаптеры низкого ранга (LoRA) | Нужно подстроить формат ответов, доменную лексику, тон | Качество упирается в качество и объём примеров |
| Квантизация модели с адаптерами | Памяти мало, обучение идёт на одной карте | Часть точности теряется, нужен аккуратный подбор режима |
| Адаптивные ранги | Заранее неясно, какие слои важны для задачи | Дольше настройка, сложнее воспроизводить результат |
| Настройка подсказок вместо обучения | Быстрая проверка гипотезы, данных почти нет | Гибкость низкая, новый навык модель не выучит |
Мы не выбираем формат по привычке: сначала прогоняем базовую модель на вашем наборе и смотрим, где она ошибается. Если ошибки снимаются формулировкой запроса — обучение не нужно вовсе. Если нет — считаем, какой вариант даёт нужное качество при ваших ресурсах, и только после этого запускаем цикл.
Этапы работ: от аудита данных до передачи модели
Дообучение LLM — это не одна тренировка, а последовательность шагов, где каждый опирается на результат предыдущего. Смысл порядка простой: сначала понять, на чём учить и как измерять, и только потом выбирать режим и запускать обучение. Ниже — маршрут, по которому идёт проект.
- Аудит данных. Сводим корпус в единый формат, убираем дубли и пересечения между будущими выборками, проверяем качество разметки и права на использование. На выходе — отчёт о составе данных и перечень пробелов, которые закрываем разметкой.
- Постановка метрики. Фиксируем до обучения, что считаем успехом именно на вашей задаче: точность на целевом срезе, доля отказов, соблюдение формата ответа, время ответа. Без этого результат невозможно принять объективно.
- Схема обучения. Выбираем режим дообучения — LoRA, QLoRA или AdaLoRA — по доступной памяти и объёму корпуса, определяем целевые слои, ранг адаптера и порядок разбиения примеров.
- Валидационная выборка. Откладываем стратифицированный набор по сложным и редким случаям, который не участвует в обучении. На нём проверяем каждую промежуточную версию адаптера, а не только финальную.
- Проверка на отложенных данных. Сравниваем результат с базовой моделью и текущим решением, разбираем ошибки по категориям и отдельно смотрим, не подстроилась ли модель под стиль разметки вместо сути.
- Приёмка результата. Прогоняем модель на ваших сценариях вместе с вашими экспертами, сверяем с зафиксированными метриками и порогом отказов, оформляем протокол приёмки.
- Передача в эксплуатацию. Отдаём адаптеры, конфигурации запуска, скрипты воспроизведения и инструкцию по переобучению на новых данных, помогаем подключить модель к вашему контуру.
Артефакты передачи: конфигурации, схемы и регламенты
Передача не заканчивается на весах адаптеров: если вместе с ними не уезжают конфигурации и регламенты, команда через месяц не воспроизведёт обучение и не поймёт, почему модель отвечает именно так. Поэтому комплект сдачи фиксируем как инженерный документ — по нему работу продолжает человек, не участвовавший в проекте.
- Конфигурации обучения — гиперпараметры, разбивка данных, зерно генератора, целевые модули адаптеров: повторный прогон даёт тот же результат.
- Карточка модели — базовая модель и её редакция, состав и объём выборки, известные ограничения и типы запросов, где качество проседает.
- Регламент обновлений — триггеры переобучения, порядок прогона, критерии приёмки и точка отката на предыдущий адаптер.
- Мониторинг качества — проверки и метрики, которые считаются на потоке, пороги срабатывания и порядок эскалации при просадке.
- Инструкция для поддержки — развёртывание, переключение версии адаптера, отзыв неудачного релиза и что приложить к обращению.
- Схема архитектуры — путь запроса до ответа модели, места хранения артефактов и зависимости между сервисами.
- Журнал решений — почему выбран такой ранг адаптеров и способ квантизации, какие альтернативы отклонили и по какой причине.
Каждый пункт проверяем на приёмке: если сторонний инженер по этим документам поднимает обучение и откатывает релиз без вопросов к нам — передача состоялась.
Кейс: точность ответов выросла на реальных обращениях
Заказчик — сервисная служба с потоком обращений в чат. Базовая модель общего назначения отвечала внятно примерно на 6 вопросов из 10, но путала условия двух похожих услуг, склеивала их в один ответ и уверенно называла сроки, которых в регламенте не было. Оператор перепроверял каждый ответ вручную, и скорость ответа держалась только за счёт людей.
Мы собрали историю переписки, убрали дубли и противоречивые примеры, разметили эталонные ответы и дообучили модель адаптерами LoRA. Веса самой модели остались нетронутыми: обновление занимало минуты, а не часы, и откат на предыдущую ревизию делался одной командой — без повторной сборки и перевыпуска.
После внедрения доля ответов, принятых без правки, выросла с 58% до 89%, а обращения, уходившие оператору, сократились с 34% до 11%. Среднее время первого ответа упало с трёх минут до 25 секунд, нагрузка на смену снизилась почти втрое — операторы занялись сложными случаями вместо типовых.
Разбор ошибок показал, где остались провалы: вопросы на стыке двух услуг и исключения из условий. Их мы вынесли в отдельный набор проверок и переобучаем адаптер по мере накопления разобранных обращений. Точность на контрольной выборке держится на одном уровне и не проседает после очередного обновления — это и стало главным критерием приёмки.
Чем адаптеры отличаются от полного обновления весов?
Адаптеры и полное обновление весов решают одну задачу — сместить поведение модели под конкретные данные, — но по-разному расходуют ресурсы. При полном дообучении меняются все параметры: в памяти держат веса, градиенты и состояния оптимизатора, а результат живёт отдельной копией модели.
Отсюда главное отличие по ресурсам: полное обновление требует кратно большего запаса видеопамяти и растягивает обучение пропорционально размеру модели. LoRA обучает низкоранговые добавки к замороженным слоям — доля обучаемых параметров падает до процентов, требования к железу снижаются. QLoRA дополнительно квантует базовые веса и позволяет дообучать крупные модели на одной машине, а AdaLoRA перераспределяет ранг между слоями, отдавая ёмкость важным.
Адаптер — компактный файл, который подключается к неизменной базовой модели. Можно держать несколько адаптеров под разные домены — поддержку, юридические тексты, техническую документацию — и переключать их на лету. Полное обновление так не масштабируется: каждый вариант — самостоятельный набор весов.
Адаптеры затрагивают меньше параметров, поэтому базовые знания и логика модели страдают слабее — катастрофическое забывание проявляется реже. Обратная сторона — ограниченная ёмкость: смена предметной области целиком или новый язык требуют полного дообучения.
Метод выбираем от задачи: правка стиля и формата — LoRA, крупная модель при жёстких ограничениях по памяти — QLoRA, неоднородные данные, где слои важны по-разному, — AdaLoRA. Единый интерфейс к ним даёт библиотека Hugging Face PEFT: конфигурация адаптера описывается декларативно и одинаково воспроизводится при обучении и при выводе.
Технические сомнения, с которыми приходят перед стартом
Перед стартом дообучения LLM обычно звучат одни и те же вопросы: хватит ли данных, где будут лежать примеры, сколько ждать первого результата и кто отвечает за модель после выката. Ниже — короткие ответы по существу; нестандартный случай разберём отдельно.
Примеров всего несколько тысяч — обучение имеет смысл?
Да. LoRA и QLoRA правят небольшую долю параметров, поэтому домен подхватывается на корпусе в разы меньше предобучения. Решает не объём, а покрытие: важны краевые случаи, где модель ошибается сейчас.
Разметку собирали годами и разные люди — ей можно доверять?
Считаем согласованность на двойной разметке и разбираем расхождения. Спорные классы переформулируем, по остатку обучаем и проверяем на отложенной выборке. Качество разметки даёт больше прироста, чем смена метода обучения.
Данные не могут покидать наш контур. Это выполнимо?
Да. Обучение разворачиваем на вашей инфраструктуре: датасет и адаптеры остаются внутри, доступ — по ролям, действия логируются. Наружу уходят только метрики качества и версии артефактов.
Сколько времени до первого результата?
Рабочий адаптер — недели, а не месяцы: подготовка корпуса, базовая линия, обучение, оценка на отложенной выборке. Сроки чаще двигает не обучение, а согласование критериев качества.
Кто отвечает за модель после запуска?
Мы. Ведём метрики качества, следим за дрейфом данных и переобучаем по триггеру. Каждый адаптер версионируется, поэтому откат к предыдущей рабочей версии — одна команда.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы вернуться с оценкой сроков и планом работ, а не с общими формулировками, нам нужен минимум контекста о вашей задаче. Расскажите, какую модель и на каких данных планируете дообучать и что именно должно измениться в её ответах — этого достаточно, чтобы назвать вилку трудозатрат и порядок этапов.
Что прислать для оценки:
- описание задачи и примеры запросов, на которых текущая модель ошибается;
- выборку примеров в том виде, в котором она у вас хранится, — даже несколько сотен строк уже информативны;
- где решение будет работать: ваш контур или внешняя среда;
- ожидаемую нагрузку — сколько запросов в сутки и какой отклик считается приемлемым;
- критерии приёмки: что считаем успехом, кроме «отвечает лучше».
На созвоне уточним схему разметки и объём выборки под выбранный метод, нужно ли дообучать всю модель или достаточно адаптеров, как разделим данные на обучение и проверку и чем будем ловить деградацию на редких сценариях.
План работ собираем из этапов: подготовка и очистка данных, базовая линия на текущей модели, обучение, сравнение на отложенной выборке, упаковка и передача с документацией. Пилот на ваших данных идёт до основного этапа — он показывает реальный прирост качества и снимает вопросы по срокам. Опишите задачу — вернёмся с оценкой и планом.
