Фреймворк HEART

Фреймворк помогает оценивать пользовательский опыт по 5 направлениям:
Happiness, Engagement, Adoption, Retention, Task Success

📺 Видео на Youtube

❤️ Happiness. Удовлетворённость
🎯 Цель: Пользователям должно быть легко, полезно и приятно пользоваться приложением.

Сигналы:
1. Оставляют отзывы в сторах
2. Делятся мнением в опросах

Метрики:
1. TPS/NPS (готовность рекомендовать)
2. Доля 5-звёздочных оценок
3. Оценка обратной связи

😱 Engagement. Вовлечённость
🎯 Цель: Пользователи регулярно потребляют контент и взаимодействуют с продуктом.

Сигналы: Время, проведённое в приложении, растёт

Метрики:
1. Среднее время сессии на пользователя
2. Конверсия в целевое действие
3. Кол-во визитов на пользователя

🚀 Adoption. Принятие
🎯 Цель: Новые пользователи начинают находить ценность в продукте.

Сигналы:
1. Рост установок
2. Рост регистраций
3. Рост логинов

Метрики:
1. Доля установок
2. % новых пользователей
3. Кол-во логинов / DAU

🔄 Retention. Удержание
🎯 Цель: Пользователи возвращаются в продукт, чтобы снова достигать свои цели.

Сигналы:
1. Растёт число активных пользователей
2. Растёт доля повторных визитов

Метрики:
1. % повторных пользователей
2. DAU, WAU, MAU
3* Retention 7D / 14D / 30D

✅ Task Success — Успешность действий
🎯 Цель: Пользователь с лёгкостью достигает того, зачем пришёл.

Сигналы: Увеличивается число успешно завершённых задач

Метрики:
1. % ошибок
2. % прерываний (drop-off)
3. % ANR (приложение не отвечает)

В целом, HEART — это как проверочный список: что именно важно для вашего UX прямо сейчас?
А ещё классно использовать его не в одиночку, а с продактом, дизайнерами и ресёчерами — чтобы не тянуть UX в одну сторону, а двигаться вместе.

Понравился пост? Ставьте 🐳, пишите в комментарии, что разобрать дальше!

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