Обучаемые векторы для рекомендательных систем.

Есть конечное множество пользователей и айтемов. Хотим рекомендовать пользователям айтемы.

Пусть для каждого объекта задано векторное представление, при этом предпочтения пользователя u определяются через скалярное произведение <u, i> для любого айтема i. Тогда говорят, что векторы пользователей и айтемов находятся в одном семантическом пространстве, а такую модель называют двухбашенной. Эти векторы еще часто называют эмбеддингами, потому что объекты буквально вкладываются (англ. to embed) в векторное пространство.

Почти в любой нейросети возникают векторы объектов. Иногда это целевая задача - получить эмбеддинги, обладающие определенными полезными свойствами (привет, representation learning). В рекомендашках это тоже актуально; и (1) для кандидатогенерации, которую часто делают на основе эмбеддингов (embedding-based retrieval), и (2) для ранжирования, серьезный вклад в которое вносят нейросетевые признаки.

В случае обучаемых эмбеддингов векторы объектов объявляются частью параметров модели; их значения подбираются в процессе оптимизации. Рассмотрим двухбашенную модель с обучаемыми векторами: она задается функционалом потерь (+ данными для обучения), процедурой оптимизации и, непосредственно, набором обучаемых векторов.

Утверждается, что у такой модели максимальная емкость. Что вообще такое емкость модели (англ. model capacity)? Это способность выражать взаимосвязи, аппроксимировать функции. В терминах двухбашенной модели об этом думать проще: представим, что у нас есть некоторая оптимальная структура семантического пространства (если нас волнует только семантическая близость объектов, то с точностью до поворотов, сдвигов и, возможно, масштабов), которую мы хотим получить.

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

Почему бы тогда не использовать всегда только обучаемые векторы? Несколько причин:
1. Недостаточно данных. Bias-variance tradeoff гласит, что более сложные модели сильнее переобучаются, hence для них нужно больше данных. Double descent в рекомендашках я пока не наблюдал, поэтому будем считать, что это правда :)
2. Тяжелые хвосты (long tail distributions). Если у вас большая часть объектов мало встречается в данных (т.е. хвост тяжелый), то про них сложновато делать выводы без дополнительной информации (e.g. контента), и тем более сложно выучить хорошие векторные представления.
3. Постоянно появляются новые объекты, поэтому нужна индуктивность - умение работать на объектах, не встречавшихся в обучении. У обучаемых векторов она отсутствует, они трансдуктивны.
4. Нестационарность распределений. Интересы пользователей меняются, содержимое айтемов обновляется, тренды (популярности объектов) эволюционируют. Обучаемые векторы это не учитывают.

Последние два пункта частично лечатся инкрементальным дообучением (получили новые данные - дообучились). Но:
* проблема курицы и яйца - чтобы дообучиться, надо накопить фидбек для новых объектов. Чтобы его накопить, нужно их рекомендовать. Если модель на них не дообучалась, то и рекомендовать их не будет.
* у инкрементального дообучения будет определенная задержка, побороть которую можно только невероятными инфраструктурными усилиями. Пока дообучение не произойдет, качество работы на новых и изменившихся объектах будет плохое.

Что же тогда делать? Вносить индуктивное смещение (англ. inductive bias): анализировать содержимое айтемов, делать нейросетевые энкодеры, добавлять регуляризацию, представлять пользователя через историю взаимодействий, etc. Об индуктивном смещении и как оно помогает бороться со всеми этими проблемами поговорим в другой раз :)

Пример мини-исследования

Прошлый пост набрал рекордное кол-во реакций за все 3-х месячное существование канала (напопрошайничал), поэтому распишу обещанный пример отдельным постом.

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

1. Постановка вопроса
Продакт приходит к нам и просит понять, насколько эффективно директора выводят на работу сборщиков? Стоит ли нам в будущем взять этот процесс на себя?

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

3. Сбор данных
Собираем данные из хранилища в формате:
день - название магазина - длина смен сборщиков - время затраченное на сборку заказов - утилизация %, где
утилизация = время на сборку заказов / время всей смены

4. Проверка данных на качество
Смотрим распределения метрик визуально и проверяем, нет ли у нас подозрительно низких или высоких значений. И находятся ли средние в интуитивно адекватных диапазонах

5. Анализ и подведение итогов
Получаем среднюю утилизацию в 40%, что нам кажется слишком маленьким значением. Считаем, сколько мы тратим денег на зарплаты/часов сборщиков впустую, с прикидкой что «в идеале» утилизация должна быть 50-60%.

6. Обсуждение итогов
Сходимся с продактом, что 40% правда маловато. Договариваемся отдельно обсудить итоги анализа с «бизнесом» (стейкхолдерами). Держим предварительно в приоритете задачу по тому, чтобы начать планировать смены сборщиков самим без участия директоров.

p.s. настоящие цифры, детали и нюансы были опущены по очевидным причинам

#quant #career

Hard skills in HFT (for software execution devs)

- С++ - потому что большинство HFT фирм используют для low latency именно его;
- template metaprogramming - в HFT используется значительно чаще чем вне, потому что из-за желания срезать каждую возможную микросекунду многое (иногда даже слишком) пишется на шаблонах;
- как работает какая нибудь конкретная биржа, какие у неё feed & transaction протоколы - спецификации обычно опубликованы на сайте биржи;
- как подписаться на market feed через multicast udp (и что делать если начнёшь терять пакеты);
- как быстро читать multicast udp с сетевой карточки через user space networking и построить вокруг этого mainloop (см. Solarflare/EfVi) и понимать почему kernel space networking не подойдёт;
- как быстро собирать order book из market feed;
- как максимально упаковать часто используемые данные в L1 cache, а редкоиспользуемые отложить в сторонку;
- как работает процессор и память (см. WEPSKAM и учебный FPGA);
- как спроектировать торговое приложение, какие в нём должны быть компоненты;
- как написать надёжные автотесты;
- как сделать бизнес-логику по-максимуму независимой от специфики конкретной биржи;
- как присоединить приложение к биржевым сессиям и ввести ограничение на транзакции в секунду;
- как добавить ограничение рисков и гарантировать, что они сработают.

@engineer10x

#recommender #graph

ML на графах в задаче e-commerce

Сегодня у нас пост присланный подписчиком: @marinadkntm (спасибо 🤩)

Допустим, мы решаем задачу поиска одинаковых товаров в онлайн-магазине.

Классический подход:
1. Подбор кандидатов. На этом этапе используется грубый, но быстрый алгоритм для подбора большого количества схожих объектов, потенциальных пар
2. Проверка пар моделью (т. н. матчинг) — более точная проверка того действительно ли в паре одинаковые объекты

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

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

На помощь приходит community detection (поиск сообществ), который представляет собой кластеризацию на графах.

В случае с товарами можно построить из них граф, рёбра между которыми будут соответствовать предсказанию модели, что товары являются дубликатами. На таком графе community detection поможет выделить группы одинаковых товаров.

Некоторые преимущества такого подхода:
1. Не нужно подбирать гиперпараметры. Например, задавать количество кластеров

2. Скорость. При таком подходе нет необходимости считать расстояние каждого объекта с каждым.

3. Масштабируемость. Можно запускать на больших графах параллельно на множестве executors

4. Self-supervised и Semi-supervised подходы. Задачу можно решать как при отсутствии какой-либо информации о кластерах, так и при заданной на части вершин информации о сообществах

Читайте подробнее про алгоритмы кластеризации на графах в:

📕 Статья на Habr

#ml #algo #novice