Всем привет, меня зовут Сергей Чепарухин, я ML инженер, иногда менеджер, а в данный момент DL/ML Ops консультант.
Как-то на закате третьего десятка меня настиг кризис самоидентификации.
Интересно обнаруживать себя в ситуации, когда тебя перевезли в Лондон, дали достаточно денег и уволили. Сразу зажигается огонек в заднем проходе и желание доказать всем, что ты можешь еще лучше. Главное понять, чем ты хочешь заниматься в будущие пару лет (мы же не размениваемся по пустякам, да?).
Собственно, на волне размышлений о том, чему я научился за предыдущие 9 лет и как это можно использовать в будущем, я решил создать этот канал.
Постараюсь делиться здесь своими мыслями, статьями и странными идеями для проектов.

Мне кажется, что самое важное в жизни любого ML-щика — умение строить бейзлайны (простенькие эвристические модели или что-нибудь из класса линейных).
Прежде чем строить огромные космолеты, которые требуют кластер из 64 Nvidia H100, построй свой маленький бейзлайн. В идеале что-то простое, наподобие “ax+b” или “a if x>b else c”. Дальше на этом можно измерить оффлайн метрики, выкатить в прод или в АБ/свитчбек тест, посмотреть продуктовые метрики.
Такая база позволяет выстраивать корректную систему оценки не только экономического эффекта, но и всех последующих улучшений в разрезе Reach, Impact, Confidence и Effort. Про RICE в планировании ML расскажу как-нибудь отдельно.
Легковесные бейзлайны к тому же позволяют довольно просто интегрироваться в обычную продуктовую разработку.
В итоге одни плюсы:)

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

Что дальше? Наверняка через пару дней/спринтов к вам придет продакт и потребует улучшений, так бейзлайн хорош, но недостаточно.
Можно начать копать в сервисы, можно попробовать поулучшать текущую модель.
Есть прекрасная идея от моего бывшего коллеги: давайте обучим две модели.
Одна — простая, линейная регрессия на расстоянии, другая — большая (например, бустинг), на большем наборе признаков, какие вы только можете придумать, за исключением расстояния. Примеры признаков — различные агрегаты, вроде средних скоростей доставки,сборки,количества айтемов, заказываемых из точки.
Дальше просто, ваше предсказание — это ax+b+GB(y). Что мы можем сделать? Конечно же посчитать b+G(y) разово для магазина и заливать как один из параметров в базу.
Затем повторяете это упражнение раз в 1-3 дня, и качество вашего предсказания становится ощутимо лучше, чем предыдущий бейзлайн. Не забудьте измерить качество в оффлайне и онлайне.

Копаясь в различных реализациях RAG пайплайнов, задался вопросом: А почему в векторных базах данных считается нормой передавать вектора эмбеддингов (некоторый набор чисел с плавающей точкой) через HTTP JSON API?
Я, конечно, понимаю, что очень просто сбоку прикрутить FastAPI/Tornado/Flask/etc, но как же потеря точности при сериализации/десериализации объектов?
Каюсь, раньше и сам так делал, храня сериализованный json как значение в Redis, типичная особенность MVP.
Как это можно обойти — уйти от REST с тасканием туда-обратно строк в сторону бинарных форматов. Лучше всех здесь смотрится GRPC, причем вы из коробки получите более надежное и быстрое взаимодействие с сервисом. Еще можно посмотреть FlatBuffers, но могут возникнуть сложности.
Что еще вы получаете от GRPC — типизацию из коробки (Pydantic не нужен), меньший объем данных за счет бинарного формата, отсутствие потерь точности. А также зафиксированный контракт обмена данными с вашим сервисом.
Прошерстив документацию 10 самых популярных vector database (растут как на дрожжах), пришел к неутешительному выводу — половина этих баз либо не имеют GRPC API, либо такой функционал только в бете.
Отдельно хочется отметить две базы:
1) Qdrant — написанная на Rust с нуля, очень приятно смотрится в бенчмарках(1000+ rps, в 3 раза больше weaviate или milvus, wow).
2) LanceDB — опять же Rust, к тому же можно делать serverless(наподобие RocksDB, SQLite). Ребята написали свой собственный формат хранения и выложили в опенсорс, что не может не радовать.
Немножко пояснил за protobuf-ы отдельно:
https://telegra.ph/Proto-Explanation-12-10

Кстати, что такое RAG?
В последнее время напридумывали множество новых терминов, под которыми скрываются давно придуманные истории.
Собственно, RAG — Retrieval Augmented Generation. Если говорить простым языком, это попытка предоставить внешние знания, например документацию по какому-то продукту или весь уголовный кодекс РФ, напрямую в LLM. Зачем? Чтобы удерживать ее внимание в рамках нужной нам задачи. По сути, мы говорим: генерируй ответ только на основе предоставленной тебе информации.
Сразу представляется волшебный мир будущего:
Пользователь — Как мне правильно оформить декларацию для налогового вычета?
Сервис — Чтобы корректно оформить налоговую декларацию по форме 3-НДФЛ, вам нужно перечислить все ваши доходы от различных источников с указанием типов деятельности.
Любая базовая LLM модель скорее всего выкинет странный ответ, не только неправильный, но и возможно вредный. Вот поэтому надо ограничивать генерацию источниками информации
Есть разные подходы, как это делать:
– Взять уже обученную модель, для каждого входного запроса предварительно искать в нашем корпусе кусочки текста, похожие на запрос пользователя, и хитро подставлять их в конечный инпут модели;
– Дообучить базовую модель на нашем корпусе, надеясь, что она все запомнит и не будет галлюцинировать;
– Взять уже обученную модель, для пользовательского запроса искать похожие кусочки текста, потом той же моделью одним промптом просить перевести в единый укороченный контекст, затем подставить этот контекст в следующий промпт для получения финального ответа;
– Дообучить модель, используя промпты как в первом подходе.


В 99% случаев, когда вам продают RAG, это будет первый подход. По сути, зумеры прикрутили к промпту быстрый поиск ближайших соседей, и вот как раз для этого нужны векторные базы данных. Что-то похожее делали 10-20 лет назад разрабы из Гугла/Бинга/Яндекса/etc. Раньше сильно беспокоились за качество выдачи, за точность ответа, но в 2022 OpenAI показали нам, что на это можно забить, продукт важнее, чем неправильные ответы.

За годы работы я прошел несколько стадий принятия оркестрации ML/Data пайплайнов.

Сначала в моей жизни был планировщик Windows. Это была Lamoda, я обкачивал Google Adsense и Google Analytics ежедневно и складывал это в Postgres, развернутый рядом. Волшебное время, Windows может в хорошие решения (иногда).

Потом в Mail.ru был Luigi в качестве контроллера исполнения DAG’ов и Jenkins в качестве контроля расписания. До сих пор вспоминаю Luigi с теплотой, тогда он казался мне вершиной инженерии. Удобный визуализатор, возможность локально потестить код, свободная передача данных между задачами в одном DAG’е — очень приятно и очень удобно.
Из минусов — приходится ставить на расписание отдельным сервисом (cron, Jenkins, etc).
Интересный факт — когда я устроился в другое подразделение Mail.ru через год, мне продолжили приходить письма о падениях DAG’ов, которые я написал несколько лет назад.
С — стабильность.

Следующим был шаг обратно к истокам — помесь bash и python скриптов, которые деплоились и ставились на крон на конечные физические машины с помощью самописного аналога Ansible. Ад редкостный, особенно в разрезе мониторинга падений (его не было).

Дальше был Сбермаркет с Airflow+K8s. Проблемы с тестовыми стендами, невозможность запустить код локально, опять разделение кода исполняемого и кода DAG’а — все это приводит к фрустрации и снижению скорости разработки. Еще из минусов: мне крайне негативно отношусь от концепции XCom (cross-communications). Выглядит как огромный костыль для возможности передачи данных между задачи в DAG’е (и не только в нем).
Есть, конечно, плюсы: расписание из коробки, возможность отвязаться от физических машин (только благодаря куберу), удобные средства мониторинга падений.

В последние годы появилось множество других оркестраторов — Prefect, Dagster, Metaflow, Flyte. Каждый имеет свою специфику и область применения, конечно, но приятно, когда есть выбор.
Если вы вдруг задумались, какой планировщик вам выбрать сейчас — я определенно посоветую вам Dagster. Супер приятный, все лучшее, что можно взять из Luigi, Cron, Airflow — все это есть в нем. Особенно радует возможность протестировать код прямо локально, довольно просто развернув мини Dagster локально (одной командой!).
Мой коллега как раз недавно рассказывал на Dagster community day про то, как мы мощно прогоняем за пару часов миллионы аудио файлов через несколько нейронок с помощью Dagster+Ray.
Стоит упомянуть проблемы:
– Backfill задач пока experimental фича;
– Есть автоматериализация downstream задач при запуске upstream, но наоборот — придется повозиться.

TLDR: Берите Дагстер, не пожалеете

Рекомендаций книг пост

В 2020 году я прочитал «Проект Феникс». Увидел множество рекомендаций этой книги в чате ctodaily (чат при канале Самата, ведущего подкаста «Запуск завтра»), так и дополз.

Эта книга написана в довольно интересном жанре «бизнес-роман». Если вкратце про жанр – это попытка донести какую-то бизнес-концепцию с помощью незамысловатого сюжета. Другие интересные примеры этого жанра – «Цель» Голдратта про оптимизации процессов и «Deadline» ДеМарко про управление проектами.

Книга в целом пытается донести до вас философию DevOps (по состоянию на 2013 год) и как научиться управлять разработкой, чтобы продуктивность вашей команды была на высоте.

Книга написана от лица менеджера, который должен в срочном режиме выкатить продукт. Этот продукт разрабатывался предыдущие два года без нашего менеджера и на 90% состоит из говна и палок. А ещё у него огромный бэклог техдолга и неправильных решений. Ничего не напоминает?

Первое впечатление после прочтения – вау, просто списано с моей текущей ситуации. Сразу захотелось начать релизить изменения раз в 3 дня, описать нормальные процессы тестирования для разработки, внедрить процесс постоянного сокращения тех долга. Зарядился, в общем.

Недавно разговаривал с другом, который только читает книгу, забавно, что у нас схожие впечатления от прочтения.
Решил прогуглить, оказалось, что в 2019 году вышла вторая книга «The Unicorn Project». Это не совсем продолжение, скорее другой взгляд на события первой книги глазами разработчика этого продукта. Так как книга более свежая, она учитывает рост екома и появление новых технологий около devops. Пока прочел только треть, но чувствую опять прилив мотивации в стиле: да, продуктивность разработки супер важна, локальность и простота изменений, погнали.

TLDR: хотите вновь прочувствовать, почему вы так любите разработку – прочтите "Проект Феникс".

Коротко про навыки ML инженера

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

Понимание алгоритмов дает вам интуицию при оценке скорости работы вашего кода (а еще иногда идеи для ускорения).
Однажды я увидел в продакшене код составления драфта рекомендаций, который при добавлении нового объекта, проверял вхождение категории этого объекта в список уже добавленных категорий. Список. Не хэшмапа, не множество, список. Теперь я считаю, что обязательно собеседовать человека на алгоритмы. Даже если ты лид — будь добр, тебе еще потом код ревью делать.

Инфраструктура обычно скользкий вопрос.
Авг ответ: а зачем я должен разбираться в этом, есть же специально обученные люди?
Ну в целом и ответ тоже базированный: может быть тогда проще научить девопса запускать фитпредикт? Заодно сэкономим на ФОТ.

Если вы понимаете, как работает инфра — вы можете быть более продуктивны. В целом считаю, что написать Gitlab CI пайплайн — это не так сложно. Уметь писать докерфайлы — базовый навык инженера уже.

В общем, теперь всегда на собесах спрашиваю что-то наподобие:
- в чем разница между cmd и run в dockerfile?
run описывает как надо собирать образ, а cmd — что нужно по дефолту запускать при старте контейнера;
- в чем разница между докер образом и докер контейнером?
Образ — описание, как нужно будет запускать исполняемую «виртуальную» среду, а контейнер — сама исполняемая среда.

Если хочется детальнее поизучать про Docker и Kubernetes, рекомендую почитать «Kubernetes в действии» Марко Лукша. Книга не первой свежести (2018 год), но все еще актуальная, хорошо описывает базу.

Этот год был тяжелым во всех смыслах. Но в то же время он был вдохновляющим и интересным.
В отпуске в Шотландии у меня было время поразмышлять о том, каким будет следующий год. И вот к каким мыслям я пришёл:

— мы все больше будем видеть применение больших моделек на персональных девайсах. Вычислительная фотография там уже давно, ждём звук и текст. Мне нравится движение вокруг ollama comfyui. Компании медленно начинают выпускать статьи про дешевый инференс моделей (Apple — про shared memory , китайцы про cpu+gpu инференс). В общем, я лично жду суммаризацию текста или локальный перевод в следующем релизе айоси;

— рыночек видеокарт наконец-то разрешится, и Nvidia начнет делать свое облако. Что-нибудь на уровне цен vast.ai, но sla получше. Кто, как не Nvidia, знает, как правильно настраивать сеть/вычисления?

— все больше крупных компаний будет стараться вкладываться в опенсорс. При этом мы чаще будем видеть мелкие модели, заточенные под определенные задачки (вроде поиска по налоговому кодексу РФ).
Кстати, из ближайших примеров Ferret — свежий дроп от Apple, мультимодальная ллмка, по сути другая опенсорсная моделька (Vicuna), немного дообученная;

— также мы увидим много новых продуктов, выстроенных вокруг опенсорса. В целом это новый старый тренд, строить продукт вокруг открытого кода. Посмотрим, что из этого получится, мы уже проходили Nginx, Aerospike, Databricks, Hortonworks;

— больше продуктов, использующих большие модельки, перейдёт из стадии ресерча в продакшн. Жду генерацию дашбордов в Tableau по одному сообщению продакта в телеге или автоматический Speech to Text в Goodnotes;

— уже к маю рассчитываю на несколько исков по новоиспеченному EU AI Act. Возможно, даже попробуют подушить TikTok на раскрытие работы их рекомендательной системы, под предлогом влияния на человеческое поведение;

— больше всего я радуюсь тренду на MLOps тулзы, надеюсь, он продолжится. MLOps сейчас будто те самые лопаты во времена золотой лихорадки. Хотите MLOps платформу как расширение к Postgres — держите PostgresML. Может вам хочется удобный мониторинг для своих фичей/моделек — держите Evidently.
Мы в sanas.ai сделали свой cli для запуска распределенного обучения/сервинга моделей, но даже под такое есть стартап — dstack.
В общем, я безумно рад такому усиленному вниманию к вопросам продуктивности и психологического здоровья ML инженеров.

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

Я потихоньку копаю историю про затачивание LLM-ок под свои задачи, желательно с инференсом на ноутбуке/смартфоне. Очень зацепила история про то, как дообучать большие модели меньшими ресурсами.
Собственно, про LoRa и QLoRa сейчас из каждого утюга, я вам принес разбор первой.
LoRA (Low-Rank Adaptation of Large Language Models) — это один из способов дообучать любую большую модель меньшим ресурсом (впрочем, можно применять и для большой линейной регрессии). Активно используется в файнтюнинге LLM-ок и диффузионных моделей. К тому же это прекрасное обобщение самой идеи дообучения моделей, ведь, если сложить все шаги градиентного спуска в процессе, мы получим такого же размера матрицу, агрегирующую все изменения.
Ссылка на статью
Мой разбор