Новое исследование на моделях от 4 млн до 4 млрд параметров зафиксировало точный механизм, стоящий за феноменом «эмерджентных способностей» LLM. Малые модели проваливаются на редких задачах не потому, что им не хватает мощности — а потому что частые задачи в процессе обучения постоянно перезаписывают то, что модель успела выучить про редкие. И вывод у авторов неожиданный: вместо того чтобы масштабировать модель, достаточно увеличить частоту появления целевой задачи в обучающих данных.
Контекст
Вопрос «почему большие модели умеют то, чего не умеют маленькие» занимает исследователей как минимум с 2022 года, когда появилась концепция emergent abilities — способностей, которые как будто возникают из ниоткуда при пересечении определённого порога параметров. Сторонники масштабирования видели в этом подтверждение: хочешь новые навыки — плати за больший кластер. Скептики возражали, что эффект может быть артефактом метрик.
Данная работа предлагает более механистичное объяснение. Суть — в интерференции градиентов: когда модель обучается на корпусе, где задача A встречается в тысячу раз чаще задачи B, обновления весов, нужные для A, методично разрушают то, что помогало выполнять B. Большая модель справляется лучше не потому что «умнее» — а потому что имеет достаточно ёмкости, чтобы удерживать редкие паттерны даже под постоянным давлением со стороны частых.
Диапазон изученных моделей — от 4M до 4B параметров — охватывает именно тот класс, который сейчас наиболее активно используется в edge-деплойментах, мобильных приложениях и локальных агентах. Это делает находку практически значимой уже сегодня.
Аналитика
Если авторы правы, то гонка за параметрами частично была ответом на неправильно поставленный вопрос. Компании тратили миллионы на инфраструктуру и вычисления, тогда как нужный рычаг находился в датасете — а именно в соотношении частоты задач при обучении. Это открывает несколько интересных следствий.
Первое: для специализированных приложений — юридические документы, медицинские протоколы, специфические форматы отчётности — малая модель, дообученная на сбалансированном корпусе, может конкурировать с большой общей моделью. Не по всем задачам, но именно по целевым. Второе: это объясняет, почему fine-tuning на специализированных данных работает так хорошо — по сути, он искусственно повышает частоту нужных задач в пространстве обновлений. Третье: для тех, кто строит production-пайплайны с маленькими моделями (on-device, offline, low-latency), появляется рабочая гипотеза — проверить баланс задач в тренировочном корпусе прежде чем искать более крупную модель.
Более широкий тренд тут тоже читается: отрасль движется от «просто сделай модель больше» к data-centric AI — тщательному конструированию обучающих данных. Это дешевле, интерпретируемее и воспроизводимее. Для команд, которые не могут позволить себе Frontier-модели, это хорошая новость.
Кейсы применения в бизнесе
B2B-SaaS стартап с вертикальным AI-агентом. Команда строит агента для автоматизации обработки договоров. Общая модель хорошо разбирает стандартные пункты, но путается в специфических для местного законодательства формулировках — они редкие. Вместо перехода на более дорогой Frontier-API: аудит датасета fine-tuning, искусственное дублирование примеров с редкими юридическими конструкциями, переобучение на сбалансированной выборке. Ожидаемый результат — сопоставимое качество на целевых задачах при меньших затратах на инференс.
Корпорация с legacy-процессами. Внутренний чат-бот на базе небольшой модели хорошо отвечает на типовые вопросы сотрудников, но регулярно ошибается в сценариях, связанных с редкими HR-процедурами или нестандартными случаями в бухгалтерии. Решение не в замене модели — а в обогащении тренировочного набора примерами именно этих редких сценариев с синтетической генерацией через большую модель и последующей верификацией экспертами.
SMB / локальный бизнес в КР и СНГ. Небольшой интернет-магазин хочет запустить AI-ассистента на базе open-source модели на собственном сервере — без подписки на облачный API. Модель хорошо отвечает про популярные товары, но теряется при вопросах про редкие позиции или нестандартные условия доставки. Практический шаг: собрать 200-300 качественных примеров Q&A именно по проблемным сценариям и добавить их в fine-tuning датасет с повторением — это дешевле и быстрее, чем переход на более тяжёлую модель.
Кейсы в личной жизни
Разработчик, использующий локальную LLM. Если ваша локальная модель (Qwen, Mistral, Phi-класс) стабильно хорошо помогает с Python, но теряется при работе с редким фреймворком или специфическим DSL — это не повод менять модель. Попробуйте сформировать небольшой набор few-shot примеров именно по проблемной области и передавать их в системном промпте. Это частично имитирует эффект балансировки частоты задач.
Контент-мейкер и фрилансер. При работе с AI-инструментами для создания контента: если модель отлично пишет типовые посты, но плохо справляется с вашим специфическим форматом или нишевой тематикой — сформируйте библиотеку из 10-15 примеров в вашем стиле и прикрепляйте её к каждому запросу. Качество на нестандартных задачах заметно растёт.
Студент или исследователь. Если вы экспериментируете с fine-tuning небольших моделей для академической задачи — теперь у вас есть конкретная гипотеза для проверки: намеренно увеличьте долю примеров по целевой редкой задаче в обучающей выборке и сравните результат с baseline. Это воспроизводимый эксперимент с понятной интерпретацией.
Как применить сегодня
- Если малая модель плохо справляется с конкретной задачей — сначала проверьте, насколько эта задача представлена в обучающих или few-shot данных, прежде чем искать более крупную модель.
- При fine-tuning: используйте oversampling для редких, но важных примеров — намеренно дублируйте их в датасете с коэффициентом 5–20× относительно частых классов.
- Для локальных моделей без возможности fine-tuning: добавляйте 5-10 few-shot примеров по редкой задаче прямо в системный промпт — это смещает распределение «задач в контексте» в нужную сторону.
- При оценке моделей для production: тестируйте не только на частых сценариях, но и на «длинном хвосте» — именно там малые модели проваливаются по описанному механизму.
- Если строите агентный пайплайн: рассмотрите маршрутизацию — частые задачи отдайте малой быстрой модели, редкие и сложные — более крупной. Это даёт баланс скорости и качества без переплаты за инференс на всём потоке.