Спустя непродолжительное время (кого я обманываю), вот мой обзор на Ray Serve

К сожалению, я им не пользовался, поэтому компилирую свой рисеч.

Что умеет:
1. Автоскейлинг моделей (Смотрит на запллнение очереди к модели и по необходимости поднимает или гасит модель. Если запросов нет, то может вообще выключить модель)
2. Полный набор примитивов для построения dag-ов (Кажется, что из последовательного, параллельного и выбор по условию можно собрать любой граф)
3. Интегрируется с fastapi (приятно получить бесплатный свагер и валидацию запросов)
4. Позволяет разделить разные dag-и (меньше перемешивания пайплайнов)
5. Имеет свое разделяемое хранилище, куда складывает большие объекты
6. Есть возможность управления ресурсами (можно сказать, кому сколько надо гпу, и при достижения лимита, Ray придержит коней)
7. Говорят, что все можно потестить локально
8. Часть экосистемы (обучение, тюнинг, сервинг и др.)

Из минусов:
1. Тензоры гоняются по сети, так как модели раскладываются по подам
2. Приколы с утекающей памятью (привет, разделяемое хранилище)
3. Сломы обратной совместимости
4. На каждое обновление переподнимаете кластер
5. Нельзя ранить onnx, torchscript, tensorrt?! (чет так и не нашел в доке)

Большинство минусов подсказали в коментариях к предыдущему посту, за что большое спасибо!

Прикольная библиотечка для валидации данных Great Expectations

Позволяет подключиться к вами данным (есть куча интеграций с постгресами, авсами и тд), прогнать тесты и сформировать отчет. Работает для табличек. Выглядит неплохо. Дока вроде обширная.

Кто вообще как проверяет датку? Особенно интересно узнать, как валидируете что-то кроме таблиц. На неделе расскажу, как покрывали тестами разметку на работе.

На работе столкнулся с проблемой, что сделанные вне репозитория схемы или диаграммы (например, в Miro) быстро устаревают, потому что забывают обновлять. Решил бороться с этим путем хранения их вместе с кодом.

Держать картинки или pdf мне не нравится, потому что:
- Быстро раздует размер репозитория, особенно pdf;
- Нельзя посмотреть, что именно изменилось.

Мой взгляд пал на языки описания схем. Например Murmaid или PlantUML. Эдакий Latex, но для диаграмм. Они позволяют создавать блоксхемы, диаграммы последовательности, ганта, классов и др.

Описание - это текст. Его можно отрисовать как в бразузере (1, 2), так и с помощью расширений для IDE.

Выглядит так:

flowchart LR
A[Hard] -->|Text| B(Round)
B --> C{Decision}
C -->|One| D[Result 1]
C -->|Two| E[Result 2]

На мой взгляд - это хороший вариант, потому что:
- Документация всегда актуальна для выбранной ветки;
- Просто следить за тем, внесены ли изменения в схему (отобразятся на код ревью);
- Видно, какая именно часть схемы изменена;
- Нет проблемы с утяжелением репозитория (это просто текст);
- Чтобы просмотреть схему, не нужно логиниться во внешние ресурсы.

Сейчас идет дата фест. Он получился, действительно, с размахом - секций очень много.

Мне крайне зашел первый день reliable ml. Клевый микс из докладов, интервью и дебатов. Всем советую к просмотру. Вас ждет мл дизайн, фейлы в дс, а также Валера Бабушкин и топы из других компаний.

Обещенная история из рабочего опыта

Для проекта с некоторой периодичностью отдаем данные с прода в разметку. Казалось бы, собрал, отдал, обработал. Что может пойти не так? Я стрелял себе в ногу на каждом из этапов 🌚

Что шло не так при разметке 3д данных на сегментацию, загибайте пальцы:
- Мы отдали данные, которые не открываются 👀
- Мы отдали неполные данные (половина просто не докачалась)
- Мы не проверили высоту данных (а нужно от определенной размечать)
- Разметчик забил на то, что маска не сохранилась (не ну а чо)
- Объект меняет класс (с одной стороны один класс, с другой - другой)
- Встречались микрообъекты из пары пикселей, потому что разметчик случайно мискликнул
- Разметчик забил на то, что не сработала интерполяция
- Нам отдали данные в не пойми каком формате
И это далеко не полный список того, что шло не так ))0)

А теперь следите за руками. Все перечисленные проблемы были решены автотестами! Простейшими из разряда, проверить что файл открывается, называется по шаблону, все объекты включают пиксели одного класса и тд. Ими проверяется как работа команды разметчиков, так и наша работа по отбору данных. Вы не поверите, скольких проблем избежите в будущем, сделав проверку по типу "Если их впустили, то они вошли".

Видимо поэтому набирают обороты библиотеки для проверки данных. Для 3д данных не нашли ничего, поэтому просто написали на pytest, где каждый тест - это одна проверка. Там, где нужно читать данные, мы объединили тесты. Все ошибки дополнительно пишем в лог с указанием их типов, сообщений и путей до файлов. Дешево и сердито.

Так что "не гоняйте забивайте на тесты, пацаны, вы матерям еще нужны"

Наткнулся на клевую подборку постов от компаний, как они делали мл. Есть описание самых разных систем - от картинок, до оттока. Я уже поглядел, как Apple в айфонах людей на фото ищет 👀

В копилку фишечек для обучения

Stochastic Weight Averaging (SWA)

Идея простая - результирующие веса получаем за счет усреднения нескольких чекпоинтов.

Интуиция за методом - оптимизатор застревает на краю плато (равнины) поверхности лосса, так как нет сигнала, которой загнал бы его в центр. Усредняя несколько чекпоинтов с краев плато, мы получаем точку ближе к центру.

Алгоритм:
- Учимся как обычно до схождения
- Фиксируем lr (можно и изменять), чтобы нас пошвыряло вокруг локального минимума, сохраняя веса с разных итераций
- Усредняем веса, чтобы получить окончательный чекпоинт
- Делаем прогон трейн данных на получившихся весах, чтобы обновить Norm слои (BatchNorm, LayerNorm и тд.)

Авторы утверждают, что работает для любого оптимизатора и задачи (CV, NLP и даже RL)

Уже реализовано в торче с версии 1.6 в torch.optim.swa_utils и реализуется в пару строчек

Интересный метод ZipIt, который позволит объединить обученные на разных задачах две модели одинаковой архитектуры в одну, по крайней мере для классификации. Если задачи слишком разные, то склеивают только часть слоев, а остальные образуют две головы (как на картинке). Авторы рапортуют просадку всего в пару пунктов по сравнению с использованием двух моделей по отдельности.

Сначала идея мне показалась прикольной, полезной для практики. Я уже обрадовался, что сейчас как расскажу о такой нужной вещи.

Однако я так и не придумал ей применения, кроме как ситуации, когда нет возможности что-то учить. Ведь можно же дистилировать две модели в одну или одну во вторую. Для этого даже можно не использовать данные, на которых училась модель, подавая на вход случайные векторы.

Что думаете на этот счет?

Заходят в бар три примера - класс 0, класс 1 и OOD (out of distribution).
Бармен им уверенно: "А я вас знаю!".

Сеточки часто бывают сверхуверенными в своих ответах. Особенно на тех примерах, которые не похожи на обучающие данные. Если для вашего случая возможна ситуация, когда от пользователя поступают такие примеры, то этим нужно озаботиться еще на обучении.

В этом докладе с датафеста, ребята боролись с такой проблемой. Они классифицировали вторсырье на 3 известных класса. Все остальное должно было попасть в 4 класс.

Спойлер - остановились на CAC Loss (Class Anchoring Clustering).

Идея в следующем:
- На обучении в пространстве признаков определяем N точек (центров) по числу классов
- Далее стягиваем примеры к центру своего класса, отталкивая от чужих
- На инференсе считаем расстояния до всех центров
- Если далеко от всех, то это OOD. Иначе - соответствующий центру класс

Код и папира от авторов.

Не секрет, что скрипты для обучения часто имеют множество параметров, которые задаются аргументами командной строки. Пожалуй, самый популярный для этого инструмент - это ArgumentParser из argparse, который входит в стандартную библиотеку Python.

В общем-то неплохая вещь, но лично я всегда испытывал некоторый дискомфорт:
1. Не хватает подсказок IDE. Когда параметров несколько десятков, легко опечататься или просто забыть имя аргумента
2. Поведение типа bool ломает мне мозг. Очень хочется простой человеческой возможности написать True, False в качестве значения аргумента
3. Много повтора кода. Для каждого аргумента пишешь parser.add_argument() и имена аргументов type, help и тд.

Моему счастью не было предела, когда я обнаружил библиотечку TypedArgumentParser.

Было:
from argparse import ArgumentParser

parser = ArgumentParser()
parser.add_argument('--language', type=str, default='Python', help='Programming language')
parser.add_argument('--stars', type=int, required=True, help='Number of stars')
parser.add_argument('--max_stars', type=int, default=5, help='Maximum stars')

args = parser.parse_args()

Стало:
from tap import Tap

class SimpleArgumentParser(Tap):
language: str = 'Python' # Programming language
stars: int # Number of stars
max_stars: int = 5 # Maximum stars

args = SimpleArgumentParser().parse_args()

Все мои боли решены:
1. IDE подсказывает имена
2. SimpleArgumentParser(explicit_bool=True) делает поведение bool абсолютно понятным. Передаешь --arg false, и твой arg получает значение False.
3. Кода стало меньше

Попробуйте. Вам понравится.

Вчерашний пост показал разнообразие предпочтений. Мне стало интересно, а что популярнее? Посмотрим, на смещенной выборке подписчиков данного канала :)

Хороший доклад "Bag-of-tricks того, как сделать ваш ML-пайплайн более reliable" с советами, что делать, чтобы мл-проект не превратился в тыкву, которую невозможно поддерживать и развивать. Докладывает легендарный Богдан, автор канала @bogdanisssimo

Спойлер - использовать практики из традиционной разработки.

1. Не забывайте и про то, что кроме мл
Ошибкам подвержены все части системы, а не только часть с мл.
2. Код - это ваш продукт
Уделяйте внимание сложности и читаемости. Используйте линтеры и тайп-чекеры.
3. Пишите тесты
Тесты - это этакий регуляризатор для вашего кода. Когда они есть, вы вынуждены, например, его модуляризировать, что упрощает поддержку.
3.1 Юнит-тесты. Не забывайте о DRY, мокайте внешние зависимости и проверяйте обработку ошибок.
3.2 Смоук-тесты. Быстрая проверка, что оно работает.
3.3 Тесты поведения модели. Например, стройте Partial dependence plot и проводите Negation test.
3.4 Проверяйте консистентность работы между средами. Вы должны быть уверенными, что расчет метрик, например, одинаков между трейном и продом.
4. Настройте логирование
Достаточное логирование позволит быстро разбираться с инцидентами.
5. Продумайте деградацию системы
Заранее определите сценарии работы системы, когда мл-часть сломалась или не справляется с нагрузкой. Для одних задач нужно перестать давать предсказания, а для других - отдавать хотя бы какие-то.
6. Не забывайте про bus-фактор
Следите за тем, чтобы знания о системе не были заключены в одном человеке. Ведите документацию, распространяйте знания и тд.

Как сказал один мудрец - "Один-два раза вот это упражнение делаешь спина код болеть не будет".

- Алло, привет! Нет времени говорить, но я больше не люблю poetry и пользуюсь pip-tools
- Так ты же мне и позвонил О_о
- Ту-ту-ту

В общем да, буду краток. Poetry мне так и не зашел. Когда дело доходило до докеров, вечно почему-то спотыкался об него.

Теперь пользуюсь pip-tools. Умеет все то, что нужно для счастья, используя pip под капотом:
- Фризить все зависимости (зависимости зависимостей) - pip-freeze
- Синхронизировать синхронизировать виртуальное окружение с тем, что зафиксировано - pip-sync
- Обновлять пакеты, учитывая резолвя зависимости - pip-compile --upgrade

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

Но все-таки это случилось. Это оказалось проще, чем я думал, ведь популярные опенсорсные разметчики (например, Cvat и Label Studio) умеют работать с вашими моделями (а также особо популярные уже интегрированы за нас).

Если вам нужно размечать сегментацию, то вы можете:
1. Поднять Label Studio одной командой в докере
2. Поднять Segment Anything в качестве модели для интерактивной разметки одной командой в докере
3. Создать и настроить проект для разметки

Вы великолепны! Теперь разметка идет быстрее. Добавлять свои модели также не сложно.

Пришло и мое время быть современным 👴🏼

Кайфовый видосик со сравнением инструментов для раскатки моделей на Kubernetes

Автор сравнивала:
- Kserve (2.4к ⭐️)
- Seldon Core (3.9к ⭐️)
- BentoML + Yatai (5.6к ⭐️)

TLDR: Фреймворки имеют одни и те же фичи, то есть +- одинаковые. Если начинаете с нуля, то присмотритесь к связке BentoML (сервит модели) и Yatai (развертывает инференс сервер на кубер)

От себя добавлю, что недавно писал сервинг на BentoML. Мне понравилось. Много интеграций с фреймворками для моделей, встроенный FastApi и Pydantic, граф обработки задается на питоне. Приятно было работать. Но в кубер, к сожалению не катил, как впрочем и в прод ))0)

Если у вас иногда возникает желание подтянуть БАЗУ, то есть почитать знаменательные в вашей сфере статьи, то вам сюда.

Есть списки для статей 2020, 2021, 2022 года. Отсортированы по количеству цитирований. Кажется, что метрика адекватная, потому что на прорывные статьи (типа статей UNET, Attention Is All you need и тд.) потом много ссылаются.

Читать пдф с архива на телефоне не очень удобно

Благо, есть ребята, которые конвертируют их в веб-страницу:
1. ar5iv
Поменяйте в ссылке на архив X на 5 (https://arxiv.org/abs/1506.02640 -> https://ar5iv.org/abs/1506.02640). Случится магия.
2. arxiv-vanity
Можно писать боту в телеге @arxiv_vanity_bot (его также можно добавить в беседу, чтобы он конвертировал по ссылкам, которые вы туда постите). Можно также вставить ссылку на их сайте.

Если еще что-то есть, дайте знать

Чего греха таить, все мы любим, когда нам дают прямые ответы на наши вопросы. Вот такой приятный видос про "Какую стеку для детекции брать?"

TLDR

1. Исходи из трейдофа скорость / точность
В зависимости от необходимой скорости работы выбирай из этих групп.

2. Не забудь про сложность модификации
Какие-то реализации проще, какие-то замороченнее. Если предполагаются твики архитектуры, то стоит учесть это.

3. Проверяй, что можно экспортировать в оптимизированный формат
Если на проде нужна эффективность, то проверь заранее. Не все реализации спокойно перегоняются

4. Лицензии 😿
Не все доступно для коммерческого использования. Ставь лайк, если пират

5. Подстраивай обучение под твою датку
Понятное дерево решений по тому, как датка влияет на трейн

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

Недавно я посвящался в Kubernetes. Сущности кубера все никак не хотели укладываться в связную структуру у меня в голове, пока я не нашел их:
1. Презентацию
2. Репу с туториалами

На мой взгляд, все подробно и понятно объяснено. Сначала проработал презентацию, а потом закрепил туториалами. Советую