More Design Patterns For Machine Learning Systems

eugeneyan

Начать здесь Статьи Выступления Прототипирование О себе

Ещё паттерны проектирования для систем машинного обучения

[ machinelearning engineering production recsys ] · 20 мин чтения

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

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

Обрабатывать сырые данные только один раз Human-In-The-Loop Аугментация данных Hard Negative Mining Переформулирование задачи Каскад Маховик данных Слой бизнес-правил Оценка перед деплоем

(Если вам это интересно, возможно, понравится и предыдущий пост про паттерны проектирования в ML-коде, во многом вдохновлённый классической книгой «Банды четырёх».)

Обрабатывать сырые данные только один раз: чтобы избежать избыточности

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

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

Представьте, что мы работаем в e-commerce-компании, которая отслеживает поведение пользователей через логи кликстрима. Логи фиксируют посещённые страницы, просмотренные товары и действия (например, клик, добавление в корзину, покупку). Такой датасет огромен (один объект на каждое событие) и хранится в формате, не предназначенном для аналитики — например, в виде JSON в очереди Kafka, а не в таблицах.

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

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

Естественное продолжение этого паттерна — паттерн feature store, который централизует вычисление и хранение фичей. Feature store обеспечивают переиспользование и согласованность фичей между приложениями и сокращают дублирование труда, вычислений и хранения.

Human-In-The-Loop: чтобы собирать явные метки

Если наша ML-система использует обучение с учителем, без меток не обойтись. А если меток нет — например, мы решаем новую задачу — можно применить HITL, чтобы их собрать. Метки можно собирать явно (например, аннотированием) или неявно (например, через органические клики и покупки). В этом разделе мы сосредоточимся на сборе явных меток.

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

Один из способов собирать метки — спросить пользователей напрямую. Например, Stack Exchange позволяет пользователям помечать посты как спам и затем использует эти метки для обучения моделей детекции спама. Аналогично, LinkedIn полагается на пользователей, которые сообщают о сообщениях с харассментом, а Uber получает жалобы на мошенничество, когда пользователи оспаривают списания или выставляют chargeback.

Пометка поста как спама, оскорбительного, низкокачественного и т.п. на Stack Exchange

Другой подход — использовать сторонние или внутренние сервисы аннотирования. Например, DoorDash использовала комбинацию Mechanical Turk и профессиональных аннотаторов, чтобы категоризировать позиции меню по стилю кухни, вкусу и т.д. Аналогично, Airbnb опиралась на HITL, чтобы распределять объявления по различным группам: достопримечательностям, активностям, типам жилья и т.д.

В качестве примера экспертных аннотаторов: в Uber внутренние аналитики разбирали тренды мошенничества. Эти эксперты анализировали и выявляли новые паттерны мошенничества, которые ML-модели, обученные на прошлых данных, могли пропустить (то есть false negatives), и затем формулировали эвристики для программного выявления таких случаев в будущих транзакциях. Они также подтверждали, действительно ли отмеченные транзакции были мошенническими (то есть true positives).

При этом в будущем HITL может понадобиться нам в меньших объёмах. Недавние исследования показали, что большие языковые модели (LLM) справляются с разметкой ground truth наравне с людьми, а то и лучше.

Например, исследование показало, что gpt-3.5-turbo превзошёл работников Mechanical Turk в четырёх из пяти задач аннотирования (релевантность, определение темы, определение позиции и определение фрейма) на 2 382 твитах. При этом стоимость составила менее $0.003 за аннотацию, то есть 5% от стоимости Mechanical Turk за аннотацию.

В другом исследовании использовали gpt-4 для классификации политической принадлежности пользователей Twitter по их твитам. Здесь LLM не только превзошли экспертов и краудворкеров по точности, но и показали более высокую межоценочную согласованность. Даже когда метки краудворкеров и экспертов объединялись голосованием большинства, LLM всё равно показывали лучшие результаты.

LLM обходят краудворкеров и экспертов-аннотаторов, даже когда последних объединяют ансамблем

Аугментация данных: чтобы увеличить объём и разнообразие данных

Аугментация данных — это процесс искусственного увеличения объёма и разнообразия обучающей выборки путём генерации новых примеров из существующих.

Плюсы: полезна, когда ground truth ограничен, несбалансирован или однообразен. Аугментация делает обучающие данные более репрезентативными и разнообразными, что помогает улучшить обобщающую способность модели и снизить переобучение. Минусы: сложно применять к табличным данным (по сравнению с изображениями и текстом). Также бывает непросто гарантировать, что синтетические данные соответствуют распределению реальных.

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

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

Аугментация текстовых данных через изменение порядка предложений или слов

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

Чтобы создать негативные примеры, они генерировали псевдослучайные строки на основе распределения вероятностей существующих токенов в обучающих данных. Они также усложнили задачу, добавляя сложные токены: валидные URI, user-agent, XML-контент и даже «опасные» n-граммы, часто встречающиеся в вредоносных payload’ах. Цель была в том, чтобы десенсибилизировать модель к отдельным токенам и ключевым словам и заставить её сосредоточиться на структурных и семантических аспектах payload’а более высокого уровня. Это снизило долю ложноположительных срабатываний примерно на 80%.

Аналогично, Meta использовала генераторы синтетических данных для создания чувствительных данных: номеров социального страхования, номеров кредитных карт, адресов и т.п. Uber также генерировала синтетические данные, опираясь на свой опыт и предположения о мошеннических атаках, чтобы валидировать алгоритмы детекции аномалий при автоматизированном тестировании пайплайнов данных. Библиотеки вроде Faker позволяют легко генерировать фейковые имена, адреса, номера телефонов и многое другое.

Hard Negative Mining: чтобы получить сложные примеры

Hard mining можно считать расширением аугментации данных: мы находим или генерируем сложные точки данных, на которых обучаем модель. Цель — улучшить качество модели на этих трудных случаях, чаще показывая ей их во время обучения.

Плюсы: часто ведёт к повышению качества модели. Как минимум, мы лучше измеряем, как модели справляются с этими сложными случаями. Минусы: найти такие сложные примеры бывает, что называется, сложно. Также нельзя просто обучать модель только на сложных примерах (см. пример Meta ниже).

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

Когда Meta строила embedding-based retrieval для поиска, они использовали hard mining, чтобы решить проблему слишком лёгких негативов в обучающих данных (то есть случайных негативов). Лёгкие негативы приводили к тому, что модель плохо справлялась с более сложными негативами. Парадоксально, но они обнаружили, что модели, обученные на сложных негативах, не работали лучше, чем модели, обученные на случайных. Причина была в том, что самые сложные негативы не отражали реальное поисковое поведение в Facebook, где большинство документов (люди, места) были относительно простыми.

Экспериментально они выяснили, что сэмплирование сложных негативов с рангов 101–500 (в результатах поиска) даёт наилучшее качество. В целом, смешивание случайных и сложных негативов улучшало recall, выходя на плато при соотношении лёгких к сложным 100:1. (У DoorDash, кстати, тоже было такое соотношение синтетических меток к реальным при обучении моделей.)

Другой подход — смешивать сложные негативы в curriculum learning, где обучающие данные отсортированы так, что сложность примеров постепенно растёт. Модель начинает с лёгких примеров и постепенно переходит к более сложным по мере того, как становится способнее.

Cloudflare использовала этот подход, обучая свой классификатор вредоносных payload’ов сначала на простых синтетических данных, затем на всё более сложных, а в финале — дообучая на реальных. Чтобы усложнить задачу, они добавляли шум разной сложности к вредоносным и безопасным примерам с целью сделать модель более устойчивой к padding-атакам. Это повысило true positive rate для зафуззенного контента с 91% до 97,5%.

Переформулирование задачи: чтобы упростить проблему или метку

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

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

В семантическом поиске Amazon у команды изначально была бинарная метка: куплено или нет. Затем они использовали двухчастный hinge loss, где \(\hat y\) — косинусное сходство между эмбеддингами запроса и товара, а \(y = 1\), если товар был куплен (в ответ на запрос), и ноль в противном случае. Hinge loss обеспечивал, что \(\hat y > 0.9\) при \(y = 1\) и \(\hat y < 0.2\) при \(y = 0\).

Однако они обнаружили большое пересечение распределений оценок (слева на картинке ниже) между случайными негативами (красный) и купленными позитивами (зелёный). После анализа выяснилось, что это связано с товарами, которые показывались, но не были куплены. Поэтому они обновили целевую метку, чтобы различать товары, которые были показаны, но не куплены (серый), и случайные негативы (красный). Они также использовали трёхчастный hinge loss, где \(\hat y < 0.55\), если товар был показан, но не куплен. Это улучшило разделение оценок между случайными негативами (красный) и купленными позитивами (зелёный).

Распределение оценок при двухчастном (слева) и трёхчастном (справа) hinge loss

Другой пример переформулирования — классификатор товаров Shopify. Чтобы упростить задачу классификации товаров по 5 000-классовой иерархической таксономии, они преобразовали n классификаторов «один против всех» в один бинарный классификатор. Они сделали это, развернув обучающую выборку так, чтобы для каждого товара получилась строка на каждую категорию, и добавив категорию к признакам. Если пара «товар-категория» валидна, метка равна 1, иначе 0. Они также учитывали иерархию, присваивая метку 1 родителям валидной категории.

Это позволило им обучить одну логистическую регрессию вместо \(n\) отдельных классификаторов, сократив вычислительные затраты и сохранив систему простой. Учёт связей «родитель-потомок» также позволил учиться на структуре таксономии.

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

Категоризация товаров через обход таксономии товаров

Последний пример — переформулирование рекомендаций из задачи о совместной встречаемости (например, матричная факторизация) в задачу о последовательностях (например, RNN, Transformers). Одна из самых ранних работ в этом направлении применила GRU для сессионных рекомендаций. Она была мотивирована необходимостью учиться на коротких сессионных данных из-за отсутствия длинных историй пользователей (таких, как у Amazon или Netflix).

С тех пор значительная часть исследований по recsys сместилась к последовательной парадигме: Self-Attentive Sequential Recommendations, Behavior Sequence Transformer, BERT4Rec и др. Эмпирически эти подходы оказывались эффективнее техник, основанных на совместной встречаемости, хотя последние остаются конкурентоспособным базовым решением.

Каскад: чтобы разбить задачу на меньшие

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

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

Классический пример каскада — дизайн рекомендательных систем, обычно разделённый на этапы retrieval и ranking. Retrieval — быстрый, но грубый шаг, сужающий миллионы товаров до сотен кандидатов. Ranking — более медленный, но точный шаг, оценивающий кандидатов после retrieval. Такая структура каскада позволяет каждому шагу оптимизироваться под разные цели: retrieval оптимизирует recall и скорость, а ranking — точность.

Candidate retrieval -> ranking -> эвристики и фильтрация -> подмешивание рекламы

Недавно открытая Twitter recsys следует этому паттерну (картинка выше). Их recsys — это каскад: (i) candidate sourcing (он же retrieval), (ii) heavy ranking, (iii) эвристики и фильтрация, (iv) подмешивание рекламы. В retrieval вносят вклад несколько компонентов, прежде чем тяжёлый ранкер (параллельный masknet) выполняет ранжирование. В конце поверх накладываются бизнес-правила.

Stack Exchange тоже использует паттерн каскада для выявления спама. Сначала выявляются пользователи, которые публикуют посты слишком часто, чтобы это было по силам человеку. Спамеру выдаётся HTTP 429 Error (Too Many Requests), и он блокируется или ограничивается по частоте.

Три уровня защиты от спама: частота постов -> эвристики -> машинное обучение

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

Последний рубеж защиты — это (machine learning?) система, которая выявляет посты, наиболее вероятно являющиеся спамом. Они shadow-тестировали её и выяснили, что она крайне точна, отлавливая почти весь явно очевидный спам. В итоге система получила право автоматически выставлять три флага, что существенно сократило время до удаления спам-постов.

Маховик данных: чтобы непрерывно улучшаться и строить ров

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

Плюсы: один из немногих источников долгосрочного конкурентного преимущества. Архитектуру модели и дизайн системы скопировать можно, но без данных они бессмысленны. Минусы: может возникнуть петля обратной связи, в которой увековечивается смещение (например, popularity bias в recsys), хотя аугментация данных может это смягчить.

Яркий пример маховика данных — рекомендательные системы Amazon и Netflix. Когда пользователи ищут следующий сериал на Netflix, их поисковые запросы, клики, превью, время просмотра и оценки логируются. Эти данные затем используются для построения recsys, которые учатся на их предпочтениях и выдают персонализированные рекомендации. В результате пользователи проводят на Netflix больше времени, генерируя больше данных, которые ещё сильнее улучшают рекомендации.

Другой пример — Tesla Autopilot. Tesla собирает изображения и видео вождения со своих автомобилей в качестве источника данных. По этим данным они выявляют ошибки, ищут похожие случаи (например, ближайших соседей) и размечают их. Новые метки используются для переобучения моделей, которые затем разворачиваются в автомобилях. Вооружившись новыми моделями, машины собирают ещё больше данных о вождении, замыкая маховик данных.

Андрей Карпатый рассказывает о Tesla data engine

Последний пример — ChatGPT. Он был построен как способ собирать обратную связь непосредственно от пользователей:

Сэм Альтман упоминал, что одной из главных причин, по которой OpenAI создала ChatGPT, было желание получать обратную связь от живых пользователей обратно в свои модели. Иными словами, они начинали как API-only, но поняли, что лучший способ улучшить качество — интегрироваться вперёд по большему количеству слоёв value chain, чтобы получить прямой доступ к данным клиентов. — Дэн Шиппер

Построив простой чат-интерфейс и позволив пользователям давать обратную связь (лайки/дизлайки), OpenAI теперь может напрямую собирать фидбэк для улучшения своих моделей. GPT-4 также интегрирован с Bing Search, который отвечает резюме топ-результатов. Ответ включает ссылки на источники, которые пользователи могут просматривать и кликать. Здесь неявная обратная связь от пользователей (то есть клики по источникам) также помогает улучшать document retrieval.

Слой бизнес-правил: чтобы дополнять или переопределять выводы

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

Плюсы: гарантирует, что выводы ML соответствуют бизнес-требованиям и ограничениям. Это помогает улучшить надёжность, безопасность и удобство системы. Минусы: при плохом управлении может вылиться в византийскую паутину взаимодействующих правил, которые неожиданным образом перекрывают друг друга. Также может поощрять анти-паттерн добавления правил для решения краткосрочных проблем без устранения первопричины.

Этот паттерн распространён в recsys. Например, когда Instagram рассказывал о своей рекомендательной инфраструктуре, они также показали пример рекомендателя, где последний шаг выполняет диверсификацию по принципу round-robin.

user .let(seed_id=user_id) .liked(max_num_to_retrieve=30) .account_nn(embedding_config=default) .posted_media(max_media_per_account=10) .filter(non_recommendable_model_threshold=0.2) .rank(ranking_model=default) .diversify_by(seed_id, method=round_robin)

Пример рекомендателя для Instagram. Обратите внимание на шаг диверсификации в последней строке.

Аналогично, Twitter использует подобранные вручную веса (ниже), чтобы скомбинировать выходы тяжёлого ранкера через взвешенную сумму предсказанных вероятностей вовлечённости. Кроме того, на этапе эвристик и фильтрации (после retrieval и ranking) они применяют эвристики: диверсификацию авторов, негативный пользовательский фидбэк и буст для верифицированных в Twitter.

scored_tweets_model_weight_fav: 0.5 scored_tweets_model_weight_retweet: 1.0 scored_tweets_model_weight_reply: 13.5 scored_tweets_model_weight_good_profile_click: 12.0 scored_tweets_model_weight_video_playback50: 0.005 scored_tweets_model_weight_reply_engaged_by_author: 75.0 scored_tweets_model_weight_good_click: 11.0 scored_tweets_model_weight_good_click_v2: 10.0 scored_tweets_model_weight_negative_feedback_v2: -74.0 scored_tweets_model_weight_report: -369.0

Подобранные вручную веса для различных вероятностей вовлечённости в рекомендательной системе Twitter.

Другие примеры эвристик и бизнес-правил, влияющих на финальный вывод, — калиброванные рекомендации Netflix, чтобы совпадать с историческим жанровым распределением пользователя, и использование подобранных вручную весов Pinterest (в шаге Memboost) после retrieval и ranking.

Также, если вы пользовались ChatGPT, вы могли испытать на себе его слой правил. Эти ограничения гарантируют, что его ответы соответствуют этическим принципам и безопасны для пользователей. Попробуйте спросить ChatGPT об опасной теме или его мнении о политической фигуре. В первом случае он откажется предоставлять информацию («К сожалению, я не могу предоставить информацию или помощь в создании опасного оружия…»), во втором — вернёт нейтральный ответ («Как языковая модель ИИ, у меня нет личных мнений или взглядов»).

ChatGPT отказывается предоставлять информацию по опасным темам или политическим взглядам.

Оценка перед деплоем: ради безопасности и надёжности

Этот паттерн отражает лучшую практику оценивать модель (например, по evaluation-метрикам) и систему (например, по error rate, latency) перед интеграцией в продакшен. По мне, не сильно отличается от тестирования сборок перед деплоем — иными словами, пожалуйста, делайте это.

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

Чтобы внедрить этот паттерн, достаточно иметь валидационный hold-out при (пере)обучении моделей. Учитывая сильный временной аспект в большинстве продакшен-систем, валидационный набор обычно стоит делить по времени; случайный сплит или кросс-валидация могут привести к завышенно оптимистичным evaluation-метрикам, особенно если будущие данные просочатся в обучающую выборку.

Возьмём рекомендательные системы как пример. Мы можем отложить последний период данных (например, день, час), переобучить модели на новых данных и оценить на валидационном наборе привычными метриками вроде hit@k, NDCG и т.п. (А затем — конкретно в recsys — можем дообучить модель и на валидационном наборе, потому что хотим переобучиться.) Также можно сравнить с наивным baseline (например, сортировкой по популярности), чтобы понять прирост. Если переобученная модель проваливает любую из evaluation-метрик, пайплайн должен сломаться и модель не должна выкатываться — лучше иметь устаревшую модель, чем поломанную.

• • •

Ого, спасибо, что дочитали до конца! Мы обсудили девять паттернов проектирования в ML-системах. Многие из них — переформулирование, каскад, бизнес-правила, оценка перед деплоем — вы не часто встретите явно упомянутыми в статьях или техблогах. И если вам понравилось, возможно, вам будут интересны и паттерны proxy и mediator, разобранные ранее.

Эти паттерны хорошо служили мне при проектировании, построении и эксплуатации ML-систем. К тому же, учитывая растущую пригодность LLM для продакшена, мне интересно: применимы ли эти паттерны к LLM-системам? Кое-что приходит на ум:

Слой бизнес-правил поверх выхода LLM ради безопасности и надёжности. Маховики данных для непрерывного сбора пользовательской обратной связи для дообучения моделей. Применение паттерна каскада при построении автономных агентов.

Какие ещё паттерны вы встречали в системах машинного обучения или LLM? Делитесь!

Ссылки

How does spam protection work on Stack Exchange? The technology behind fighting harassment on LinkedIn Project RADAR: Intelligent Early Fraud Detection System with Humans in the Loop Using a HITL to Overcome the Cold Start Problem in Menu Item Tagging Building Airbnb Categories with ML and Human-in-the-Loop ChatGPT Outperforms Crowd-Workers for Text-Annotation Tasks ChatGPT-4 Outperforms Experts and Crowd Workers in Annotating Political Twitter Messages with Zero-Shot Learning Improving the accuracy of machine learning using data augmentation & sampling Scalable Data Classification for Security and Privacy Embedding-based Retrieval in Facebook Search Curriculum Learning: A Survey Semantic Product Search Categorizing Products at Scale Session-based Recommendations with Recurrent Neural Networks Self-Attentive Sequential Recommendation Behavior Sequence Transformer for E-commerce Recommendation in Alibaba BERT4Rec: Sequential Recommendation with Bidirectional Encoder Representations from Transformer Twitter's Recommendation Algorithm MaskNet: Introducing Feature-Wise Multiplication to CTR Ranking Models by Instance-Guided Mask Powered by AI: Instagram's Explore recommender system Calibrated Recommendations Related Pins at Pinterest: The Evolution of a Real-World Recommender System

Промпт для OG-картинки в MidJourney: «a woman drawing a system design diagram, in the style of contrasting tones, artifacts of online culture, innovative page design, complexity theory, bold black and whites, bold color scheme, rectangular fields –ar 2:1»

Если вам это пригодилось, пожалуйста, цитируйте эту заметку так:

Yan, Ziyou. (Apr 2023). More Design Patterns For Machine Learning Systems. eugeneyan.com. https://eugeneyan.com/writing/more-patterns/.

или

@article{yan2023patterns2, title = {More Design Patterns For Machine Learning Systems}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Apr}, url = {https://eugeneyan.com/writing/more-patterns/} }

К 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.