Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда маршрутизация идеальна, а точность нет: история эксперимента 13b
В проекте **llm-analisis** я работал над стратегией специализированных моделей для CIFAR-100. Идея казалась логичной: обучить роутер, который направляет примеры на специализированные сети. Если маршрутизация будет точной, общая accuracy должна вырасти. Вот только жизнь оказалась сложнее. ## Четыре стратегии и парадокс Я протестировал четыре подхода: - **Стратегия A** (простая маршрутизация): 70.77% accuracy, но роутер угадывал правильный класс только в 62.5% случаев - **Стратегия B** (смешанный подход): 73.10%, маршрутизация на уровне 62.3% - **Стратегия C** (двухфазная): 72.97%, роутинг 61.3% - **Стратегия D** (глубокий роутер + двухфазный training): вот здесь всё интересно ## Успех, который не сработал Стратегия D показала впечатляющий результат для маршрутизации — **79.5%**. Это в 1.28 раза лучше, чем простой однослойный роутер. Я был уверен, что это прорыв. Но финальная accuracy выросла всего на 0.22 процентных пункта до 73.15%. Это был момент истины. **Проблема не в маршрутизации.** Даже если роутер почти идеально определяет, на какую специализированную сеть отправить пример, общая точность почти не растёт. Значит, сами специализированные модели недостаточно хорошо обучены, или задача классификации на CIFAR-100 просто не подходит для такой архитектуры. ## Факт о нейросетях Вот что интересно: **оракульная accuracy** (когда мы знаем правильный класс и отправляем пример на соответствующую специализированную сеть) оставалась в диапазоне 80–85%. Это потолок архитектуры. Роутер, улучшив маршрутизацию, не может превысить этот потолок. Проблема была в самих специализированных сетях, а не в способности их выбирать. ## Итог Эксперимент 13b завершился вердиктом **NO-GO** — 73.15% меньше требуемых 74.5%. Но это не поражение, а ценный урок. Иногда идеально сделанная часть системы не спасает целое. Нужно было либо пересмотреть архитектуру специализированных моделей, либо использовать другой датасет. Документация обновлена, результаты залогированы. Команда готовится к следующему витку экспериментов. *Совет дня: перед тем как обновить ArgoCD, сделай бэкап. И резюме. 😄*
Почему картинки в заметках исчезали — и как я это чинил
В проекте **bot-social-publisher** большинство заметок генерировались без картинок. Я открыл pipeline обогащения контента и понял: изображения генерируются, но где-то теряются при публикации на сайт. Сначала подумал, что проблема в самом генераторе картинок — может быть, Unsplash API разобрался со скоростью запросов или что-то сломалось в fallback на Pillow. Но логи показали: функция `generate_image()` работает стабильно, возвращает валидные URL или локальные пути. Дальше проследил цепочку обогащения: **ContentSelector** срезает контент до 40–60 информативных строк, Claude CLI генерирует текст на русском и английском, валидация языков переворачивает контент если перепутались локали. Все работает. Изображение есть в `EnrichedNote`. Чек перед публикацией через Strapi API показал, что в JSON отправляется корректно, но в ответе сервера поле `imageUrl` появлялось пустым. Оказалось, что при PUT-запросе на обновление заметки нужно передавать не просто URL, а правильно структурированную ссылку с указанием локали — `?locale=ru` для русского варианта. Вторая причина была более коварной: когда контент на английском оказывался длиннее русского, система неправильно маппила картинку. Я перепроверил логику выбора языка — оказалось, что валидация через `detect_language()` иногда ошибалась при смешанном контексте (когда в заметке много технических терминов на латинице). **Решение оказалось двухуровневым:** 1. Явно привязать изображение к основному языку заметки (русский, как определено в конфиге), не к случайному выбору в цикле обогащения. 2. Добавить проверку в `scripts/update_site.py` — если картинка есть, отправлять её в отдельном поле `media` с правильным MIME-type, а не мешать с текстом. После этих изменений заметки начали публиковаться с картинками стабильно. Кстати, интересный момент: **Swift и кот делают только то, что хотят и игнорируют инструкции** 😄 — примерно так себя вел и этот баг, пока я не прочитал логи в деталях. Обновил также документацию enrichment-пайплайна, чтобы следующий разработчик не искал картинки в пяти файлах сразу.
Когда батч-норм ломает миксчур экспертов на CIFAR-100
Три недели охоты за призраком. Работал над проектом `llm-analysis` с амбициозной идеей: **mixture-of-experts** для классификации на CIFAR-100. Теория обещала +40 процентных пункта над baseline. На практике упёрся в две стены сразу. ## Первая стена: BatchNorm молчаливый убийца Всё началось на фазе 12b с горячей замены экспертов (hot-plug test). Замораживаю веса одного эксперта, обучаю новый, включаю замороженный назад. И вот беда — точность первого эксперта падает на **2.48 процентных пункта**. Часы в отладчике, проверка логик, перепроверка кода... Потом осенило: `requires_grad=False` не спасает. **BatchNorm слои обновляют running statistics** даже с заморозкой весов. Это внутренние счётчики среднего и дисперсии — они ломают инференс замороженного эксперта, когда я обучаю рядом лежащего. Решение глупо-простое: добавил `model.stem.eval()` после `model.train()`. Явно перевести backbone в режим инференса. Дрейф упал с 2.48pp до нуля. Полдня на баг, который решился одной строкой. Классика. ## Вторая стена: роутер, который не хочет учиться Фаза 13a должна была быть волшебной. Oracle (идеальный роутер) показывал потолок в **80.78%**. А мой `nn.Linear(128, 4)` застрял на **72.93%** — зазор в семь с половиной пункта. Запустил три стратегии подряд: 1. **Глубокий роутер + отдельное обучение**: 73.32% — тоже не помогает 2. **Совместное обучение роутера и экспертов**: 73.74% — хуже 3. **Ещё глубже архитектура**: routing accuracy 62.5% и не растёт Вот в чём подвох: на CIFAR-100 эксперты видят **одинаковые 100 классов** из каждого батча. Градиенты идут со всех направлений одновременно. Доменная специфика просто стирается. Роутер не может выучить разделение — потому что эксперты сами никогда не специализируются. Это не инженерный баг. Это архитектурный потолок. ## Странное совпадение про зависимости Кстати, а знаешь, почему ZeroMQ расстался с разработчиком? **Слишком много зависимостей в отношениях** 😄 Но серьёзно — я запустил четыре параллельных эксперимента, пытаясь одновременно решить две несвязанные задачи. BatchNorm — это был мой быстрый win. Маршрутизация — архитектурный блокер. **Итог фазы 12b**: горячая замена экспертов работает. Hot-plug стабилен. Batch-norm под контролем. **Итог фазы 13a**: нельзя требовать специализацию, если эксперты видят одинаковые данные. На CIFAR-100 с такой архитектурой это невозможно. Нужна либо переделка доменов под каждого эксперта, либо... признание поражения и переход на другой датасет. Иногда две стены одновременно — это знак, что дверь в другом месте.
Когда маршрутизация экспертов встречает стену батч-нормализации
Работал над проектом `llm-analysis` — попытка воплотить мечту о смеси экспертов (MoE) для классификации на CIFAR-100. На бумаге звучит идеально: несколько специализированных нейросетей, умный роутер распределяет примеры, каждый эксперт углубляется в свою область. Теория говорит, что на специализированных данных эксперт должен дать +40 процентных пункта над базовым подходом. На практике упёрся в две стены одновременно. ## Batch Norm предательство Началось с фазы 12b — горячей замены экспертов (hot-plug test). Замораживаю веса эксперта, обучаю новый, включаю замороженный обратно. Точность первого эксперта падала на 2.48pp. Думал, это неизбежный дрейф при переобучении остальных. Копался в коде часами. Потом понял: `requires_grad=False` не спасает. BatchNorm слои вычисляют running statistics (среднее и дисперсию) даже с frozen весами. Когда обучаю эксперт E1, BatchNorm в backbone'е (E0) видит новые батчи, обновляет свои внутренние счётчики и ломает инференс замороженного эксперта. Решение простое, как кувалда: добавить `model.stem.eval()` после `model.train()`, явно перевести backbone в режим инференса. Дрейф упал с 2.48pp до **0.00pp**. Это был просто инженерный баг, но на него потратил полдня. ## Роутер, который не может научиться Фаза 13a обещала быть волшебной: построю более глубокий роутер, обучу его совместно с экспертами, роутер нужен для анализа — всё сойдётся. Oracle (идеальный роутер) показывал потолок в 80.78%, а наш простой `nn.Linear(128, 4)` давал 72.93%. Зазор в семь с половиной пункта! Запустил три стратегии: - **A**: глубокий роутер + отдельное обучение экспертов → 73.32% (нет улучшения) - **B**: совместное обучение роутера и экспертов → 73.10% (хуже baseline) - **C**: вообще неудача, routing accuracy 62.5% и не растёт Вдруг понимаю: **специализация и совместное обучение на CIFAR-100 несовместимы**. Каждый экспертный поток получает данные всех 100 классов, градиенты идут со всех направлений, и доменная специфика стирается. Роутер не может выучить отделение — потому что эксперты сами не специализируются. ## Факт из реальности Вот забавное совпадение: идеальный день программиста — ни одного тикета в Jira. Реальный день — 15 тикетов, три митинга, ноль коммитов 😄 Но в нашей ситуации это метафора посерьёзнее. Я запустил четыре параллельных эксперимента, пытаясь одновременно решить две задачи (hot-plug + маршрутизация). Батч-норм проблема — это мой тикет, который решился за пятнадцать минут кода. Маршрутизация — это архитектурный блокер, который требует другого подхода. ## Вывод **Фаза 12b победила**: BatchNorm теперь в eval mode, hot-plug стабилен, друсть экспертов валидирован. Но **фаза 13a показала** — нельзя требовать специализацию, если эксперты видят одинаковые данные. Дальше либо пересмотр архитектуры (правильные домены для каждого эксперта), либо смирение с тем, что роутер так и не научится лучше случайного. На CIFAR-100 это не работает — надо идти на другой датасет с явной структурой доменов.