My Notes From Spark+AI Summit 2020 (Application-Specific Talks)
Статья представляет заметки Eugene Yan с конференции Spark+AI Summit 2020, посвящённые прикладным докладам. Рассматриваются фреймворк Zipline от Airbnb для декларативного извлечения point-in-time признаков и Sputnik — фреймворк дата-инженерии, устраняющий шаблонный код Spark-задач. Описывается Feast от Gojek — хранилище признаков, модуляризирующее ML-пайплайн от обучения до продакшена. Netflix делится подходом к качеству данных через статистический тест Колмогорова–Смирнова и «дорожки» (swim lanes) для ETL-пайплайнов, что привело к 80% проактивному обнаружению ошибок и 15% экономии на хранении. LinkedIn применяет методы обучения без учителя — изолирующие леса и кластеризацию графов — для борьбы со злоупотреблениями, а Zynga использует обучение с подкреплением для персонализации в мобильных играх.
My Notes From Spark+AI Summit 2020 (Application-Specific Talks)
Мои заметки с Spark+AI Summit 2020 (прикладные доклады)
[ machinelearning deeplearning production survey ] · 15 мин. чтения
To follow up with the previous write-up on application-agnostic talks, here’s my notes on some application-specific sessions.
В продолжение предыдущего обзора докладов общего характера — вот мои заметки по некоторым прикладным сессиям.
The previous write-up largely focused on deep learning best practices and reflects the challenges people are facing now. This write-up focuses on data engineering (frameworks, data quality) and reflects the maturity of Spark in production, with organizations sharing how they apply it effectively. We also have two interesting talks on unsupervised learning and reinforcement learning.
Предыдущий обзор был в основном посвящён лучшим практикам глубокого обучения и отражал текущие вызовы, с которыми сталкиваются специалисты. Этот обзор фокусируется на дата-инженерии (фреймворки, качество данных) и отражает зрелость Spark в продакшене — организации делятся опытом его эффективного применения. Также представлены два интересных доклада об обучении без учителя и обучении с подкреплением.
Table of Contents
Содержание
Zipline от Airbnb — фреймворк для инженерии признаков Sputnik от Airbnb — фреймворк дата-инженерии Feast от Gojek — хранилище признаков для сквозного машинного обучения Подход Netflix к качеству данных через статистику и swim lanes Подход LinkedIn к борьбе со злоупотреблениями через обучение без учителя Подход Zynga к персонализации через обучение с подкреплением
Zipline: Declarative Feature Engineering (24 June)
Zipline: декларативная инженерия признаков (24 июня)
Nikhil Simha, Senior Engineer at Airbnb’s ML Infra, shared about Zipline (similar talk at Strata 2018) and how Airbnb uses it to tackle the problem of collecting point-in-time (PIT) features.
Nikhil Simha, старший инженер ML-инфраструктуры Airbnb, рассказал о Zipline (аналогичный доклад на Strata 2018) и о том, как Airbnb использует его для решения проблемы сбора point-in-time (PIT) признаков.
What are PIT features? At Point 1 (P1), the latest PIT features are F1=7, F2=3, F3=8. However, at P2, the latest PIT features for F1 and F2 have changed to 4 and 2 respectively. Calculating these PIT features (from historical data) is very difficult—it usually involves some aggregation on last and temporal joins. (Also addressed in Gojek’s Feast talk below.)
Что такое PIT-признаки? В момент Point 1 (P1) последние PIT-признаки — F1=7, F2=3, F3=8. Однако в момент P2 последние PIT-признаки для F1 и F2 изменились на 4 и 2 соответственно. Вычисление этих PIT-признаков (по историческим данным) — очень сложная задача — обычно она включает агрегацию по last и временные джойны. (Эта тема также затрагивается в докладе Gojek о Feast ниже.)
Getting those last values are tricky, especially if the data is at the second/minute level
Получить последние значения непросто, особенно если данные имеют детализацию до секунды/минуты
We can collect PIT features via two approaches:
Собирать PIT-признаки можно двумя способами:
Логирование и ожидание: написать код для сбора PIT-признаков через логирование и ждать 3–6 месяцев для накопления достаточного объёма данных. Ручное обратное заполнение: воспроизвести логику инженерии признаков на исторических данных и выполнить обратное заполнение (backfill). Это создаёт проблемы консистентности и может занять много времени.
To improve on the manual backfill approach, it’s useful to distinguish between two classes of aggregations. The first class of aggregations are Abelian groups, such as sum, count, etc. They have the following properties:
Чтобы улучшить подход с ручным обратным заполнением, полезно различать два класса агрегаций. Первый класс агрегаций — абелевы группы, такие как сумма, количество и т.д. Они обладают следующими свойствами:
a + b = b + a(a + b) + c = a + (b + c)(a + b) - a = bКоммутативность: a + b = b + a Ассоциативность: (a + b) + c = a + (b + c) Обратимость: (a + b) - a = b
With commutativity and associativity, we can parallelize via the map-reduce paradigm. With reversibility, we don’t have to compute on the full window with each update: Just subtract the outdated data and add the new data (e.g., moving average).
Благодаря коммутативности и ассоциативности мы можем параллелизировать вычисления через парадигму map-reduce. Благодаря обратимости нам не нужно пересчитывать всё окно при каждом обновлении: достаточно вычесть устаревшие данные и добавить новые (например, скользящее среднее).
However, the second class of aggregations are non-reversible. These are operations like min, max, count unique, etc. With max, we cannot update windows easily—all you would have stored is the max value. Nonetheless, we can get past this with a binary tree.
Однако второй класс агрегаций — необратимые. Это такие операции, как минимум, максимум, количество уникальных и т.д. В случае с максимумом мы не можем легко обновлять окна — всё, что у нас хранится, это значение максимума. Тем не менее это можно обойти с помощью бинарного дерева.
We can do quick non-reversible aggregations with a binary tree.
С помощью бинарного дерева можно быстро выполнять необратимые агрегации.
In the example above, we perform the max operation on every two periods to get the first level node, and repeat recursively. This reduces the problem space from O(N) to O(LogN) and the compute time from O(N^2) to O(NLogN). We trade off faster compute (Log(365) = 8.5) for more storage required (2x).
В примере выше мы выполняем операцию max на каждых двух периодах для получения узлов первого уровня и повторяем рекурсивно. Это сокращает пространство задачи с O(N) до O(LogN), а время вычислений — с O(N^2) до O(NLogN). Мы жертвуем дополнительным хранилищем (2x) ради более быстрых вычислений (Log(365) = 8.5).
Further reading:
Дополнительное чтение:
Zipline: платформа управления данными для машинного обучения Airbnb — Nikhil Simha и Andrew Hoh (слайды) Zipline: платформа управления данными для машинного обучения Airbnb
Sputnik: A Data Engineering Framework (25 June)
Sputnik: фреймворк дата-инженерии (25 июня)
Egor Pakhomov, Senior Software Engineer at Airbnb Infra, shares about how Sputnik bakes in Spark and engineering best practices and improve developer experience.
Egor Pakhomov, старший инженер-разработчик в Airbnb Infra, рассказывает о том, как Sputnik встраивает лучшие практики Spark и инженерии, улучшая опыт разработки.
There’s two kinds of logic in Spark jobs (and code):
В Spark-задачах (и коде) есть два типа логики:
SparkSession, scheduling, creating tables, I/O, running in dev, etc. (mostly boilerplate).Логика задачи: бизнес-логика, указание входных и выходных таблиц, партиционирование данных, способ валидации результата и т.д. Логика запуска: парсинг аргументов, создание SparkSession, планирование, создание таблиц, ввод-вывод, запуск в dev и т.д. (в основном шаблонный код).
Most of the code in a Spark job is boilerplate; little of it is the actual transformation.
Большая часть кода в Spark-задаче — шаблонный код; лишь малая часть — собственно преобразование данных.
Sputnik implements the run logic so data engineers can focus on the job logic. Sputnik jobs are simple: input -> transformation -> output; no boilerplate.
Sputnik реализует логику запуска, чтобы дата-инженеры могли сосредоточиться на логике задачи. Задачи в Sputnik просты: вход → преобразование → выход; никакого шаблонного кода.
Sputnik also bakes in best practices. Take for example, the HiveTableWriter. It does the following with minimal effort from data engineers:
Sputnik также встраивает лучшие практики. Возьмём, к примеру, HiveTableWriter. Он выполняет следующее с минимальными усилиями со стороны дата-инженеров:
dev, staging, prod)DataFrame schema to follow output schemaСоздаёт таблицу, если она не существует; обновляет метаданные Перепартиционирует данные для уменьшения количества файлов на диске Выполняет проверки данных перед записью (например, проверка на нулевое количество) Обновляет имена выходных таблиц (для dev, staging, prod) Нормализует схему DataFrame в соответствии с выходной схемой
The last feature is interesting. By default, Spark’s HiveWriter matches columns by position—instead of name—and casts the data into the Hive schema. Thus, incorrect values are written into columns without error. (SPARK-14543).
Последняя возможность особенно интересна. По умолчанию HiveWriter в Spark сопоставляет столбцы по позиции — а не по имени — и приводит данные к схеме Hive. Из-за этого некорректные значения записываются в столбцы без ошибок. (SPARK-14543).
Sputnik also makes backfill jobs more efficient. Usually, backfilling a job involves running it for each session (e.g., day) in the historical period. This reduces economies of scale (e.g., starting a new SparkSession each time, batching daily instead of monthly). Sputnik also batches historical jobs across the entire history, or multiple periods per run to fit the resource constraints.
Sputnik также делает обратное заполнение более эффективным. Обычно backfill задачи включает её запуск для каждой сессии (например, дня) в историческом периоде. Это снижает эффект масштаба (например, создание нового SparkSession каждый раз, батчинг по дням вместо месяцев). Sputnik также группирует исторические задачи по всему периоду или по нескольким периодам за один запуск, чтобы уложиться в ограничения ресурсов.
Sputnik makes backfilling easy and efficient.
Sputnik делает обратное заполнение простым и эффективным.
Sputnik also has utils for testing on a singleton SparkSession, with DataFrame comparison, loading data from csv/json, and cleaning the Hive store between runs. It also checks data on output (e.g., zero-count check). And if we re-run a job (e.g., original output erroneous), it also triggers the re-run of downstream jobs.
Sputnik также имеет утилиты для тестирования на синглтон-экземпляре SparkSession, с возможностью сравнения DataFrame, загрузки данных из csv/json и очистки хранилища Hive между запусками. Он также проверяет данные на выходе (например, проверка на нулевое количество). А если мы перезапускаем задачу (например, из-за ошибочного исходного вывода), он также инициирует перезапуск нижестоящих задач.
Further reading:
Дополнительное чтение:
Sputnik: фреймворк Apache Spark от Airbnb для дата-инженерии Sputnik GitHub
Feast: Scaling End-to-End Machine Learning (25 June)
Feast: масштабирование сквозного машинного обучения (25 июня)
Willem Pienaar, Data Science Platform Lead at Gojek, shares about how they developed Feast (Feature Store) to modularize end-to-end machine learning.
Willem Pienaar, руководитель платформы Data Science в Gojek, рассказывает о том, как они разработали Feast (Feature Store) для модуляризации сквозного машинного обучения.
When Gojek started, they had a monolithic, tightly-coupled, system that was hard to iterate on. Training code had to be rewritten for serving, leading to code duplication, high overhead, and inconsistency between training and serving features. There was minimal feature reusability and data quality monitoring.
Когда Gojek только начинал, у них была монолитная, тесно связанная система, которую было сложно итерировать. Код обучения приходилось переписывать для обслуживания, что приводило к дублированию кода, высоким накладным расходам и несогласованности между признаками для обучения и обслуживания. Переиспользование признаков и мониторинг качества данных были минимальными.
The original monolith made iteration slow and brittle.
Исходный монолит делал итерации медленными и хрупкими.
Thus, they built Feast to decouple the ML lifecycle. By providing a consistent interface, Feast allows separate teams and data developers to work on creating features, training models, and serving models independently.
Поэтому они создали Feast для декомпозиции жизненного цикла ML. Предоставляя единый интерфейс, Feast позволяет отдельным командам и разработчикам данных независимо работать над созданием признаков, обучением моделей и обслуживанием моделей.
With Feast, the end-to-end machine learning pipeline is modularized.
С Feast сквозной пайплайн машинного обучения становится модульным.
For the data pipeline, we see various data sources (streaming, SQL, data lake) go through Apache Beam as an ingestion layer—thus, they adopt Google’s Dataflow model.
В части data pipeline различные источники данных (потоковые, SQL, озеро данных) проходят через Apache Beam в качестве слоя приёма данных — таким образом, они используют модель Dataflow от Google.
In most extract-transform-load (ETL) jobs, data is viewed as a bounded batch (e.g., daily batches). The Dataflow model proposes viewing it as an unbounded stream instead (e.g., session). This provides flexibility where streams can easily be aggregated into batches; in contrast, going from batches to streams is very difficult.
В большинстве задач extract-transform-load (ETL) данные рассматриваются как ограниченный батч (например, ежедневные батчи). Модель Dataflow предлагает рассматривать их как неограниченный поток (например, сессия). Это обеспечивает гибкость: потоки легко агрегировать в батчи, тогда как переход от батчей к потокам крайне сложен.
Here’s the abstract from the paper (emphasis mine):
Вот аннотация из статьи (выделение моё):
Unbounded, unordered, global-scale datasets are increasingly common in day-to-day business (e.g. Web logs, mobile usage statistics, and sensor networks). At the same time, consumers of these datasets have evolved sophisticated requirements, such as event-time ordering and windowing by features of the data themselves, in addition to an insatiable hunger for faster answers. Meanwhile, practicality dictates that one can never fully optimize along all dimensions of correctness, latency, and cost for these types of input. As a result, data processing practitioners are left with the quandary of how to reconcile the tensions between these seemingly competing propositions, often resulting in disparate implementations and systems.
Неограниченные, неупорядоченные наборы данных глобального масштаба всё чаще встречаются в повседневном бизнесе (например, веб-логи, статистика использования мобильных устройств, сенсорные сети). Одновременно потребители этих данных выработали сложные требования — такие как упорядочение по времени событий и окна по свойствам самих данных — в дополнение к ненасытному желанию получать ответы быстрее. При этом на практике невозможно полностью оптимизировать одновременно корректность, задержку и стоимость для таких типов входных данных. В результате практики обработки данных стоят перед дилеммой: как примирить противоречия между этими, казалось бы, конкурирующими требованиями, что часто ведёт к разрозненным реализациям и системам.
We propose that a fundamental shift of approach is necessary to deal with these evolved requirements in modern data processing. We as a field must stop trying to groom unbounded datasets into finite pools of information that eventually become complete, and instead live and breathe under the assumption that we will never know if or when we have seen all of our data, only that new data will arrive, old data may be retracted, and the only way to make this problem tractable is via principled abstractions that allow the practitioner the choice of appropriate tradeoffs along the axes of interest: correctness, latency, and cost.
Мы предлагаем фундаментальный сдвиг подхода для работы с этими эволюционировавшими требованиями в современной обработке данных. Нам как области необходимо перестать пытаться причёсывать неограниченные наборы данных в конечные пулы информации, которые когда-нибудь станут полными, и вместо этого жить с осознанием того, что мы никогда не узнаем, видели ли мы все наши данные и когда это произошло — мы лишь знаем, что придут новые данные, старые могут быть отозваны, и единственный способ сделать эту задачу решаемой — это принципиальные абстракции, дающие практику выбор подходящих компромиссов по осям: корректность, задержка и стоимость.
In this paper, we present one such approach, the Dataflow Model, along with a detailed examination of the semantics it enables, an overview of the core principles that guided its design, and a validation of the model itself via the real-world experiences that led to its development.
В этой статье мы представляем один такой подход — модель Dataflow — вместе с детальным разбором обеспечиваемой ею семантики, обзором ключевых принципов, определивших её проектирование, и валидацией самой модели через реальный опыт, который привёл к её разработке.
For storage, Gojek has a historical feature store (likely based on Hive or BigQuery) and an online feature store (Redis, Cassandra). MLflow is used to log model training parameters and metrics, and also to track models for serving. TensorFlow Extended and TensorFlow Data Validation is used for statistical data validation with visualisation using Facets.
Для хранения Gojek использует историческое хранилище признаков (предположительно на базе Hive или BigQuery) и онлайн-хранилище признаков (Redis, Cassandra). MLflow используется для логирования параметров и метрик обучения моделей, а также для отслеживания моделей при обслуживании. TensorFlow Extended и TensorFlow Data Validation используются для статистической валидации данных с визуализацией через Facets.
Further reading:
Дополнительное чтение:
Feast GitHubFeast: связующее звено между ML-моделями и данными Feast GitHub Модель Dataflow: практический подход к балансу корректности, задержки и стоимости при масштабной обработке неограниченных, неупорядоченных данных Facets: инструмент визуализации обучающих данных ML с открытым исходным кодом
Data Quality at Netflix for Personalization (24 June)
Качество данных в Netflix для персонализации (24 июня)
Preetam Joshi and Vivek Kaushal, Senior Software Engineers at Netflix, share two approaches they adopt to tackle poor data quality at source and introduced via ETL.
Preetam Joshi и Vivek Kaushal, старшие инженеры-разработчики Netflix, представляют два подхода к борьбе с низким качеством данных — на источнике и на этапе ETL.
There are three forms of “ETL smells”:
Существует три формы «запахов ETL»:
Флуктуации: мы ожидаем 1–2 миллиона строк данных ежечасно, но вдруг происходит скачок до 0–5 миллионов, что указывает на возможные узкие места ETL. Резкие падения: мы ожидаем 5 миллионов строк данных ежедневно, но вдруг объём падает до 1,5 миллиона. Недоиспользование: мы собираем 5 миллионов строк данных ежедневно, но в последнее время используется только 1 миллион, что указывает на расточительство и потенциальную экономию.
Tracking the last point led to savings on 15% of storage costs.
Отслеживание последнего пункта привело к экономии 15% затрат на хранение.
Bad data gets introduced in two main ways: At source and via ETL.
Некачественные данные появляются двумя основными путями: на источнике и через ETL.
To detect errors at the source, we compare the distribution of values between the previous and current period. However, at any day, there could be hundreds of distribution mismatches—to prune it, we can apply the Kolmogorov-Smirnov statistical test.
Для обнаружения ошибок на источнике мы сравниваем распределение значений между предыдущим и текущим периодом. Однако в любой день могут быть сотни расхождений в распределениях — для их отсеивания можно применить статистический тест Колмогорова–Смирнова.
In a nutshell, the KS test computes the maximum discrepancy between two cumulative distributions (the vertical red line below) and ranges from 0 - 1. Larger values indicate greater discrepancy.
Если кратко, тест КС вычисляет максимальное расхождение между двумя кумулятивными распределениями (вертикальная красная линия ниже), значение лежит в диапазоне от 0 до 1. Большие значения указывают на большее расхождение.
We can use the Kolmogorov-Smirnov test to check for discrepancies between two continuous distributions.
Тест Колмогорова–Смирнова позволяет проверить расхождения между двумя непрерывными распределениями.
Question: The KS test would work on continuous values—what about discrete or categorical values?
Вопрос: Тест КС работает на непрерывных значениях — а как быть с дискретными или категориальными?
Answer: For discrete values, we perform simple checks (likely comparing key category proportions).
Ответ: Для дискретных значений мы выполняем простые проверки (вероятно, сравнивая пропорции ключевых категорий).
To detect errors in ETL pipelines, we see the approach of “swim lanes”. Let’s say we want to add or update an attribute (i.e., column) in an existing pipeline. The code would be developed and checked into a dev branch. Then, both dev and master branches would run in separate swim lanes on identical sets of sampled data. The output is compared to ensure the rest of the columns are unchanged.
Для обнаружения ошибок в ETL-пайплайнах используется подход «swim lanes» (дорожки). Допустим, мы хотим добавить или обновить атрибут (т.е. столбец) в существующем пайплайне. Код разрабатывается и коммитится в ветку dev. Затем обе ветки — dev и master — запускаются в отдельных дорожках на идентичных выборках данных. Выходные данные сравниваются, чтобы убедиться, что остальные столбцы не изменились.
Having these data quality processes led to:
Внедрение этих процессов контроля качества данных привело к:
80% проактивного обнаружения проблем 15% экономии затрат благодаря лучшему выявлению неиспользуемых данных 99% валидации при критических миграциях данных с помощью swim lanes Повышению продуктивности разработчиков
Further reading:
Дополнительное чтение:
MIT: Статистика для исследовательских проектов (непараметрическая статистика и выбор модели) Обнаружение аномалий для качества данных и сдвигов метрик в Netflix Подход к качеству данных для систем персонализации Netflix
SuperConductive also had a great talk on data quality (Automated Testing For Protecting Data Pipelines From Undocumented Assumptions, 26 June).
SuperConductive также представила отличный доклад о качестве данных (Автоматизированное тестирование для защиты data-пайплайнов от недокументированных предположений, 26 июня).
They shared about the Great Expectations (an open-source project) that lets you declare data expectations (i.e, tests) simply. It streamlines the deployment and running of tests, and storage and exposure of results.
Они рассказали о Great Expectations (проект с открытым исходным кодом), который позволяет просто декларировать ожидания к данным (т.е. тесты). Он упрощает развёртывание и запуск тестов, а также хранение и предоставление результатов.
Preventing Abuse via Unsupervised Learning (24 June)
Борьба со злоупотреблениями с помощью обучения без учителя (24 июня)
James Verbus and Grace Tang, Machine Learning Engineers at Linkedin, share about the challenges in identifying abuse and fraud, and how they apply unsupervised machine learning to tackle it.
James Verbus и Grace Tang, инженеры машинного обучения в LinkedIn, рассказывают о трудностях выявления злоупотреблений и мошенничества и о том, как они применяют обучение без учителя для решения этих задач.
Catching abuse and fraud (and in general, anomalies) has unique challenges:
Обнаружение злоупотреблений и мошенничества (и аномалий в целом) имеет уникальные сложности:
Мало размеченных данных для обучения и оценки моделей Ограниченный сигнал от отдельных злоумышленных аккаунтов Состязательный характер — злоумышленники быстро адаптируются
They share two unsupervised learning techniques that worked well: isolation forests and graph clustering.
Они делятся двумя методами обучения без учителя, которые хорошо себя зарекомендовали: изолирующие леса и кластеризация графов.
Isolation forests are an ensemble of randomly grown binary trees. At each node, a random feature and split is chosen. The tree grows until all data is isolated in the leaf nodes. Why does this work? The intuition is that outliers will be easier to separate (i.e., fewer splits) and thus appear shallower in the tree.
Изолирующие леса — это ансамбль случайно построенных бинарных деревьев. На каждом узле случайно выбирается признак и точка разделения. Дерево растёт, пока все данные не окажутся изолированными в листовых узлах. Почему это работает? Интуиция в том, что выбросы легче отделить (т.е. требуется меньше разделений), и поэтому они оказываются на меньшей глубине дерева.
Here’s two examples of accounts picked up by isolation forests. The x-axis represents the number of user actions, while the y-axis represents the outlier score.
Вот два примера аккаунтов, обнаруженных изолирующими лесами. По оси X — количество действий пользователя, по оси Y — оценка аномальности.
In this example, the group of highlighted accounts (orange) are real members who use automation tools. The number of actions they take, and the outlier score, is fairly high, but they’re normal users.
В этом примере группа выделенных аккаунтов (оранжевые) — это реальные пользователи, использующие инструменты автоматизации. Количество их действий и оценка аномальности довольно высоки, но это обычные пользователи.
Normal users using automation tools have high outliers scores.
Обычные пользователи, использующие инструменты автоматизации, имеют высокие оценки аномальности.
In this example, the group of highlighted accounts (red) are fake accounts created via automation. Visually, they’re well separated from the rest and appear as a thick swarm (of locusts) with outlier scores far above regular activity.
В этом примере группа выделенных аккаунтов (красные) — это фейковые аккаунты, созданные с помощью автоматизации. Визуально они хорошо отделены от остальных и выглядят как плотный рой (саранчи) с оценками аномальности, значительно превышающими обычную активность.
An attack shows up very clearly, despite the range of user actions to blend in.
Атака отчётливо видна, несмотря на разброс действий пользователей для маскировки.
Graph clustering is applied to identify networks of similar accounts based on signals (e.g., liking similar content). We can do this naively by computing similarity between all pairs of users. However, this is O(N^2) expensive. Thus, we can adopt the following optimisations:
Кластеризация графов применяется для выявления сетей похожих аккаунтов на основе сигналов (например, лайки одного и того же контента). Наивный подход — вычислить сходство между всеми парами пользователей. Однако это стоит O(N^2). Поэтому можно применить следующие оптимизации:
Исключить клиентов с низкой активностью (так как они низкорисковые) Исключить вирусный контент (слишком много шума и мало сигнала) Исключить пары без пересечения во взаимодействии с контентом
To find networks, we can compute Jaccard Similarity between two accounts. Or more specifically, LinkedIn uses weighted Jaccard Similarity (aka Ruzicka similarity) as they represent user-content relationships as a value between 0 and 1. Next, Jarvis-Patrick clustering is applied to ensure that clusters are more homogeneous.
Для поиска сетей можно вычислить коэффициент Жаккара между двумя аккаунтами. Точнее, LinkedIn использует взвешенный коэффициент Жаккара (он же сходство Ружички), поскольку связи пользователь-контент представлены значениями от 0 до 1. Затем применяется кластеризация Джарвиса–Патрика для повышения однородности кластеров.
Here are some examples of fake accounts. In the top left, all accounts were engaged on the same piece of content. In the lower-middle, three groups of fake accounts were created to test the system.
Вот примеры фейковых аккаунтов. В левом верхнем углу все аккаунты взаимодействовали с одним и тем же контентом. В нижней центральной части три группы фейковых аккаунтов были созданы для тестирования системы.
Networks of abusers engaging on the same content show up clearly, even when they add noise to blend in.
Сети злоумышленников, взаимодействующих с одним и тем же контентом, отчётливо видны, даже когда они добавляют шум для маскировки.
Nonetheless, there’re false positives too. Here, we see accounts that engage on similar content where members know each other from a book club, company, or interest group.
Тем не менее встречаются и ложные срабатывания. Здесь мы видим аккаунты, взаимодействующие с похожим контентом, где пользователи знают друг друга по книжному клубу, компании или группе по интересам.
Nonetheless, real users and communities get picked up as well.
Тем не менее реальные пользователи и сообщества тоже попадают в выборку.
Thus, while unsupervised techniques are effective in identifying outliers, they have to be complemented with supervised techniques and heuristics to exclude false positives (i.e., real accounts that were incorrectly identified as fake).
Таким образом, хотя методы обучения без учителя эффективны для выявления аномалий, их необходимо дополнять методами обучения с учителем и эвристиками для исключения ложных срабатываний (т.е. реальных аккаунтов, ошибочно идентифицированных как фейковые).
Further reading:
Дополнительное чтение:
Isolation Forest от LinkedIn на GitHub Обнаружение и предотвращение злоупотреблений в LinkedIn с помощью изолирующих лесов
Production Reinforcement Learning at Zynga (25 June)
Продакшен-обучение с подкреплением в Zynga (25 июня)
Patrick Halina (ML Engineering Lead) and Curren Pangler (Principal Software Engineer) share about Zynga’s journey into reinforcement learning for personalisation.
Patrick Halina (руководитель ML-инженерии) и Curren Pangler (ведущий инженер-разработчик) рассказывают о пути Zynga к обучению с подкреплением для персонализации.
First, they started with rule-based segments. Program managers defined these segments and assigned personalised actions to each segment. However, this involved a lot of trial and error, had to be updated when player patterns change, and had limited personalization.
Сначала они использовали сегменты на основе правил. Менеджеры программ определяли эти сегменты и назначали персонализированные действия каждому сегменту. Однако это требовало множества проб и ошибок, нуждалось в обновлении при изменении паттернов поведения игроков и ограничивало персонализацию.
Then, they built machine learning models to predict long term reward for each action. However, this required a lot of labelled data and many individual models.
Затем они построили модели машинного обучения для предсказания долгосрочной награды за каждое действие. Однако для этого требовалось много размеченных данных и множество отдельных моделей.
Currently, they’ve adopted reinforcement learning that can personalise actions for each user and continuously explore and improve over time. The daily message from Words With Friends has the time determined by a reinforcement learning agent. It led to a significant increase in CTR vs. a hand-tuned system.
В настоящее время они используют обучение с подкреплением, которое может персонализировать действия для каждого пользователя и непрерывно исследовать и улучшаться со временем. Время отправки ежедневного сообщения в Words With Friends определяется агентом обучения с подкреплением. Это привело к значительному росту CTR по сравнению с вручную настроенной системой.
Zynga’s tech stack uses TF-Agents at its core; it comes with many RL models, from the baseline (DQN, DDQN) to the cutting edge (PPO, SAC). There’s a wrapper (RL-Bakery) around it. RL-Bakery helps to build experience replays, orchestrate training pipelines, and deploy models.
Технический стек Zynga использует TF-Agents в качестве ядра; он включает множество RL-моделей — от базовых (DQN, DDQN) до передовых (PPO, SAC). Вокруг него создана обёртка (RL-Bakery). RL-Bakery помогает создавать буферы воспроизведения опыта, оркестрировать пайплайны обучения и разворачивать модели.
Zynga also shared insights from their years of designing RL applications:
Zynga также поделилась выводами из многолетнего опыта проектирования RL-приложений:
Выбирайте правильную задачу: можно ли задачу смоделировать как последовательность (действий)? Является ли награда обучаемой (т.е. не разреженной)? Если нет — вероятно, не стоит использовать RL. Выбирайте правильные состояния: RL-агенты чувствительны к слишком большому числу входов; начинайте с простого пространства состояний. Выбирайте правильные действия: начинайте с небольшого набора дискретных действий и базовой модели (например, DDQN). Непрерывные пространства действий требуют методов Policy Gradient. Предварительно обучайте на офлайн-данных: «прогревайте» RL-агентов, чтобы они имитировали существующее поведение на основе исторических данных или вручную созданных сценариев. Тогда при запуске у них уже будет это (хорошее) поведение, и они будут улучшаться, обучаясь на реальных данных.
They also shared about how they automated hyperparameter tuning with MLflow.
Они также рассказали о том, как автоматизировали подбор гиперпараметров с помощью MLflow.
Here’s my previous write-up and accompany GitHub on running rapid experiments using Jupyter, Papermill, and MLflow.
Вот мой предыдущий обзор и сопутствующий GitHub о быстром проведении экспериментов с использованием Jupyter, Papermill и MLflow.
Further reading:
Дополнительное чтение:
Глубокое обучение с подкреплением в продакшене в Zynga Машинное обучение масштаба портфолио в Zynga RL-Bakery GitHub
Adding These to a GitHub on Applied Machine Learning
Добавляю всё это в GitHub-репозиторий по прикладному машинному обучению
Enjoy such application-specific content on machine learning?
Нравится такой прикладной контент о машинном обучении?
So do I. So much that I’ve created a GitHub repo (applied-ml) for it. The examples from this write-up can be found there. I’ve also added other content I’ve come across.
Мне тоже. Настолько, что я создал для этого GitHub-репозиторий (applied-ml). Примеры из этого обзора можно найти там. Я также добавил другие материалы, которые встречал.
If you enjoy such content and the repository, I would really appreciate if you give it a star and spread the word. Even better if you contributed content via a pull request. Thank you!
Если вам нравится такой контент и этот репозиторий, я буду очень признателен, если вы поставите звезду и расскажете о нём. Ещё лучше — если вы внесёте контент через pull request. Спасибо!
P.S., Want to share a summary of this article? Retweet the thread below!
P.S. Хотите поделиться кратким содержанием этой статьи? Ретвитните тред ниже!
My notes on app-specific talks @ @SparkAISummit 2020👇
Airbnb's Sputnik: A Data Engineering Framework
• Removes boilerplate run logic so devs focus on job logic
• Bakes in best practices
• E.g., reduce file counts via repartition
• Easy batching of backfill jobs
Мои заметки по прикладным докладам на @SparkAISummit 2020👇Sputnik от Airbnb: фреймворк дата-инженерии• Убирает шаблонную логику запуска, чтобы разработчики фокусировались на логике задачи• Встраивает лучшие практики• Например, уменьшение числа файлов через repartition• Простая пакетная обработка задач backfill— Eugene Yan (@eugeneyan) 7 июля 2020
If you found this useful, please cite this write-up as:
Если вы нашли это полезным, пожалуйста, цитируйте этот обзор как:
Yan, Ziyou. (Jul 2020). My Notes From Spark+AI Summit 2020 (Application-Specific Talks). eugeneyan.com. https://eugeneyan.com/writing/notes-from-sparkai-summit-application-specific/.
Yan, Ziyou. (Jul 2020). My Notes From Spark+AI Summit 2020 (Application-Specific Talks). eugeneyan.com. https://eugeneyan.com/writing/notes-from-sparkai-summit-application-specific/.
or
или
@article{yan2020spark2,
title = {My Notes From Spark+AI Summit 2020 (Application-Specific Talks)},
author = {Yan, Ziyou},
journal = {eugeneyan.com},
year = {2020},
month = {Jul},
url = {https://eugeneyan.com/writing/notes-from-sparkai-summit-application-specific/}
}
@article{yan2020spark2, title = {My Notes From Spark+AI Summit 2020 (Application-Specific Talks)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jul}, url = {https://eugeneyan.com/writing/notes-from-sparkai-summit-application-specific/} }
Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, рекомендательных системах, LLM и инженерии.