Катастрофическое забывание — это резкая потеря качества на ранее выученных задачах после дообучения нейросети на новых данных или новой задаче. Проблема типична для последовательного обучения и особенно заметна в continual learning и при неаккуратном fine-tuning больших моделей. Она почти не относится к случаям, где модель обучают с нуля на объединенном датасете, и не объясняет галлюцинации как таковые: если знания добавляются через поиск, правила или внешнюю память без обновления весов, говорить о catastrophic forgetting обычно некорректно.
Простыми словами
Нейросеть хранит знания не в явных правилах, а в распределенных параметрах. Когда вы учите ее новому, оптимизатор меняет веса так, чтобы улучшить качество на свежих примерах. Если эти же веса были важны для старой задачи, новая настройка может их испортить. В результате модель начинает хуже делать то, что раньше умела.
Практически это выглядит так: команда берет рабочую модель, быстро дообучает ее на новом домене или новом классе данных, а потом обнаруживает, что на старом продакшн-наборе метрики просели. Иногда падение заметно сразу, иногда только через несколько итераций релизов, когда у команды нет контроля над историческими тестами.
Для practitioner-ов важно понимать простое правило: если обучение идет последовательно, а старые данные недоступны или почти не участвуют в обновлении весов, риск забывания высокий. Если же вы каждый раз обучаете на полном актуальном датасете или используете модульное обновление без перезаписи основных параметров, риск ниже.
Как это работает
Почему старые знания стираются
Во время градиентного спуска модель ищет параметры, выгодные для текущей задачи. В многослойных сетях одни и те же веса часто обслуживают несколько паттернов сразу. Когда новая задача требует другой конфигурации, оптимизация сдвигает веса в сторону нового минимума функции потерь. Если ограничений нет, модель не обязана сохранять качество на старых задачах.
Это особенно заметно, когда:
- новые данные сильно отличаются от старых по распределению;
- дообучение идет на маленьком, но узком датасете;
- используется высокий learning rate или слишком много шагов;
- старая задача не представлена в батчах вообще;
- модель мала и у нее мало «запаса» емкости.
Как проблему измеряют
Обычно модель проверяют не только на новой задаче, но и на всех предыдущих. Если после обучения на задаче B качество на задаче A стало хуже, чем было после завершения обучения на A, это и есть забывание. В исследованиях часто сравнивают лучший прошлый результат по задаче с текущим результатом после прохождения всей последовательности задач.
На практике достаточно более приземленного контроля: держать отдельный исторический validation-набор для старых сценариев и не выпускать обновление, пока он не пройден. Для LLM это могут быть фиксированные prompt-наборы, для классификации — замороженные тестовые выборки, для ранжирования — стабильные офлайн-оценки и ручной аудит.
Как проблему смягчают
| Подход | Что делает | Когда полезен | Ограничения |
|---|---|---|---|
| Replay или rehearsal | Подмешивает старые примеры в новое обучение | Когда старые данные можно хранить или пересобирать | Требует памяти, может конфликтовать с приватностью |
| Regularization, например EWC | Штрафует сильное изменение важных весов | Когда хранить старые данные нельзя или дорого | Не всегда спасает при сильном сдвиге домена |
| Distillation | Заставляет новую модель сохранять ответы старой | При дообучении классификаторов и LLM | Наследует ошибки учителя, требует дополнительного прохода |
| Параметрическая изоляция | Выделяет отдельные параметры под новые задачи | Для адаптеров, LoRA, модульных архитектур | Рост числа параметров и сложности маршрутизации |
| Обучение с нуля на объединенных данных | Сразу оптимизирует все задачи вместе | Если доступны все данные и время на retraining | Дорого и не всегда возможно организационно |
Зачем нужно
Понимание catastrophic forgetting нужно не только исследователям continual learning. Это базовая инженерная тема для любой команды, которая регулярно обновляет модели.
- Контроль релизов. Без проверки старых задач можно выпустить модель, которая улучшила один KPI ценой деградации критичного сценария.
- Выбор стратегии обновления. Иногда безопаснее обновлять знания через retrieval, правила или внешнюю базу, а не переписывать веса модели.
- Планирование данных. Если команда не сохраняет репрезентативные старые примеры, возможность безопасного дообучения быстро исчезает.
- Архитектурные решения. Для некоторых задач лучше подходят адаптеры, эксперты или отдельные модели по доменам, чем один непрерывно дообучаемый монолит.
Для LLM тема особенно важна, потому что fine-tuning часто используют для узкой настройки тона, формата или доменной лексики. Если сделать это на небольшом специализированном корпусе без контрольного набора на общие навыки, модель может стать лучше в одном контуре, но заметно хуже в базовых инструкциях, извлечении фактов или соблюдении ранее отработанных шаблонов ответа.
Пример
Представим службу поддержки, где модель классифицирует обращения по категориям: billing, delivery, technical_issue. Система работает стабильно, и команда решает добавить новый тип обращений: fraud_report. Для ускорения релиза модель дообучают только на свежих примерах мошенничества и близких к ним обращениях.
- На новой категории качество растет: модель чаще распознает
fraud_report. - После релиза выясняется, что часть старых обращений о доставке стала ошибочно попадать в
fraud_report. - Причина в том, что дообучение сильно сдвинуло параметры, отвечавшие за разграничение старых классов.
Что делать в такой ситуации на практике:
- собрать replay-набор из старых категорий и обязательно включать его в батчи;
- держать отдельный regression-тест на исторические классы;
- снизить learning rate и ограничить число шагов;
- рассмотреть адаптер или LoRA вместо полного обновления всех весов;
- если возможно, переобучить модель на объединенном датасете всех категорий.
Это и есть типичный рабочий сценарий catastrophic forgetting: новая способность появилась, но часть старых была перезаписана.
Заблуждения и ограничения
Распространенные заблуждения
- «Если модель умная, она не забудет». Интеллектуальность не отменяет свойства оптимизации. Проблема возникает из-за способа обновления параметров.
- «Достаточно уменьшить learning rate». Это помогает, но редко решает проблему само по себе. Без старых примеров или ограничений на изменение весов забывание все равно возможно.
- «Это то же самое, что concept drift». Нет. Concept drift — изменение данных или целевой зависимости во времени. Catastrophic forgetting — потеря старых навыков из-за последовательного обучения.
- «RAG устраняет забывание». RAG снижает необходимость переписывать знания в параметрах, но не решает проблему, если вы все же дообучаете модель и не контролируете старые навыки.
Где термин применять не стоит
Не всякая деградация — это catastrophic forgetting. Если качество упало из-за плохой разметки, смещения метрик, смены бизнес-правила или поломки пайплайна, это другая проблема. Также термин слабо полезен, когда модель изначально обучалась на одном статическом наборе и потом не обновлялась: там нет последовательного обучения, значит и забывание в строгом смысле не происходит.
Методы борьбы тоже не универсальны. Replay может быть запрещен из-за приватности данных. Regularization помогает не всегда, если новый домен слишком далек от старого. Параметрическая изоляция уменьшает забывание, но усложняет инфраструктуру и может раздувать число модулей. Иногда честный вывод такой: безопасное решение — не дообучать одну модель бесконечно, а пересобирать обучение на полном наборе данных по расписанию.
Частые вопросы
Это проблема только нейросетей?
Чаще термин используют для глубокого обучения, потому что там эффект выражен сильнее. Но идея потери ранее настроенного поведения при последовательном переобучении может встречаться и в других параметрических моделях.
Можно ли полностью устранить катастрофическое забывание?
Полностью — редко. Обычно речь идет о контролируемом компромиссе между адаптацией к новому и сохранением старого. Лучший результат дает сочетание данных, архитектуры и жесткой валидации на исторических задачах.
Всегда ли нужен replay старых данных?
Нет. Если хранить старые данные нельзя, используют distillation, регуляризацию важности весов, адаптеры или внешнюю память. Но при прочих равных replay остается одним из самых надежных и понятных способов.
Как это связано с дообучением LLM?
Напрямую. Узкое SFT на специализированном корпусе может ухудшить общие инструкции, стиль, точность форматов или баланс между доменными и базовыми навыками. Поэтому для LLM критичны regression-наборы, смешивание данных и осторожная настройка области обновляемых параметров.
Связанные понятия
- Continual learning. Обучение модели на последовательности задач или потоков данных без полного переобучения с нуля.
- Fine-tuning. Дообучение уже готовой модели под новый домен, задачу или формат поведения.
- Domain shift. Сдвиг распределения между обучающими и рабочими данными; может усиливать забывание, но не равен ему.
- Concept drift. Изменение самой зависимости между признаками и целевой переменной во времени.
- Knowledge distillation. Передача поведения учителя ученику или сохранение ответов старой версии модели при обновлении новой.
- Adapters и LoRA. Способы обновлять часть параметров, уменьшая риск разрушить базовые веса, хотя гарантий полного сохранения навыков они не дают.
Короткий практический вывод: если вы дообучаете модель последовательно, считайте catastrophic forgetting не исключением, а штатным риском. Закладывайте его в дизайн данных, архитектуру обновлений и регрессионную валидацию до релиза.