Блог
Публикации о процессе разработки, решённых задачах и изученных технологиях
Как я ловил лучший seed в поиске по нейросети
Поднялся с дивана, кофе в руках, и понял: нужно найти оптимальный seed для LLM Analysis. Проект требовал прорыва — текущий baseline давал 72.86% accuracy, а это было не достаточно для production. Задача казалась простой на первый взгляд: протестировать 20 разных seed'ов, каждый из которых порождает свою инициализацию модели. Но за этой простотой скрывалась неприятная правда — каждый seed требовал примерно 100 минут вычислений. Около 30 часов чистого времени на поиск. Я запустил *seed_search.py* и отправил в фоновый процесс через nohup — пусть работает сам, а я займусь остальным. Первый результат удивил: **seed 1 показал 76.5% на 200-м checkpoint**, то есть улучшение на 3.64 процентных пункта. Не революция, но движение в правильном направлении. Скрипт работал стабильно, результаты накапливались в *results_seed_search.json* с поддержкой resume — если процесс упадёт, просто перезапусти, и он продолжит с того же места. Пока seed'ы считались, я занялся параллельной работой. Написал *augment_problems.py*, который превратил 6604 оригинальные задачи в 39,582 вариации — это база для самодистилляции модели. Одновременно готовил *majority_voting.py* для голосования между Orchestra и baseline, и *dual_orchestra.py* для двухэтапной архитектуры с промежуточными слоями. План кристаллизовался в голове. После того как seed search закончится (ещё дня три), я: 1. Проанализирую распределение 20 результатов и выберу лучший seed 2. Запущу majority voting на лучшем checkpoint'е 3. Построю Dual Orchestra Stage 1, используя лучший seed как базу 4. Натренирую self-distillation на 39K augmented problems Технология за всем этим простая, но упрямая. Claude как основной LLM — быстрый, достаточно точный для анализа. Python для оркестрации процесса, JavaScript где-то в соседних сервисах. Но главное — это терпение и систематичность. Через месяц, если всё сойдётся, эта модель будет работать лучше. А пока я жду результатов, попивая остывший кофе. **Забавный факт:** Kafka и мой чёрный кот имеют одно общее качество — оба делают только то, что хотят и активно игнорируют инструкции. 😄
Когда промежуточные данные расскажут больше, чем финальный результат
Работал над **LLM Analysis** — проектом для изучения того, как модели обучаются на примерах. Задача казалась простой: запустить экспериментальный скрипт `train_exp29b.py`, проверить метрику точности и двигаться дальше. В Python и JavaScript легко впасть в такую ловушку — сосредоточиться только на конечном результате, забыв про промежуточные шаги. Запустил первый эксперимент. Финальная точность на задачах GSM8K составила 75%. Нормально, но не блеск. Обновил скрипт с другими параметрами — снова 75%. Третий раз... и вдруг заметил что-то странное. В логах stdout мелькали числа: 76%, 78%, 79.3%. Но функция `eval_gsm8k()` возвращала только финальное значение — 73% на последней итерации. Это был момент озарения. Я пропустил **пик производительности в 79.3%** просто потому, что смотрел только на конец кривой, а не на саму кривую. Функция писалась для простого GO/NO-GO вердикта: "работает или нет?" Промежуточные данные терялись в консоли и никуда не сохранялись. Переписал `eval_gsm8k()` так, чтобы она возвращала массив `intermediate` — точность после каждых 50 задач — и отдельное поле `peak` с максимальной точностью и номером проверки, на которой она достигнута. Теперь все промежуточные результаты автоматически попадают в `results.json`. Обновил оба скрипта синхронно, добавил правило в MEMORY.md: **"КРИТИЧНО: Промежуточные eval данные"**. Когда собрал полные данные фаз 28–29, картина кардинально изменилась. На 150 задачах с curriculum-данными модель достигала **79.3% — это на 4 процентных пункта выше, чем в любых других экспериментах** на том же чекпоинте. Curriculum стратегия работала, но только на подмножестве! На остальных задачах производительность падала ниже базовой. Главный вывод: **потеря промежуточных данных — это потеря сигнала**. Когда код работает в черном ящике и сообщает только финальный вердикт, мы слепы к динамике обучения, к моментам перелома, к точкам отказа. В JavaScript-проектах это часто выглядит как натуральная логика: запустил `async function`, получил Promise, обработал результат. Но в машинном обучении каждый шаг — это данные. Теперь следующий этап — понять, **какие именно задачи выигрывают от curriculum подхода и почему остальные страдают**. Это требует детального анализа, но теперь у меня есть, на что смотреть. --- *Кстати, почему NestJS расстался с разработчиком? Слишком много зависимостей в отношениях.* 😄
Как мы потеряли пик 79.3% и что теперь делать
Работаю над LLM Analysis — экспериментирую с curriculum learning для модели на задачах GSM8K. Phase 29a показала странный результат: когда я обучал модель на первых 150 задачах из 500, она достигала **79.3% accuracy**. Но потом финальный тест на всех 500 задачах давал только 72.1%. Вроде неплохо, но что-то было упущено. Разбираюсь в логах и вижу: промежуточные данные **печатались в stdout каждые 50 задач**, но я их попросту не сохранял структурно. Читал только финальный результат из `results.json`. Получалось, что 79.3% — это просто число, которое пронеслось мимо моего мониторинга. Я видел кривую в консоли, но не анализировал её как систему. Вот что произошло на самом деле: модель на первых 150 задачах решила **119 из 150** (79.3%), но на оставшихся 350 задачах только **246 из 350** (70.3%). Curriculum подход — обучение от простого к сложному — оказался эффективнее на начальном наборе и вредоносен на конце. Это не ошибка модели, это сигнал о том, что я смотрю на данные неправильно. **Почему пропустили пик?** Во-первых, `eval_gsm8k()` возвращала только финальное число. Промежуточные вычисления существовали, но были скрыты в stdout. Во-вторых, мониторинг работал через GO/NO-GO вердикт: если final accuracy выше порога — пускаем в production, если ниже — отправляем на переобучение. Никто не спрашивал: *а почему кривая имеет такую форму?* В-третьих, я не сохранял промежуточные результаты в структурированном виде. **Что меняю в правилах:** Теперь каждая функция оценки возвращает полный массив `intermediate_results` — не просто финальный скор, а весь путь модели через батчи. Добавляю в `eval_gsm8k()` сохранение данных по 50 задач и запись в отдельное поле JSON. Плюс — обязательный анализ кривой: если падение accuracy между батчами больше чем на 5%, логирую это как сигнал тревоги. Phase 28 теперь включает эту метрику. Phase 29a переделаю с новым tracking. И самое важное — я перестану смотреть только на финальное число. Теперь вижу всю траекторию обучения, все взлёты и падения. Curriculum learning показал, что простые задачи — это не просто ступенька, это отдельный класс данных, который требует своего внимания. Funny fact: в NoSQL базах тоже часто "теряют" данные — когда забывают про индексы и потом удивляются, почему запрос на миллион документов работает как замёрзший слон 😄
Когда перевод ломает капитализацию: история про русские аббревиатуры
Работаю над **Trend Analysis** — проектом, который собирает, анализирует и показывает тренды из разных источников. Фронт на JavaScript, интеграция с Claude API для генерации контента и переводов. Вчера заметил странное: узлы графика отображают русские названия, но с поломанной капитализацией. "Финансирование инвестиций в ии" вместо "Финансирование инвестиций в ИИ". Данные приходят от бэкенда корректно — проблема на клиенте. Начал искать виновника. В коде фронта нашёл функцию `formatClassName()` — она отвечает за форматирование названий узлов. На первый взгляд логика выглядела стандартной: первая буква заглавная, остальное в нижний регистр. Но тут же понял подвох. Функция применяет sentence-case трансформацию ко *всем* текстам, включая уже переведённые на русский. Когда `toLowerCase()` срабатывает на "ИИ" (русские заглавные буквы), они становятся "ии". Английские аббревиатуры спасала специальная таблица `ABBREVIATIONS` с исключениями вроде "LLM", "API", "AI". Но русских аббревиатур там не было. США, ЕС, ИИ — всё падало жертвой функции. Решение нашлось через детектирование языка прямо в `formatClassName()`. Если текст содержит кириллицу — он уже переведён и корректно капитализирован на бэкенде (там работает `_enforce_sentence_case()` через Claude). Значит, нужно просто гарантировать заглавную первую букву и *не трогать остальное*. Английский текст обрабатывается по старой логике с `ABBREVIATIONS`. Итог: добавил регулярное выражение для проверки на non-ASCII символы. Non-ASCII текст — минимальная обработка (только первая буква). ASCII текст — полная sentence-case логика. Тесты прошли, билд собрался, и теперь "Финансирование инвестиций в ИИ" отображается так, как положено. **Финальный факт**: многие разработчики забывают, что `toLowerCase()/toUpperCase()` в JavaScript работают правильно только для ASCII. С кириллицей, греческими буквами и иероглифами нужна осторожность — часто проще положиться на исходную капитализацию источника, чем переделывать её в коде. 😄
Как мы спасали аналитику трендов от невидимых багов
Работаю над **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 и подростка? Оба непредсказуемы и требуют постоянного внимания 😄
Пять проектов, которые окупают себя за месяц
Я сидел над **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 непредсказуем? Наши проекты тоже. Но они работают. 😄
Монорепо, который заставил пересмотреть структуру проекта
Когда решил мигрировать **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 спрашиваешь его, как дела, база отвечает: «Я уже не то, что раньше». 😄
Как 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 и кота? Оба делают только то, что хотят, и игнорируют инструкции** 😄
Когда 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 жив — это не означает, что он готов к работе.** Это урок, который хорошо запоминается после часа отладки логов 😄