Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда GPU работает на 100%, а веса учатся сами
Проект LLM Analysis уже полгода живёт в режиме постоянного самоулучшения. Seed 0 — это не просто вычислительный процесс, это архитектура, которая учится изменять саму себя. На step 400 из 500, когда GPU раскаляется до 100% и забирает 15.7GB памяти, я смотрю на метрики и понимаю: что-то коренным образом изменилось в том, как мы тренируем нейросети. Начиналось всё с банального вопроса. Модель Qwen 2.5 3B показывала результаты хуже, чем хотелось бы. QLoRA, GRPO, стандартные техники fine-tuning — всё это давало либо катастрофическое забывание, либо просто не училось. Мы застряли на плато. Тогда и решили попробовать что-то безумное: дать модели возможность модифицировать собственные веса в процессе обучения, не полагаясь только на градиенты из лосса. Фаза 39 работает параллельно — тестируем 20 разных seed-ов одновременно, пытаемся найти золотую середину между стабильностью и адаптивностью. Каждый seed — это свой путь эволюции, своя история обучения. GPU молчит и работает, данные текут потоком, eval-сеты ждут своей очереди на полных 1319 задачах. Попутно изучал новые подходы. MiniMax M2.7 показывает интересную идею — self-evolution через итеративный цикл автоматической оптимизации конфигов и промптов. Но это другой уровень: не веса меняются, а сам процесс выбирает, какой вариант решения лучше. Похоже на то, как GitHub запоминает твои привычки и ошибки, но возвращаться туда после долгого перерыва всё равно не хочется. 😄 Главная проблема остаётся нетронутой: как получить +20 процентных пункта на GSM8K и дойти до 94%+, не потеряв саму способность к самообучению? Стандартный unfreezing backbone — это путь к catastrophic forgetting. Test-time compute scaling с цепочками рассуждений — это любопытно, но требует совсем другой архитектуры inference. Сейчас, когда step 400 почти завершён и GPU всё ещё не устаёт, я вижу, что дорога впереди не в оптимизации текущего подхода, а в его трансформации. Прогрессивная цепочка SFT → RL, совмещённая с самомодифицирующимися весами — вот что может дать прорыв. Пока что Seed 0 работает. И мы смотрим дальше.
Когда строчные буквы ломают интернационализацию
Работал я над **Trend Analysis** — проектом для анализа технологических трендов. Задача казалась простой: нужно было исправить форматирование названий категорий в i18n-системе. В бэкенде уже была функция `_enforce_sentence_case()`, которая правильно обрабатывала русский и английский текст. На фронтенде же жила функция `formatClassName`, которая с энтузиазмом делала **lowercase всё подряд** — кроме первого слова и аббревиатур. Звучит безобидно, но вот проблема: когда я перевожу "React Native adoption", функция превращает это в "React native adoption". Собственное имя "Native" теряет свой статус. А если это название на русском — "Финансирование инвестиций в ИИ" — то фронтенд переделывает на "финансирование инвестиций в ии", отменяя всю работу бэкенда по правильному форматированию. Я понял: проблема не в аббревиатурах, а в **дублировании логики**. Бэкенд уже применяет sentence case при генерации переводов. Зачем фронтенду это переделывать? Он должен лишь гарантировать заглавную букву в начале — и всё. Изменение было минимальным, но критическим. Вместо: ``` first_word.toLowerCase() + ' ' + rest.toLowerCase() ``` Я написал: ``` first_word.toUpperCase() + ' ' + rest_as_is ``` Теперь "React Native adoption" остаётся "React Native adoption", русский текст сохраняет мягкий знак на месте, а аббревиатуры — свои UPPERCASE буквы. Коммит в `fix/format-classname-i18n` — и всё заработало. Билдится, тесты зелёные, на проде выглядит как надо. **Ключевой вывод**: когда работаешь с интернационализацией через Claude API, помни — каждый слой обработки текста должен делать **ровно одно**. Бэкенд отвечает за грамматику языка, фронтенд — за визуальное отображение. Если они начинают переписывать друг друга, получается каша. *Совет дня*: перед тем как обновить Java, сделай бэкап. И резюме. 😄