31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа (копия 1, копия 2) New UUID Formats (далее – стандарт), который должен формально обновить, а фактически заменить давно устаревший и изначально ущербный RFC 4122.

В долгих и жарких спорах удалось выработать стандарт высокого качества. Можно надеяться, что этот стандарт заменит многочисленные «самоделки» энтузиастов и отдельных компаний: ULID, KSUID, CUID и т.д., а в СУБД будут встроены генераторы UUID новых форматов, предназначенных для ключей высоконагруженных систем.

Привет, меня зовут Сергей Алямкин, я CTO компании Expasoft. В сфере моих профессиональных интересов: ML/DL, нейросети, квантизация, компьютерное зрение (полный список). В своей первой статье на Хабре хочу поделиться нашим пилотным проектом – как мы разрабатывали модель предиктивного обслуживания нефтедобывающих насосов для компаний из Северной Америки и России.

Привет, Хабр! Компания Acer снова с вами! Мы планируем рассказывать об интересных продуктах: как своих, так и других участников рынка. В первую очередь речь пойдет о серверах и соответствующих корпоративных решениях.

Сегодня же публикуем первый свой пост – это аналитика наиболее заметных трендов на рынке ЦОД в 2022 году. Главный принцип, по которому мы отбирали тренды, – наличие примеров практического внедрения. Кроме того, мы расскажем о необычных разновидностях дата-центров, которых становится все больше.

Важность Humans-in-the-Loop

RFM - классический инструмент маркетинга для сегментации вашей клиентской базы. Я использую ее для работы в В2В, В2G сегменте. В основе него - понятные управленцу ценности: LTV и Purchase Frequency. Как можно строить сегменты с помощью Python - читайте в материале.

Друзья, рад представить вам свой новый курс "Циклы и функционалы в R". Курс и все сопутствующие материалы к нему распространяются бесплатно, и являются общедоступными. Во время кризиса лучшей инвестицией времени является обучение.

В данной публикации вы найдёте ссылку на курс, подробное описание и программу курса.

Зачем создавать процесс разметки данных на основе ML?

Это вторая часть нашего рассказа о работе со смещениями оценок медиа активности респондентов онлайн-панелей. В предыдущей статье мы разобрали саму проблему, причины возникновения смещений и способы их коррекции, а теперь более подробно остановимся на практическом применении алгоритма Propensity Score Adjustment для коррекции реальных онлайн-данных.

Если вы проводите панельные исследования, то обязательно столкнетесь с одним из главных вызовов – набрать выборку достаточного размера, которая будет достоверно отражать важные для исследования параметры генеральной совокупности. Набрать большую и качественную, а значит несмещенную выборку с применением оффлайн-рекрутмента дорого и проблематично. Однако существует альтернативный вариант – это онлайн-рекрутмент, который давно зарекомендовал себя как максимально быстрый, простой и дешевый способ привлечь респондентов для различных исследований. В то же время выборки, набранные в интернете, являются неслучайными и, как правило, искажены по ряду параметров, даже если процедура рекрутирования была хорошо  спланирована.  В этой статье мы расскажем о методе  Propensity Score Adjustment, который применили для коррекции смещений и улучшения данных, полученных на онлайн-панелях. Этот алгоритм помогает калибровать (уточнять) вклад респондентов, набранных в панель онлайн.

Мы привыкли, что Machine Learning предоставляет нам большое количество предиктивных методов, которые с каждым годом предсказывают события лучше и лучше. Деревья, леса, бустинги, нейронные сети, обучение с подкреплением и другие алгоритмы машинного обучения позволяют предвидеть будущее все более отчетливо. Казалось бы, что нужно еще? Просто улучшать методы и тогда мы рано или поздно будем жить в будущем так же спокойно, как и в настоящем. Однако не все так просто.

Когда мы рассматриваем бизнес задачи, мы часто сталкиваемся с двумя моментами. Во-первых, мы хотим понять что к чему относится и что с чем связано. Нам важна интерпретация. Чем сложнее модели мы используем, тем более нелинейные они. Тем больше они похожи на черную коробку, в которой очень сложно выявить связи, понятные человеческому разуму. Все же мы привыкли мыслить довольно линейно или близко к тому. Во-вторых, мы хотим понять - если мы подергаем вот эту "ручку", изменится ли результат в будущем и насколько? То есть, мы хотим увидеть причинно-следственную связь между нашим целевым событием и некоторым фактором. Как сказал Рубин - без манипуляции нет причинно следственной связи. Мы часто ошибочно принимаем обыкновенную корреляцию за эту связь. В этой серии статей мы сконцентрируемся на причинах и следствиях.

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

Добрый день, уважаемые читатели! Не открою для большинства секрета, если скажу, что большая часть задач в материалах к учебным курсам сформулирована шаблонно. Какие-то вопросы в принципе могут представлять интерес, но очень оторваны от реальных потребностей бизнеса. Какие-то моменты выдернуты из книг, поэтому лучше знакомиться с ними, читая первоисточник. Но есть кейсы, которые на первый взгляд хоть и кажутся простыми и стереотипными, но, если присмотреться к ним более пристально, могут дать пищу для размышления. Вот на одной из таких полезных задач мне хотелось бы заострить внимание в данной заметке. Формулируется вопрос следующим образом: «Необходимо определить количество пар товаров в продуктовых чеках. Вывести 10 самых частых сочетаний». Пример, чек 1 содержит товар 1, товар 2, товар 3, а чек 2 -  товар 1, товар 2, товар 5. Следовательно, комбинация «товар 1, товар 2» встречается 2 раза, «товар 1 , товар 3» один раз и т.д.

В исходнике решать данный кейс предлагалось силами Python. Но реальная жизнь может потребовать от аналитика данных умения выполнять данное упражнение как с помощью SQL, так и Spark. Следовательно, рассмотрим три подхода, оставив за скобками разговора четвертый вариант – расчеты на платформах BI.

Естественным источником информации в банке о покупках клиента являются карточные транзакции – любые операции, проводимые по дебетовым или кредитным картам. При этом денежные операции клиента не ограничиваются транзакциями, проводимыми с помощью карт. Оплата ЖКХ, оплата образования, крупные покупки и другие денежные переводы – это примеры транзакций, которые никак не привязаны к карте клиента, но при этом они ассоциируются с другой банковской сущностью – расчетным счетом. 

Про то, как мы в Альфа-Банке применяем карточные транзакции в моделировании, мы уже рассказывали в этом посте. Логичным развитием идеи использования карточной транзакционной истории клиента является использование данных, которые содержатся в клиентской истории транзакций расчетного счета.

Архитектура сети данных (data mesh) распределяет владение данными среди команд из разных предметных областей, с федеративным управлением и децентрализованными продуктами по обработке данных. Сеть данных отличается от других аналогичных архитектур именно своей высокой децентрализацией: она распределена, а не централизована.

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

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

Правильное построение ETL-процессов (преобразования данных) — сложная задача, а при большом объёме обрабатываемых данных неизбежно возникают проблемы с ресурсами. Поэтому нам требуется выискивать новые архитектурные решения, способные обеспечить стабильность расчётов и доступность данных, а при необходимости и масштабируемость — с минимальными усилиями.

Когда я пришел в Ozon, мне пришлось столкнуться с огромным количеством ETL-джоб. Прежде чем применить модель машинного обучения, сырые данные проходят множество этапов обработки. А само применение модели (то, ради чего существует команда) занимает всего 5% времени.

Всем привет! Меня зовут Иван Максимов, я работаю Lead Data Scientist’ом в команде рекомендаций и A/B-тестирования Delivery Club. Это первая из серии статей про нашу рекомендательную систему. Я расскажу о том, как мы определили проблемы предыдущего подхода к рекомендациям, и как начали строить новый: с оптимизацией рекомендаций сразу под несколько бизнес-метрик. 

Статья будет интересна data scientist’ам и менеджерам продуктов, которые хотят с нуля построить систему рекомендации контента.

Одной из проблем, свойственным заведениям из сферы HoReCa (рестораны, фастфуды, кафе и отели) и Call Center/Contact Center, является планирование расписания. Проблемы с планированием, в первую очередь, возникают из-за плавающих графиков, различных типов совмещений и построения рабочих графиков исходя из квалификации сотрудников (компетенции). Особенно остро данный вопрос стоит у крупных сетей с большим товарооборотом, где правильная расстановка смен определяет качество обслуживания, оперативность и, самое главное, влияет на выручку и прибыль заведения либо всей сети.

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