System Design for Recommendations and Search

eugeneyan

eugeneyan

Start Here Writing Speaking Prototyping About

System Design for Recommendations and Search

Системный дизайн для рекомендаций и поиска

[ teardown production engineering recsys 🔥 ] · 13 min read

[ teardown production engineering recsys 🔥 ] · 13 мин чтения

Also translated to Korean thanks to Zimin Park.

Также переведено на корейский благодаря Zimin Park.

How do the system designs for industrial recommendations and search look like? It’s uncommon to see system design discussed in machine learning papers or blogs; most focus on model design, training data, and/or loss functions. Nonetheless, the handful of papers that discuss implementation details elucidate design patterns and best practices that are hard to gain outside of hands-on experience.

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

Specific to discovery systems (i.e., recommendations and search), most implementations I’ve come across follow a similar paradigm—components and processes are split into offline vs. online environments, and candidate retrieval vs. ranking steps. The 2 x 2 below tries to simplify this.

Если говорить именно о системах обнаружения (то есть рекомендациях и поиске), большинство встреченных мной реализаций следуют схожей парадигме: компоненты и процессы разделены на оффлайн- и онлайн-среды, а также на этапы candidate retrieval и ranking. Матрица 2×2 ниже пытается упростить это представление.

2 x 2 of online vs. offline environments, and candidate retrieval vs. ranking.

Матрица 2×2 онлайн- и оффлайн-сред, а также candidate retrieval и ranking.

The offline environment largely hosts batch processes such as model training (e.g., representation learning, ranking), creating embeddings for catalog items, and building an approximate nearest neighbors (ANN) index or knowledge graph to find similar items. It may also include loading item and user data into a feature store that is used to augment input data during ranking.

Оффлайн-среда в основном содержит батч-процессы: обучение моделей (например, representation learning, ranking), создание эмбеддингов для товаров каталога, построение индекса approximate nearest neighbors (ANN) или графа знаний для поиска похожих объектов. Сюда же может входить загрузка данных о товарах и пользователях в feature store, который используется для обогащения входных данных во время ranking.

The online environment then uses the artifacts generated (e.g., ANN indices, knowledge graphs, models, feature stores) to serve individual requests. A typical approach is converting the input item or search query into an embedding, followed by candidate retrieval and ranking. There are also other preprocessing steps (e.g., standardizing queries, tokenization, spell check) and post-processing steps (e.g., filtering undesirable items, business logic) though we won’t discuss them in this writeup.

Онлайн-среда затем использует сгенерированные артефакты (например, ANN-индексы, графы знаний, модели, feature stores) для обработки отдельных запросов. Типичный подход — преобразование входного товара или поискового запроса в эмбеддинг с последующим candidate retrieval и ranking. Существуют также другие шаги предобработки (например, нормализация запросов, токенизация, проверка орфографии) и постобработки (например, фильтрация нежелательных товаров, бизнес-логика), но в этой заметке мы их не рассматриваем.

Candidate retrieval is a fast—but coarse—step to narrow down millions of items into hundreds of candidates. We trade off precision for efficiency to quickly narrow the search space (e.g., from millions to hundreds, a 99.99% reduction) for the downstream ranking task. Most contemporary retrieval methods convert the input (i.e., item, search query) into an embedding before using ANN to find similar items. Nonetheless, in the examples below, we’ll also see systems using graphs (DoorDash) and decision trees (LinkedIn).

Candidate retrieval — быстрый, но грубый шаг для сужения миллионов товаров до сотен кандидатов. Мы жертвуем точностью ради эффективности, чтобы быстро сузить пространство поиска (например, с миллионов до сотен — сокращение на 99,99%) для последующей задачи ranking. Большинство современных методов retrieval преобразуют вход (товар, поисковый запрос) в эмбеддинг, а затем используют ANN для поиска похожих объектов. Тем не менее, в примерах ниже мы увидим и системы, использующие графы (DoorDash) и деревья решений (LinkedIn).

Ranking is a slower—but more precise—step to score and rank top candidates. As we’re processing fewer items (i.e., hundreds instead of millions), we have room to add features that would have been infeasible in the retrieval step (due to compute and latency constraints). Such features include item and user data, and contextual information. We can also use more sophisticated models with more layers and parameters.

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

Ranking can be modeled as a learning-to-rank or classification task, with the latter being more commonly seen. If deep learning is applied, the final output layer is either a softmax over a catalog of items, or a sigmoid predicting the likelihood of user interaction (e.g., click, purchase) for each user-item pair.

Ranking можно моделировать как задачу learning-to-rank или классификации, причём вторая встречается чаще. Если применяется deep learning, итоговый выходной слой представляет собой либо softmax по каталогу товаров, либо sigmoid, предсказывающий вероятность взаимодействия пользователя (например, клик, покупка) для каждой пары пользователь-товар.

Next, let’s see how the processes above come together in a recommender or search system.

Далее посмотрим, как описанные процессы складываются вместе в рекомендательной или поисковой системе.

Basic system design for recommendations and search, based on the 2 x 2 above.

Базовый системный дизайн для рекомендаций и поиска на основе матрицы 2×2 выше.

In the offline environment, data flows bottom-up, where we use training data and item/user data to create artifacts such as models, ANN indices, and feature stores. These artifacts are then loaded into the online environment (via the dashed arrows). In the online environment, each request flows left to right, through the retrieval and ranking steps before returning a set of results (e.g., recommendations, search results).

В оффлайн-среде данные движутся снизу вверх: мы используем обучающие данные и данные о товарах/пользователях для создания артефактов — моделей, ANN-индексов и feature stores. Эти артефакты затем загружаются в онлайн-среду (через пунктирные стрелки). В онлайн-среде каждый запрос проходит слева направо, через шаги retrieval и ranking, прежде чем вернуть набор результатов (например, рекомендации, поисковую выдачу).

Additional details on some arrows in the diagram:

Дополнительные пояснения к некоторым стрелкам на схеме:

С помощью обученной модели representation learning эмбеддируем товары в каталоге. На основе эмбеддингов товаров строим ANN-индекс, позволяющий находить похожие эмбеддинги и соответствующие им товары. Получаем (исторические) признаки для обогащения обучающих данных модели ranking. Используем один и тот же feature store при оффлайн-обучении и онлайн-сервинге, чтобы минимизировать train-serve skew. Может потребоваться time travel. Используем эмбеддинг входного запроса/товара(ов) для извлечения k похожих объектов через ANN. Добавляем признаки товаров и пользователей к кандидатам для последующего ranking. Ранжируем кандидатов по целевым метрикам — клики, конверсии и т. п.

Update: This 2x2 has since been referenced in other resources, including:

• NVIDIA’s “Recommender Systems, Not Just Recommender Models”
• Xavier Amatriain’s “Blueprints for RecSys Architectures”

Обновление: эта матрица 2×2 с тех пор упоминалась в других материалах, в том числе: NVIDIA «Recommender Systems, Not Just Recommender Models» и Xavier Amatriain «Blueprints for RecSys Architectures».

Examples from Alibaba, Facebook, JD, Doordash, etc.

Примеры от Alibaba, Facebook, JD, Doordash и других

Next, we’ll briefly discuss the high-level system design of some discovery systems, based on their respective papers and tech blogs. I’ll highlight how these systems are split into offline and online environments, and their retrieval and ranking steps. For full details on the methodology, model, etc., I recommend you read the full paper/blog.

Далее кратко обсудим высокоуровневый системный дизайн нескольких систем обнаружения по их статьям и техноблогам. Я выделю, как эти системы разделены на оффлайн- и онлайн-среды и шаги retrieval и ranking. За полным описанием методологии, моделей и т. п. рекомендую обратиться к самим статьям и публикациям.

We start with Alibaba’s sharing about building item embeddings for candidate retrieval. In the offline environment, session-level user-item interactions are mined to construct a weighted, bidirectional item graph. The graph is then used to generate item sequences via random walks. Item embeddings are then learned via representation learning (i.e., word2vec skip-gram), doing away with the need for labels. Finally, with the item embeddings, they get the nearest neighbor for each item and store it in their item-to-item (i2) similarity map (i.e., a key-value store).

Начнём с публикации Alibaba о построении эмбеддингов товаров для candidate retrieval. В оффлайн-среде взаимодействия пользователь-товар на уровне сессий анализируются для построения взвешенного двунаправленного графа товаров. Затем граф используется для генерации последовательностей товаров с помощью случайных блужданий. Эмбеддинги товаров обучаются через representation learning (word2vec skip-gram), что устраняет необходимость в разметке. Наконец, имея эмбеддинги, для каждого товара находят ближайшего соседа и сохраняют его в item-to-item (i2i) similarity map (хранилище ключ-значение).

Alibaba's design for candidate retrieval in Taobao via item embeddings and ANN.

Дизайн Alibaba для candidate retrieval в Taobao через эмбеддинги товаров и ANN.

In the online environment, when the user launches the app, the Taobao Personalization Platform (TPP) starts by fetching the latest items that the user interacted with (e.g., click, like, purchase). These items are then used to retrieve candidates from the i2i similarity map. The candidates are then passed to the Ranking Service Platform (RSP) for ranking via a deep neural network, before being displayed to the user.

В онлайн-среде, когда пользователь запускает приложение, Taobao Personalization Platform (TPP) начинает с получения последних товаров, с которыми взаимодействовал пользователь (клик, лайк, покупка). Эти товары затем используются для извлечения кандидатов из i2i similarity map. Кандидаты передаются в Ranking Service Platform (RSP) для ранжирования через глубокую нейросеть, после чего отображаются пользователю.

Alibaba also shared a similar example where they apply a graph network for ranking. In the offline environment, they combine an existing knowledge graph (G), user behavior (e.g., impressed but not clicked, clicked), and item data to create an adaptive knowledge graph (G_ui). This is then merged with user data (e.g., demographics, user-item preferences) to train the ranking model (Adaptive Target-Behavior Relational Graph Network, ATBRN).

Alibaba также поделилась похожим примером, где применяет графовую сеть для ranking. В оффлайн-среде они объединяют существующий граф знаний (G), поведение пользователей (например, показано, но не кликнуто, кликнуто) и данные о товарах, чтобы создать адаптивный граф знаний (G_ui). Затем он объединяется с данными о пользователях (демография, предпочтения пользователь-товар) для обучения модели ranking — Adaptive Target-Behavior Relational Graph Network (ATBRN).

Alibaba's design for ranking in Taobao via a graph network (ATBRN).

Дизайн Alibaba для ranking в Taobao через графовую сеть (ATBRN).

In the online environment, given a user request, the candidate generator retrieves a set of candidates and the user ID, before passing them to the Real-Time Prediction (RTP) platform. RTP then queries the knowledge graph and feature stores for item and user attributes. The graph representations, item data, and user data is then fed into the ranking model (i.e., ATBRN) to predict the probability of click on each candidate item. The candidates are then reordered based on probability and displayed to the user.

В онлайн-среде на запрос пользователя генератор кандидатов извлекает набор кандидатов и user ID, после чего передаёт их в Real-Time Prediction (RTP) платформу. RTP затем запрашивает граф знаний и feature stores для атрибутов товаров и пользователей. Графовые представления, данные о товарах и пользователях подаются в модель ranking (ATBRN), которая предсказывает вероятность клика по каждому кандидату. Кандидаты затем переупорядочиваются по вероятности и показываются пользователю.

Next, we look at Facebook’s embedding-based retrieval for search. In the offline environment (right half of image), they first train a two-tower network—with a query encoder and document encoder—that outputs cosine similarity for each query-document pair (not shown in image). This ensures that search queries and documents (e.g., user profiles, groups) are in the same embedding space.

Далее посмотрим на embedding-based retrieval для поиска от Facebook. В оффлайн-среде (правая половина изображения) они сначала обучают двухбашенную сеть — с энкодером запросов и энкодером документов — которая выдаёт косинусное сходство для каждой пары запрос-документ (на изображении не показано). Это гарантирует, что поисковые запросы и документы (например, профили пользователей, группы) находятся в одном эмбеддинг-пространстве.

Facebook's design for embedding-based retrieval via query and document encoders.

Дизайн Facebook для embedding-based retrieval через энкодеры запросов и документов.

Then, with the document encoder, they embed each document via Spark batch jobs. The embeddings are then quantized and published into their ANN index (“inverted index”). This ANN index is based on Faiss and fine-tuned (see Section 4.1 of paper). The embeddings are also published in a forward index, without quantization, for ranking. The forward index can also include other data such as profile and group attributes to augment candidates during ranking.

Затем с помощью энкодера документов они эмбеддируют каждый документ через батч-задачи Spark. Эмбеддинги квантуются и публикуются в их ANN-индексе («inverted index»). Этот ANN-индекс основан на Faiss и доработан (см. раздел 4.1 статьи). Эмбеддинги также публикуются в forward index без квантования — для ranking. Forward index может также включать иные данные, например атрибуты профилей и групп, для обогащения кандидатов во время ranking.

In the online environment, each search request goes through query understanding and is embedded via the query encoder. The search request and associated embedding then go through the retrieval step to get nearest neighbor candidates via the ANN index and boolean filtering (e.g., match on name, location, etc.). The candidates are then augmented with full embeddings and additional data from the forward index before being ranked.

В онлайн-среде каждый поисковый запрос проходит через query understanding и эмбеддируется через энкодер запросов. Запрос и связанный эмбеддинг затем проходят через шаг retrieval, чтобы получить ближайших соседей через ANN-индекс и булеву фильтрацию (например, совпадение по имени, локации и т. п.). Кандидаты затем обогащаются полными эмбеддингами и дополнительными данными из forward index перед ранжированием.

JD shared a similar approach for semantic retrieval for search. In the offline environment, a two-tower model with a query encoder and an item encoder is trained to output a similarity score for each query-item pair. The item encoder then embeds catalog items before loading them into an embedding index (i.e., key-value store).

JD поделились похожим подходом к семантическому retrieval для поиска. В оффлайн-среде обучается двухбашенная модель с энкодером запросов и энкодером товаров, выдающая оценку сходства для каждой пары запрос-товар. Энкодер товаров затем эмбеддирует товары каталога и загружает их в embedding index (хранилище ключ-значение).

Major stages of an e-commerce search systems (left), JD's design for candidate retrieval (right).

Основные стадии e-commerce поисковых систем (слева), дизайн JD для candidate retrieval (справа).

Then, in the online environment, each query goes through preprocessing (e.g., spelling correction, tokenization, expansion, and rewriting) before being embedding via the query encoder. The query embedding is then used to retrieve candidates from the embedding index via nearest neighbors lookup. The candidates are then ranked on factors such as relevance, predicted conversion, etc.

Затем в онлайн-среде каждый запрос проходит предобработку (проверка орфографии, токенизация, расширение и переформулировка) перед эмбеддингом через энкодер запросов. Эмбеддинг запроса используется для извлечения кандидатов из embedding index через поиск ближайших соседей. Кандидаты затем ранжируются по таким факторам, как релевантность, прогнозируемая конверсия и т. п.

The paper also shares practical tips to optimize model training and serving. For model training, they raised that the de facto input of user-item interaction, item data, and user data is duplicative—item and user data appear once per row, consuming significant disk space. To address this, they built a custom TensorFlow dataset where user and item data are first loaded into memory as lookup dictionaries. Then, during training, these dictionaries are queried to append user and item attributes to the training set. This simple practice reduced training data size by 90%.

В статье также приводятся практические советы по оптимизации обучения и сервинга моделей. Что касается обучения, они отметили, что де-факто вход — взаимодействия пользователь-товар, данные о товарах и пользователях — дублируется: данные о товарах и пользователях встречаются в каждой строке, занимая значительное место на диске. Чтобы решить эту проблему, они построили кастомный TensorFlow dataset, где данные о пользователях и товарах сначала загружаются в память как lookup-словари. Затем во время обучения эти словари запрашиваются, чтобы добавить атрибуты пользователей и товаров к обучающей выборке. Эта простая практика сократила размер обучающих данных на 90%.

They also called out the importance of ensuring offline training and online serving consistency. For their system, the most critical step was text tokenization which happens thrice (data preprocessing, training, serving). To minimize train-serve skew, they built a C++ tokenizer with a thin Python wrapper that was used for all tokenization tasks.

Они также подчеркнули важность обеспечения согласованности оффлайн-обучения и онлайн-сервинга. Для их системы самым критичным шагом была токенизация текста, которая выполняется трижды (предобработка данных, обучение, сервинг). Чтобы минимизировать train-serve skew, они построили токенизатор на C++ с тонкой Python-обёрткой, который использовался для всех задач токенизации.

For model serving, they shared how they reduced latency by combining services. Their model had two key steps: query embedding and ANN lookup. The simple approach would be to have each as a separate service, but this would require two network calls and thus double network latency. Thus, they unified the query embedding model and ANN lookup in a single instance, where the query embedding is passed to the ANN via memory instead of network.

Что касается сервинга моделей, они рассказали, как снизили задержку, объединив сервисы. Их модель имела два ключевых шага: эмбеддинг запроса и ANN-поиск. Простой подход — сделать каждый из них отдельным сервисом, но это потребовало бы двух сетевых вызовов и, соответственно, удвоило бы сетевую задержку. Поэтому они объединили модель эмбеддинга запроса и ANN-поиск в одном инстансе, где эмбеддинг запроса передаётся в ANN через память, а не через сеть.

They also shared how they run hundreds of models simultaneously, for different retrieval tasks and various A/B tests. Each “servable” consists of a query embedding model and an ANN lookup, requiring 10s of GB. Thus, each servable had their own instance, with a proxy module (or load balancer) to direct incoming requests to the right servable.

Они также рассказали, как запускают сотни моделей одновременно — для разных задач retrieval и различных A/B-тестов. Каждый «servable» состоит из модели эмбеддинга запроса и ANN-поиска и требует десятки гигабайт. Поэтому у каждого servable свой инстанс, а прокси-модуль (или балансировщик нагрузки) направляет входящие запросы к нужному servable.

How JD organizes the embedding model and ANN indices across multiple versions.

Как JD организует модель эмбеддинга и ANN-индексы в нескольких версиях.

(Aside: My candidate retrieval systems have a similar design pattern. Embedding stores and ANN indices are hosted on the same docker container—you’ll be surprised how far this goes with efficiently-sized embeddings. Furthermore, Docker makes it easy to version, deploy, and roll back each model, as well as scale horizontally. Fronting the model instances with a load balancer takes care of directing incoming requests, blue-green deployments, and A/B testing. SageMaker makes this easy.)

(Отступление: мои системы candidate retrieval имеют похожий паттерн. Embedding stores и ANN-индексы хостятся в одном docker-контейнере — вы удивитесь, насколько далеко это работает при эффективно подобранных размерах эмбеддингов. Кроме того, Docker облегчает версионирование, развёртывание и откат каждой модели, а также горизонтальное масштабирование. Балансировщик нагрузки перед инстансами моделей берёт на себя направление входящих запросов, blue-green deployments и A/B-тестирование. SageMaker делает это простым.)

Next, we move from the embedding + ANN paradigm and look at DoorDash’s use of a knowledge graph for query expansion and retrieval. In the offline environment, they train models for query understanding, query expansion, and ranking. They also load documents (i.e., restaurants and food items) into ElasticSearch for use in retrieval, and attribute data (e.g., ratings, price points, tags) into a feature store.

Далее уходим от парадигмы эмбеддинги + ANN и смотрим, как DoorDash использует граф знаний для расширения запросов и retrieval. В оффлайн-среде они обучают модели для query understanding, расширения запросов и ranking. Они также загружают документы (рестораны и блюда) в ElasticSearch для использования в retrieval, а данные атрибутов (рейтинги, ценовые категории, теги) — в feature store.

DoorDash splits search into offline and online, and retrieval (recall) and ranking (precision).

DoorDash разделяет поиск на оффлайн и онлайн, а также retrieval (recall) и ranking (precision).

In the online environment, each incoming query is first standardized (e.g., spell check) and synonymized (via a manually curated dictionary). Then, the knowledge graph (Neo4J) expands the query by finding related tags. For example, a query for “KFC” will return tags such as “fried chicken” and “wings”. These tags are then used to retrieve similar restaurants such as “Popeyes” and “Bonchon”.

В онлайн-среде каждый входящий запрос сначала нормализуется (проверка орфографии) и синонимизируется (через вручную составленный словарь). Затем граф знаний (Neo4J) расширяет запрос, находя связанные теги. Например, запрос «KFC» вернёт теги «fried chicken» и «wings». Эти теги затем используются для извлечения похожих ресторанов вроде «Popeyes» и «Bonchon».

These candidates are then ranked based on lexical similarity between the query and documents (aka restaurants, food items), store popularity, and possibly the search context (e.g., time of day, location). Finally, the ranked results are augmented with attributes such as ratings, price point, and delivery time and cost before displayed to the customer.

Эти кандидаты затем ранжируются на основе лексического сходства между запросом и документами (то есть ресторанами и блюдами), популярности заведения и, возможно, поискового контекста (время суток, локация). Наконец, ранжированные результаты обогащаются атрибутами — рейтингами, ценовой категорией, временем и стоимостью доставки — перед показом клиенту.

Finally, we look at how LinkedIn personalizes talent search results. Their system relies heavily on XGBoost, first as a model to retrieve the top 1,000 candidates for ranking, and second, as a generator of features (i.e., model scores, tree interactions) for their downstream ranking model (a generalized linear mixed model aka GLMix).

Наконец, посмотрим, как LinkedIn персонализирует поиск талантов. Их система во многом опирается на XGBoost: сначала как модель для извлечения топ-1000 кандидатов для ranking, а затем как генератор признаков (оценки модели, взаимодействия деревьев) для последующей модели ranking — generalized linear mixed model, она же GLMix.

LinkedIn's offline design for generating tree-based features, and training GLMix ranking models.

Оффлайн-дизайн LinkedIn для генерации признаков на основе деревьев и обучения моделей ranking GLMix.

In the offline environment, they first combine impression and label data to generate training data (step 1 in image above). Labels consist of instances where the recruiter sent a message to potential hires and the user responded positively. The training data is then fed into a pre-trained XGBoost model to generate model scores and tree interaction features (step 3 in image above) to augment the training data. This augmented data is then used to train the ranking model (GLMix).

В оффлайн-среде они сначала объединяют данные о показах и разметку для создания обучающих данных (шаг 1 на изображении выше). Метки состоят из случаев, когда рекрутер отправлял сообщение потенциальному кандидату, и пользователь отвечал положительно. Обучающие данные затем подаются в предобученную модель XGBoost для генерации оценок модели и признаков взаимодействия деревьев (шаг 3 на изображении выше) для обогащения обучающих данных. Эти обогащённые данные затем используются для обучения модели ranking (GLMix).

LinkedIn's online design for candidate retrieval, feature augmentation, and ranking via GLMix.

Онлайн-дизайн LinkedIn для candidate retrieval, обогащения признаками и ranking через GLMix.

In the online environment, with each search request, the search engine (maybe Elastic or Solr?) first retrieves candidates which are then scored via a first-level XGBoost model. The top 1,000 candidates are then augmented with (i) additional features (step 2 in image above) and (ii) tree interaction features via a second-level XGBoost model (step 3 in image above). Finally, these augmented candidates are ranked before the top 125 results are shown to the user.

В онлайн-среде на каждый поисковый запрос поисковый движок (возможно, Elastic или Solr?) сначала извлекает кандидатов, которых затем оценивает модель XGBoost первого уровня. Топ-1000 кандидатов затем обогащаются (i) дополнительными признаками (шаг 2 на изображении выше) и (ii) признаками взаимодействия деревьев через модель XGBoost второго уровня (шаг 3 на изображении выше). Наконец, эти обогащённые кандидаты ранжируются, и топ-125 результатов показываются пользователю.

Conclusion

Заключение

That was a brief overview of the offline-online, retrieval-ranking pattern for search and recommendations. While this isn’t the only approach for discovery systems, from what I’ve seen, it’s the most common design pattern. I’ve found it helpful to distinguish the latency-constrained online systems from the less-demanding offline systems, and split the online process into retrieval and ranking steps.

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

If you’re starting to build your discovery system, start with candidate retrieval via simple embeddings and approximate nearest neighbors, before adding a ranker on top of it. Alternatively, consider using a knowledge graph like Uber and DoorDash did. But before you get too excited, think hard about whether you need real-time retrieval and ranking, or if batch recommendations will suffice.

Если вы только начинаете строить свою систему обнаружения, начните с candidate retrieval через простые эмбеддинги и approximate nearest neighbors, а затем добавьте ranker сверху. Альтернативно можно рассмотреть граф знаний — как сделали Uber и DoorDash. Но прежде чем слишком увлекаться, серьёзно подумайте, действительно ли вам нужны realtime retrieval и ranking, или батчевых рекомендаций будет достаточно.

Did I miss out anything? Please reach out and let me know!

Я что-то упустил? Пожалуйста, напишите мне и расскажите!

Let's explore how recsys & search are often split into:

• Latency-constrained online vs. less-demanding offline environments
• Fast but coarse candidate retrieval vs. slower and more precise ranking

Examples from Alibaba, Facebook, JD, DoorDash, etc.https://t.co/zTsfElLw1z

Давайте разберём, как recsys и поиск часто делятся на: • Онлайн-среды с ограничениями по задержкам vs. менее требовательные оффлайн-среды • Быстрый, но грубый candidate retrieval vs. более медленный и точный ranking. Примеры от Alibaba, Facebook, JD, DoorDash и других. https://t.co/zTsfElLw1z — Eugene Yan (@eugeneyan) June 30, 2021

Update (2022-04-14): Even Oldridge and Karl Byleen-Higley from NVIDIA updated the 2-stage design to 4-stages by adding a filtering step and splitting ranking into scoring and ordering. They also presented it at KDD’s Industrial Recommender Systems workshop.

Обновление (2022-04-14): Even Oldridge и Karl Byleen-Higley из NVIDIA расширили двухстадийный дизайн до четырёхстадийного, добавив шаг фильтрации и разделив ranking на scoring и ordering. Они также представили это на воркшопе Industrial Recommender Systems на KDD.

Even Oldridge & Karl Byleen-Higley (NVIDIA) augmented my 2-stage design with 2 more stages.

Even Oldridge и Karl Byleen-Higley (NVIDIA) дополнили мой двухстадийный дизайн ещё двумя стадиями.

References

Источники

Billion-scale Commodity Embedding for E-commerce Recommendation Alibaba Adaptive Target-Behavior Relational Graph Network for Recommendation Alibaba Embedding-based Retrieval in Facebook Search Facebook An End-to-End Solution for E-commerce Search via Embedding Learning JD Things Not Strings: Understanding Search Intent with Better Recall DoorDash Entity Personalized Talent Search Models with Tree Interaction Features LinkedIn Faiss: A Library for Efficient Similarity Search Facebook

Thanks to Yang Xinyi for reading drafts of this.

Спасибо Yang Xinyi за чтение черновиков.

If you found this useful, please cite this write-up as:

Если этот материал был полезен, пожалуйста, цитируйте его как:

Yan, Ziyou. (Jun 2021). System Design for Recommendations and Search. eugeneyan.com. https://eugeneyan.com/writing/system-design-for-discovery/.

Yan, Ziyou. (Jun 2021). System Design for Recommendations and Search. eugeneyan.com. https://eugeneyan.com/writing/system-design-for-discovery/.

or

или

@article{yan2021system, title = {System Design for Recommendations and Search}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Jun}, url = {https://eugeneyan.com/writing/system-design-for-discovery/} }

@article{yan2021system, title = {System Design for Recommendations and Search}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Jun}, url = {https://eugeneyan.com/writing/system-design-for-discovery/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателей, получающих обновления о машинном обучении, RecSys, LLM и инженерии.