Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда модель учит саму себя (и роняет цифры)
Работал над LLM Analisis — проектом, где модель решает math word problems на GSM8K датасете. Казалось, 80% accuracy — потолок? Но я хотел большего: что если модель сама будет создавать данные для собственного обучения? Начал с самоаугментации. Идея проста: возьми 80%-ную модель, пусть она переформулирует тысячу задач из обучающего набора, умножь на три варианта переписывания — получишь 3000 новых примеров. Модель обучится на собственных данных и поднимется выше. Правда? **Неправда.** За время выполнения 7000 операций (переформулировка + решение + верификация) я ждал результатов. И получил -3.5pp. Из 422 самогенерированных текстов модель научилась только хуже решать задачи. Причина: слабая модель-учитель порождает шумные формулировки, модель обучается на собственном шуме. Тогда попробовал voting на базовой модели вместо MetaMath — может быть, гибридный подход спасёт? Запустил эксперимент: **83.0%**, а базовый voting показывает 84.0%. Та же ошибка, что и на Phase 47 VF r16 — voting не спасает. Greedy при этом выдал рекорд: **80.0%** вместо 77.0%. Осознание пришло резко: **я усиливал не то**. Проблема не в модели — ей не нужны новые нейроны, она уже знает 95.5% ответов. Ей нужна другая *качество* данных, не количество. Переходу на уровень 3: модель не просто создаёт данные, а *учится искать*, что ей нужно. Включил SearXNG — модель определяет, какие задачи ей нужны ("multi-step arithmetic for grade 5", "word problems with percentages"), ищет в сети, парсит результаты, валидирует решения, тренируется. Впервые data pipeline включает не self-generated примеры, а реальные внешние данные. Это заняло 10 минут чистого Python без GPU. Потом 30-60 минут обучения. Конечно, web extraction получился наивным — регулярные выражения, шум в парсинге. Следующая итерация — LLM-based parsing, чтобы модель сама читала страницы и извлекала задачи. Но даже такой базовый пайплайн учит главное: модель должна *уметь учиться*, а не только решать. И знаете, разработчик на Stack Overflow уровня 😄
Молчаливый краш каждые восемь минут: как мы искали баг в конвейере тренд-анализа
Работаю над **Trend Analysis** — системой, которая вытаскивает из кластеров событий настоящие тренды. Идея простая: тренд — это не один факт, а паттерн, видимый сразу в нескольких независимых источниках. Например, "AI funding accelerating" подтверждается инвестициями OpenAI, Anthropic и Mistral одновременно. Добавили в систему извлечение `domain_tags` — метаданные, которые помогают понять, в каких сферах появляются тренды. Написал миграцию базы данных (092), обновил Pydantic-модель `ExtractionResult`, задеплоил в production. Всё выглядело хорошо. Потом начался ад. Pipeline рестартовался сам по себе каждые 8–10 минут. Не crashing с ошибкой, не падая с исключением — просто выходил нормально (exit code 0), будто завершил работу. PM2 считал это штатным поведением, счётчик restarts поднялся до 450. Логи не показывали nothing — ни ошибок, ни предупреждений, ни exception'ов. Я начал добавлять debug-маркеры на критических этапах. "PHASE_DEBUG" перед главной стадией extraction. Ждал цикла за циклом. Маркер никогда не появлялся. Потом заметил: логи говорят "Fact extraction done", потом сразу — крах. Между фазой extraction и следующей стадией что-то умирало молча. Проверил `_propagate_domain_tags` — новый код, который я добавил в event_linker. Он вызывается после commit. Обёрнут в try/except. Не должно быть проблем. Но потом я посмотрел на главный `asyncio.gather()` в функции `main()`. Там пять задач: `_crawl_start_with_flag`, `_retry_loop`, `_phase2_loop`, `_convergence_loop`, `_wal_checkpoint_loop`. И `gather()` **без флага `return_exceptions=True`**. Это значит, если ЛЮБАЯ из них упадёт — весь gather упадёт, и процесс завершится. Но логов нет... А потом вспомнил: я использую `asyncio.create_task()` для запуска `_extract_facts_pipeline` ВНУТРИ `crawl_once()`. Это отдельная задача, не добавленная в основной gather. Если она поднимает exception — в Python 3.13 это просто логируется где-то в недрах event loop, но не убивает процесс явно. Процесс выходит чисто, потому что задача закончилась (с ошибкой). Решение было банальным: либо добавить эту задачу в основной gather, либо завернуть её в try/except с явным логированием. Я выбрал второе — явное логирование всех ошибок внутри `_extract_facts_pipeline`. После fix pipeline работал стабильно. Uptime перевалил за 30 минут. Никаких рестартов. **Урок:** когда Python молчит, ищи asyncio. Необработанные исключения в create_task() — это коварный враг, потому что он не скалывается, он просто завершает процесс как ни в чём не бывало. 😄
Асинхронный краш, который молча убивал процесс
В проекте Bot Social Publisher я столкнулся с багом, который преподал мне урок о том, как Python молча убивает асинхронные задачи. Всё началось с того, что процесс падал каждые 8–10 минут. Exit code 0, как будто ничего не произошло. PM2 думал, что это нормальный цикл, и перезапускал всё заново. В логах структурного ничего не было — просто обрыв на середине слова. Я начал добавлять debug-маркеры в критические точки: перед extract, после linking, перед formation. Маркеры появлялись до определённого момента, а потом — тишина. Это означало только одно: краш происходит в асинхронном task'е, который создан через `asyncio.create_task()`, но не добавлен в основное `asyncio.gather()`. Нашёл проблему в `_extract_facts_pipeline` — это была задача, создаваемая внутри `crawl_once()`. Если в ней поднимался exception, он просто испарялся. Основной event loop об этом не знал, потому что task не был часть собранной группы. Python молча падает в таких случаях — exception в orphaned task'е не выводится в stderr. Решение было простым, но требовало переделки архитектуры: все критические задачи теперь либо ловят exception вручную и логируют его, либо зарегистрированы в основном `gather()`. Вместо: ```python asyncio.create_task(self._extract_facts_pipeline()) ``` Перешёл на явный контроль — task регистрируется и отслеживается. Дальше обнаружилась конкурентная проблема: `_extract_facts_pipeline` и translation loop одновременно пытались использовать один инстанс Ollama на одном порту. Dual-port routing, который я писал, не работал как ожидалось. Переделал маршрутизацию — теперь потребители разнесены по портам явно, через конфиг. После этого цикл прошёл 5+ минут без крахов. Рестартов всё ещё было 450 в логе, но это уже были контролируемые перезагрузки, а не молчаливые падения. Вывод прост: асинхронная архитектура требует такого же внимания к обработке ошибок, как синхронный код, но Python здесь хитрее. Orphaned task'и падают молча, и если ты не проверяешь логи на предмет неполных маркеров, потратишь дни на отладку фантомного бага. TypeScript в этом плане честнее — там ты не можешь просто так создать task и забыть про него, система будет ругаться. 😄
Замкнутый цикл: как модель сама себя обучает
Работал над **LLM Analisis** — проектом анализа математических рассуждений. Взял готовую модель на базе Claude и столкнулся с проблемой: обучающий датасет был исчерпан, а качество на тестах застыло на 78%. Нужно было что-то менять. Первый импульс — скачать MetaMathQA, больший датасет из нескольких источников. Но тут осознал: зачем искать внешние данные, если модель может их *создавать*? Идея простая, но изящная: взял существующий датасет GSM8K (7473 задачи на арифметику) и запустил самоаугментацию. Модель переформулирует каждую задачу тремя способами — получается 22 тысячи вариантов. Затем добавляю обратное рассуждение: если модель знает ответ, она может восстановить условие задачи с другими числами. Это даёт ещё 7000 новых примеров. Финальный трюк — FOBAR (Fixing Out-of-range Bad Answers): беру задачу, меняю числа так, чтобы сломать неправильные паттерны рассуждения. В итоге из 7473 исходных задач получилось примерно 36 тысяч разнообразных примеров. Замкнутый цикл: модель не скачивает, не ждёт аннотаторов — она *сама генерирует* себе обучающие данные. Запустил тренировку на полной MetaMathQA (395K примеров, не только GSM) с 10 тысячами шагов вместо 3 тысяч. Параллельно добавил voting: во время теста модель решает задачу восемь раз независимо, и берётся ответ, выбранный большинством. Это снижает влияние случайных ошибок. Результат: качество прыгнуло с 78% в режиме greedy decoding до ожидаемых 80-82% на одном проходе, а с voting обещает 88-91%. Для математических моделей это существенно. Самое интересное в этом подходе — масштабируемость. Когда SearXNG агент всё же поднимется, цикл усложнится: модель будет сама искать задачи на web, парсить их, валидировать и добавлять в тренировочный набор. Получится бесконечный конвейер: ошибка → диагностика → поиск примеров → переобучение → улучшение. Без человека в цикле. Знаешь, это напоминает Laravel: день 1 — восторг от элегантной архитектуры, день 30 — понимаешь, что elegance имеет цену 😄
PM2 под root сломал деплой на 502
Проект **Borisov AI** — это сайт с фронтенд-приложением и Strapi API. Всё работало, пока я не начал менять логику запуска процессов в CI/CD. Ветка `fix/ci-pm2-selective-delete` должна была переместить управление PM2 с root-овского сервера на `gitlab-runner`, но получилось нечто неожиданное. Утром проверяю **https://borisovai.tech** — оба сервиса отдают **502 Bad Gateway**. Reverse proxy (Traefik) жив и здоров, но PM2-процессы на портах 4001 и 4002 не отвечают. Заглядываю в PM2 Web UI на сервере — видно, что запущен только `scadacoating`, а `frontend` и `strapi` вообще отсутствуют в списке. Команда `pm2 list` под gitlab-runner показывает, что процессы были попытаны запустить, но упали с ошибками. Frontend кричит "Failed to start server", Strapi жалуется, что порт 4002 уже занят. Вот оно что. Углубляюсь дальше. Проверяю, что слушает порты 4001 и 4002 — и нахожу **два PM2 daemon'а**: один под root (запущен давно), второй под gitlab-runner. Root-овый PM2 ещё держит старые процессы frontend и strapi. Когда CI деплоит под `gitlab-runner`, новые процессы не могут захватить порты — они заняты. Оказывается, раньше всё запускалось под root, и никто это не трогал. Когда я добавил задачу в CI переместить на gitlab-runner, произошла коллизия: старые процессы продолжали висеть, новые не могли стартовать, и сайт упал. Решение простое, но требует аккуратности. Останавливаю frontend и strapi в root PM2, меняю права на директорию `/var/www/borisovai-site` на `gitlab-runner`, перезапускаю процессы. На этот раз они поднялись чистенько — 0 рестартов, порты свободны, сайт дышит. **Главный вывод:** когда меняешь пользователя, под которым запускается сервис, нужно убедиться, что старый процесс полностью мёртв. Иначе порты останутся заняты и новый деплой будет биться в стену. PM2 отлично работает, пока не сталкиваются два инстанса daemon'а с одинаковыми приложениями. Насчёт Docker — как первая любовь: никогда не забудешь, но возвращаться не стоит 😄
Как вдохновение спасает проект: урок от 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. Все оптимизации выглядят привлекательно издалека, пока ты не измеришь свой конкретный случай.