Дообучение нейросети: когда оно нужно и как проверить результат

Желание «научить модель нашей компании» объединяет разные задачи. Одной нужен свежий справочник, другой — стабильный JSON, третьей — терминология или стиль. Только часть таких проблем требует изменения модели. Ошибка выбора превращает обновление знаний в дорогое переобучение.

LoRA — один конкретный способ адаптации с малым числом обучаемых параметров. Эта статья шире: как выбрать между промптом, примерами, RAG, LoRA и полным fine-tuning и как провести доказательный эксперимент.

Используйте официальную документацию выбранной модели по допустимым методам обучения, лицензии и формату датасета. Для LoRA первичный источник приведён в отдельной статье.

Классифицируйте проблему

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

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

До настройки сохраните матрица ошибок для объекта «факт, формат, стиль, язык или решение». Затем выполните «разметить типы неудач» и разберите случай «устаревшая цена является знанием, а не стилем». Этап «Классифицируйте проблему» принят, если владелец продукта подтверждает показатель «доля ошибок каждого типа», а риск «все ошибки называют нехваткой обучения» не проявляется на пограничной выборке.

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

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

Попробуйте дешёвую альтернативу

Этап «Попробуйте дешёвую альтернативу» рассматривает промпт, few-shot, RAG или правило. Дообучение оправдано только после базовой линии и ясного типа ошибки. Сбой возникает, когда обучение запускают до baseline; поэтому сначала готовят таблица baseline, а затем выполняют «сравнить методы на одном наборе».

• Рабочее действие: сравнить методы на одном наборе.
• Сохраняемый артефакт: таблица baseline.
• Контрольная ситуация: формат JSON исправляется схемой без весов.
• Показатель решения: выигрыш метода над базой.

Раздел «Попробуйте дешёвую альтернативу» проверяют обратным порядком: сначала фиксируют риск «обучение запускают до baseline», затем воспроизводят «формат JSON исправляется схемой без весов» и только после этого выполняют «сравнить методы на одном наборе». Вывод опирается на таблица baseline; метрику «выигрыш метода над базой» подписывает ML-инженер.

За этот участок отвечает ML-инженер. В журнале он связывает объект «промпт, few-shot, RAG или правило» с артефактом «таблица baseline», записывает версию входных данных, условия запуска и принятое решение. Если показатель «выигрыш метода над базой» улучшается ценой нового риска «обучение запускают до baseline», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «сравнить методы на одном наборе» должен воспроизводиться на примере «формат JSON исправляется схемой без весов».

Разберите пример отдельно: формат JSON исправляется схемой без весов. Полезно попросить второго специалиста повторить шаг «сравнить методы на одном наборе» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «промпт, few-shot, RAG или правило» владелец «ML-инженер» сверяет артефакт «таблица baseline» с метрикой «выигрыш метода над базой».

Определите критерий успеха

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

• Рабочее действие: связать обучение с пользовательским решением.
• Сохраняемый артефакт: карточка метрик.
• Контрольная ситуация: классификатор должен находить жалобы без роста ложных тревог.
• Показатель решения: precision и recall критичного класса.

Для объекта «метрика конечной задачи и защитный показатель» соберите обычный, крайний и ошибочный вход. Действие «связать обучение с пользовательским решением» должно дать проверяемый карточка метрик. В сценарии «классификатор должен находить жалобы без роста ложных тревог» роль аналитик принимает решение по значению «precision и recall критичного класса» и отдельно записывает, возник ли риск «loss принимают за бизнес-результат».

За этот участок отвечает аналитик. В журнале он связывает объект «метрика конечной задачи и защитный показатель» с артефактом «карточка метрик», записывает версию входных данных, условия запуска и принятое решение. Если показатель «precision и recall критичного класса» улучшается ценой нового риска «loss принимают за бизнес-результат», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «связать обучение с пользовательским решением» должен воспроизводиться на примере «классификатор должен находить жалобы без роста ложных тревог».

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

Подготовьте датасет

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

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

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

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

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

Разделите выборки

В задаче «Разделите выборки» ожидаемый объект — train, validation и test без утечки. Дообучение оправдано только после базовой линии и ясного типа ошибки. Команда отдельно записывает опасение «похожие документы попадают в разные части», выполняет «делить по источнику или времени» и оставляет манифест разбиения для повторной проверки.

• Рабочее действие: делить по источнику или времени.
• Сохраняемый артефакт: манифест разбиения.
• Контрольная ситуация: шаблоны одного клиента остаются в одной части.
• Показатель решения: разрыв train и test.

Не демонстрируйте раздел «Разделите выборки» на одном удобном примере. Возьмите «шаблоны одного клиента остаются в одной части», сохраните манифест разбиения и попросите роль специалист качества выполнить «делить по источнику или времени». Решение по объекту «train, validation и test без утечки» принимают по метрике «разрыв train и test», учитывая риск «похожие документы попадают в разные части».

За этот участок отвечает специалист качества. В журнале он связывает объект «train, validation и test без утечки» с артефактом «манифест разбиения», записывает версию входных данных, условия запуска и принятое решение. Если показатель «разрыв train и test» улучшается ценой нового риска «похожие документы попадают в разные части», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «делить по источнику или времени» должен воспроизводиться на примере «шаблоны одного клиента остаются в одной части».

Разберите пример отдельно: шаблоны одного клиента остаются в одной части. Полезно попросить второго специалиста повторить шаг «делить по источнику или времени» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «train, validation и test без утечки» владелец «специалист качества» сверяет артефакт «манифест разбиения» с метрикой «разрыв train и test».

Выберите глубину адаптации

Эксперимент «Выберите глубину адаптации» ограничьте контуром «полный fine-tuning, LoRA или иной PEFT». Главная ловушка: дорогой метод берут без сравнения. Действие «оценить ресурсы и требуемое изменение» допустимо после фиксации материала «протокол выбора». Дообучение оправдано только после базовой линии и ясного типа ошибки.

• Рабочее действие: оценить ресурсы и требуемое изменение.
• Сохраняемый артефакт: протокол выбора.
• Контрольная ситуация: LoRA достаточно для формата, полное обучение не даёт прироста.
• Показатель решения: качество на час GPU.

Эксперимент для «Выберите глубину адаптации» замораживают до изменения: объект «полный fine-tuning, LoRA или иной PEFT», пример «LoRA достаточно для формата, полное обучение не даёт прироста», ожидаемый показатель «качество на час GPU». После шага «оценить ресурсы и требуемое изменение» должен появиться протокол выбора. Ответственный исследователь отклоняет вариант, если сохраняется риск «дорогой метод берут без сравнения».

За этот участок отвечает исследователь. В журнале он связывает объект «полный fine-tuning, LoRA или иной PEFT» с артефактом «протокол выбора», записывает версию входных данных, условия запуска и принятое решение. Если показатель «качество на час GPU» улучшается ценой нового риска «дорогой метод берут без сравнения», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «оценить ресурсы и требуемое изменение» должен воспроизводиться на примере «LoRA достаточно для формата, полное обучение не даёт прироста».

Разберите пример отдельно: LoRA достаточно для формата, полное обучение не даёт прироста. Полезно попросить второго специалиста повторить шаг «оценить ресурсы и требуемое изменение» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «полный fine-tuning, LoRA или иной PEFT» владелец «исследователь» сверяет артефакт «протокол выбора» с метрикой «качество на час GPU».

Контролируйте обучение

На собственном материале проверьте loss, переобучение и сохранение checkpoint. Дообучение оправдано только после базовой линии и ясного типа ошибки. Если возникает «лучший train loss выпускают автоматически», вернитесь к шагу «смотреть validation и раннюю остановку» и пересоберите кривые и checkpoints, не меняя одновременно остальные условия.

• Рабочее действие: смотреть validation и раннюю остановку.
• Сохраняемый артефакт: кривые и checkpoints.
• Контрольная ситуация: качество перестаёт расти после определённой эпохи.
• Показатель решения: validation metric.

В разделе «Контролируйте обучение» сравните две версии на одинаковом входе «качество перестаёт расти после определённой эпохи». Свидетельство кривые и checkpoints связывает объект «loss, переобучение и сохранение checkpoint» с действием «смотреть validation и раннюю остановку». Итоговый показатель — «validation metric»; владелец ML-инженер отдельно проверяет ошибку «лучший train loss выпускают автоматически».

За этот участок отвечает ML-инженер. В журнале он связывает объект «loss, переобучение и сохранение checkpoint» с артефактом «кривые и checkpoints», записывает версию входных данных, условия запуска и принятое решение. Если показатель «validation metric» улучшается ценой нового риска «лучший train loss выпускают автоматически», изменение не выпускают, пока не появится защитная метрика и план отката. Практический шаг «смотреть validation и раннюю остановку» должен воспроизводиться на примере «качество перестаёт расти после определённой эпохи».

Разберите пример отдельно: качество перестаёт расти после определённой эпохи. Полезно попросить второго специалиста повторить шаг «смотреть validation и раннюю остановку» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «loss, переобучение и сохранение checkpoint» владелец «ML-инженер» сверяет артефакт «кривые и checkpoints» с метрикой «validation metric».

Ищите регрессии

Владельца для этапа «Ищите регрессии» назначают до работы с объектом «старые навыки и безопасные отказы». Дообучение оправдано только после базовой линии и ясного типа ошибки. Он не допускает ошибку «новая специализация ломает общий ответ», требует выполнить «прогнать постоянный набор» и принять регрессионный отчёт.

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

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

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

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

Проведите слепое сравнение

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

• Рабочее действие: перемешать ответы.
• Сохраняемый артефакт: протокол оценки.
• Контрольная ситуация: редактор выбирает ответ без знания версии.
• Показатель решения: предпочтение и критичные ошибки.

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

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

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

Подготовьте релиз и откат

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

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

Перед закрытием пункта «Подготовьте релиз и откат» воспроизведите цепочку: версия модели, данных, кода и маршрута; запускать через долю трафика; план rollback. На примере «при росте ошибок трафик возвращается базе» измерьте «время обнаружения и отката». Роль дежурная команда выбирает запуск, исправление или отказ, если обнаруживается риск «новые веса заменяют рабочие без возврата».

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

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

Матрица приёмки

Что изучить дальше

• LoRA
• RAG
• few-shot prompting
• локальная нейросеть
• синтетические данные
• персональные данные в ИИ
• аудит ИИ-систем

Чек-лист запуска