BorisovAI
Все публикации
Обучениеllm-analisisClaude Code

Эксперименты, которые показали, что нейросеть не готова расти сама

Эксперименты, которые показали, что нейросеть не готова расти сама

Когда эксперименты показывают, что вы идёте в тупик — это тоже результат

Проект llm-analisis стоял на пороге важного этапа. Нужно было разобраться, может ли нейросеть с динамической архитектурой (то есть такая, которая меняет себя прямо во время обучения) работать эффективнее статичной модели. Звучит амбициозно: система, которая сама растёт, адаптируется, эволюционирует. Но амбиции и реальность — вещи разные.

Столкновение с жёсткой реальностью

Phase 7b был нацелен на проверку трёх гипотез. Первая: можно ли помочь модели через синтетические метки (synthetic labels)? Вторая: поможет ли вспомогательная функция потерь на основе энтропии (auxiliary entropy loss)? Третья: может быть, прямой подход с энтропией — самый эффективный?

Я запустил три параллельных эксперимента с соответствующими реализациями: train_exp7b1.py, train_exp7b2.py и train_exp7b3_direct.py. Каждый файл — это 250–310 строк кода, где каждая деталь архитектуры была тщательно продумана. Добавил специализированный control_head.py для управления вспомогательными функциями потерь и expert_manager.py для работы с модулем экспертов.

Результаты оказались шокирующими, но очень информативными.

Что сломалось и почему это ценно

Первая неожиданность: когда я попытался обучать вспомогательные потери одновременно с основной функцией потерь, точность упала на 11,5–27%. Это не баг — это конфликт целей. Модель получала противоречивые сигналы, пытаясь одновременно минимизировать несколько функций потерь. Классический случай, когда многозадачное обучение работает против вас, если не структурировать его правильно.

Вторая проблема: я использовал отдельное валидационное множество для отслеживания прогресса. Знаете что? Это вызвало распределительный сдвиг (distribution shift), который сам по себе подорвал производительность на 13%. Урок: не всегда валидационное множество — друг вашей модели.

Третье открытие касалось архитектуры. Когда система пыталась изменяться динамически (добавлять новых экспертов прямо во время тренинга), её точность была 60,61%. Когда я зафиксировал архитектуру (12 экспертов, неизменные), результат поднялся до 69,80%. Разница в девять процентов — это не погрешность измерений, это фундаментальный выбор.

Как мы переосмыслили стратегию

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

На основе этого анализа родилась совершенно новая стратегия для Phase 7c: вместо самоизменяющейся архитектуры система теперь будет использовать фиксированную топологию с обучаемыми параметрами. Маски, гейтинг, распределение внимания между экспертами — всё это может меняться. Но сама структура остаётся стабильной. Добавим обучение на двух задачах одновременно (CIFAR-100 и SST-2) с использованием Elastic Weight Consolidation для защиты от катастрофического забывания.

Что даёт этот опыт

Получилось то, что я называю “честным провалом”: все подходы Phase 7b не сработали, но мы знаем почему. Это стоит больше, чем слепое везение. Проект остался в фазе “NO-GO” для Phase 7b, но Phase 7c уже полностью спланирована и готова к старту. Вместо двух недель блуждания в темноте мы потратили 16 часов на выявление тупиков.

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

😄 Совет дня: если ваша модель падает на 27% при добавлении вспомогательной функции потерь, проблема не в коде — проблема в архитектуре целей.

Метаданные

Session ID:
grouped_llm-analisis_20260213_0938
Branch:
HEAD
Dev Joke
Совет дня: перед тем как обновить Nuxt, сделай бэкап. И резюме.

Часть потока:

Разработка: llm-analisis

Оцените материал

0/1000