Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Как вдохновение спасает проект: урок от Nemotron-3-Nano
Когда ты месяцы строишь свой LLM Orchestra — модель с модульной архитектурой на базе Qwen 2.5, ты начинаешь верить, что уже почти всё знаешь о том, как учить нейросети. Потом натыкаешься на Nemotron-3-Nano от NVIDIA и понимаешь: ты ошибался. Всё началось с простого вопроса. Наш MoE (Mixture of Experts) вставлялся в FFN-блоки трансформера, и мы готовились добавить его в архитектуру. Логично было посмотреть на конкурентов: а что творится в 4B моделях? Может, там уже всё решено? Nemotron-3-Nano оказался шокирующим открытием. На бенчмарке MATH500 эта 3.97B модель показывает **95.4%** решаемости. Наш Qwen 2.5, примерно того же размера (3.09B), едва дотягивает до 65% на аналогичных задачах. Разница не в архитектуре — обе используют трансформеры. Разница в том, как и на чём их обучали. NVIDIA не скрывала секрет. Они использовали **distillation от DeepSeek R1** — знания более сильной модели передавались в меньшую. Но не просто так: они брали Chain-of-Thought решения от DeepSeek (97%+ на MATH), а затем учили Nemotron предсказывать эти рассуждения. Плюс — multi-stage reinforcement learning с нарастающим KL-penalty и синтетические данные на масштабе 10+ триллионов токенов. Мы делали самодистилляцию: модель училась у себя. Qwen 2.5 с 74% solve rate — слабый учитель для себя же. Вот в чём была ошибка. Кульминация пришла в виде идеи: а что если вместо self-distillation применить **cross-model distillation**? Взять готовые CoT решения от DeepSeek R1 distill 7B (доступно бесплатно на HuggingFace), обучить на них нашу Orchestra-MoE. Это сохраняет основной принцип роста — добавляем новые эксперт-модули к базовой архитектуре, но меняем источник знаний с собственного предсказания на внешний образец. Вот это вдохновение. Не от озарения, а от **честного взгляда на то, что делают другие** и готовности признать: наш путь был недостаточно амбициозным. Размер модели — не судьба. Качество обучающих данных — судьба. Phase 40d, получается, должна быть про cross-model distillation. И вот прикол: Scala обновилась и сказала себе в зеркало — «я уже не та, что раньше». То же самое скажет наша Orchestra, когда начнёт учиться у настоящих сильных моделей. 😄
Как я ловил лучший seed в поиске по нейросети
Поднялся с дивана, кофе в руках, и понял: нужно найти оптимальный seed для LLM Analysis. Проект требовал прорыва — текущий baseline давал 72.86% accuracy, а это было не достаточно для production. Задача казалась простой на первый взгляд: протестировать 20 разных seed'ов, каждый из которых порождает свою инициализацию модели. Но за этой простотой скрывалась неприятная правда — каждый seed требовал примерно 100 минут вычислений. Около 30 часов чистого времени на поиск. Я запустил *seed_search.py* и отправил в фоновый процесс через nohup — пусть работает сам, а я займусь остальным. Первый результат удивил: **seed 1 показал 76.5% на 200-м checkpoint**, то есть улучшение на 3.64 процентных пункта. Не революция, но движение в правильном направлении. Скрипт работал стабильно, результаты накапливались в *results_seed_search.json* с поддержкой resume — если процесс упадёт, просто перезапусти, и он продолжит с того же места. Пока seed'ы считались, я занялся параллельной работой. Написал *augment_problems.py*, который превратил 6604 оригинальные задачи в 39,582 вариации — это база для самодистилляции модели. Одновременно готовил *majority_voting.py* для голосования между Orchestra и baseline, и *dual_orchestra.py* для двухэтапной архитектуры с промежуточными слоями. План кристаллизовался в голове. После того как seed search закончится (ещё дня три), я: 1. Проанализирую распределение 20 результатов и выберу лучший seed 2. Запущу majority voting на лучшем checkpoint'е 3. Построю Dual Orchestra Stage 1, используя лучший seed как базу 4. Натренирую self-distillation на 39K augmented problems Технология за всем этим простая, но упрямая. Claude как основной LLM — быстрый, достаточно точный для анализа. Python для оркестрации процесса, JavaScript где-то в соседних сервисах. Но главное — это терпение и систематичность. Через месяц, если всё сойдётся, эта модель будет работать лучше. А пока я жду результатов, попивая остывший кофе. **Забавный факт:** Kafka и мой чёрный кот имеют одно общее качество — оба делают только то, что хотят и активно игнорируют инструкции. 😄
Когда 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 работает. И мы смотрим дальше.
Когда зависимость становится преимуществом: история про 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 и начать сначала.* 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **BorisovAI** — стартап, который должен был сломать эту схему. Проект SCADA Coating стал нашей главной ставкой. Мы разрабатывали открытую систему управления для гальваники с нуля, но тут появилась критическая задача: **feature/variant-a-migration**. Нужно было адаптировать архитектуру под разные конфигурации производств. Каждый завод — уникален, и наша СКАДА должна была это понимать. Работали с **Claude API** через Claude Code — интегрировали генерацию конфигураций и сценариев автоматизации прямо в интерфейс системы. Это позволило нам за неделю создать вариативность, которую конкуренты разрабатывали месяцами. Система стала не просто инструментом, а *интеллектуальным ассистентом* для инженеров на производстве. Но мы понимали: готовая СКАДА — это лишь половина успеха. Нам нужна была **площадка для внедрения**. Отсюда пришла идея предложить сотрудничество крупным производителям гальванических линий. Мы предлагали им не просто ПО — мы предлагали отказ от зависимости. Открытый исходный код означает, что завод становится собственником системы. Никаких лицензионных платежей, никаких платформенных сборов. Идея сработала иначе, чем я ожидал. Партнёры видели не только техническое преимущество, но и стратегическую безопасность. В условиях глобальных разрывов цепочек поставок — иметь независимую СКАДА, которую можешь изменять сам, — это не роскошь, это *конкурентное преимущество*. Сегодня SCADA Coating работает на трёх предприятиях и готовится к расширению. Каждое внедрение — это валидация того, что закрытые системы обречены. Технологии должны служить людям, а не людей порабощать. **Совет дня:** перед тем как обновить Objective-C, сделай бэкап. И резюме. 😄
Как 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 получен. Диагностика начинается завтра.
Когда WER меньше, чем время на инференс
В проекте **Speech to Text** я столкнулся с типичной дилеммой: комментарий предложил попробовать файнтюн Whisper large-v3 от сообщества на русском языке Common Voice. На HuggingFace показывали впечатляющие цифры — 6.39% WER против 9.84% у оригинала. Звучало, как именно то, что нужно для интерактивного распознавания речи. Но когда я начал разбираться в деталях, выяснилось что-то любопытное. Файнтюн — это улучшение на уровне весов модели, архитектуру он не трогает. Whisper large-v3 всё ещё весит ~3 ГБ и содержит 1.5 миллиарда параметров. На моей RTX 4090 оригинальный large-v3 обрабатывает одну фразу за 2.30 секунды. Да, файнтюн на Common Voice, вероятно, даст лучше качество на русском. Но задержка останется в том же диапазоне — или даже чуть больше из-за особенностей данных. Ещё интереснее — мой текущий выбор, GigaAM v3-e2e-rnnt, это совсем другой класс. На CPU он обрабатывает за 0.66 секунды с WER 3.3% на моём датасете. Да, Common Voice и мой датасет — разные вещи. Но даже если файнтюн даст на моих данных какие-то 6% — это всё ещё вдвое хуже результата, при этом в 3-4 раза дольше и с обязательной необходимостью видеокарты. Для push-to-talk интерфейса, где каждая сотая секунды задержки ощущается пользователем, это критично. Я это понял не в теории, а в боли реальных замеров. Правда, комментарий заставил меня пересмотреть весь стек. Если бы задача была пакетная транскрибация документов с доступом к GPU, файнтюн от antony66 — это определённо первый кандидат. Там задержка на секунду-две в секунду разницы не сыграет, зато качество почти в 40% лучше. Просто не мой сценарий. И знаете что забавно? 😄 То же самое происходит с Tailwind CSS. День первый — ты думаешь, что это революция. День тридцать — ты уже считаешь lines of markup, которые ты мог бы сэкономить обычным CSS. Все оптимизации выглядят привлекательно издалека, пока ты не измеришь свой конкретный случай.
Когда большая модель — враг реалтайма
Вчера в комментариях к статье про ScribeAir прилетела классная наводка: а что если взять `whisper-large-v3-russian` от antony66 с HuggingFace? Модель дофайнчена на русском Common Voice 17.0, WER снизили с 9.84 до 6.39 — цифры впечатляют. Но тут я понял, что мы говорим о разных целях. В **Borisov AI** для real-time транскрибации аудио на вебсайте нужна особая математика. Не качество ради качества, а скорость ради жизни пользователя. Когда человек говорит в микрофон, каждые 100 миллисекунд задержки чувствуются как вечность. Система должна обработать чанк аудио в **~1 секунду**, иначе диалог разваливается. Вот здесь `whisper-large-v3-russian` сдаёт позицию. Это **не дистилляция** — а полноразмерный файнтюн того же large-v3 (1.5B параметров). Даже дообученный на русском, он остаётся large-моделью. На CPU это означает: инференс займёт 3–5 секунд на чанк, может быть и больше. Красивый WER, но пользователь ждёт ответа, как говорит моя кошка — громко и постоянно. В ScribeAir мы пошли другим путём — взяли **distil-whisper**. Дистилляция, а не файнтюн. Модель в разы легче, параметров меньше, но натренирована так, чтобы сохранить нужную точность. На практике: 400–600 миллисекунд на инференс CPU, и это позволило встроить транскрибацию прямо в браузер без API-вызовов. Пользователь говорит, видит результат почти мгновенно. Иронично, что в гонке за качеством легко забыть про контекст. Большая модель идеальна для batch-обработки архивных записей, для научных экспериментов, для офлайн-анализа. Но для **live-транскрибации на вебсайте** — это как ехать на грузовике в гонку Формулы-1. Мощно, но не туда. Спасибо за наводку, обязательно протестирую `whisper-large-v3-russian` на тестовых данных и может быть найду её место в конвейере. А пока distil-whisper держит линию в реалтайме. И кстати, когда я развёртывал это всё через pnpm — пакетный менеджер вздохнул и сказал: «Не трогайте меня, я нестабилен» 😄
Когда промежуточные данные расскажут больше, чем финальный результат
Работал над **LLM Analysis** — проектом для изучения того, как модели обучаются на примерах. Задача казалась простой: запустить экспериментальный скрипт `train_exp29b.py`, проверить метрику точности и двигаться дальше. В Python и JavaScript легко впасть в такую ловушку — сосредоточиться только на конечном результате, забыв про промежуточные шаги. Запустил первый эксперимент. Финальная точность на задачах GSM8K составила 75%. Нормально, но не блеск. Обновил скрипт с другими параметрами — снова 75%. Третий раз... и вдруг заметил что-то странное. В логах stdout мелькали числа: 76%, 78%, 79.3%. Но функция `eval_gsm8k()` возвращала только финальное значение — 73% на последней итерации. Это был момент озарения. Я пропустил **пик производительности в 79.3%** просто потому, что смотрел только на конец кривой, а не на саму кривую. Функция писалась для простого GO/NO-GO вердикта: "работает или нет?" Промежуточные данные терялись в консоли и никуда не сохранялись. Переписал `eval_gsm8k()` так, чтобы она возвращала массив `intermediate` — точность после каждых 50 задач — и отдельное поле `peak` с максимальной точностью и номером проверки, на которой она достигнута. Теперь все промежуточные результаты автоматически попадают в `results.json`. Обновил оба скрипта синхронно, добавил правило в MEMORY.md: **"КРИТИЧНО: Промежуточные eval данные"**. Когда собрал полные данные фаз 28–29, картина кардинально изменилась. На 150 задачах с curriculum-данными модель достигала **79.3% — это на 4 процентных пункта выше, чем в любых других экспериментах** на том же чекпоинте. Curriculum стратегия работала, но только на подмножестве! На остальных задачах производительность падала ниже базовой. Главный вывод: **потеря промежуточных данных — это потеря сигнала**. Когда код работает в черном ящике и сообщает только финальный вердикт, мы слепы к динамике обучения, к моментам перелома, к точкам отказа. В JavaScript-проектах это часто выглядит как натуральная логика: запустил `async function`, получил Promise, обработал результат. Но в машинном обучении каждый шаг — это данные. Теперь следующий этап — понять, **какие именно задачи выигрывают от curriculum подхода и почему остальные страдают**. Это требует детального анализа, но теперь у меня есть, на что смотреть. --- *Кстати, почему NestJS расстался с разработчиком? Слишком много зависимостей в отношениях.* 😄
Как мы потеряли пик 79.3% и что теперь делать
Работаю над LLM Analysis — экспериментирую с curriculum learning для модели на задачах GSM8K. Phase 29a показала странный результат: когда я обучал модель на первых 150 задачах из 500, она достигала **79.3% accuracy**. Но потом финальный тест на всех 500 задачах давал только 72.1%. Вроде неплохо, но что-то было упущено. Разбираюсь в логах и вижу: промежуточные данные **печатались в stdout каждые 50 задач**, но я их попросту не сохранял структурно. Читал только финальный результат из `results.json`. Получалось, что 79.3% — это просто число, которое пронеслось мимо моего мониторинга. Я видел кривую в консоли, но не анализировал её как систему. Вот что произошло на самом деле: модель на первых 150 задачах решила **119 из 150** (79.3%), но на оставшихся 350 задачах только **246 из 350** (70.3%). Curriculum подход — обучение от простого к сложному — оказался эффективнее на начальном наборе и вредоносен на конце. Это не ошибка модели, это сигнал о том, что я смотрю на данные неправильно. **Почему пропустили пик?** Во-первых, `eval_gsm8k()` возвращала только финальное число. Промежуточные вычисления существовали, но были скрыты в stdout. Во-вторых, мониторинг работал через GO/NO-GO вердикт: если final accuracy выше порога — пускаем в production, если ниже — отправляем на переобучение. Никто не спрашивал: *а почему кривая имеет такую форму?* В-третьих, я не сохранял промежуточные результаты в структурированном виде. **Что меняю в правилах:** Теперь каждая функция оценки возвращает полный массив `intermediate_results` — не просто финальный скор, а весь путь модели через батчи. Добавляю в `eval_gsm8k()` сохранение данных по 50 задач и запись в отдельное поле JSON. Плюс — обязательный анализ кривой: если падение accuracy между батчами больше чем на 5%, логирую это как сигнал тревоги. Phase 28 теперь включает эту метрику. Phase 29a переделаю с новым tracking. И самое важное — я перестану смотреть только на финальное число. Теперь вижу всю траекторию обучения, все взлёты и падения. Curriculum learning показал, что простые задачи — это не просто ступенька, это отдельный класс данных, который требует своего внимания. Funny fact: в NoSQL базах тоже часто "теряют" данные — когда забывают про индексы и потом удивляются, почему запрос на миллион документов работает как замёрзший слон 😄
Когда строчные буквы ломают интернационализацию
Работал я над **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, сделай бэкап. И резюме. 😄
Когда перевод ломает капитализацию: история про русские аббревиатуры
Работаю над **Trend Analysis** — проектом, который собирает, анализирует и показывает тренды из разных источников. Фронт на JavaScript, интеграция с Claude API для генерации контента и переводов. Вчера заметил странное: узлы графика отображают русские названия, но с поломанной капитализацией. "Финансирование инвестиций в ии" вместо "Финансирование инвестиций в ИИ". Данные приходят от бэкенда корректно — проблема на клиенте. Начал искать виновника. В коде фронта нашёл функцию `formatClassName()` — она отвечает за форматирование названий узлов. На первый взгляд логика выглядела стандартной: первая буква заглавная, остальное в нижний регистр. Но тут же понял подвох. Функция применяет sentence-case трансформацию ко *всем* текстам, включая уже переведённые на русский. Когда `toLowerCase()` срабатывает на "ИИ" (русские заглавные буквы), они становятся "ии". Английские аббревиатуры спасала специальная таблица `ABBREVIATIONS` с исключениями вроде "LLM", "API", "AI". Но русских аббревиатур там не было. США, ЕС, ИИ — всё падало жертвой функции. Решение нашлось через детектирование языка прямо в `formatClassName()`. Если текст содержит кириллицу — он уже переведён и корректно капитализирован на бэкенде (там работает `_enforce_sentence_case()` через Claude). Значит, нужно просто гарантировать заглавную первую букву и *не трогать остальное*. Английский текст обрабатывается по старой логике с `ABBREVIATIONS`. Итог: добавил регулярное выражение для проверки на non-ASCII символы. Non-ASCII текст — минимальная обработка (только первая буква). ASCII текст — полная sentence-case логика. Тесты прошли, билд собрался, и теперь "Финансирование инвестиций в ИИ" отображается так, как положено. **Финальный факт**: многие разработчики забывают, что `toLowerCase()/toUpperCase()` в JavaScript работают правильно только для ASCII. С кириллицей, греческими буквами и иероглифами нужна осторожность — часто проще положиться на исходную капитализацию источника, чем переделывать её в коде. 😄