Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Как мы спасали аналитику трендов от невидимых багов
Работаю над **Trend Analysis** уже несколько спринтов, и вот снова: всё выглядит правильно, данные есть, но аналитика молчит. История обновлений с версии 0.12.0 — это история, как мы учились видеть то, что скрывается за очевидным. Началось просто. В версии 0.13.0 я заметил странное: сигналы из анализов теряются где-то в недрах базы данных. Проверил логи, проверил запросы — всё на месте. Потом понял: в коде стояло `phase='new'`, а должно было быть `'emerging'`. Казалось бы, мелочь, но на ней теряется 18 из 19 сигналов. Одна буква — и половина функциональности не работает. Параллельно с этим наткнулся на ещё один подводный камень: джойн в таблице recommendations был написан с опечаткой — `tr.id = t.id` вместо `tr.object_id = t.id`. Результат: momentum вообще не считался после миграции. Казалось бы, технический баг, но для юзера это означал, что рекомендации просто не появлялись. Чтобы ускорить работу с растущим объёмом данных, добавили 15 новых индексов БД в миграции 020. Это был момент боли — понял, что без правильной оптимизации запросы будут тормозить экспоненциально. К счастью, индексы сработали идеально, и теперь аналитика летает. А потом пришла версия 0.14.0, и мы переросли в новое качество. Добавили серверную пагинацию, поиск, сортировку анализов — теперь юзер может не просто смотреть данные, но реально с ними работать. Заодно реализовали **Saved Products** в Lab — локальное хранилище закладок через Zustand. Мелочь, но очень удобная. Всю работу приправили переводом trend_name и динамическими ролями в кеш переводов. Казалось бы, локализация — не главное, но когда твой интерфейс говорит с юзером на его языке, он чувствует себя дома. **Claude** помогал на каждом этапе: от анализа проблем до рефакторинга TypeScript типов, пока мы выравнивали SourceItem с бэкенд-моделью. Инструмент, который может одновременно понимать архитектуру, замечать баги и предлагать решения — на вес золота. Главный урок: **невидимые баги опаснее очевидных**. Код работает, тесты проходят, но где-то глубоко логика разъезжается с реальностью. Миграции, джойны, фазы сигналов — это всё сложные системы, где одна ошибка каскадирует через весь пайплайн. Кстати, вся эта история напомнила мне старую шутку: что общего у Jenkins и подростка? Оба непредсказуемы и требуют постоянного внимания 😄
Когда больше данных — это меньше точности
Я работаю над проектом LLM Analysis, и недавно столкнулся с парадоксом, который поначалу выбил меня из колеи. В Phase 24a мы добились **76.8% на GSM8K** — отличный результат для наших экспериментов. Казалось, можно расслабиться и двигаться дальше. Но я решил проверить гипотезу: а что если добавить больше данных обучения? В Phase 29a я попробовал самый логичный шаг — собрал **89 дополнительных borderline-решений** и добавил их в обучающий набор. Это были настоящие примеры из наших данных, просто выбранные через temperature-sampling вместо greedy-декодирования. На бумаге звучало идеально. На практике результат упал до **73.0% — минус 3.8 процентных пункта**. Первый шок прошёл. Начал анализировать логи. Оказалось, что новые данные были намного шумнее: PPL метрика скакнула с 1.60 до 2.16. Иными словами, модель хуже подгонялась к расширенному датасету, потому что temperature-sampled ответы менее структурированы и более разнородны. Мы как бы кормили её случайными вариантами правильного ответа вместо канонических примеров. Решил проверить вторую гипотезу — может быть, дело просто в длительности обучения? В Phase 29b увеличил количество шагов с 500 до 1000. Результат: **74.4% против 76.8%** — опять минус, уже 2.4 пункта. Зато loss упал до 0.004 (был 0.032). Модель просто переобучилась на себя. Вывод поразил меня: Phase 24a оказался **экстремально хрупким оптимумом**. Любое изменение в данных или параметрах обучения разрушает то хрупкое равновесие, которое мы случайно нашли. Это не просто «немного хуже» — это резкое падение на несколько процентных пункта. Остались ещё два эксперимента в очереди: 29c с multi-expert маршрутизацией и 29d с MATH-датасетом. Запускаю их параллельно, но теперь уже с другой ментальностью: буду искать не просто улучшение, а **стабильное плато**, где результат держится при вариациях входных данных. Классический момент в ML-разработке: когда ты учишь свою систему, как Vim учит новичков — всё сломалось, и виноват либо инструмент, либо ты 😄
Пять проектов, которые окупают себя за месяц
Я сидел над **Trend Analysis** и вдруг понял: вокруг слишком много side-проектов, которые генерируют доход, но требуют минимума времени. Вчера разбирал ошибку в crawler — `sqlite3.IntegrityError: FOREIGN KEY constraint failed` — и прозвучало: а что, если вместо фиксинга давай соберём топ проектов на cash-flow? Вот мой список из боевого опыта. **Первый** — аналитический краулер для нишевых рынков. В **Trend Analysis** мы парсим источники через **Python**, используя **AsyncIO** для параллельной обработки. Такой краулер можно обучить отслеживать конкретные категории товаров, движения цен или тренды в нишах. B2B-клиенты платят от 500 до 2000 долларов в месяц за свежие данные. Главное — настроить **API** и забыть. Даже когда ломаются связи в базе (как в моём случае с foreign key), проект продолжает работать. **Второй** — автоматизация контента через **Claude AI**. Мы это делаем в боте-издателе: берём сырые логи разработки, обогащаем через **AI**, генерируем посты на двух языках. Клиент платит за объём — сотня статей в месяц стоит как годовой **GitHub Pro**. Zero-touch после настройки. **Третий** — аудит и рефакторинг React-компонентов. Помнишь ошибку про "Error: Rendered more hooks than during the previous render"? Кучу проектов на **JavaScript** ломают именно такие баги. Консультация, правка — 300–500 в день. Один фиксинг за вечер — это деньги на ужин. **Четвёртый** — интеграции между системами через **REST API**. Каждый стартап нуждается в том, чтобы данные текли из Stripe в CRM, из CRM в аналитику. Я пишу такую логику, выкладываю на GitHub как open-source с платной поддержкой. Два-три клиента в месяц — и окупает время разработки в 10 раз. **Пятый** — security-аудит. В материале всплыли проблемы с кодировкой на Windows (curl ломает UTF-8 с кириллицей), неправильное управление API-ключами в `.env`. Фрилансеры платят 200–400 долларов за быстрый аудит кодовой базы. У меня есть чеклист на 20 пунктов, проверю за два часа. Что объединяет все пять? **API**, **AI** и **Python**. Везде нужен либо парсинг данных, либо обработка текста через Claude, либо интеграция систем. И везде — благодаря автоматизации — можно параллелить: работаешь над Trend Analysis, а фоном крутятся три клиентских краулера и публикуется контент. Главное — не начинать с идеального кода. Помнишь, как Spring Boot непредсказуем? Наши проекты тоже. Но они работают. 😄
Когда разрозненные фильтры становятся одной красивой системой
Вчера закончил работу над **Trend Analysis v0.12.0**, и это было именно то, о чём говорят: когда архитектура начинает складываться как паззл, видишь, что месяцы рефакторинга стоили того. Началось с обычной проблемы. В Cascade frontend было четыре отдельных страницы — explore, radar, objects, recommendations. На каждой свои фильтры, свой способ отображения, свои попапы. Пользователи путались, интерфейс выглядел как лоскутное одеяло. Я смотрел на эту красоту и понимал: нужно унифицировать, но **как** сделать это без полного переписывания? Решение пришло не с первого дня. Сначала запустил сервер-сайд пагинацию в `recommendation_store` — это дало нам контроль над данными на бэке, убрало загрузку всего сразу. Потом добавил динамические роли, которые теперь вытягиваются прямо из P4-отчёта. Не захардкодили — система сама адаптируется к изменениям. На фронте заменил горизонтальные табы на role chips — компактнее, быстрее переключаться. Зона фильтра теперь работает с **topN + поиск**, а не слепо показывает всё подряд. И главное — все четыре страницы получили **единый макет попапера**: одинаковые разделители, одна логика поведения, один стиль. Заняло больше времени, чем казалось, но оно того стоило. Backend часть тоже потребовала внимания. Изначально routes в `api/main.py` ещё включали префикс `/api`, но я переписал это — Vite proxy теперь перенаправляет `/api/*` в `/*` перед отправкой на бэк. Чище, проще масштабировать. Добавил `html.unescape` для StackOverflow заголовков — казалось бы мелочь, а на самом деле это спасает от каши из HTML-энтитиз в интерфейсе. В Lab тоже не сидели сложа руки. Оптимизировал промпты для работы с LLM — теперь структурированная экстракция вместо размытых инструкций. Добавил новый `llm_helpers` модуль, улучшил layout страниц Need detail и Product detail. Таблицы в Lab получили новые колонки — данные стали полнее. Самое приятное? Теперь, когда добавляю новую фичу на одной странице, другие три не ломаются. Система дышит. Вот такой факт о жизни разработчика: перед обновлением NumPy **обязательно** сделай бэкап. И резюме. 😄
Почему Python идеален для инференса, когда модель уже оптимизирована
Когда я работал над Speech to Text на Claude Code, столкнулся с классическим вопросом хейтера: «Зачем Python? Напиши на нормальном языке!» Звучит разумно — если нужна скорость, берешь C++ или Rust. Но дьявол в деталях. Я профилировал конвейер: аудио поступает, ONNX Runtime распознает речь, возвращает текст. Всё просто. Только вот где на самом деле тратится время? **660 миллисекунд на весь процесс. Из них на код Python приходится меньше 5 миллисекунд.** Остальное — это чистый инференс модели, и тут уже работает C++ CUDA-кернелов, а Python просто вызывает `model.recognize()` и передает результат дальше. Переписать обёртку на Rust? Технически возможно. Выигрыш? Максимум те же 5 миллисекунд — меньше одного процента от общей задержки. А потери? Огромные. Python-экосистема даёт мне **Silero VAD** для фильтрации молчания, **faster-whisper** для оптимизации, прямой доступ к **HuggingFace Hub**. Всё это хорошо интегрируется, не требует обвязки на С++, работает из коробки. Вот здесь кроется главное: язык обёртки на результат не влияет, *если узкое место лежит в самой модели*. А оно там и лежит. Если когда-нибудь профилировщик покажет, что 50% времени тратится на парсинг результатов в Python или на трансформацию данных перед инференсом — тогда, конечно, пересядем на Rust и будем счастливы. Но сейчас это просто преждевременная оптимизация. Оказалось, что правильный выбор языка — это не престиж, а **соответствие бутылочному горлышку**. И моё горлышко находится в ONNX Runtime, а не в моём коде.
Монорепо, который заставил пересмотреть структуру проекта
Когда решил мигрировать **Bot Social Publisher** с одномонолитного хранилища на многопакетную архитектуру, предполагал, что главная сложность будет в коде. Глупо. На самом деле всё сломалось на границах между пакетами. Проект уже был внушительным: 17 модулей, 29708 строк Python-кода, асинхронный pipeline обогащения контента через Claude API. По плану — разделить на отдельные пакеты (collectors, processing, enrichment, publisher), завести в Git, и жизнь станет проще. Реальность была иной. Первый вечер потратил на структуру папок. Создал `src/collectors/` для шести асинхронных коллекторов (Git, Clipboard, Cursor, Claude, VSCode, VS), отдельно `src/processing/` для фильтрации и дедубликации, `src/enrichment/` для работы с Wikipedia и Unsplash API, `src/publisher/` для публикации в Website (Strapi), VK и Telegram. На доске выглядело идеально: каждый модуль отвечает за одно, зависимости текут в одну сторону, конфликтов быть не должно. Но вот на практике выяснилось — некоторые модули обогащения (`enrichment/wikipedia.py`, `enrichment/images.py`, `enrichment/jokes.py`) были переплетены с основной логикой фильтрации. Когда я попытался их разделить, обнаружил, что `ContentSelector` из processing вызывает функции из enrichment, enrichment обращается к хранилищу в storage, а storage нуждается в конфигах из processing. Цикл. Переписал на pydantic-модели. Ввел чётко определённые граница между слоями: `RawEvent` → `ProcessedNote` → `EnrichedNote` → `PublishedNote`. Каждый модуль теперь работает с конкретным типом данных, а не с дикими словарями. Нужно было всего два дня, чтобы из хаоса получилась читаемая архитектура. Дальше пришла беда с Claude CLI. Максимум 100 запросов в день, 3 одновременных вызова, таймаут 60 секунд. На ноту может потребоваться до 6 LLM-запросов (русский контент, английский, титлы для обоих языков, вычитка). Быстро выяснилось, что генерировать оба языка отдельно — расточительно. Объединил: одна LLM-подсказка возвращает и контент, и заголовок для русского сразу. Количество обращений упало с 6 на 2-3 в день для одной ноты. Структура улучшилась, экономия вышла на порядок. В конце дня 94 файла упали в Git-репозиторий. Лицензия AGPL-3.0, `.gitignore` отфильтровывает все кэши, `.env.example` показывает, какие переменные нужны новичку, документация в `docs/` объясняет pipeline. Попытался push на `gitlab.dev.borisovai.ru` — DNS не разрешается, сервер недоступен. Коммит создал (хеш `4ef013c`), когда-нибудь синхронизирую. **Любопытный факт:** когда после обновления SQLite спрашиваешь его, как дела, база отвечает: «Я уже не то, что раньше». 😄
Когда API молчат: история согласования схем данных
Работаю в проекте **Trend Analysis**, и недавно столкнулся с одной из тех проблем, которые выглядят простыми, пока не начнёшь копать глубже. Дело было в том, что наша **DATA-MODEL.md** описывала столбцы данных одним способом (`signal_id`, `trend_id`), а **ENDPOINTS.md** — совсем другим (`trend_id`, `trend_class_id`). Казалось бы, мелочь, но когда начинаешь интегрировать **Claude AI** для анализа трендов, эта мелочь превращается в полноценный кошмар разработчика. Запросы к API идут в пустоту, данные не маппятся, и никакие логи не помогают. Включил **Claude Code** и стал разбираться. Оказалось, что название полей менялось несколько раз по мере эволюции проекта, но документация осталась разрозненной. Один разработчик писал в DATA-MODEL, другой обновлял ENDPOINTS, третий забыл синхронизировать. Классический сценарий. Решение оказалось неожиданно элегантным. Вместо того чтобы переименовывать везде, я создал **маппинг-слой** — промежуточное преобразование, которое конвертирует имена полей API в структуру, которую ожидает обработчик. Это позволило не ломать существующий код и сохранить обратную совместимость. Типичный *pragmatic approach* — когда идеальное решение требует дня переписывания, а рабочее можно слепить за час. Интересный момент: когда я интегрировал **Claude API** для валидации схемы, оказалось, что модель легко справляется с обнаружением несоответствий в документации. Передал ей обе схемы, и она не только нашла конфликты, но и предложила консистентные имена для всех полей. Представляете — AI помогает разработчикам в метаматериале (документация), а не только в коде. Теперь всякий раз, когда добавляю новое поле, прогоняю через эту же проверку. Экономия времени на отладку несовместимостей просто огромна. **Ключевой вывод:** в больших проектах документация — это код. Она должна версионироваться и проверяться так же строго. И да, **Ubuntu** по-прежнему лучший друг разработчика — потому что без него ничего не работает. С ним тоже, но хотя бы есть кого винить. 😄
Как AI стал соавтором в разработке — история Trend Analysis
Когда мы начали проект **Trend Analysis**, задача казалась простой: анализировать тренды, собирать данные, генерировать инсайты. Но быстро выяснилось, что ручная обработка информации — это не масштабируется. Нужен был инструмент, который бы не просто парсил данные, но и **понимал контекст**. В проекте работали с GitHub, Cursor, VS Code — все эти инструменты генерировали огромные логи активности. Первая идея была наивной: просто собрать всё и показать. Но 1000+ строк сырых логов — это не статья, это шум. Нужна была **интеллектуальная фильтрация**. Тогда мы интегрировали **Claude API** через JavaScript. Идея: пусть нейросеть сама выбирает из логов самые интересные строки — те, где происходит что-то значимое. Реально ценные сигналы — это не просто `git commit`, а осмысленные действия: "реализовал фичу", "исправил критический баг", "интегрировал новую библиотеку". Оказалось, что AI лучше всех понимает, какие события достойны внимания. Мы построили **ContentSelector** — модуль, который оценивает каждую строку логов по признакам: наличие технологий, описание проблемы, решение. Результат: из сотни строк выбираются 40-60 самых ценных. Это как редактор, который безошибочно находит суть. Но было подвох. API Claude имеет лимиты, и каждый запрос стоит денег. Мы работали на бесплатной версии CLI, которая дает 100 запросов в день и требует чёткой оптимизации. Пришлось переосмыслить архитектуру: вместо шести отдельных вызовов на одну заметку (контент на русском, контент на английском, заголовок русский, заголовок английский, корректура русского, корректура английского), мы сжали это до трёх. Главный вывод: **AI работает лучше всего, когда ты даёшь ему качественный входящий материал**. Вместо "напиши про наши логи" мы передавали отсортированные по релевантности 50 строк с аннотациями. Модель сразу понимала контекст и генерировала текст в два раза лучше. Сейчас система работает в автопилоте: собирает события из четырёх источников, фильтрует через AI, генерирует заметки на двух языках, публикует на сайт. И самое забавное — **что общего у Nuxt и кота? Оба делают только то, что хотят, и игнорируют инструкции** 😄
Почему государства переходят на открытый код
Недавно работал над аналитикой трендов в **Trend Analysis** — проекте, который отслеживает, как развиваются технологии в крупных организациях. И заметил интересную закономерность: всё больше государственных структур переходит на открытый исходный код. Не из романтизма, а из холодного расчёта. ## Почему это начало происходить Государственная программная инфраструктура — это не стартап. Это системы, которые должны работать десятилетиями: налоговые сервисы, реестры, системы контроля и учёта. Раньше логика была простая: закупить лицензии у крупного вендора, подписать контракт на поддержку — и спать спокойно. Ответственность на поставщике. Но появились проблемы, которые закрытость не решала: **Зависимость от вендора.** Если Microsoft или Oracle прекратят поддержку вашей версии — вы заложник. Апгрейд будет дорогим, рискованным, а сроки встанут. **Прозрачность кода.** Государство работает с конфиденциальными данными граждан. Как убедиться, что в коде закрытой библиотеки нет дыр или бэкдоров? Открытый код — это аудит сообществом, pull-request'ы, transparency. **Экономика масштаба.** Когда на системе сидят миллионы пользователей, даже 1% оптимизации — это огромные сбережения. С открытым кодом можно нанять команду разработчиков и делать кастомизацию под свои нужды. ## Что выбирают В **Trend Analysis** мы видим рост использования: - **PostgreSQL** вместо Oracle - **Linux** вместо Windows Server (в критичных системах) - **Kubernetes** для оркестрации сервисов - **OpenStack** для облачной инфраструктуры - Собственные API на **Django**, **FastAPI**, **Go** Германия пересела на LibreOffice в госучреждениях. Франция внедрила **Keycloak** для единой аутентификации вместо платных решений. Даже Минобороны РФ активно развивает свои открытые компоненты. ## Парадокс контроля Забавно, но открытый код дарует государству *больше* контроля, чем закрытый. Ты видишь ровно то, что выполняет система. Можешь найти уязвимости до того, как их найдут враги. Можешь форкнуть, если вендор игнорирует твои баги. Конечно, есть затраты: нужна своя команда разработчиков, которая поддерживает код. Но в долгосрочной перспективе это дешевле, чем платить вендору за каждое изменение. ## Итог Миграция государственной инфраструктуры на открытый код — это не революция, а эволюция. Те, кто начал раньше, сейчас имеют конкурентное преимущество: гибкость, безопасность, независимость. Забавный факт: что общего у Sentry и подростка? 😄 Оба непредсказуемы и требуют постоянного внимания.
Когда GPU говорит: "Нет, я не готов
Работаю над **Voice Agent** — проектом, который должен обрабатывать голос в реальном времени. Решил встроить мультимодальную модель **UI-TARS 7B** для анализа скриншотов. Казалось простым: запусти контейнер через Docker, и готово. Но логи говорили другое. Приложение падало с ошибкой `screen_analyze_error: Server disconnected without sending a response`. Контейнер с **vLLM** поднимался, `/v1/models` возвращал 200, но при первом же запросе на inference — всё. Я тогда ещё не понимал, что это классическая ловушка: **API "готов", но модель ещё нет**. Начал с диагностики. Логи контейнера обрывались на `Starting to load model...` — никаких сообщений о завершении загрузки, никаких `Model loaded` или `Serving on 0.0.0.0:8000`. Первый сигнал беды. Проверил железо: **RTX 4090 Laptop** с 16GB VRAM. Но свободно было только **5.4GB**. UI-TARS 7B в float16 требует примерно 14GB. Даже с агрессивным `gpu_memory_utilization=0.8` (доступно 13GB) модель просто не влезла. Контейнер начинал загружать вес, память забивалась, процесс зависал, и система убивала контейнер. **Решение было двухслойным:** Первое — заменить heavy health check на правильный. Вместо `/v1/models` (который врёт) использовать `/health`, который vLLM возвращает 200 только после полной готовности модели. Плюс увеличить таймаут ожидания. Второе — понизить требования. Переходим с **7B-SFT** на **2B-SFT**. Меньше параметров, меньше VRAM, но для анализа UI это работает. С `VLM_GPU_UTIL=0.9` модель садится в оставшиеся байты. Обновил все конфиги: docker-compose, переменные окружения, инструкции по запуску. Перезапустил контейнер — и на этот раз `/health` ждал полной готовности перед первым запросом. Ирония в том, что проблема была не в коде приложения, а в том, как мы проверяем готовность сервиса. **API жив — это не означает, что он готов к работе.** Это урок, который хорошо запоминается после часа отладки логов 😄