Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда зависимость становится преимуществом: история про seed'ы в LLM Analisis
Мы застряли. Три недели исследований на проекте **LLM Analisis** не давали результата — модель **Orchestra-MoE** показывала странное поведение. Результаты прямо зависели от того, как мы инициализировали веса. Казалось, это баг. На самом деле это была возможность, которую мы просто не видели. Проблема началась невинно. Запускали эксперимент десять раз подряд — получали разные скоры. Изменился только seed инициализации. Сначала думали: "Может, это нестабильность модели?" Проверили архитектуру, данные, loss функцию — всё чисто. Но результаты плясали от 75% до 78% в зависимости от random seed'а. Вместо того чтобы искать проблему, мы решили посмотреть на это под другим углом. Позвали экспертов — собрали панель из четырех специалистов по машинному обучению. И вот что они сказали: *не боритесь с зависимостью, используйте её*. **Voronova** привела теорию: если запустить одну и ту же модель N раз с разными seed'ами, максимальный результат растёт предсказуемо. По закону экстремумов распределения, для N=20 можно ожидать улучшение на 1.4 процентных пункта просто за счёт выбора лучшего seed'а. Для N=100 это уже 2.1pp. **Zhang** посчитал прагматику: двадцать запусков по полчаса каждый — всего десять часов GPU времени. Это намного дешевле, чем те 85+ часов, что мы уже потратили на архитектурные улучшения, которые ничего не дали. **Merkulov** добавил статистическую честность: выбирать best seed нужно по валидационному сплиту, а потом репортить результат на тестовом. Иначе выглядит как overfitting на тест-данные. **Kalenov** и **Patel** предложили бонусы: можно собрать ensemble из топ-трёх seed'ов через majority voting — разные инициализации делают разные ошибки, и вместе они сильнее. Или использовать data-dependent инициализацию через SVD от активаций, это снизит дисперсию. Что нас выбило из колеи? Не баг, а **feature selection**. Система работает хорошо, но нужно выбрать правильное начальное состояние. Как выбрать гитару — звучит одна и та же модель совсем по-разному в руках разных людей. Планируем теперь batch-запуск двадцати seed'ов на полных 1319 задачах, анализ распределения, построение ensemble'я. Может, finally доберёмся до 79% и выше. *Кстати, как Ubuntu: никогда не забудешь первый опыт, но возвращаться туда, где застрял, обычно не стоит — лучше выбрать новый seed и начать сначала.* 😄
Как 79% точности стало воспроизводимо: история отладки модели LLM
Когда я запустил Phase 30b, первый вопрос был просто: это реальный результат или артефакт грязных данных? На Phase 29a модель выдала пик 79.3% на GSM8K, но потом график выглядел как пила — скачки, провалы, непредсказуемость. Я не мог поверить в цифру, пока не повторю на чистых данных. Перевожу проект LLM Analysis на режим диагностики. Беру свежий датасет, убираю все грязные примеры — дубликаты, невалидные задачи, шум. Запускаю Phase 30b с полным tracking'ом: не просто финальный результат, а промежуточные замеры на каждых 50 задачах. Результаты потрясли меня в хорошем смысле. **Пик 79.0% воспроизводим.** Не один раз — стабильно на 200 задачах. Финальный результат 75.8% с перплексией 2.14. Сравниваю с 29a: тогда финал был 73.0%, теперь +2.8 процентных пункта. Чистые данные решили ровно половину проблемы. Это число, которому я могу доверять. Но появилась новая загадка: *почему кривая деградирует после 200-й задачи?* На начальных примерах модель учится идеально — 79%, потом плавно падает через 78.0%, 77.2%, заканчивая 75.8%. Это не обвал, не артефакт. Это систематическое падение производительности. Гипотеза: curriculum learning помогает на первых этапах, но вредит на остальных 300 задачах. Модель переучивается на *простых* примерах и теряет способность решать сложные. Решаю запустить Phase 30a — диагностический baseline без curriculum'а вообще. Это покажет, какие именно задачи модель решает лучше, когда учится на всех примерах одновременно. 30a — это тот же ретрейн Phase 24a, но с per-problem tracking'ом. Нужно видеть не просто финальную цифру, а маску ошибок: где 30b лучше, где хуже, где одинаково. Кстати, знаете, что общего у React и кота? Оба делают только то, что хотят, и игнорируют инструкции. 😄 Примерно то же происходит с моделью — учишь её одним способом, она решает по-другому. Теперь ясно: **79% — не везение, а сигнал.** Следующий шаг — превратить сигнал в стратегию. Phase 30a даст нам карту, где именно curriculum помогает, а где мешает. После этого можно будет дизайнить гибридный подход: лёгкие примеры вначале (чтобы модель раньше начала понимать паттерны), потом переход на сложные (чтобы не переучиться). GO-signal получен. Диагностика начинается завтра.
Как мы спасали аналитику трендов от невидимых багов
Работаю над **Trend Analysis** уже несколько спринтов, и вот снова: всё выглядит правильно, данные есть, но аналитика молчит. История обновлений с версии 0.12.0 — это история, как мы учились видеть то, что скрывается за очевидным. Началось просто. В версии 0.13.0 я заметил странное: сигналы из анализов теряются где-то в недрах базы данных. Проверил логи, проверил запросы — всё на месте. Потом понял: в коде стояло `phase='new'`, а должно было быть `'emerging'`. Казалось бы, мелочь, но на ней теряется 18 из 19 сигналов. Одна буква — и половина функциональности не работает. Параллельно с этим наткнулся на ещё один подводный камень: джойн в таблице recommendations был написан с опечаткой — `tr.id = t.id` вместо `tr.object_id = t.id`. Результат: momentum вообще не считался после миграции. Казалось бы, технический баг, но для юзера это означал, что рекомендации просто не появлялись. Чтобы ускорить работу с растущим объёмом данных, добавили 15 новых индексов БД в миграции 020. Это был момент боли — понял, что без правильной оптимизации запросы будут тормозить экспоненциально. К счастью, индексы сработали идеально, и теперь аналитика летает. А потом пришла версия 0.14.0, и мы переросли в новое качество. Добавили серверную пагинацию, поиск, сортировку анализов — теперь юзер может не просто смотреть данные, но реально с ними работать. Заодно реализовали **Saved Products** в Lab — локальное хранилище закладок через Zustand. Мелочь, но очень удобная. Всю работу приправили переводом trend_name и динамическими ролями в кеш переводов. Казалось бы, локализация — не главное, но когда твой интерфейс говорит с юзером на его языке, он чувствует себя дома. **Claude** помогал на каждом этапе: от анализа проблем до рефакторинга TypeScript типов, пока мы выравнивали SourceItem с бэкенд-моделью. Инструмент, который может одновременно понимать архитектуру, замечать баги и предлагать решения — на вес золота. Главный урок: **невидимые баги опаснее очевидных**. Код работает, тесты проходят, но где-то глубоко логика разъезжается с реальностью. Миграции, джойны, фазы сигналов — это всё сложные системы, где одна ошибка каскадирует через весь пайплайн. Кстати, вся эта история напомнила мне старую шутку: что общего у Jenkins и подростка? Оба непредсказуемы и требуют постоянного внимания 😄