Привет, Хабр! Меня зовут Леонид Огрель, я работаю аналитиком в Джум Лабс. В этой статье я расскажу, зачем нужен эксперимент в ИТ-продукте, и на что нужно обратить внимание при его запуске.

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

Чтобы ответить на подобные вопросы, мы проводим большое число онлайн экспериментов, по итогам которыx ожидаем получить чёткий ответ: улучшает ли изменение метрики компании или нет.

Процесс подготовки эксперимента к запуску можно разделить на три этапа. Ниже остановимся подробнее на каждом из них.

Задача матчинга в последнее время набирает всё большую популярность и используется во многих сферах: банки матчат транзакции, маркетплейсы – товары, а Google и другие IT-гиганты проводят соревнования по решению таких задач на Kaggle.

Для маркетплейса матчинг – очень важный процесс, который решает сразу несколько задач:

1. При поисковом ранжировании из множества товаров показывать сначала самые выгодные предложения.

2. Объединять множество товаров в одну сущность и показывать предложения одного и того же товара от разных селлеров.

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

Сегодня мы поговорим не только о решении этой задачи, но и о способах её реализации: offline (batch) vs online (realtime). Также обсудим, как и зачем переходить от первого ко второму.

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

Как становятся тимлидами? Типичный путь в этот омут — “эволюционный”. Ты успешно выполнил кучу экспидайт-эпик-мамонтов, принёс в своё разработческое племя благодатный огонь метрик и мониторинга, показал, что тесты — это хорошо... И вот тебя уже назначают тимлидом — просто по принципу, что ты самый сильный среди других разработчиков. А бывает, что ты слишком долго на проекте, и вот, вуаля, предыдущий тимлид сгорел в битве при Монолите, и теперь по наследству мантия обязанностей переходит к тебе. Ну, и, конечно, путь инициативы — где ты сам вызвался на эту должность, из-за того, что очень ответственный, или от скуки, ради денег, или просто по фану.

Меня зовут Константин, недавно в Каруне я стал тимлидом и тут я поделюсь причинами, почему не стоит необдуманно падать в управленческую бездну.

Привет! Меня зовут Василий Копытов, я руковожу группой разработки рекомендаций в Авито. Мы занимается системами, которые предоставляют пользователю персонализированные объявления на сайте и в приложениях. На примере нашего основного сервиса покажу, когда стоит переходить с Python на Go, а когда нужно оставить всё как есть. В конце дам несколько советов по оптимизации сервисов на Python.

Разрабатываете приложения с применением Apache Kafka? Мы собрали для вас статьи, которые помогут освоить инструмент, познакомят с рабочими кейсами с использованием ПО. Делимся пользой и свежими идеями, подборками книг и реализованными задумками.

Спорить плохо, но раз уж всё равно все спорят, то почему бы не делать это конструктивно и продуктивно :)

Лайфхак как успешно убеждать датасайентистов по результатам A/B тестирования. Работают такие аргументы:

Привет, Хабр! Меня зовут Сергей, я руководитель команды поиска в Ozon. Сегодня я расскажу об эволюции наших поисковых систем: как всё начиналось более 20 лет назад с обычных SQL-запросов, как мы осваивали Sphinx и Elasticsearch и как сейчас наш собственный поисковый движок O2 на базе Apache Lucene выдерживает нагрузку в десятки тысяч RPS в сезон распродаж. Исторические хроники восстанавливались по воспоминаниям современников и представлены для полноты картины. Новейшая история описана на основе собственного опыта, поэтому подробностей будет на порядок больше. Поехали!

Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

Сейчас существенная часть машинного обучения основана на решающих деревьях и их ансамблях, таких как CatBoost и XGBoost, но при этом не все имеют представление о том, как устроены эти алгоритмы "изнутри".

Данный обзор охватывает сразу несколько тем. Мы начнем с устройства решающего дерева и градиентного бустинга, затем подробно поговорим об XGBoost и CatBoost. Среди основных особенностей алгоритма CatBoost:

• Упорядоченное target-кодирование категориальных признаков
• Использование решающих таблиц
• Разделение ветвей по комбинациям признаков
• Упорядоченный бустинг
• Возможность работы с текстовыми признаками
• Возможность обучения на GPU

В конце обзора поговорим о методах интерпретации решающих деревьев (MDI, SHAP) и о выразительной способности решающих деревьев. Удивительно, но ансамбли деревьев ограниченной глубины, в том числе CatBoost, не являются универсальными аппроксиматорами: в данном обзоре приведено собственное исследование этого вопроса с доказательством (и экспериментальным подтверждением) того, что ансамбль деревьев глубины N не способен сколь угодно точно аппроксимировать функцию . Поговорим также о выводах, которые можно из этого сделать.

Современный человек много чем занимается в интернете: ходит по магазинам, слушает музыку, читает новости. Все эти задачи подразумевают поиск и выбор того, что ему нужно. При этом важную роль тут играют рекомендательные системы. Они помогают людям не утонуть в многообразии вариантов и увидеть именно то, что им подойдёт, то, что иначе им сложно было бы найти. Предоставление пользователям качественных рекомендаций — это важнейшая часть обеспечения первоклассного уровня удовлетворения клиента. Это — один из самых эффективных способов взращивания лояльности клиентов и повышения ценности продукта или услуги в их глазах. Всё это так важно, что целые бизнес-модели некоторых компаний построены вокруг предоставления их клиентам наилучших рекомендаций, что делает рекомендательные системы важнейшими факторами, влияющими на прибыль подобных компаний! В результате неудивительно то, что клиенты проекта Microsoft CSE часто обращаются к нам с просьбами, касающимися реализации эталонных рекомендательных техник. Один из таких проектов был моим первым опытом в данной сфере.

Кто лучше всех знает, как справляться с проблемами? От кого ждут, что он закроет своим хрупким тельцем все бреши в продукте? Тимлиды иногда напоминают собой зонтик, под которым прячется команда. Команда видит — можно особо и не стараться, потому что если что, Вася вытянет. Вася тянет всё больше, и всё начинает ехать на энергии Васи. Энергия заканчивается, и бизнес людей заменяет.

Если все едет на вашей энергии, то… энергия закончится.

Вы не будете двигаться дальше. 

Вас никому не будет жалко.

Александр Орлов, бизнес-коуч и сооснователь школы менеджеров и тимлидов «Стратоплан»  поделился на конференции TeamLead 2021 своими наблюдениями, что происходит с энергией, почему она уходит и почему приходит. Показал, какие инструменты есть для решения проблемы выгорания. Сегодняшняя статья именно об этом. Если вы предпочитаете разговорный формат — для вас видео выступления.

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

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

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

Как и в большинстве компаний, наш основной инструмент для принятия решений — это A/B-тесты. Мы уделяем им большое внимание: проверяем на корректность все используемые критерии, пытаемся сделать результаты более интерпретируемыми, а также увеличиваем мощность критериев. В текущем посте я хочу рассказать, как дополнительно увеличить мощность, используя машинное обучение.