Case study of how small team in Preply started with inheriting an existing ranking model to being able to produce a model per day. In this talk we'll cover steps to take if you find yourself in a similar situation: what kind of technology and processes can you introduce in order to achieve a great speedup in a development speed.

1. Як Preply зменшила час
розробки ML моделі з 1 місяця
до 1 дня
Євген Євсюгов, Senior Software Engineer @ Preply

2. Що таке Preply?

3. З чого ми почали?

4. Як працювала модель спочатку?
Розробка і тренування: Jupyter Notebooks на локальних машинах
Джерело даних: декілька баз даних, що join’ились за допомогою pandas
Калькуляція ранжування: Jenkins job
Інтеграція з бекендом: Elasticsearch
Час на ітерацію: більше місяця

5. Як ми це вирішували?
Поступово.
1. Джерело даних.
2. Розробка (і production).
3. Джерело даних (ще раз).
4. Розробка і production (ще раз).

6. Джерело даних

7. Джерело даних

8. Стало краще
1. Pandas всередині Jenkins “тупив”, бо даних було забагато
2. Перевикористали уже готову інфраструктуру (Snowflake)
3. Стало набагато зручніше рахувати features
a. Було: SQL in python, pandas to join
b. Стало: SQL in python

9. Які проблеми залишились?
1. Jenkins досі виглядає, як “костиль”.
2. Розробка і тренування моделі досі відбуваються на локальних машинах.
3. SQL запити туплять.

10. Що зробили з SQL запитами?
Оптимізували.
1. Йшли від найбільш “важких” до найбільш “легких” запитів.
2. Більшість запитів оптимізувати було тривіально — використання pre-computed tables для
зменшення часу на сканування таблиці.

11. Тренуємо моделі в хмарах

12. Мінуси Sagemaker
1. AWS Console UI
2. Доволі “сирий” продукт
a. Ноутбуки “помирали”, якщо сесія закінчиться
b. Виглядає як швидка обгортка AWS над Jupyter notebooks

13. Рішення

14. Переваги databricks
1. Легка інтеграція з існуючими хмарними вендорами: AWS, GCP тощо
2. PySpark з коробки
3. “Вертикальне” рішення для data-задач:
a. Notebooks
b. Jobs
c. Data Lake
d. Streaming
e. MLFlow
f. MLOps

15. Нова архітектура

16. Нова архітектура

17. Checkpoint
1. Snowflake
2. Databricks
3. Sagemaker

18. Проблемa
model_a
– collect_impressions_features.sql
– collect_profile_views_features.sql
model_b
– collect_impressions_features.sql
– collect_profile_views_features.sql
– collect_lessons_features.sql
model_c
– collect_impressions_features.sql
– collect_profile_views_features_new.sql
– collect_lessons_features.sql

19. Feature store
Ціль: перевикористання features
Вирішення:
1. Обраховуємо features кожного дня і зберігаємо
2. SQL використовує features з feature store
Підхід:
1. Feast
2. Databricks feature store
3. Самописний “фреймворк” поверх Snowflake

20. Чому самописний “фреймворк”?
1. Готові продукти не вирішують основної задачі: “як рахувати features?”.
2. Можливість власних абстракцій для калькуляції features
a. Testing
b. Monitoring
c. Вимоги специфічні до нашої моделі
Проблема: абстракції над features лімітують архітектуру моделі.

21. Пролемa залишилась
model_a
– collect_impressions_features.sql
– collect_profile_views_features.sql
model_b
– collect_impressions_features.sql
– collect_profile_views_features.sql
– collect_lessons_features.sql
1. Зменшили к-сть рядків в SQL запитах з тисяч
до десятків/сотень
2. Значно пришвидшилась швидкість збирання
даних для тренування

22. MLFlow / MLOps
1. Data scientists можуть натренувати модель “однією кнопокою”
2. Версіонування
3. Облік: які features використовує модель, на якому наборі даних тренувались
4. Статистичні метрики (AUC, NDCG тощо) зберігаються в одному місці (databricks)
5. Бізнес метрики автоматични рахуються та збергіються в одному місці (databricks)

23. Як зараз проходить тренування моделі?
1. (Опціонально) Додати нові features у feature store
2. Описати модель:
a. Які features з feature store використовувати
b. Прописати SQL для targets
c. Прописати “пост-процессинг”, наприклад feature_c = feature_a / feature_b
3. Натиснути “одну кнопку” в databricks інтерфейсі

26. Результат

27. Проблеми нашого підходу
Feature store і MLOps лімітовані під нашу задачу:
1. Features калькулюються раз в день
a. Якщо захочемо перераховуати ранжування погодинно — доведеться доробляти
2. Привʼязані до певного формату input/output
a. Якщо захочемо робити іншу архітектуру, наприклад, real time — доведеться переробляти
3. Складність додавання features
a. Накидати SQL-скриптик простіше, ніж додати feature у feature store по процесу

28. Плюси нашого підходу
Час на ітерацію: більше 1 місяця -> 1 день

29. Дякую!