Архитектура, управляемая событиями, может убрать ваши зашумленные ярлыки машинного обучения

Архитектура, управляемая событиями, может убрать ваши зашумленные ярлыки машинного обучения

Я работаю в Riskified почти семь лет, сначала работая частично аналитиком-исследователем и частично инженером-программистом, прежде чем стать разработчиком на полную ставку. Теперь я один из архитекторов программного обеспечения. Благодаря моему уникальному карьерному росту в компании я знаком с обеими сторонами медали, когда дело доходит до требований к машинному обучению, - с точки зрения специалистов по данным и с точки зрения разработчиков.

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

В случае Riskified ярлыки изменяемы. Это означает, что ярлыки могут меняться с течением времени. Кроме того, ярлыки получены из нескольких полей. Почему это проблема? По мере роста компании увеличивается количество используемых ярлыков и полей. В результате нет единого человека, который знает их все, и это может привести к потере данных.

Если это так в вашей компании, и ваши ярлыки взяты из управляемой государством архитектуры, вы, вероятно, знаете, о чем я говорю. Эти изменяемые метки, рассчитанные из нескольких полей, могут создавать шум, который может сильно повлиять на точность модели. Так чем же может помочь архитектура системы?

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

В этом сообщении блога я опишу решение, которое мы использовали, и расскажу, как дизайн, управляемый событиями помогает нашим специалистам по данным, которым требуются две точки зрения на ярлыки:

1. Самая последняя версия должна быть доступна из потока в реальном времени.
2. Все версии на определенный момент времени должны быть доступны для использования в автономном режиме.

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

Проблемное состояние

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

Проще говоря, когда мы классифицируем заказ, у нас есть только две метки:

«Мошенничество» (положительный результат) и «Не мошенничество » (отрицательный результат).

Предположим, например, что мы классифицировали заказ как «Не мошенничество»:

Это могло быть легко, но скоро все станет еще сложнее. Могут возникнуть два типа проблем, которые я называю проблемами M&M. Итак, что означает каждая буква M?

Во-первых, поля m utable: после нашей первоначальной классификации «не мошенничество» клиент обновляет заказ, добавляя другой адрес доставки. Это вызывает дополнительный анализ заказа. Скажем, новая классификация - «мошенничество»:

В этом случае есть момент времени, когда заказ был помечен как «Not Fraud», но после обновления он был помечен как «Fraud».

Во-вторых, m несколько полей: после нашей первоначальной классификации «не мошенничество» дополнительная проверка порядка показывает, что наша модель дала ложноотрицательную классификацию.

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

В этом случае мы не хотим засчитывать заказ как «Not Fraud», поэтому наш ярлык фактически будет получен из нескольких (в данном случае двух) разных полей:

def positive():
  classification == "Fraud" or 
  (classification == "Not Fraud" and tag == "false-negative")
def negative():
  classification == "Not Fraud"

Теперь вы знаете проблему M&M:

• M utable поля - метки изменяемы и меняются со временем, но сохраняется только самое последнее состояние (пример 1).
• M нескольких полей - метки могут быть распределены по нескольким доменам и группам разработки, и, следовательно, нескольким полям. Пример 2 - это простой пример одного дополнительного поля, но на самом деле он может включать гораздо больше полей, возможно, из нескольких баз данных, которые определяют метки. В сочетании с несколькими сотрудниками, которые могут быть знакомы не со всеми областями, очень вероятным результатом является потеря знаний.

Что будет, если мы ничего не сделаем? Мы закончим хаосом.

Итак, как мы можем решить эту проблему M&M? Поскольку это прямой результат дизайна, управляемого состоянием, мы могли бы подумать об изменении архитектуры.

Состояние против события

Прежде всего, давайте договоримся о некоторых основных определениях. Как я объяснял ранее, дизайн, управляемый состоянием, - это когда мы сохраняем определенное состояние в какой-то базе данных и перезаписываем данные всякий раз, когда это требуется. В примере 1 мы перезаписали поле classification, потому что адрес был обновлен.

Итак, что такое событие и чем оно отличается? Допустим, ваш возраст - это состояние (сохраняется в поле под названием «возраст» в базе данных), и каждый год ваш возраст заменяется событием - днем ​​рождения. Когда состояние меняется, легко узнать, каким оно было раньше (если мне сейчас 35 лет, то 5 лет назад мне было 30 лет), но это не всегда так. В примере 1 вы не можете знать, каким было состояние до его изменения.

Как мероприятие нам поможет в этом случае? Если мы сохраним журнал событий, мы сможем узнать, какое состояние было в любой момент времени.

Вернемся к примерам 1 и 2 и посмотрим на временную шкалу (та же временная шкала для обоих примеров):

На t1 наша метка отрицательная, а на t3 - положительная. Обратите внимание, что разница во времени между t1 и t3 может быть разной: она может составлять секунды или дни. Итак, какой лейбл выбрать?

Сейчас хорошее время, чтобы напомнить вам о наших требованиях:

1. Самая последняя версия этикетки должна быть доступна в режиме реального времени.
2. Все версии этикетки на определенный момент времени должны быть доступны для использования в автономном режиме.

В дизайне, управляемом состоянием, точка 1 проста, но как насчет точки 2? Дизайн, управляемый событиями, - возможное решение, потому что он предоставляет нам все состояния в любой момент времени.

На помощь приходит событийная архитектура

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

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

Эта часть является небольшой ознакомительной, так как у нас есть много данных в нескольких базах данных и ни один человек, который мог бы все это знать. Как архитектор, мне приходилось проводить исследования с несколькими командами, и в итоге я обнаружил более 40 (🤯) различных событий, которые возникли в разных частях системы и были важны для нашего обучения модели.

Что мы могли сделать со всеми этими событиями? Выбрав нашу технологию обмена сообщениями о событиях (Kafka), мы убедились, что все события будут перетекать в одно и то же место (тему) из каждого микросервиса:

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

Как работает потребитель-производитель этикеток? Это потребитель, который использует один из продуктов экосистемы Kafka, Kafka Streams, который позволяет разрабатывать потоковую обработку с отслеживанием состояния. Вы можете запрограммировать различные DSL для расчета своего состояния. Мы можем фильтровать, отображать, группировать, агрегировать и объединять различные темы, а также вычислять наши метки (состояние).

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

Обратите внимание, что это конкретное решение, в котором используется Kafka, но можно использовать и другие решения для потоковой передачи.

Вернемся к M&M и убедимся, что наш дизайн, управляемый событиями, действительно решил проблему:

• M табличные поля - теперь наши специалисты по данным смогут получить доступ к данным в любое время, не беспокоясь о внесенных изменениях.
• M нескольких полей - теперь у нас есть единый источник правды, который решает проблему нескольких полей в нескольких базах данных для нескольких сотрудников. Для потребителей не имеет значения, где хранятся данные.

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

1. Самая последняя версия этикетки должна быть доступна в режиме реального времени - Она изготовлена ​​производителем этикеток.
2. Конкретная версия этикетки на определенный момент времени должна быть доступна для использования в автономном режиме - ✅ Пользователь, находящийся в автономном режиме, имеет все данные, сохраненные с течением времени.

Скрытое преимущество

Поскольку наша компания ориентирована на аналитику, мы постоянно добавляем инсайты к нашим данным (в виде тегов, таких как «ложноотрицательный» тег из примера 2). Мы не всегда с самого начала знаем, как тег повлияет на «положительные» и «отрицательные» ярлыки и на какие из них повлияет. Таким образом, благодаря архитектуре, управляемой событиями, мы можем задним числом применять к тегам положительную / отрицательную метку. Таким образом, наши специалисты по данным могут «поиграть» с данными и создать любое материализованное представление, которое они хотят, - создавая нужные им метки и, возможно, даже новые метки, которые построены совершенно по-другому.

Подведение итогов

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

И если вам нужна еще одна причина того, почему дизайн, управляемый событиями, настолько эффективен, вот забавный факт для вас: как только мы получили эту централизованную тему, о которой мы упоминали, мы получили запрос от другой команды на использование ее в других системных доменах, и мы это сделали. это легко. В событийно-ориентированном дизайне замечательно то, что мы можем привлекать все больше и больше потребителей - и они не будут влиять друг на друга! Еще одна победа для событийного дизайна!