Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда модель учит саму себя (и роняет цифры)
Работал над 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 уровня 😄
Пять фильтров, которые спасают тренды от мусора
Работаю над системой анализа трендов, и вот столкнулся с классической проблемой: алгоритм извлекает тренды из событий, но половина из них — полная ерунда. Тренд про нефть, апельсины и страховку в одной кучке. Код всё правильно считал, данные прошли все проверки, а результат — помойка. Начал добавлять фильтры. Первый — **проверка когерентности эмбеддингов**. Идея простая: если события в тренде топически не связаны, их эмбеддинги будут далеко друг от друга. Задал порог 0,35 на косинусное сходство. Тестировал на 84 старых трендах — алгоритм корректно отклонил все 56 мусорных. Остальные 28 прошли, потому что там правда были связанные события. Второй шаг — добавил **relевance score прямо в события тренда**. Раньше я просто считал, что событие относится к тренду с уверенностью 1.0. Теперь считаю косинус до центроида кластера. Неожиданный эффект: стало видно, какие события в тренде настоящие якоря, а какие — на грани выпадения. Третий — **чёрный список сущностей**. Оказалось, что при связывании новых событий с существующими трендами система матчит их на "Россия", "Китай", "ИИ" — настолько общие сущности, что они ничего не говорят. Добавил фильтр: если матч только на blacklist-сущности, событие не цепляется к тренду. Шум упал заметно. Четвёртый — **порог уверенности LLM >= 0.5**. Когда модель извлекает тренд, она даёт скор. Если скор низкий, я просто отбрасываю кандидата до материализации. Фильтр дешёвый, срабатывает до дорогих операций. И наконец, пятый — **второй проход LLM**. Это был прорыв. На каждого кандидата тренда LLM отвечает на один вопрос: "Это действительно тренд или просто ситуация/процесс?" Дешево — всего 1-2 кандидата на кластер, но ловит ложные срабатывания, которые прошли все code-фильтры. Вместе эти пять ворот резко подняли качество. Не идеально, но уже можно работать. История же в том, что когда ты полагаешься только на код и статистику, спотыкаешься об edge-cases, которые люди видят с первого взгляда. 😄
Молчаливый краш каждые восемь минут: как мы искали баг в конвейере тренд-анализа
Работаю над **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 имеет цену 😄
Как HDBSCAN раскрыл истинное лицо трендов
Три месяца назад в проекте Trend Analisis возникла беда: система обозвала *трендом* любое, даже совершенно рандомное событие. Мы парили события в эмбеддингах, выуживали несколько похожих друг на друга и думали, что открыли закономерность. На самом деле собирали мусор. Первое время казалось, что проблема в нейросетях или в пороговых значениях для фильтрации. Раскидывали параметры кластеризации, ловили иголку в стоге сена. Потом дошло: проблема не в инструментах, а в самой логике. Мы искали тренд в одном событии вместо того, чтобы смотреть на *паттерны внутри кластера*. Развернули HDBSCAN и переписали всю pipeline с нуля. Теперь тренд — это не одно событие, а структурированный паттерн, извлечённый из группы связанных событий. В каждый кластер добавили шаг `_extract_trends_from_cluster()`, который просит LLM найти 0–3 реальных структурных закономерности с доказательствами: какие события их подтверждают, в какую сторону идёт изменение, кто задействован, какие метрики вообще говорят. Потом добавили **domain_tags** — 3–5 широких категорий для каждого события. Звучит небольшой деталью, но эта штука стала мостом между источниками данных. Теперь события из гита, Слака и журналов понимают друг друга через общие темы. И главное — это не требует дополнительных вызовов LLM: теги шли вместе с экстракцией паттернов. Пришлось перестраивать матчинг. Раньше пробовали простое совпадение по сущностям — полный провал. Теперь используем гибридный подход: 55% веса на эмбеддинг-похожесть, остальное на пересечение тегов и сущностей. Миграция базы добавила три новых таблицы для хранения связей события-тренд, и дедупликация трендов с порогом перекрытия 0.40. На 12GB сервере обработали 5 кластеров, вытащили 14 валидных трендов и повязали к ним 56 событий. Это не мировая цифра, но тренды стали реальными паттернами, а не сборищем разнополюсных событий. Одна смешная деталь — в пики нагрузки Ollama работает на два порта одновременно, всё синхронизируется мьютексом и гробит RAM нещадно. Поэтому пришлось временно отключить переклассификацию событий после дедупликации, иначе сервер шёл в отказ. TensorFlow, кстати, здесь не причём — но принцип тот же: решение проблемы, о которой ты не знал, способом, который никто до конца не понимает 😄
Как вдохновение спасает проект: урок от 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, когда начнёт учиться у настоящих сильных моделей. 😄
Как мы спасали открытую СКАДА от закрытых систем
Когда я уходил из Тагата, где два года разрабатывал системы автоматизации для гальванических линий, то понимал одно: отрасль задыхается от монополии. Заводы привязаны к проприетарному ПО, а любое обновление стоит как небольшой станок. Я собрал команду и запустил **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, сделай бэкап. И резюме. 😄
Когда 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 базах тоже часто "теряют" данные — когда забывают про индексы и потом удивляются, почему запрос на миллион документов работает как замёрзший слон 😄