Log & roll №3

У меня все равно плохо получается регулярно о чем-либо сообщать, потому что бывают такие моменты, когда написать нечего — рутина и рутина. В первую неделю после отпуска, сколько бы я ни был заряжен на работу, она вообще не шла в том темпе, в котором хотелось бы. Но за три недели что-то да накопилось.

💼 Работа

Я продолжил заниматься задачей по временным рядам, хорошо по ней продвинулся: добавил недостающие метрики, сделал кучу фиксов, написал огромную доку по каждому аспекту, докинул разные аугментации — в основном рутина, но отдельные моменты отмечу:

1️⃣ Подбор гиперпараметров

Оформил подбор гиперпараметров в максимально удобный скрипт, запустил и получил результаты. Скажу так: это шикарная возможность поднять метрики, особенно если есть ресурс на 20+ запусков обучения, а в моем случае это было возможно, поскольку модель очень легковесная. Здесь важно понимать, какой метод вам подойдет — будь то ASHA, которая при шаге, равном полному обучению, вырождается в Random Search, или же Model-based методы типа Байеса (однажды я напишу статью об этом...).

Капля дегтя – разные методы поддерживают разные типы данных – где-то есть поддержка категорий, где-то ее нет, где-то даже была поддержка квантованных (для русских людей – просто с меньшим числом значений после запятой, чтобы не было потом 0.232545589 в конфиге), но её убрали в новых версиях.

2️⃣ Пайплайн проекта

В этой задаче для разных типов временных рядов используются разные предобработки и модели, в связи с чем была необходимость в реализации достаточно серьезного пайплайна. Основная цель — сделать так, чтобы на вход можно было просто отправить практически любой ряд + его тип, а на выходе получить верный ответ. Я подошел к реализации с помощью Triton Business Logic Scripting (BLS). Я думал написать пост о нем, но не сложилось. (Если нужно, сообщите в комментах, потому что у меня в сохраненках два текста по нему, оба бросил 👍).

Если кратко, то BLS — это скрипт на Python, который в Triton Inference Server трактуется как независимая модель. То есть, к ней так же пишется конфиг с I/O модели, внутри скрипта model.py реализуется класс с методом execute, а дальше делай с питоном все, что захочешь. И я сделал две обычные TensorRT модели, дописал BLS-скрипт, в котором вся-вся логика предобработки + отправка рядов в нужную модель + логика постобработки. Разумеется, сделал асинхронное обращение к моделям.

Самое неприятное в этой задаче — куча разных мелочей, которые вылезают, потому что человеческий мозг (окей, подмножество {мой мозг}) не вмещает все нюансы разом. Это различные размерности, это правильная конвертация тензоров одного бэкенда в другой, это... в общем, об этом читать неинтересно. Главное — оно заработало, а я задолбался.

3️⃣ Документация

Документации было много, вплоть до ссылки на другие README внутри основного, но это не главное. Оказывается, в Gitlab есть поддержка Mermaid-графов, которые позволяют шикарно визуализировать пайплайн модели. Причем, судя по всему, эта поддержка есть уже давно. Да, достаточно просто написать '''mermaid, описать диаграмму и она появится в доке. Магия да и только. К сожалению, в Github не завезли.

👨‍💻 Продолжил рефакторинг BoxMOT

Я обнаружил еще одну важную проблему — в проекте мало того, что дублируется, так еще и разбросана в разных местах логика скачивания весов моделей. Я решил сделать так: назвал эту сущность ModelRegistry, дал ей геттеры, чтобы узнавать URL/названия доступных моделей, а также метод download. И все ее наследники должны просто прокинуть свои словарики с URL весов и прочей информацией, которая нужна для загрузки.

Затем у меня была долгая дилемма по поводу связывания различных сущностей вместе, но решилось это примерно так: роль скачивания берет на себя ModelRegistry, роль инициализации pytorch-модели берет на себя непосредственно класс модели — ReID или Detector, назовем этот метод build, а в PytorchBackend на вход будем подавать модель + веса.

Негусто, но немного продвинулся.

В иных аспектах пока тоже все в порядке — жизнь бьет ключом, пока что не по голове.

#lognroll