Основні висновки
У Binance ми використовуємо машинне навчання (ML) для вирішення різноманітних бізнес-проблем, включаючи, але не обмежуючись цим, шахрайство з захопленням облікового запису (ATO), P2P-шахрайство та викрадену платіжну інформацію.
Використовуючи операції машинного навчання (MLOps), наші вчені Binance Risk AI створили наскрізний конвеєр ML у реальному часі, який постійно надає готові до виробництва послуги ML.
Чому ми використовуємо MLOps?
По-перше, створення сервісу машинного навчання є ітеративним процесом. Фахівці з обробки даних постійно експериментують, щоб покращити певний показник, як офлайн, так і онлайн, виходячи з цілі досягнення цінності для бізнесу. Отже, як ми можемо зробити цей процес ефективнішим — наприклад, скоротити час виходу моделі ML на ринок?
По-друге, на поведінку служб машинного навчання впливає не лише код, який ми, розробники, визначаємо, а й дані, які він збирає. Ця ідея, також відома як дрейф концепції, наголошується в статті Google під назвою «Прихований технічний борг у системах машинного навчання».
Візьмемо як приклад шахрайство; шахрай — це не просто машина, а людина, яка адаптується та постійно змінює спосіб атаки. Таким чином, базовий розподіл даних буде розвиватися відповідно до змін у векторах атак. Як ми можемо ефективно переконатися, що виробнича модель враховує останні шаблони даних?
Щоб подолати проблеми, згадані вище, ми використовуємо концепцію під назвою MLOps, термін, спочатку запропонований Google у 2018 році. У MLOps ми зосереджуємося на продуктивності моделі та інфраструктурі, що підтримує виробничу систему. Це дозволяє нам створювати сервіси машинного навчання, які є масштабованими, високодоступними, надійними та доступними для обслуговування.
Розбираємо наш наскрізний конвеєр машинного навчання в реальному часі
Уявіть наведену вище діаграму як нашу стандартну операційну процедуру (SOP) для розробки моделі в реальному часі зі сховищем функцій. Наскрізний конвеєр машинного навчання визначає, як наша команда застосовує MLops, і він створений із двома типами вимог: функціональними та нефункціональними.
Функціональний
Обробка даних
Модельне навчання
Розробка моделі
Розгортання моделі
Моніторинг
Нефункціональні вимоги
Масштабований
Високодоступний
Надійний
Ремонтопридатний
Далі трубопровід розділений на шість ключових компонентів:
Обчислювальний рівень
Зберегти шар
Централізована БД
Модельне навчання
Розгортання моделі
Моніторинг моделі
1. Обчислювальний рівень
Обчислювальний рівень головним чином відповідає за розробку функцій, процес перетворення необроблених даних у корисні функції.
Ми класифікуємо обчислювальний рівень на два типи залежно від частоти оновлення: потокові обчислення з інтервалами в одну хвилину/секунду та пакетні обчислення для щоденних/годинних інтервалів.
Вхідні дані обчислювального рівня зазвичай надходять із бази даних на основі подій, яка включає Apache Kafka і Kinesis, або бази даних OLAP, яка включає Apache Hive для відкритих вихідних кодів і Snowflake для хмарних рішень.
2. Зберегти шар
На рівні сховища ми реєструємо визначення функцій і розгортаємо їх у нашому сховищі, а також виконуємо заповнення, процес, який дозволяє нам відновлювати функції за допомогою історичних даних щоразу, коли визначається нова функція. Засипка – це, як правило, одноразова робота, яку наші дослідники даних можуть виконати в середовищі ноутбука. Оскільки Kafka може зберігати лише події за останні сім днів, він використовує механізм резервного копіювання в таблиці s3/hive для підвищення відмовостійкості.
Ви помітите, що проміжний рівень, Hive і Kafka, навмисно розміщений між обчислювальним і сховищем. Подумайте про це розташування як про буфер між функціями обчислення та запису. Аналогією було б відокремлення виробника від споживача. Потокове обчислення є виробником, тоді як прийом потоку є споживачем.
Відокремлення обчислень і прийому дає низку переваг для наших конвеєрів машинного навчання. Для початку ми можемо підвищити надійність трубопроводу у разі збоїв. Наші спеціалісти з обробки даних все ще можуть отримувати значення функції з централізованої бази даних, навіть якщо рівень прийому даних або обчислювальний рівень недоступні через проблеми з роботою, обладнанням або мережею.
Крім того, ми можемо індивідуально масштабувати різні частини інфраструктури та зменшувати енергію, необхідну для будівництва та експлуатації трубопроводу. Наприклад, якщо це не вдається з будь-якої причини, рівень прийому не блокуватиме обчислювальний рівень. На фронті інновацій ми можемо експериментувати та застосовувати нові технології, такі як нова версія програми Flink, не впливаючи на нашу існуючу інфраструктуру.
Обчислювальний рівень і рівень зберігання — це те, що ми називаємо автоматизованими конвеєрами функцій. Ці конвеєри є незалежними, працюють за різними графіками та класифікуються як потокові або пакетні конвеєри. Ось як два конвеєри працюють по-різному: одна група функцій у пакетному конвеєрі може оновлюватися щоночі, а інша група оновлюється щогодини. У потоковому конвеєрі група функцій оновлюється в реальному часі, коли вихідні дані надходять у вхідний потік, наприклад тема Apache Kafka.
3. Централізована БД
Рівень централізованої бази даних – це місце, де наші дослідники даних представляють свої готові дані в онлайн- або офлайн-сховище функцій.
Онлайн-магазин функцій — це магазин із низькою затримкою та високою доступністю, який дає змогу переглядати записи в реальному часі. З іншого боку, офлайн-сховище функцій забезпечує безпечне та масштабоване сховище всіх даних функцій. Це дозволяє вченим створювати набори даних для навчання, перевірки або пакетної оцінки з набору централізовано керованих груп ознак із повним історичним записом значень ознак у системі зберігання об’єктів.
Обидва сховища функцій автоматично синхронізуються один з одним кожні 10-15 хвилин, щоб уникнути перекосів під час навчання. У наступній статті ми детально зануримося в те, як ми використовуємо сховища функцій у конвеєрах.
4. Модельне навчання
Рівень навчання моделі – це місце, де наші вчені витягують навчальні дані з офлайн-сховища функцій для вдосконалення наших служб машинного навчання. Ми використовуємо запити на певний момент часу, щоб запобігти витоку даних під час процесу вилучення.
Крім того, цей рівень включає важливий компонент, відомий як цикл зворотного зв’язку для повторного навчання моделі. Перенавчання моделі мінімізує ризик відхилення концепції, гарантуючи, що розгорнуті моделі точно відображають найновіші моделі даних — наприклад, хакер змінює свою поведінку атаки.
5. Розгортання моделі
Для розгортання моделі ми в основному використовуємо хмарну службу підрахунку балів як основу нашого обслуговування даних у реальному часі. Ось діаграма, яка показує, як поточний код висновку інтегрується зі сховищем функцій.
6. Модельний моніторинг
На цьому рівні наша команда відстежує показники використання для підрахунку служб, таких як QPS, затримка, пам’ять і рівень використання CPU/GPU. Окрім цих основних показників, ми використовуємо зібрані дані для перевірки розподілу функцій у часі, перекосу, що обслуговує навчання, і дрейфу прогнозу, щоб забезпечити мінімальний дрейф концепції.
Заключні думки
Підсумовуючи, вільний поділ нашої конвеєрної інфраструктури на обчислювальний рівень, рівень зберігання та централізовану базу даних дає нам три ключові переваги порівняно з більш тісно зв’язаною архітектурою.
Більш міцні трубопроводи на випадок збоїв
Підвищена гнучкість у виборі інструментів для впровадження
Незалежно масштабовані компоненти
Зацікавлені у використанні ML для захисту найбільшої у світі криптоекосистеми та її користувачів? Ознайомтеся з Binance Engineering/AI на нашій сторінці кар’єри, щоб знайти відкриті оголошення про вакансію.