Надання точних, послідовних і готових до виробництва функцій машинного навчання.

У цій статті докладніше розглядається наш магазин функцій машинного навчання (ML). Це продовження нашої попередньої публікації в блозі, яка надає ширший огляд усієї інфраструктури конвеєра машинного навчання.

Чому ми використовуємо магазин функцій?

Сховище функцій, одна з багатьох частин нашої системи, є, мабуть, найважливішим гвинтиком у системі. Його основна мета — функціонувати як центральна база даних, яка керує функціями до того, як їх відправлять для навчання моделі або висновку.

Якщо ви не знайомі з цим терміном, функції — це, по суті, необроблені дані, які вдосконалюються за допомогою процесу, який називається розробкою функцій, у щось більш зручне, що наші моделі ML можуть використовувати для самостійного навчання або розрахунку прогнозів.

У двох словах, магазини функцій дозволяють нам:

  • Повторно використовуйте та діліться функціями в різних моделях і командах

  • Скоротіть час, необхідний для експериментів МЛ

  • Зведіть до мінімуму неточні прогнози через сильний перекіс тренувального обслуговування

Щоб краще зрозуміти важливість сховища функцій, ось діаграма конвеєра ML, який його не використовує.

У цьому конвеєрі дві частини — навчання моделі та служба логічного висновку — не можуть визначити, які функції вже існують і можуть бути повторно використані. Це призводить до того, що конвеєр ML дублює процес розробки функцій. У червоному колі на діаграмі ви помітите, що конвеєр ML замість повторного використання функцій створив нагромадження повторюваних функцій і надлишкових конвеєрів. Ми називаємо цю групу розростанням конвеєра функцій.

Підтримка цього розповсюдження функцій стає дедалі дорожчим і некерованим сценарієм у міру того, як бізнес зростає та все більше користувачів приходять на платформу. Подумайте про це таким чином; спеціаліст із даних повинен починати процес розробки функцій, який є довгим і виснажливим, повністю з нуля для кожної нової моделі, яку вони створюють.

Крім того, надмірне повторне впровадження логіки функцій вводить концепцію, яка називається перекосом у обслуговуванні навчання, який є розбіжністю між даними під час навчання та стадії висновку. Це призводить до неточних прогнозів і непередбачуваної поведінки моделі, яку важко усунути під час виробництва. Перш ніж створювати сховища функцій, наші спеціалісти з обробки даних перевірятимуть узгодженість функцій за допомогою перевірок надійності. Це трудомісткий процес, який виконується вручну і відволікає увагу від завдань із вищим пріоритетом, таких як моделювання та розробка глибоких функцій. Тепер давайте дослідимо конвеєр ML із сховищем функцій.

Подібно до іншого конвеєра, ми маємо ті самі джерела даних і функції зліва. Однак замість того, щоб проходити через кілька конвеєрів функцій, у нас є сховище функцій як один центральний хаб, який обслуговує обидві фази конвеєра машинного навчання (навчання моделі та служба висновків). Немає повторюваних функцій; усі процеси, необхідні для створення функції, включаючи трансформацію та агрегацію, потрібно виконати лише один раз.

Науковці даних можуть інтуїтивно взаємодіяти зі сховищем функцій за допомогою спеціально створеного Python SDK для пошуку, повторного використання та виявлення функцій для подальшого навчання моделі ML і висновків.

По суті, сховище функцій — це централізована база даних, яка об’єднує обидві фази. А оскільки сховище функцій гарантує узгоджені функції для навчання та логічного висновку, ми можемо значно зменшити відхилення від навчання.

Зауважте, що магазини функцій роблять набагато більше, ніж те, що ми згадали вище. Це, звичайно, більш рудиментарне резюме того, чому ми використовуємо сховище функцій, і те, що ми можемо далі розбити лише на кілька слів: підготовка та надсилання функцій у моделі ML найшвидшим і найпростішим способом.

У магазині функцій

На малюнку вище показано типовий макет магазину функцій, будь то AWS SageMaker Feature Store, Google vertex AI (Feast), Azure (Feathr), Iguazio або Tetcom. Усі магазини функцій пропонують два типи зберігання: онлайн або офлайн.

Онлайн-сховища функцій використовуються для висновків у реальному часі, тоді як офлайн-сховища функцій використовуються для пакетного прогнозування та навчання моделей. Через різні варіанти використання метрика, яку ми використовуємо для оцінки продуктивності, зовсім інша. В онлайн-функції ми шукаємо низьку затримку. Для офлайн-магазинів функцій нам потрібна висока пропускна здатність.

Розробники можуть вибрати будь-який корпоративний магазин функцій або навіть відкритий код на основі стеку технологій. На діаграмі нижче показано ключові відмінності між онлайн-магазинами та офлайн-магазинами в AWS SageMaker Feature Store.

Інтернет-магазин: зберігає найновішу копію функцій і надає їх із низькою затримкою в мілісекундах, швидкість якої залежить від розміру корисного навантаження. Для нашої моделі захоплення облікового запису (ATO), яка має вісім груп функцій і загалом 55 функцій, швидкість становить близько 30 мс затримки p99.

Офлайн-сховище: сховище лише для додавання, яке дозволяє відстежувати всі історичні функції та здійснювати подорожі в часі, щоб уникнути витоку даних. Дані зберігаються в стандартному форматі з розподілом за часом для підвищення ефективності читання.

Що стосується узгодженості функцій, якщо групу функцій налаштовано як для онлайн-, так і для офлайн-використання, дані будуть автоматично та внутрішньо скопійовані в офлайн-сховище, поки функція надходить в онлайн-магазин.

Як ми використовуємо магазин функцій?

Код, зображений вище, приховує багато складності. Магазини функцій дозволяють нам просто імпортувати інтерфейс python для навчання моделі та висновків.

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

Найкращі методи використання магазину функцій

У нашому попередньому дописі в блозі ми пояснили, як ми використовуємо рівень магазину для введення функцій у централізовану БД. Тут ми хотіли б поділитися двома найкращими методами використання магазину функцій:

  1. Ми не завантажуємо функції, які не змінилися

  2. Ми розділяємо функції на дві логічні групи: активні операції користувача та неактивні

Розглянемо цей приклад. Припустімо, у вас є ліміт регулювання 10K TPS для PutRecord у вашому онлайн-магазині функцій. Використовуючи цю гіпотетику, ми отримаємо функції для 100 мільйонів користувачів. Ми не можемо отримати їх усі одразу, і з нашою поточною швидкістю це займе приблизно 2,7 години. Щоб вирішити цю проблему, ми вибираємо лише нещодавно оновлені функції. Наприклад, ми не будемо завантажувати функцію, якщо значення не змінилося з часу останнього надходження.

Щодо другого пункту, припустімо, ви помістили набір функцій в одну логічну групу функцій. Деякі з них активні, тоді як велика частина неактивна, тобто більшість функцій не змінено. Логічним кроком, на нашу думку, є розділення активних і неактивних на дві групи функцій, щоб пришвидшити процес прийому.

Для неактивних функцій ми скорочуємо 95% даних, які нам потрібно завантажувати в сховище функцій для 100 мільйонів користувачів на погодинній основі. Крім того, ми все ще скорочуємо 20% даних, необхідних для активних функцій. Отже, замість трьох годин конвеєр пакетної обробки обробляє функції 100 мільйонів користувачів за 10 хвилин.

Заключні думки

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

Зацікавлені у використанні ML для захисту найбільшої у світі криптоекосистеми та її користувачів? Ознайомтеся з Binance Engineering/AI на нашій сторінці кар’єри, щоб знайти відкриті оголошення про вакансію.

Подальше читання:

  • (Блог) Використання MLOps для створення конвеєра наскрізного машинного навчання в реальному часі