Очевидный для ML-инженера факт: если на вход модели подать мусор — на выходе тоже будет мусор. Это правило действует всегда, независимо от того, насколько у нас крутая модель. Поэтому важно понимать, как ваши данные будут храниться, использоваться, версионироваться и воспроизведутся ли при этом результаты экспериментов. Для всех перечисленных задач есть множество различных инструментов: DVC, MLflow, W&B, ClearML и другие. Git использовать недостаточно, потому что он не был спроектирован под требования ML. Но есть инструмент, который подходит для версионирования данных и не только — это ClearML. О нем я сегодня и расскажу.

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

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

Кадры или, если брать шире, люди по-прежнему решают все, и сфера Machine Learning — не исключение. Но подбор специалистов, поддержание работоспособности команды, отношения с заказчиками — все в этой области имеет определенную специфику.

Как проводить собеседования, что общего между сеньорами и ворами в законе, зачем тимлиду быть еще и психологом, наконец, какие magic tools облегчают жизнь команде? Обо всем этом нам рассказал senior-разработчик и DL-инженер Роман Тезиков, который собаку съел в работе с людьми на ML-проектах. Передаем ему слово.

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

К нам на огонек в подкаст заглянул Роман Тезиков — senior-разработчик и DL-engineer. Эксперт рассказал много интересного о своем опыте реализации ML-проектов. А «на десерт» Роман поделился тем, как он применяет промт-инжиниринг в работе и личной жизни и каких впечатляющих результатов ему удалось добиться с помощью подобных технологий.

Scrum, Kanban и другие «‎эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.

Рассмотрим острые методологические проблемы, на которые почему-то редко обращают внимание. Порассуждаем, как не споткнуться о такие камни преткновения или хотя бы удержать равновесие после этого.

Спойлер: многие затронутые вопросы спорные, и готовых решений у нас нет (как, наверное, у большинства PM). Так что заранее приглашаем всех желающих к диалогу и обмену опытом в комментариях.

Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?

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

Спойлер: многие затронутые вопросы спорные, и готовых решений у нашей команды нет (как, наверное, у большинства PM). Так что заранее приглашаю всех желающих к диалогу и обмену опытом в комментариях.

Растущие зарплаты, рекордно низкая безработица — в структуре занятости происходят тектонические сдвиги. Чтобы приводить в команду новых крутых разрабов, мы просто обязаны подмечать тенденции, анализировать рынок труда и выделять большие тренды.

Последние годы здорово изменили правила игры в IT-найме. Эта статья — попытка зафиксировать, обобщить наши наблюдения и сделать выводы, которые будут полезны и рекрутерам, и соискателям.

Иллюстрация Андрея Попова

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

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

Привет! На связи лид команды аналитиков Magnus Tech Владислава Никитина.

В заказной разработке каждый проект начинается со сбора бизнес-требований к будущей системе. Это важный этап, ведь именно здесь определяются контуры задач, которыми займутся разработчики. И с ним связан вечный проблемный вопрос: как лучше собрать и зафиксировать эти требования, чтобы оптимизировать разработку?

Подходы у всех команд разработки в целом общие, но есть профессиональные хитрости, которые отражаются и на процессе сбора информации, и на том, как оформляются бизнес-функциональные требования. У нашего подразделения — свои подходы. Это не истина в последней инстанции, но у нас они работают достаточно хорошо. Мы хотим поделиться своим видением того, как собрать требования в единый документ, и покажем пример структуры шаблона. Используя его, можно сфокусироваться на качественном сборе требований, не тратя время на придумывание и реализацию оформления.

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

Фото до (слева) и после (справа) калибровки камеры

В первой части статьи мы немного поупражнялись на яблоках, чтобы понять, как 3D-объекты проецируются на 2D-плоскость фотографии. Заодно мы описали математическую модель камеры и ее параметры.

Знаешь параметры — живешь в Сочи можешь восстановить 3D-сцену или ее характеристики: высоту здания, расстояние до пешехода, загруженность самосвала. Словом, сплошная польза для целого ряда отраслей. 

А вот как именно определить эти заветные параметры, так и осталось за кадром. К тому же мы рассматривали простейшую модель pinhole, но в реальной жизни все сложнее. У большинства камер есть линзы, которые искажают изображения (вспомните эффект fisheye). Все эти «рыбьи глаза»‎ и другие отклонения нужно как-то корректировать.

О том, как восстанавливать параметры камеры (калибровать ее) и нивелировать искажения (дисторсию), читайте в этой публикации.

Также из нее вы узнаете:

• как выглядит математическая модель калибровки и дисторсии;

• как собрать датасет для калибровки;

• какие есть методы калибровки;

• детали одного из этих методов.

Казалось бы, жизнь невозможно повернуть назад, а предмет из фотографии не восстановишь. Хотя с последним можно поспорить: из плоского 2D-изображения реально восстановить 3D-модель объекта. Подобная «магия» часто практикуется в AR/VR, управлении беспилотниками и других сферах. Для этого первым делом производится калибровка камеры. Чтобы понять процесс калибровки, сперва следует освоить базовые принципы преобразования трехмерных координат точек в двухмерные на плоскости. 

Сегодня мы рассмотрим:

• геометрию формирования изображения на сенсоре камеры (pinhole модель);

• как рассчитываются координаты точки на сенсоре для точки из реального мира;

• как переходить от одной системы координат к другой;

• что такое внутренние и внешние параметры камеры и зачем они нужны.

У нас в гостях специалист с 15-летним опытом в Machine Learning который совмещает пару высокоуровневых должностей в разных компаниях — Head of ML в Cherry Labs и CTO в Rembrain. За полтора часа мы обсудили: позабытые ML-фреймворки и перспективы Reinforcement Learning, выяснили, какие платы с NPU лучше подходят для pet-project и зачем норвежцам роборуки.

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

В этой статье мы расскажем о том, почему на создание видеоридера понадобилось 6 месяцев, почему пришлось его переписывать и какие еще сложности были на этом пути. Поскольку велосипед изобретали трижды, наши выводы могут пригодиться всем разработчикам, которые реализуют крупные проекты с долей исследовательской работы.

В 2019 году (кажется, целую вечность назад), мы начали эксперимент. Решили использовать наши знания в области нейронных сетей, чтобы создать продукт для многообещающей, как нам казалось, ниши. Целью было разработать аналитическую систему для застройщиков, которая с помощью камер и нейронных сетей следила бы за происходящим на строительных площадках. У нас была гипотеза. Мы изучили бизнесы, делающие подобную аналитику. Нашли несколько зарубежных стартапов, которые получили значительные инвестиции. Естественно, мы задались вопросом: «Почему мы не можем сделать то же самое?»

И что могло пойти не так?

К нам в гости заглянул Влад Грозин — создатель ODS Pet Projects, ex. Head of Data Science из компании INCYMO, чтобы поговорить за жизнь про получение PhD в Америке и экзистенциальные риски, связанные с разработкой рекомендательных систем: пузыри рекомендаций и появление алгоритмов, которые будут предсказывать желания пользователя.

Продолжаем разбирать подходы призеров Kaggle-соревнований от американской национальной футбольной лиги (NFL). Участники этого челленджа детектировали столкновения игроков в американском футболе, анализируя данные с видеокамер и датчиков, прикрепленных к форме футболистов. В продолжении первой части статьи расскажу про самые успешные подходы к этой задаче.

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

Недавно закончилось соревнование от американской национальной футбольной лиги (NFL), которая объединилась с AWS, чтобы прокачать системы спортивной видеоаналитики.

Организаторы поставили простую, казалось бы, задачу — точно определить, в каких случаях игроки сталкиваются друг с другом во время матча по американскому футболу. Мы с коллегами приняли участие, но не успели реализовать все свои идеи. Зато изучили подходы других команд и поняли, что были на верном пути. В этой статье я рассмотрю некоторые из решений, которые принесли денежное вознаграждение и золотые медали участникам этого челленджа.