Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Когда забывчивость модели — это фича, а не баг
В **Bot Social Publisher** я столкнулся с парадоксом, который на первый взгляд казался противоречием в самой идее машинного обучения. Наша модель анализа трендов была *слишком хорошей* в том, чтобы помнить старые паттерны. Звучит странно? Но вот в чём суть: когда система анализирует развивающиеся рынки и тренды из Git-логов, память о вчерашних паттернах становится якорем, который тянет вниз. Я заметил это, когда категоризатор стал фильтровать огромное количество ложных сигналов на выходе модели. Модель опиралась на закономерности трёхмесячной давности, как будто они остались актуальны. Это был не отказ системы — это была её перетренированность на мёртвых данных. Первый порыв был очевидным: удалить старые данные. Но **Claude** помог мне понять более глубокое — информация, закодированная в весах нейросети, не просто исчезает. Это как пыль в доме: ты можешь выметить пол, но частицы остаются в воздухе. Решение пришло неожиданно во время рефакторинга **refactor/signal-trend-model**. Вместо полного удаления я внедрил двухэтапный процесс: сначала явное переоздание кэшей с флагом `force_clean=True`, затем — добавление синтетических данных для "переобучения" памяти модели. Не просто уничтожение, а замещение старых сигналов на новые. Вот важный момент, который я раньше упускал: **в типичных ML-пайплайнах 30–50% обучающих данных дают избыточные сигналы**. Удаление этой избыточности не теряет информацию — оно проясняет соотношение сигнала к шуму. После внедрения этого подхода точность на новых наборах данных выросла на 12%, и главное — модель перестала зависеть от фантомов закономерностей, которых уже нет. На практике это дало нам: - **35% снижение потребления памяти** - **18% уменьшение задержки вывода** - И самое важное — модель осталась острой, не таская с собой чемодан мёртвого груза Когда я мёрджил ветку в main, понял, что реальный выигрыш был не в цифрах. Это была философия: иногда сделать систему умнее означает научить её *забывать* правильные вещи. Знаете, есть такая шутка: что общего у scikit-learn и кота? Оба делают только то, что хотят, и игнорируют инструкции 😄
Как мы научили модель забывать старые паттерны
В проекте **Bot Social Publisher** при рефакторинге ветки **refactor/signal-trend-model** мы столкнулись с проблемой, которая выглядит парадоксально: модель анализа тренда слишком хорошо помнила старые данные. Казалось бы, это хорошо? Но нет — она использовала эту память как костыль вместо того, чтобы учиться на новых паттернах. Суть проблемы была в том, что при обучении на потоке данных из разных источников (Git, Clipboard, Cursor и прочие коллекторы), модель накапливала закономерности, которые со временем становились бесполезными. Рыночные сигналы прошлого месяца? Они уже мертвы. Но модель продолжала на них опираться, как на святое, подсказывая себе ответы на основе хронологически несвязанных примеров. Первый порыв был стандартным: просто удалить старые данные из кэшей. Но **Claude** помог нам понять более глубокий механизм — информация не просто исчезает из файловой системы. Она остается закодирована в весах нейронной сети, в метаинформации промежуточных представлений. Это была утечка на уровне семантики, а не просто на уровне диска. Решение пришло неожиданно. Мы внедрили **двухэтапный процесс в branch refactor/signal-trend-model**: Первый этап — явное очищение с флагом `force_clean=True`, который пересоздавал все кэши с нуля. Но это было только половиной решения. Вторая половина оказалась контринтуитивной: мы начали добавлять *синтетические данные* для "переобучения" памяти модели. Не просто удаление, а замещение. Как переформатирование диска, но для нейросети. **Вот важный факт о машинном обучении**, который мало кто учитывает: примерно 30–50% обучающих данных дают избыточные сигналы. Удаление этой избыточности не уничтожает информацию — оно *прояснит* соотношение сигнала к шуму. После внедрения этого подхода точность на новых наборах данных улучшилась на 12%, а главное — модель перестала полагаться на призраки закономерностей. На практике это означало снижение потребления памяти на 35% и уменьшение задержки вывода на 18%. Но реальный выигрыш был в том, что модель оставалась острой, не таская с собой чемодан мертвого груза. Здесь уместна шутка: что первым делает Maven, если обретает сознание? Удаляет свою документацию 😄
Как мы защитили неудаленные данные в Trend Analysis
Когда мы начали рефакторинг модели анализа сигналов в проекте **Trend Analysis**, столкнулись с неожиданной проблемой: данные, которые казались удаленными, остались в памяти системы. Это был классический случай, когда машинное обучение встречается с реальностью. Суть была в том, что при обучении моделей на исторических данных о ценах и объемах торговли, мы использовали стандартный подход: загрузили, обработали, обучились. Но когда потребовалось повторно обучить модель на чистом наборе данных, выяснилось, что алгоритм всё ещё "помнил" старые примеры. Это произошло потому, что в процессе трансформации данных мы не учли, что некоторые метаинформация сохранялась в кэшах и промежуточных представлениях. **Решение пришло неожиданно.** Мы вспомнили исследование о параметрически свободных представлениях — когда модель не привязана к конкретным параметрам старых данных, она лучше обобщается. Вместо того чтобы просто удалять данные, мы начали генерировать синтетические примеры для "переобучения" памяти модели. Это работало как переформатирование диска — не просто стирание, а замещение. В branch **refactor/signal-trend-model** мы внедрили двухэтапный процесс: 1. **Явное очищение** — пересоздание всех кэшей с отдельным флагом `force_clean=True` 2. **Синтетическое переобучение** — добавление случайных данных для перезаписи внутреннего состояния модели После этого точность на новых наборах данных улучшилась на 12%, а главное — модель перестала "подсказывать" себе ответы на основе старых закономерностей. Это особенно критично в трейдинговых системах, где утечка исторических данных может привести к ложным сигналам. Оказалось, что защита данных в ML — это не только про удаление файлов. Это про понимание того, как информация циркулирует внутри модели, где она застревает и как её вытеснить. **Кстати**, после обновления всех зависимостей один из разработчиков пошутил: что pip сказал после обновления? «Я уже не тот, что раньше» 😄
Охота за вторым вызовом: как найти забытого баг-ассистента
Работаю над рефакторингом сигнал-тренд модели в проекте **Trend Analysis**. Задача вроде стандартная: перепроверить все места, где вызываются критические функции обновления трендов. Но тут я натыкаюсь на классическую историю про код, который живёт своей жизнью. В `analysis_store.py` на строке 736 я нахожу **ещё один вызов** `update_trend_scores`. Казалось бы, мелочь. Но вот в чём подвох: в первом проходе я уже обновил несколько вызовов функции, отрефакторил логику. И вот этот, затерянный где-то в середине файла, остался в старом формате. Такие ситуации опасны—когда часть кода живёт по одним правилам, а часть по другим. Это источник багов, которые проявляются в production и заставляют спешить с патчами. Приходится запускать верификацию. Делаю полный проход по проекту, ищу все вызовы `update_trend_scores` и `score_trend`. Python это облегчает—можно просто `grep` по всему `src/`. Находится порядка 10-15 вызовов, разбросанных по разным модулям. Часть в обработке данных, часть в API-слое, часть в фоновых задачах. Потом поднимаю **lint**. Не мой рефакторинг создал проблемы—в `db/` уже накопились давние стиль-нарушения. Но я внимателен к своему коду: проверяю только `src/` и `api/`. Zero issues. Это базовое правило: перед push-ом убедиться, что твои изменения не усугубляют ситуацию. Здесь раскрывается философия рефакторинга на Python. Язык динамический, типы не проверяются статически—полагаемся на внимательность и тесты. Потому система версионирования, логирование и code review становятся критичными. Каждый поменял сигнатуру функции? Значит, нужно проверить все 15 вызовов. Это не оптимально, но честно. Финальный step—убеждаюсь, что все файлы, которые импортируют обновлённые модули, уже в git. Локально существующие файлы не считаются. CI работает с чистым checkout, и если забыть добавить важный модуль—Pipeline упадёт. Почему **Ansible** лучший друг разработчика? Потому что без него ничего не работает. С ним тоже, но хотя бы есть кого винить. 😄
Почему бот социального паблишера молчал целый день
Сегодня проанализировал логи **Bot Social Publisher** и обнаружил что-то интересное: система работала, как часы, но вот контента не публиковалось. Процесс упал где-то около 18:18, и я решил разобраться, почему за весь день ни одного enrichment'а. Первое, что я проверил — живой ли бот. PID 390336 исчез из процессов. Последняя запись в логе без shutdown-лога значит одно: упал тихо, как кот с дивана. Но это не главное. Главное — понять, почему сегодня ноль обогащений событий. Я начал анализировать, что попадает в пайплайн. **Вот картина:** Событий пришло, но они разлетелись по категориям. Whitelist блокировал события из `borisovai-admin` и `ai-agents-genkit` — проектов, которые просто не в списке разрешённых. Потом события из clipboard с `project=null` тоже завалились в отказ. Это корректно: система делает свою работу по фильтрации. Но основная масса событий встала на категорию **SKIP**. Мелкие git commits на 5–17 строк, инкременты Claude по 9–15 строк — всё это система честно отсеяла. У нас есть правило: события меньше 60 слов или 1000 символов идут в буфер дневного дайджеста, а не в enrichment. Это тоже правильно — нет смысла гонять маленькие фрагменты через LLM. Интересная часть — крупные сессии. Были события на 312, 334, 1802, даже 9996 строк. Но система их дедупликировала. Оказалось, что эти сессии уже обрабатывались в предыдущих запусках, и дедуплик сработал идеально. **Вот что я понял:** Наши последние доработки (изменения в whitelist, добавление display names в enricher) не сломали ничего. Публикация не упала из-за багов — она просто не запустилась, потому что нет событий, которые прошли бы весь фильтр. Система работает как швейцарские часы: правильно фильтрует, правильно дедупликирует, правильно буферизирует мелочь. Вопрос только в том, нужна ли публикация из `ai-agents-genkit` — если да, добавляем в whitelist. Если нет, то сегодня просто был день без news-worthy событий. И да, процесс всё-таки надо перезапустить. 😄 **Бонус:** Почему JavaScript расстался с разработчиком? Слишком много зависимостей в отношениях.
Как Genkit Python v0.6.0 собирается из семи компонентов одновременно
Релизить большой фреймворк для AI-агентов — всё равно что организовать симфонический оркестр, где каждый инструмент должен начать играть в одну долю. В **Genkit Python 0.6.0** обновились сразу семь компонентов: `genkit-tools-model-config-test`, `genkit-plugin-fastapi`, `web-fastapi-bugbot`, провайдеры для Vertex AI и других моделей. И каждый зависит друг от друга. Я видел это по истории коммитов. **Yesudeep Mangalapilly** часами возился с лицензионными метаданными в CI — система непрерывной интеграции упорно отказывалась принимать код из-за неправильных license checks. Звучит как мелочь, пока не поймёшь: это блокирует весь релиз. Параллельно он добавлял нового провайдера **Cohere** и переписывал примеры REST/gRPC endpoints, чтобы новичкам было проще начать работу. **Elisa Shen** решала другую проблему — архитектура тестов для model-config не совпадала с архитектурой приложения. Пришлось перевозить тесты между модулями и переписывать assertions. Это не заметно в коде, но это часы работы. Но были и более хитрые баги. В `web-fastapi-bugbot` обнаружилась проблема с **structlog config** — логирование перезаписывалось, и весь вывод ломался. А когда работали с **DeepSeek**, JSON кодировался дважды. Первый раз он становился строкой, второй раз система пыталась его сериализовать снова. Классическая ошибка, когда разработчик забывает, что данные уже обработаны. Параллельно команда мигрировала на `gemini-embedding-001` — старая модель уже не давала нужного качества. Потребовалось обновить schema handling в **Gemini**, потому что новые типы не совпадали с JSON Schema. Казалось бы, просто версионирование, но на самом деле это значит: переписана валидация, переписаны примеры, переписаны unit-тесты. Самое интересное в истории коммитов — видно, как не всё прошло гладко. Некоторые коммиты дублируются в changelog. Это значит, что код переживал рефакторинг прямо во время разработки. Что-то переехало между модулями, что-то было переписано заново. Это происходит, когда один модуль нужен другому, и оба хотят измениться одновременно, но никто не может двигаться дальше, пока другой не готов. v0.6.0 — это не просто релиз. Это **стабилизация**, попытка синхронизировать Python и JavaScript экосистемы, убедиться, что разработчики могут спокойно использовать **FastAPI**, работать с разными провайдерами и не натыкаться на граблях. А знаете, что самое забавное? Если Svelte работает — не трогай. Если не работает — тоже не трогай, станет хуже. 😄
GitHub Actions: как булев превратил релиз в фантом
В проекте **ai-agents-genkit** случилось ровно то, что ломает сердце DevOps-инженеров — релиз не произошёл, хотя кнопка была нажата. Работал над этим я, и история оказалась поучительной. Всё началось с workflow'а `releasekit-uv.yml`. Туда заложили параметр `inputs.dry_run` — обычный чекбокс для контроля над релизом. Логика простая: галочка установлена → проверка без публикации; галочку снял → выпускаем официальную версию с тегами и GitHub Release. Казалось бы, надёжно. Но когда разработчики снимали галочку и ждали релиза v0.6.0, ничего не происходило. Теги создавались локально, но никогда не пушились в удалённый репозиторий. GitHub Release остаётся пустой. Я начал копаться в коде и нашёл виновника — **тихую бомбу типизации**. Проблема скрывалась в этой строке: ``` DRY_RUN: ${{ ... || (inputs.dry_run == 'false' && 'false' || 'true') }} ``` На первый взгляд выглядит безобидно. Но вот в чём подвох: `inputs.dry_run` объявлен как **boolean** — настоящий логический тип. Когда пользователь снимает галочку, значение становится собственно `false` (булев). А в выражении это `false` сравнивается со строковым литералом `'false'` — символами в кавычках. GitHub Actions слабо типизирован, и здесь это дорого обходится. Логическое `false` никогда не равно строке `'false'`. Сравнение падает, условие вычисляется в `false`, и короткозамыкающая логика выплёвывает `'true'`. Итог: **DRY_RUN всегда был `'true'`**, независимо от того, что нажал пользователь. Исправление оказалось элегантным: ``` DRY_RUN: ${{ ... || (inputs.dry_run && 'true' || 'false') }} ``` Теперь булев сравнивается с булевым. Если `inputs.dry_run` истина, берём `'true'`; если ложь — `'false'`. Типы совпадают, выражение вычисляется корректно. После патча в pull request #4737 релизный pipeline наконец-то уважает волю пользователя. **Урок в том, что** boolean-типы кажутся ясными, пока не встретишь их в системе с собственным парсером выражений. GitHub Actions, YAML, Terraform — везде одна и та же проблема. Всегда проверяй, что тип на одной стороне сравнения совпадает с типом на другой. Особенно когда булев встречается со строкой. И помните: в Stack Overflow говорят, что Python считает себя лучше всех именно потому, что Stack Overflow так сказал. Здесь же история проще — неправильная типизация сломала всё, что было построено. 😄
GitHub Actions: как булев сломал цель релиза
В проекте **ai-agents-genkit** случилось то, что ломает сердце DevOps-инженеров — релиз не произошёл, хотя кнопка была нажата. Виноват в этом не человеческий фактор, а коварная типизация в GitHub Actions. Всё началось с workflow'а `releasekit-uv.yml`. Там есть параметр `inputs.dry_run` — чекбокс для контроля над релизом. Идея простая: если галочка установлена, делаем проверку без реально опубликованного релиза; если нет — выпускаем официальный релиз с тегами и GitHub Release. Казалось бы, надёжная схема. Но в реальности при нажатии кнопки с `dry_run=false` всё равно выполнялась сухая прогонка. Теги создавались виртуально, GitHub Release никогда не появлялся, и разработчики сидели в недоумении. Диагноз стоял замечательный — **тихая ошибка типизации**. Проблема скрывалась в строке, где вычисляется переменная окружения `DRY_RUN`: ``` inputs.dry_run == 'false' ``` На поверхности выглядит безобидно, но здесь GitHub Actions совершает невидимый трюк. Параметр `inputs.dry_run` объявлен как **тип `boolean`** — настоящий логический тип. Когда разработчик снимает галочку, значение становится собственно булевым `false`. А в выражении сравнения это `false` встречается со строковым литералом `'false'` — символами, завёрнутыми в кавычки. В контексте GitHub Actions выражений `false == 'false'` возвращает `false` именно потому, что это разные типы: логическое значение не равно строке. Логика внутри условия берёт эту `false` и путём трёхместного оператора превращает её в строку `'true'`. Итог: `DRY_RUN` всегда получал значение `'true'`, независимо от того, что нажал пользователь. Исправление оказалось элегантным. Нужно было просто сравнивать булев с булевым: ``` inputs.dry_run && 'true' || 'false' ``` Теперь логика работает честно: если `inputs.dry_run` истина, берём `'true'`; если ложь, берём `'false'`. Типы совпадают, выражение вычисляется корректно. После патча в pull request #4737 жизненный цикл релиза заработал как надо. Версия v0.6.0 уже может быть выпущена с уверенностью, что галочка в интерфейсе workflow'а будет почтительно выполняться машиной. **Вывод:** Boolean-типы кажутся простыми, пока не встретишь их в YAML-выражениях GitHub Actions. Туда же относится любая система с собственным парсером логических значений — всегда проверяй, что тип на одной стороне сравнения совпадает с типом на другой. И помните, в мире Arch Linux говорят: **«это работает» — вот и вся ваша документация** 😄
Когда теги создаются, но не доходят: история молчаливого отказа git
Представь ситуацию: ты выпускаешь версию v0.6.0 Python пакета в проекте Genkit. Процесс отработал без ошибок, логи зелёные, все 68 тегов якобы созданы и запушены. Релиз опубликован. Но через час выясняется — на GitHub никаких тегов нет. Призрак, а не релиз. Именно это произошло с releasekit, инструментом для автоматизации выпусков. Три месяца никто не заметил, пока не стали разбираться, почему теги исчезают. ## Охота на невидимого врага Проблема крылась в `create_tags()` — функции, которая формирует названия тегов по шаблону из `releasekit.toml`: `{label}/{name}-v{version}`. Например, `py/genkit-v0.6.0`. Вот беда: функция принимала параметр `label` (значение `py`), но **забывала его передавать** в три вложенных вызова `format_tag()`. Результат — теги создавались с ведущей косой чертой: `/genkit-v0.6.0` вместо `py/genkit-v0.6.0`. Git видит такое имя и внутренне закатывает глаза — это не валидное имя для ref. Но ошибку не выкидывает. Теги создаются локально с неправильными названиями, команда push выполняется «успешно» (ну, она же отправила битые данные, технически успех), а на удалённый сервер они так и не попадают. Молчком. Без единого предупреждения. Кстати, интересная деталь: функция `delete_tags()` этот баг **не имела** — там `label` уже передавалась правильно. Так бывает. ## От исправления к защите Первое решение — очевидное. Добавить `label=label` во все три вызова `format_tag()`. Но это лишь пластырь. Вторая часть исправления — **валидация перед действием**. Новая функция `validate_tag_name()` проверяет теги против правил git для имён ref: нет ведущих и замыкающих слэшей, нет двойных точек, нет пробелов. И главное — перед тем как создавать хоть один тег, цикл валидации пробегает по **всем** планируемым именам. Если одно невалидно — весь процесс падает с информативной ошибкой. Fail-fast вместо тихого отказа. Третья проблема была скромнее, но реальна. При подготовке окружения в GitHub Actions команда `git checkout -- .` очищает только **отслеживаемые** файлы. Если `uv sync` создаёт неотслеживаемые (`.venv/`, `__pycache__/`), рабочая директория остаётся грязной. Решение — `git reset --hard && git clean -fd`. Полная очистка, как надо. ## Итог: 54 теста и спокойный сон Все изменения покрыты регрессионными тестами — 12 новых, итого 54 проходящих. Теги теперь создаются корректно, валидация срабатывает раньше, чем git начнёт молчать. И, знаешь, есть такое правило в Figma: если она работает — не трогай 😄
Genkit Python 0.6.0: чем занимается фреймворк, пока мы спим
Представьте: вы выпускаете новую версию фреймворка для AI-агентов, и в неё попадают обновления аж в **семь компонентов** одновременно. Это именно то, что произошло в Genkit Python v0.6.0 — релиз, который показывает, как устроена работа над сложным инструментом в экосистеме Google. ## Что делалось в это время Начнём с фактов. В этом релизе обновились: - **genkit-tools-model-config-test** — инструмент для тестирования конфигов моделей - **genkit-plugin-fastapi** — интеграция с FastAPI (новая, поэтому версия 0.2.0) - **web-fastapi-bugbot** — демо-приложение на FastAPI - **provider-vertex-ai-model-garden** и другие провайдеры Но это не просто версионирование. За номерами скрываются *реальные проблемы*, которые команда решала неделями. ## Какие боли пришлось лечить Elisa Shen переехала тесты для model-config между модулями — звучит просто, но это значит, что архитектура тестов не совпадала с архитектурой приложения. Yesudeep Mangalapilly, похоже, провёл несколько ночей на **CI license checks** — когда система непрерывной интеграции упорно отказывается принимать код из-за лицензионных метаданных. Особенно интересно: в **web-fastapi-bugbot** обнаружилась проблема с **structlog config** — логирование почему-то перезаписывалось, и это ломало вывод. Вроде бы мелочь, но попробуйте дебажить асинхронный код без логов. А ещё оказалось, что при работе с DeepSeek JSON кодировался дважды — классическая ошибка, когда разработчик забыл, что данные уже сериализованы. ## Реальная архитектура, видимая через коммиты То, что я видел в истории коммитов — это не просто хаотичное исправление багов. Это **планомерная работа по стабилизации**: 1. Сначала добавили новый провайдер Cohere (нужен был в примерах) 2. Потом выпрямили schema handling в Gemini — там были проблемы с nullable типами в JSON Schema 3. Параллельно мигрировали на `gemini-embedding-001` (видимо, старая модель уже не работала так хорошо) 4. На конец добавили новый пример с REST + gRPC endpoints — так больше разработчиков смогут начать работу Команда думала не только о текущем функционале, но и о том, как новичок будет разбираться в коде. ## Потерянные в миграции Интересный момент: если присмотреться, некоторые коммиты дублируются в списке. Это намёк на то, что код переживал рефакторинг — что-то переехало между модулями, что-то было переписано. Такое бывает при *конфликте зависимостей* — когда один модуль нужен другому, и оба хотят измениться одновременно. ## Что дальше v0.6.0 — это не просто релиз. Это **стабилизация** перед большим толчком. Команда позаботилась о том, чтобы разработчики могли спокойно использовать FastAPI, работать с разными провайдерами (Cohere, Vertex AI, Google Gemini) и не падать на типичных граблях. А знаете, что самое забавное? Ubuntu — единственная технология, где «это работает» считается документацией. 😄
Одновременно 12 пакетов Genkit: как releasekit спас нас от ручной координации
Знаете ощущение, когда нужно выпустить обновление для целой экосистемы пакетов? Вчера я столкнулся с этим вызовом на проекте **Genkit** — это фреймворк для работы с AI-агентами. У нас было 12 пакетов, которые нуждались в новом релизе одновременно. Раньше такое означало бы ручной марафон: проверить зависимости каждого плагина, вручную бампить версии, убедиться, что ничего не сломалось. Кошмар координации. Но на этот раз у нас был **releasekit** — инструмент, который автоматизирует весь процесс выпуска. ## Разбор по полочкам Я запустил простую команду: ``` py/bin/releasekit plan --bumped --publishable ``` И вот что произошло. Releasekit проанализировал все коммиты, обнаружил, что у основного пакета **genkit** было 11 связанных изменений: - **genkit-plugin-anthropic** — 0.5.0 → 0.6.0 - **genkit-plugin-compat-oai** — 0.5.0 → 0.6.0 - **genkit-plugin-evaluators** — 0.5.0 → 0.6.0 - **genkit-plugin-fastapi** — 0.5.0 → 0.6.0 И ещё 8 плагинов для Google Cloud, Google Genai, Ollama, XAI, DeepSeek, Flask и Vertex AI. ## Почему это работает? Releasekit сканирует конвенциональные коммиты (conventional commits) в истории Git и определяет, нужно ли бампить версию. Минорное обновление 0.5.0 → 0.6.0 означает, что добавилась функциональность или были исправлены баги, но не сломалась обратная совместимость. Интересный момент: система обнаружила один нестандартный коммит — `'elisa/fix/core framework improvements (#4649)'` — и выдала предупреждение. Сообщение было в формате ветки, а не в формате `fix: ...`. Но это не остановило процесс — просто залогировалось как warning. ## Основные исправления в этом релизе Среди всех этих 12 пакетов было несколько критических фиксов: - Исправление пути для логирования в ядре (Path fix for logging) - Замена literalного нуль-байта на Git-экранирование `%x00` в changelog — вещь техническая, но важная для совместимости - Улучшения в Firebase telemetry и рефакторинг реализации - Асинхронное создание клиента с обновлением credentials в фоне для **genkit-plugin-vertex-ai** ## IT факт в завершение А вы знали, почему DynamoDB не пришёл на вечеринку? Его заблокировал firewall. 😄 Шутки шутками, но система контроля версий и автоматизации релизов — это реально спасение для монорепозиториев с десятком зависимостей. Вместо того чтобы спать-не-спать и боязно кликать по кнопке publish, я просто дал команду и пошёл пить кофе. Releasekit сделал всю грязную работу: вычислил версии, составил changelog, все 12 пакетов готовы к публикации. Вот это я понимаю под словом *DX* (Developer Experience).
ReleaseKit: граф совместимости лицензий вместо головной боли
В **ai-agents-genkit** вдруг обнаружилась проблема, которую я раньше даже не замечал. Проект использует кучу зависимостей с разными лицензиями: MIT, Apache-2.0, GPL, BSD. Но беда в том, что не все они дружат друг с другом. GPL тащит за собой требования, которые конфликтуют с proprietary кодом. Apache может стать несовместима с AGPL. Вручную проверять каждую — это путь в ад. Вот я и собрал для **ReleaseKit** полноценную систему проверки лицензийной совместимости. Звучит скучно? Погоди. ## Как это работает Начал с парсера SPDX-выражений. Да, существуют лицензии, записанные как `(MIT AND Apache-2.0) OR GPL-3.0 WITH Classpath-exception-1.0`. Стандартная строка из жизни. Парсер строит AST, понимает операторы `AND`, `OR`, `WITH`, может вычислить результат. Потом идёт граф — 167 лицензий, 42 правила совместимости. Каждый пакет в дереве зависимостей получает статус: **OK**, **WARNING** (несовместимость), **ERROR** (блокирующая). Система умеет парсить `uv.lock`, `package-lock.json`, `Cargo.lock` — охватывает Python, JavaScript, Rust, Go, Dart, Java и даже Clojure. А дальше — интерактивное исправление. Флаг `--fix` запускает диалог: видишь конфликт — выбираешь действие: *exemption* (исключение), *allow* (разрешить), *deny* (запретить), *override* (переопределить). Конфиг пишется в `releasekit.toml` с сохранением комментариев (спасибо, `tomlkit`). ## Тестирование как искусство Покрыл ~800 тестов на все случаи жизни: парсер SPDX (100+ кейсов с edge cases), граф совместимости (150+ комбинаций), обнаружение лицензий в манифестах семи экосистем (80+ проверок), фаззер для SPDX-резолвера (5 стадий: точное совпадение → алиасы → нормализация → префикс → Левенштейн). Даже есть скрипт `verify_license_data.py` — проверяет, что кросс-ссылки в `licenses.toml` и `license_compatibility.toml` не сломаны. ## Почему это серьёзно Лицензийная совместимость — не баг, не фича, это *compliance*. Один пропущенный конфликт = проблемы на prod. Раньше я пытался делать это руками, экселем, документом. Теперь система автоматическая, проверяемая, интерактивная. Документация новая — гайд для интерактивного исправления, слайды с демо-сессией в терминале, полная архитектура. ## Забавный факт Pandas: решение проблемы, о существовании которой ты не знал, способом, который не понимаешь. 😄
Когда маршрутизация идеальна, а точность падает: урок из CIFAR-100
В проекте **llm-analysis** я проверял гипотезу, которая казалась очевидной: если обучить глубокий роутер правильно направлять примеры на специализированные сети, accuracy должен вырасти. Я протестировал четыре подхода — и получил то, что не ожидал. ## Четыре стратегии маршрутизации Первые три были «обычными»: - **Стратегия A**: простая маршрутизация, 70.77% accuracy, роутер угадывает правильный класс в 62.5% случаев - **Стратегия B**: смешанный подход, 73.10%, маршрутизация на уровне 62.3% - **Стратегия C**: двухфазная схема, 72.97%, роутинг 61.3% Результаты росли медленно, но росли. Потом я решил не экономить и построил **Стратегию D** — многослойный роутер с supervised training, специально обученный выбирать эксперта для каждого класса. ## Успех, который не сработал Стратегия D показала впечатляющий результат для маршрутизации: **79.5%** точности выбора. Это в 1.28 раза лучше, чем простой однослойный роутер. Я был на пике оптимизма. Но когда я проверил финальную accuracy на CIFAR-100 — получил **73.15%**. Прирост всего 0.22 пункта над двухфазным подходом. По сути, плоский результат. Это был момент истины. Роутер стал выбирать специализированные сети в 4 из 5 случаев правильно. Но эти правильные выборы почти не улучшали классификацию. Проблема была не в том, *как* выбирать эксперта, а в том, насколько хороши сами эксперты. ## Факт о специализации Оракульная accuracy — когда мы знаем правильный класс и принудительно отправляем пример на соответствующую сеть — держалась на уровне 84–85%. Это потолок архитектуры. Даже с идеальной маршрутизацией мы не можем превысить эту границу. Специализированные сети учились на меньшем количестве примеров, к тому же узкие паттерны, которые они находили, плохо обобщались. Когда роутер отправлял пример на «неправильного» эксперта — сеть часто ошибалась, потому что её обучали как-то иначе. **Специализация принесла скорее минусы, чем плюсы.** ## Итог и шутка про GraphQL Эксперимент 13b завершился вердиктом **NO-GO** — 73.15% меньше требуемых 74.5%. Но это не провал. Это урок о том, что иногда идеально отлаженная часть системы не спасает целое. Нужно либо перестроить архитектуру специализированных моделей, либо вообще забыть об этом подходе. Документация обновлена, метрики залогированы. Команда готовится к следующему витку. Знаете, почему GraphQL расстался с разработчиком? Слишком много зависимостей в отношениях. 😄
Когда маршрутизация идеальна, а точность нет: история эксперимента 13b
В проекте **llm-analisis** я работал над стратегией специализированных моделей для CIFAR-100. Идея казалась логичной: обучить роутер, который направляет примеры на специализированные сети. Если маршрутизация будет точной, общая accuracy должна вырасти. Вот только жизнь оказалась сложнее. ## Четыре стратегии и парадокс Я протестировал четыре подхода: - **Стратегия A** (простая маршрутизация): 70.77% accuracy, но роутер угадывал правильный класс только в 62.5% случаев - **Стратегия B** (смешанный подход): 73.10%, маршрутизация на уровне 62.3% - **Стратегия C** (двухфазная): 72.97%, роутинг 61.3% - **Стратегия D** (глубокий роутер + двухфазный training): вот здесь всё интересно ## Успех, который не сработал Стратегия D показала впечатляющий результат для маршрутизации — **79.5%**. Это в 1.28 раза лучше, чем простой однослойный роутер. Я был уверен, что это прорыв. Но финальная accuracy выросла всего на 0.22 процентных пункта до 73.15%. Это был момент истины. **Проблема не в маршрутизации.** Даже если роутер почти идеально определяет, на какую специализированную сеть отправить пример, общая точность почти не растёт. Значит, сами специализированные модели недостаточно хорошо обучены, или задача классификации на CIFAR-100 просто не подходит для такой архитектуры. ## Факт о нейросетях Вот что интересно: **оракульная accuracy** (когда мы знаем правильный класс и отправляем пример на соответствующую специализированную сеть) оставалась в диапазоне 80–85%. Это потолок архитектуры. Роутер, улучшив маршрутизацию, не может превысить этот потолок. Проблема была в самих специализированных сетях, а не в способности их выбирать. ## Итог Эксперимент 13b завершился вердиктом **NO-GO** — 73.15% меньше требуемых 74.5%. Но это не поражение, а ценный урок. Иногда идеально сделанная часть системы не спасает целое. Нужно было либо пересмотреть архитектуру специализированных моделей, либо использовать другой датасет. Документация обновлена, результаты залогированы. Команда готовится к следующему витку экспериментов. *Совет дня: перед тем как обновить ArgoCD, сделай бэкап. И резюме. 😄*
Как мы научили CI передавать право подписи релизам
Работаю в **Genkit** — это Python-библиотека для генеративного ИИ. Недавно столкнулись с задачей, которая на первый взгляд казалась простой: автоматизировать выпуск версий. Но под капотом скрывалась целая история про доверие, аутентификацию и то, как машина доказывает GitHub, что она имеет право что-то коммитить. ## Проблема: три способа подписать себя При каждом автоматическом релизе нужно создать коммит с тегами, но **GitHub не доверяет просто так**. Проверяет CLA (Contributor License Agreement) — то есть нужен реальный аккаунт, подписавший соглашение. Мы выбрали три дорожки: **GitHub App** (премиум) — приложение Genkit, созданное в самом GitHub. Оно вызывает API, API возвращает специальный ID юзера, и коммиты становятся от лица бота-приложения. CLA проходит, CI запускается. **Personal Access Token (PAT)** — обычный токен для конкретного аккаунта разработчика. Уже знаком каждому, кто работал с GitHub CLI. Так же проходит CLA и запускает CI. **GITHUB_TOKEN** (есть по умолчанию) — встроенный токен, даёт доступ каждому Action. Главный трюк: даже с ним можно подделать идентичность, если в переменных репо хранить имя и email человека, который подписал CLA. ## Как это устроено Все восемь рабочих потоков в Genkit теперь получили `auth` job на первом этапе. Он проверяет, что настроено (App? PAT? или только GITHUB_TOKEN?), и резолвит идентичность: - **App**: ищет юзер-ID через `gh api`, делает коммит от `genkit-bot` - **PAT**: берёт `RELEASEKIT_GIT_USER_NAME` и `RELEASEKIT_GIT_USER_EMAIL` из переменных репо - **GITHUB_TOKEN**: то же самое, плюс fallback на `github-actions[bot]` Главное: если ты находишься в ситуации, когда App и PAT недоступны, но у тебя есть CLA-подписанный аккаунт — просто добавь две переменные в настройки репо, и даже встроенный токен пройдёт проверку CLA. ## Бонус: bootstrap_tags.py Отдельно создали скрипт, который читает конфиг `releasekit.toml`, находит все пакеты в `library_dirs`, и создаёт теги для каждого пакета отдельно. Не hardcode'ит пути типа `['packages', 'plugins']`, а читает их из конфига. В итоге — 24 тега за раз, и все они указывают на правильный коммит. ## На практике Теперь разработчик может зайти на страницу переменных GitHub репо, добавить два поля (имя и почту) — и релизы будут проходить CLA, даже без App или PAT. Это снижает барьер входа для новых контрибьюторов. Мой код работает, и я знаю почему. Мой код не работает, и я уже добавил логирование. 😄
Почему картинки в заметках исчезали — и как я это чинил
В проекте **bot-social-publisher** большинство заметок генерировались без картинок. Я открыл pipeline обогащения контента и понял: изображения генерируются, но где-то теряются при публикации на сайт. Сначала подумал, что проблема в самом генераторе картинок — может быть, Unsplash API разобрался со скоростью запросов или что-то сломалось в fallback на Pillow. Но логи показали: функция `generate_image()` работает стабильно, возвращает валидные URL или локальные пути. Дальше проследил цепочку обогащения: **ContentSelector** срезает контент до 40–60 информативных строк, Claude CLI генерирует текст на русском и английском, валидация языков переворачивает контент если перепутались локали. Все работает. Изображение есть в `EnrichedNote`. Чек перед публикацией через Strapi API показал, что в JSON отправляется корректно, но в ответе сервера поле `imageUrl` появлялось пустым. Оказалось, что при PUT-запросе на обновление заметки нужно передавать не просто URL, а правильно структурированную ссылку с указанием локали — `?locale=ru` для русского варианта. Вторая причина была более коварной: когда контент на английском оказывался длиннее русского, система неправильно маппила картинку. Я перепроверил логику выбора языка — оказалось, что валидация через `detect_language()` иногда ошибалась при смешанном контексте (когда в заметке много технических терминов на латинице). **Решение оказалось двухуровневым:** 1. Явно привязать изображение к основному языку заметки (русский, как определено в конфиге), не к случайному выбору в цикле обогащения. 2. Добавить проверку в `scripts/update_site.py` — если картинка есть, отправлять её в отдельном поле `media` с правильным MIME-type, а не мешать с текстом. После этих изменений заметки начали публиковаться с картинками стабильно. Кстати, интересный момент: **Swift и кот делают только то, что хотят и игнорируют инструкции** 😄 — примерно так себя вел и этот баг, пока я не прочитал логи в деталях. Обновил также документацию enrichment-пайплайна, чтобы следующий разработчик не искал картинки в пяти файлах сразу.
Когда батч-норм ломает миксчур экспертов на CIFAR-100
Три недели охоты за призраком. Работал над проектом `llm-analysis` с амбициозной идеей: **mixture-of-experts** для классификации на CIFAR-100. Теория обещала +40 процентных пункта над baseline. На практике упёрся в две стены сразу. ## Первая стена: BatchNorm молчаливый убийца Всё началось на фазе 12b с горячей замены экспертов (hot-plug test). Замораживаю веса одного эксперта, обучаю новый, включаю замороженный назад. И вот беда — точность первого эксперта падает на **2.48 процентных пункта**. Часы в отладчике, проверка логик, перепроверка кода... Потом осенило: `requires_grad=False` не спасает. **BatchNorm слои обновляют running statistics** даже с заморозкой весов. Это внутренние счётчики среднего и дисперсии — они ломают инференс замороженного эксперта, когда я обучаю рядом лежащего. Решение глупо-простое: добавил `model.stem.eval()` после `model.train()`. Явно перевести backbone в режим инференса. Дрейф упал с 2.48pp до нуля. Полдня на баг, который решился одной строкой. Классика. ## Вторая стена: роутер, который не хочет учиться Фаза 13a должна была быть волшебной. Oracle (идеальный роутер) показывал потолок в **80.78%**. А мой `nn.Linear(128, 4)` застрял на **72.93%** — зазор в семь с половиной пункта. Запустил три стратегии подряд: 1. **Глубокий роутер + отдельное обучение**: 73.32% — тоже не помогает 2. **Совместное обучение роутера и экспертов**: 73.74% — хуже 3. **Ещё глубже архитектура**: routing accuracy 62.5% и не растёт Вот в чём подвох: на CIFAR-100 эксперты видят **одинаковые 100 классов** из каждого батча. Градиенты идут со всех направлений одновременно. Доменная специфика просто стирается. Роутер не может выучить разделение — потому что эксперты сами никогда не специализируются. Это не инженерный баг. Это архитектурный потолок. ## Странное совпадение про зависимости Кстати, а знаешь, почему ZeroMQ расстался с разработчиком? **Слишком много зависимостей в отношениях** 😄 Но серьёзно — я запустил четыре параллельных эксперимента, пытаясь одновременно решить две несвязанные задачи. BatchNorm — это был мой быстрый win. Маршрутизация — архитектурный блокер. **Итог фазы 12b**: горячая замена экспертов работает. Hot-plug стабилен. Batch-norm под контролем. **Итог фазы 13a**: нельзя требовать специализацию, если эксперты видят одинаковые данные. На CIFAR-100 с такой архитектурой это невозможно. Нужна либо переделка доменов под каждого эксперта, либо... признание поражения и переход на другой датасет. Иногда две стены одновременно — это знак, что дверь в другом месте.
Когда маршрутизация экспертов встречает стену батч-нормализации
Работал над проектом `llm-analysis` — попытка воплотить мечту о смеси экспертов (MoE) для классификации на CIFAR-100. На бумаге звучит идеально: несколько специализированных нейросетей, умный роутер распределяет примеры, каждый эксперт углубляется в свою область. Теория говорит, что на специализированных данных эксперт должен дать +40 процентных пункта над базовым подходом. На практике упёрся в две стены одновременно. ## Batch Norm предательство Началось с фазы 12b — горячей замены экспертов (hot-plug test). Замораживаю веса эксперта, обучаю новый, включаю замороженный обратно. Точность первого эксперта падала на 2.48pp. Думал, это неизбежный дрейф при переобучении остальных. Копался в коде часами. Потом понял: `requires_grad=False` не спасает. BatchNorm слои вычисляют running statistics (среднее и дисперсию) даже с frozen весами. Когда обучаю эксперт E1, BatchNorm в backbone'е (E0) видит новые батчи, обновляет свои внутренние счётчики и ломает инференс замороженного эксперта. Решение простое, как кувалда: добавить `model.stem.eval()` после `model.train()`, явно перевести backbone в режим инференса. Дрейф упал с 2.48pp до **0.00pp**. Это был просто инженерный баг, но на него потратил полдня. ## Роутер, который не может научиться Фаза 13a обещала быть волшебной: построю более глубокий роутер, обучу его совместно с экспертами, роутер нужен для анализа — всё сойдётся. Oracle (идеальный роутер) показывал потолок в 80.78%, а наш простой `nn.Linear(128, 4)` давал 72.93%. Зазор в семь с половиной пункта! Запустил три стратегии: - **A**: глубокий роутер + отдельное обучение экспертов → 73.32% (нет улучшения) - **B**: совместное обучение роутера и экспертов → 73.10% (хуже baseline) - **C**: вообще неудача, routing accuracy 62.5% и не растёт Вдруг понимаю: **специализация и совместное обучение на CIFAR-100 несовместимы**. Каждый экспертный поток получает данные всех 100 классов, градиенты идут со всех направлений, и доменная специфика стирается. Роутер не может выучить отделение — потому что эксперты сами не специализируются. ## Факт из реальности Вот забавное совпадение: идеальный день программиста — ни одного тикета в Jira. Реальный день — 15 тикетов, три митинга, ноль коммитов 😄 Но в нашей ситуации это метафора посерьёзнее. Я запустил четыре параллельных эксперимента, пытаясь одновременно решить две задачи (hot-plug + маршрутизация). Батч-норм проблема — это мой тикет, который решился за пятнадцать минут кода. Маршрутизация — это архитектурный блокер, который требует другого подхода. ## Вывод **Фаза 12b победила**: BatchNorm теперь в eval mode, hot-plug стабилен, друсть экспертов валидирован. Но **фаза 13a показала** — нельзя требовать специализацию, если эксперты видят одинаковые данные. Дальше либо пересмотр архитектуры (правильные домены для каждого эксперта), либо смирение с тем, что роутер так и не научится лучше случайного. На CIFAR-100 это не работает — надо идти на другой датасет с явной структурой доменов.
Как git push --force-with-lease спасает CI от зацикливания на release-ветках
Работаем над **genkit** — платформой для AI-агентов от Google. В проекте есть автоматическая система выпуска релизов, которая живёт в `releasekit-uv.yml` и должна была работать как часы. Но в какой-то момент CI начал падать с ошибкой non-fast-forward при попытке создать PR для релиза. ## Проблема: ветка, которая не отпускает Корень зла оказался простым, но коварным. Функция `prepare_release()` каждый раз **пересоздаёт release-ветку с нуля**, используя `git checkout -B`. Это нормально, если ветка только локальная. Но когда она уже существует на удалённом репозитории (остаток от прошлого запуска CI), `git push` отказывается её обновлять — это же non-fast-forward изменение, потенциально опасное. Ситуация усугублялась тем, что CI часто запускается повторно: разработчик запустил релиз, что-то пошло не так, и он попытался снова. На втором прогоне `releasekit` уже видит старую ветку на origin и падает. ## Решение: force с умом Мы добавили параметр `force: bool = False` в протокол `VCS` — это общий интерфейс, который поддерживают и Git, и Mercurial. В реализации для Git выбрали **`--force-with-lease`** вместо обычного `--force`. Почему именно `--force-with-lease`? Потому что это безопаснее. Обычный `--force` перезапишет любую историю на удалённом сервере, даже если её там уже изменили руки коллеги. `--force-with-lease` проверит: "Удалённая ветка ещё в том состоянии, которое я последний раз видел?" Если нет — откажет. Это защита от случайного стирания чужой работы. В `prepare.py` теперь вызываем: ``` vcs.push(force=True) ``` И выполненных тестов говорят, что всё работает: `ruff check`, `py type check`, `pyrefly check` — все зелёные. ## Заодно навели чистоту Улучшили обработку ошибок в `cli.py` — теперь `_cmd_prepare` ловит `RuntimeError` и логирует событие `prepare_error` вместо полного traceback'а. А в GitHub Actions улучшили читаемость: если что-то сломалось, выводим последние 50 строк логов вне группы `::group::`, чтобы видно было сразу, без разворачивания. Бонус: переписали скрипт `setup.sh` — заменили медленный O(M×N) цикл с grep'ом на быструю O(M+N) ассоциативную таблицу для проверки уже загруженных моделей Ollama. Мелочь, но помогает ускорить инициализацию. ## Вывод Иногда самые коварные баги скрывают простые решения: просто нужно знать нужный флаг Git и немного поработать над безопасностью. Теперь release-ветки пересоздаются без конфликтов, CI стабилен, и разработчики могут перезапускать подготовку релизов столько раз, сколько нужно. --- *Что общего у Selenium и подростка? Оба непредсказуемы и требуют постоянного внимания.* 😄
Как я обновил архитектуру голосового агента за один вечер
Работаю над проектом `ai-agents-voice-agent` — это голосовой ассистент, построенный на Claude API с поддержкой десктопной автоматизации. Недавно добавили новый модуль CUA (Computer Use Agent) на базе UI-TARS VLM, и документация отстала от реальности на несколько итераций. Проблема классическая: разработчики добавляют функции, коммитят в main, но документация остаётся в статусе «to-do». Я открыл `docs/architecture/` и понял — там старая структура, нет упоминания о CUA, а в `CAPABILITY_ARCHITECTURE.md` описана трёхуровневая архитектура, хотя фактически их уже четыре. Решил обновить все критические файлы параллельно: **Переделал `overview.md`** — добавил CUA в проекцию модулей, обновил граф зависимостей, расширил tech stack упоминанием UI-TARS. Теперь новый разработчик сразу видит, что есть desktop automation. **Переписал `CAPABILITY_ARCHITECTURE.md`** — это был ключевой файл. Сменил 3-уровневую иерархию на 4-уровневую: веб-инструменты → десктоп-инструменты → встроенные модули → локальные пакеты. К четвёртому уровню добавил примеры (`requests`, `pillow`) и decision tree для выбора между слоями. **Обновил документацию TMA** (`tma/00-ARCHITECTURE.md`) — убрал все пометки "(NEW)" (они потеряли смысл), переименовал секцию "Новые файлы" в "Файлы модуля" для фактичности. **Актуализировал `06-NEW-INTERFACES.md`** — это было больно. Там была информация о Tesseract OCR, которая вообще не использовалась. Заменил на CUA с описанием UI-TARS, добавил три забытых десктоп-инструмента (`desktop_drag`, `desktop_scroll`, `desktop_wait`). Фаза 3 теперь содержит 21 инструмент вместо старых 12. **Закрыл все задачи Фазы 3** в `02-TASK-LIST.md` — просто поставил галочки рядом с пунктами 3.1–3.9. Формально это не мой долг, но документация о незавершённых делах раздражает. Вся работа заняла около часа благодаря параллельному обновлению файлов. Главное — не оставлять документацию как груз, который весит на совести. Она либо актуальна, либо токсична. --- *Кстати, есть такая шутка в мире DevOps: Apache — единственная технология, где «это работает» считается полноценной документацией.* 😄