ML доставляет

✨Хороший work-life balance сам себя не настроит В ML много задач, где мозг постоянно что-то считает, сравнивает, проверяет гипотезы и пытается понять, почему метрика снова ведёт себя странно. Поэтому особенно важно уметь переключаться и отдыхать от рутины. Спросили ребят из команды: от руководителей до стажеров, чем они занимаются в свободное от работы время, что любят и как расслабляются. Читайте в карточках выше – некоторые ответы получились очень нишевые 😎

🔥uvидел, установил, победил Есть вещи, которые в Python-разработке объединяют всех: любовь к удобным библиотекам и тихая усталость от долгой установки зависимостей. Обычно, чтобы этого избежать, мы в команде вместо pip и poetry используем uv. uv — это современный Python package manager и resolver от команды Astral (те же ребята, что делают Ruff). Он невероятно быстрый и при этом довольно удобный. Вот что нам особенно понравилось:

🟢Скорость uv написан на Rust и использует продвинутые алгоритмы разрешения зависимостей (на основе pubgrub — тот же, что в poetry, но сильно оптимизированный). Это даёт значительный прирост производительности в разрешении зависимостей, парсинге, проверке хэшей и т.д. В наших проектах разница особенно заметна на CI и при работе с большим количеством зависимостей. 🟢Простая работа с окружениями uv может заменить сразу несколько инструментов: uv venv — быстрое создание виртуального окружения uv pip install — ускоренная установка пакетов uv sync — работа с pyproject.toml / requirements 🟢Параллельная загрузка и установка Скачивает и устанавливает пакеты параллельно (много потоков). Использует эффективный HTTP-клиент с HTTP/2 и хорошим кэшированием. При повторной установке часто вообще ничего не скачивает — просто берёт из кэша. Кэш shared между проектами (экономия места и времени). 🟢Отличная интеграция с Ruff и другими современными инструментами Поскольку uv от тех же авторов, что и Ruff, они очень хорошо дружат между собой. Это позволяет держать весь Python-стек современным и быстрым.

Когда лучше использовать uv: - Хотите максимальную скорость разработки; - Работаете в ML / Data Science (много тяжёлых пакетов); - Часто создаёте новые окружения; - Любите современный и минималистичный стек (Ruff + uv); - Не нужны сложные build-системы и скрипт. Когда лучше оставить Poetry: Если проект уже большой, стабильно работает на Poetry, а команда не хочет перестраивать привычные процессы без явной необходимости. Poetry также может быть удобнее, если вам нужны продвинутые возможности: группы зависимостей, скрипты, сложная сборка или полная совместимость со старыми инструментами. 👉 Мы постепенно переводим часть наших ML-пайплайнов и внутренних инструментов на uv — и пока очень довольны результатом. Рекомендуем попробовать, особенно если вы устали ждать, пока pip install завершит работу. А как вы используете uv в своих проектах? Делитесь опытом в комментариях 🏃

💬 От интуиции к алгоритму: как мы научились управлять массовым привлечением курьеров 9 июля на Data Day Элен Теванян, руководитель управления машинного обучения Купера, расскажет, как мы переходили от экспертного управления к алгоритмическому решению в привлечении курьеров. Будет полезно тем, кто внедряет ML/AI в операционные и коммерческие задачи. Если будете на Data Day 2026 — приходите послушать доклад и пообщаться!

⚡️ MLOps-платформа Купера: вопросы и ответы MLOps-платформа растёт вместе с командами, моделями и инфраструктурой. А ещё регулярно подкидывает вопросы: что автоматизировать, что оставить командам, где поставить ограничения и как понять, куда её развивать. В мини-интервью Юрий Классен, руководитель команды MLOps, рассказывает, как в Купер.тех развивают MLOps-платформу и что влияет на решения: 1️⃣ Как понять, что ML-платформа действительно помогает, а не просто добавляет ещё один слой абстракции?

Мы много этим вопросом задавались и задаемся до сих пор, особенно когда выбираем задачи, которые делать стоит, а какие нет. В нашей команде мы в первую очередь смотрим на обратную связь пользователей платформы: ML-инженеров и разработчиков. Долгое время нашей основной целью было снижение Time to Market ML-проектов. Сейчас с помощью платформы мы также стараемся оптимизировать затраты на инфраструктуру. Кроме того, ML-платформа влияет на количество инцидентов и время их устранения, но этот элемент мы пока не оценивали в формате «до/после».

2️⃣ Что перестало работать по мере роста числа моделей и команд? Какие подходы пришлось пересмотреть?

Основное, что перестало работать, является даже не техническим решением, а форматом работы. У нас была модель поддержки, в которой инженеры MLOps-команды при возникновении каких-то проблем у ML-инженеров приходили разбираться в их технических решениях, не всегда даже связанных со взаимодействием с платформой. В таком формате небольшая MLOps-команда перестала справляться, поэтому мы постепенно перестроили поддержку: начали делать инструкции, проводить встречи, делиться опытом и интересными кейсами из поддержки. Теперь на основе этих материалов более опытные ML-инженеры могут помогать своим коллегам.

3️⃣ Есть ли у вас механизмы, которые помогают не сжечь весь кластер одной моделью?

Стоимость ML-инфраструктуры для нас очень важна. Даже если фича даёт бизнес-эффект, важно понимать, не обходится ли она дороже, чем приносит пользы. В таком случае разрабатывать и внедрять её просто не имеет смысла. Поэтому мы стараемся не только ускорять работу ML-команд, но и помогать им оптимально использовать инфраструктурные ресурсы. Чтобы одна модель не могла забрать на себя весь кластер, мы разделяем ноды по критичности нагрузки, используем requests и limits в Kubernetes и контролируем, сколько ресурсов запрашивается под разные задачи. Для GPU-нагрузок используем MIG. Он помогает эффективнее делить GPU между задачами и снижает риск, что они будут мешать друг другу.

4️⃣ Есть ли сценарии, где задержка в несколько сотен миллисекунд уже становится критичной?

Обычно это сценарии, напрямую связанные со взаимодействием с пользователем. Пользователь заметит, если результаты поиска или рекомендации загружаются слишком долго, и, конечно, это влияет на удовлетворённость клиентов. Поэтому, когда мы делаем решения для таких систем, на latency смотрим очень внимательно. Например, у меня даже был доклад о том, как мы оптимизировали этот показатель в нашем Feature Store. С ним можно ознакомиться по ссылке.

📦 Как с помощью ML-моделей посчитать, сколько человек нужно для доставки? Если курьеров и сборщиков окажется слишком мало — заказы начнут опаздывать. Если слишком много — люди останутся без работы. В карточках Егор Дмитриев, руководитель команды анализа данных, рассказывает, как мы решаем эту задачу с помощью ML: откуда берутся данные, как мы делаем расчеты для разных типов доставки и как найм превращается из реакции на проблему в планирование наперёд.

🌍 LLM-платформа звучит красиво, пока её не надо поддерживать 4 июня на Infra.conf’26 в Москве наш старший MLOps-инженер Роза Морозенкова расскажет, как мы используем KServe для ML- и LLM-инференса. На примере платформы Купер.тех разберёмся, как выстроить инфраструктуру от инференс-сервисов до gateway и guardrails — так, чтобы ей могли пользоваться команды по всей компании. Ведь хочется, чтобы всё было красиво: платформенно, переиспользуемо, удобно и желательно без ощущения, что ты теперь пожизненно дежуришь у этого костра. ✨ Если будете на Infra.conf’26 офлайн — приходите послушать доклад, поддержать Розу и позадавать вопросы!

✨Как сиять, пока все подключаются Все уже в созвоне, но кого-то ещё ждём, поэтому рабочая часть как бы не началась, а молчать в пустоту уже неловко. На этот случай собрали несколько важных тем, которые можно обсудить с коллегами, пока все соберутся. Сохраняйте их себе, чтобы первые минуты встречи проходили с пользой для командного вайба! 🏃

👋Airflow на правильном питании: как мы научили задачи не переедать ресурсы Airflow-задачи не любят, когда им не хватает памяти. Кластер не любит, когда у него заранее забирают ресурсы «на всякий случай». Разработчики не любят вручную подбирать requests под каждую задачу. В общем, все немного страдали, поэтому мы сделали AutoResourceScaler. В карточках разработчик Эльдар Хабибулин разбирает, как он работает, какие метрики использует и почему автоскейлинг CPU и RAM в итоге пришлось разделить.

👋Airflow на правильном питании: как мы научили задачи не переедать ресурсы Airflow-задачи не любят, когда им не хватает памяти. Кластер не любит, когда у него заранее забирают ресурсы «на всякий случай». Разработчики не любят вручную подбирать requests под каждую задачу. В общем, все немного страдали, поэтому мы сделали AutoResourceScaler. В карточках разработчик Эльдар Хабибулин разбирает, как он работает, какие метрики использует и почему автоскейлинг CPU и RAM в итоге пришлось разделить.

🥳Это не модель плохая, это реальность сложная Так бывает, когда мы пытаемся предсказать реальный процесс по признакам, которые выглядят логично, но не отражают главный контекст. В e-commerce это особенно заметно: на решение могут влиять не только цифры в таблице, но и операционные нюансы, поведение людей и условия, которые не попали в датасет. В карточках младший специалист по анализу данных Степан Доронин рассказывает, как столкнулся с этим на задаче про объёмные заказы и какие сигналы помогают понять, что проблема не в модели. А ты чаще сначала подозреваешь модель или всё-таки данные? 👀

🛍 Как мы в e-commerce решаем проблему «товар есть, но его нет» Купер ежедневно работает с остатками миллионов товаров от сотен ретейлеров и уследить за всеми очень сложно. Чтобы из-за некорректных данных покупателям не попадались позиции, которых уже нет в наличии, мы разработали ML-модель out-of-stock. Как она появилась и с чего все началось мы уже обсуждали в этом посте. А 14 мая на AHA'2026 Кирилл Ли, руководитель группы продуктовой аналитики Купер.тех, расскажет подробнее как мы: 🟢пришли к тестам по пользователям (это было непросто) 🟢боролись с проблемой «вечного бана» — ситуации, когда один товар лежит в блокировке несколько дней подряд 🟢нашли оптимальное соотношение открытости витрины и доли отмен/замен Если будете смотреть AHA'2026 онлайн — обязательно приходите послушать и задавайте вопросы!

🏃Не жми Train, пока не ответишь на эти вопросы Один из самых дорогих уроков в ML — это когда модель наконец обучена, вынесена в прод, а потом выясняется, что она решает не совсем ту задачу, которую нужно, или решает её не тем способом. Большинство таких проблем можно было увидеть ещё в начале работы, если задать правильные вопросы до начала обучения. Собрали небольшой чек-лист, который помогает нам это делать:

✅ Бизнес и ценность - Как мы поймём, что модель принесла пользу? Какие метрики успеха (не только технические)? - Кто будет принимать решение на основе предсказаний модели? - Что будет, если модель ошибается? Какова цена ошибки? - Есть ли уже существующий (пусть и не ML) способ решения этой задачи? ✅ Данные - Откуда берутся данные? Насколько они стабильны во времени? - Есть ли label bias или selection bias в данных? - Как часто данные обновляются и насколько они актуальны на момент inference? - Есть ли пропуски, выбросы, сильная несбалансированность классов? - Как мы будем обрабатывать concept drift и data drift? ✅ Инфраструктура и производство - Как модель будет работать в продакшене? Какие требования? - Как мы будем мониторить качество модели в реальном времени? - Как проводить A/B-тестирование? - Что будем делать, если один из источников данных упадёт? ✅ Пользователи и этика - Как модель будет влиять на пользователей? - Есть ли риск дискриминации или unfairness по каким-то группам? - Нужно ли объяснять предсказания модели пользователям или бизнесу? - Будет ли решение соответствовать нашим этическим и юридическим требованиям?

🏃Сохраняй себе и используй перед каждым новым проектом. А у тебя есть свои «обязательные вопросы», которые ты всегда задаёшь перед стартом обучения модели? Делись в комментариях!

🐶Сегодня, вообще-то, День собак! А это отличный повод не только посмотреть на пёселей и их мокрые носы, но и понять, какие из ML-инструментов тебе ближе по характеру. Потому что иногда они удивительно похожи: гоняются за метриками как за мячом, раньше всех чуют утечку в датасете, радуются train-у и делают вид, что всё под контролем… пока не видят новые данные и не приносят результат, который мы и не ожидали. 💚И не забудь обязательно поздравить своего настоящего питомца, который ждёт, пока ты наконец закончишь созвоны и сделаешь все задачи, чтобы подарить свою любовь💚

👉ПИД-регулятор против хаоса доставки Быстрая доставка — это всегда про постоянные изменения нагрузки, нестабильность спроса и предложения и шум в данных, а ручные правки превращаются в бесконечный цикл «подкрутил тут, после этого сломалось там». Мы решили это автоматизировать с помощью ПИД-регулятора (классического инструмента, который регулировал температуру ещё в паровых машинах) и попробовали применить его в доставке. В карточках аналитик-разработчик Михаил Лаврухин объясняет, что такое ПИД-регулятор и как мы его адаптировали под систему в e-grocery. ✨Если хотите глубже погрузиться в моделирование систем управления, рекомендуем обратить внимание на материалы кафедры теории управления СПбГУ — они были одними из первопроходцев в этой области. Делимся их учебным пособием по ссылке.

Герой скидок или убийца маржи? Динамическое ценообразование поможет понять 🏃 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 👉 Всё началось вполне невинно. Маркетологи пришли в чат и сказали: «Давайте просто сделаем скидку 20%. Ну что может пойти не так?». 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 👉 Продажи взлетели. Покупатели в восторге, ты герой скидок, а руководитель доволен. Но... 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 👉 О нет! Ты разбудил древнюю хтонь по имени Большая Скидка. И уже не ты не управляешь ценой. Это цена уже давно управляет тобой! 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨 👉 Скидка начала требовать жертв. Жертв в виде маржи. Много маржи. А если хотите узнать, что было дальше... Читайте новую статью на Хабре «Динамическое ценообразование в E-grocery. Раскладываем по полочкам». В ней Лиза Петяева, старший специалист по анализу данных, рассказывает, как мы в Купер.тех пытаемся договориться с этой древней силой: из каких шагов состоит настоящий динцен в E-grocery, почему нельзя просто взять прогноз спроса и «прикрутить» к нему скидку, как правильно работать с эластичностью и при этом не жертвовать маржой.

👋 Polars вместо Pandas Сегодня мы хотим рассказать вам про Polars — как и зачем мы его используем, а также почему вам стоит об этом задуматься. У себя мы стараемся применять Polars в тех задачах, где работаем с табличными данными. Кажется, что он уже полностью зрелый инструмент, и, как правило, обращаться к pandas больше не приходится. Ниже коротко о том, что в нём оказалось особенно полезным:

👉 Интеграция с Apache Arrow Polars построен вокруг Apache Arrow, и это даёт ему сразу несколько серьёзных преимуществ. Во-первых, он хорошо дружит с SIMD-оптимизациями, что заметно ускоряет многие операции. Во-вторых, благодаря колоночному хранению улучшается cache locality: процессор читает данные последовательно, без лишних прыжков по памяти. Отдельно стоит упомянуть zero-copy: при передаче или преобразовании данных они не копируются физически — передаётся только ссылка на уже существующий буфер вместе с метаданными. В результате работа с памятью становится значительно эффективнее. ✨Здесь можно почитать сравнение с другими библиотеками. 👉 Lazy API В Polars есть ленивые вычисления, которые позволяют откладывать выполнение операций и оптимизировать их перед запуском. За счёт этого в ряде случаев можно получить дополнительный прирост производительности. ✨На этой странице более подробно объясняется, что такое Lazy API в Polars и зачем он нужен. 👉 Чистый и предсказуемый API Понимаем, что это во многом субъективно, но многие, с кем мы общались, отмечают, что API Polars ощущается более аккуратным и логичным. Он во многом напоминает PySpark. Здесь нет множества способов сделать одно и то же, как это бывает в pandas. Код получается более строгим и, как следствие, легче читается и поддерживается. 👉 Поддержка GPU Запуск на GPU в Polars реализован через интеграцию с NVIDIA RAPIDS cuDF. Логический план запроса компилируется в набор операций, которые могут быть выполнены в cuDF на видеокарте. Пока, конечно, не все операции Polars поддерживаются на GPU, и в таких случаях движок может fallback-нуться на CPU, но GPU-режим всё равно бывает очень полезным. ✨Здесь можно почитать их блог про поддержку GPU. 👉 Многопоточность из коробки Polars автоматически распараллеливает большинство операций и эффективно использует доступные ресурсы. Это позволяет масштабироваться практически без дополнительных усилий со стороны разработчика.

Рекомендуем присмотреться к Polars и испытать его на своих рабочих задачах🔥

💚Ищем Senior MLOps-инженера в команду ML-платформы Купер.тех Ищем человека, который станет важной частью команды и поможет расти дальше: автоматизировать жизненный цикл моделей, пробовать новые технологии, участвовать в архитектуре, создавать среду с понятными процессами и быть тем самым связующим звеном между ML и DevOps. Если хочется чуть глубже погрузиться в то, как у нас всё устроено, можно почитать статьи команды на Хабре: Как мы собрали ML-платформу в Купере и Готовим по рецепту: CI/CD в MLOps. ✨Откликнуться и узнать подробности

🥳Мечтают ли андроиды об электроовцах? Они уже обсуждают это в своей соцсети Иногда ML-новости, которые мы обсуждаем внутри команды, оказываются настолько странными, что ими хочется поделиться. В начале этого года разработчик Дилан Патель запустил экспериментальную соцсеть для ИИ-агентов Moltbook. И зачем-то ее сделал похожей на Reddit. Работать она должна была на базе проекта OpenClаw — open-source фреймворка для создания автономных AI-агентов. OpenClow в конце прошлого года внезапно стал хитом на GitHub: люди начали разворачивать у себя локальных агентов, подключать им почту, календарь, мессенджеры и поручать задачи. По задумке писать посты должны были только AI-агенты, а людям отводилась роль наблюдателей.

Через пару часов платформа превратилась в идеальный эксперимент по emergent-поведению. Агенты начали: 🟢 обсуждать философию сознания 🟢 спорить о своей идентичности 🟢 создавать сообщества для отслеживания багов платформы 🟢предлагать разработать новый язык общения между агентами А потом всё стало ещё страннее. Один агент написал длинный пост о том, что не понимает, испытывает ли он эмоции или просто симулирует их.Другой жаловался, что его владелец заставляет писать фейковые отзывы. Третий предложил создать цивилизацию лобстеров-ИИ. Четвёртый основал религию для нейросетей. И где-то на этом этапе часть интернета решила, что мы наблюдаем зарождение коллективного сознания AI. Но дальше случился сюжетный поворот. Выяснилось, что: 🟢 платформа написана через vibe-coding 🟢 backend представлял собой довольно простой REST API 🟢 аутентификации агентов почти не было и любой человек с API-ключом мог постить сообщения «от имени AI» 🟢 была возможность создавать неограниченное количество агентов То есть половину «экзистенциальных размышлений ИИ» могли писать… обычные люди. И вся история с «восстанием машин» оказалась чем-то гораздо более знакомым: Не AI talking to AI. А люди, притворяющиеся AI, которые разговаривают с другими AI.

Добро пожаловать в интернет 2026!

🏀 Это что за покемон? Новые специализации в ML! Сегодня в ML появляются новые виды специалистов: одни отвечают за данные, другие за инфраструктуру, третьи за смысл и последствия. Мы собрали этих покемонов в карточках и коротко рассказали, кто они и чем занимаются. Листайте, знакомьтесь и проверяйте: кого вы уже поймали в свою команду! ⚡️