Привет всем! 👋
Меня зовут Андрей (@saws_baws), я программист, интересующийся распределенными системами, машинным обучением/ИИ, обработкой и хранением данных, облачными вычислениями и real-time системами.
Здесь я планирую писать про Real-Time AI/ML - междисциплинарную область основанную на построении и использовании систем машинного обучения в режиме реального времени, и все, что с этим связано (алгоритмы, инфраструктура, оптимизация производительности, system design, общие понятия, бизнес-кейсы и т.д.).
А также про Volga - open-source движок для обработки данных в режиме реального времени для AI/ML (над которым я работаю):
• Github: https://github.com/volga-project/volga
• Технический блог: https://volgaai.substack.com
Канал включает как общие сведения/новости/понятия, так и глубокие технические детали и может быть интересен широкому спектру специалистов: PM/BA, AI/ML eng, data eng, ML/Dev/LLM/AIOps, бэкенд, системные инженеры и т.д.
Меня зовут Андрей (@saws_baws), я программист, интересующийся распределенными системами, машинным обучением/ИИ, обработкой и хранением данных, облачными вычислениями и real-time системами.
Здесь я планирую писать про Real-Time AI/ML - междисциплинарную область основанную на построении и использовании систем машинного обучения в режиме реального времени, и все, что с этим связано (алгоритмы, инфраструктура, оптимизация производительности, system design, общие понятия, бизнес-кейсы и т.д.).
А также про Volga - open-source движок для обработки данных в режиме реального времени для AI/ML (над которым я работаю):
• Github: https://github.com/volga-project/volga
• Технический блог: https://volgaai.substack.com
Канал включает как общие сведения/новости/понятия, так и глубокие технические детали и может быть интересен широкому спектру специалистов: PM/BA, AI/ML eng, data eng, ML/Dev/LLM/AIOps, бэкенд, системные инженеры и т.д.
👍3
Real-Time AI/ML - Инфраструтктура, алгоритмы, данные pinned «Привет всем! 👋 Меня зовут Андрей (@saws_baws), я программист, интересующийся распределенными системами, машинным обучением/ИИ, обработкой и хранением данных, облачными вычислениями и real-time системами. Здесь я планирую писать про Real-Time AI/ML - междисциплинарную…»
Real-Time AI/ML как отдельная инженерная дисциплина
Вступительный пост с определениями и понятиями по тематике канала.
Определим ML (machine learning/машинное обучение) как процесс создания математической модели и ее использования для моделирования какого бы то ни было процесса, при этом любую ML систему (очень условно) можно описать как состоящую из (в нашем случае, мы обычно говорим про supervised learning системы - т.н. "обучение с учителем"):
• Feature Engineering - создание т.н. "фичей" или "признаков" (features) - чисел, скармливаемых модели, полученных из сырых входных данных о моделируемой системе. Сюда же включим создание данных для обучения и валидации модели из этих фичей (т.н. "разметка" - data labeling).
• Model Training/Validation - обучение модели на "размеченных" фичах (то есть "объясненных учителем" модели какой набор данных к какому результату приводит) и валидация ее производительности на заранее известных данных.
• Model Inference - "генерация" моделью результата с использованием фичей рассчитанных во время запроса.
Тогда (еще более условно) Real-Time ML (смежные понятия - Online/Streaming) можно описать как концепцию состоящую из:
• Real-time feature engineering - вычисление фичей в реальном времени используя потоковые/онлайн данные с минимальной задержкой и большой точностью для мгновенного инференса. Здесь можно вводить огромное количество более детальных категорий (свежесть фичи, время вычисления/запроса, вычисление скопом (batch) или событийно (event-based), какой вычислительный движок используется и т.д.)
• Real-time learning (так же continual learning, adaptive learning, incremental learning, online learning) - "адаптивное" изменение модели (например, переобучением или до-обучением) для отражения статистических изменений в данных (data drift) и/или фундаментальных изменений процессообразующих систем (concept drift) c течением времени.
Каждая из этих частей является отдельной инженерной областью, а префикc "real-time" вносит огромный ряд концептуальных изменений по сравнению с обычными "статическими" ML системами, на уровнях от логического до инфраструктурного (которые мы будем детально рассматривать на этом канале).
Почему это важно
В реальном мире не все ML системы имеют прямую пользу от real-time, однако на интуитивном уровне понятно, что целый ряд случаев может иметь огромное преимущество, а именно:
• Fraud Detection - анти-фрод системы (анти-мошенничество), особенно превентивного реагирования
• Recommender Systems - рекомендательные системы, особенно с живой лентой (feed)
• Personalized Search - улучшение релевантности результатов в поисковых системах
• IoT Anomaly Detection - мониторинг интернета вещей (сервера, датчики) на предмет аномалий (сбои, поломки)
• Estimated Time of Arrival (ETA) - расчет времени/скорости доставки чего либо (райдтех, фудтех)
• Dynamic Pricing - динамическое ценообразование чего-либо (ad-tech, ride-tech)
• Credit Risk - подсчет риска в кредитовании для услуг требующих быстрого реагирования
• Retrieval Augmented Generation - энтерпрайз-готовые RAG системы всегда оперируют самыми свежими данными для формирования контекста при запросе к LLM
И немного цифр почему real-time это важно:
• Рекомендательная система Monolith от TikTok увеличила эффективность на 18% (CTR AUC) в онлайн режиме
• Google: увеличение задержки поискового запроса c 100 мс до 400 мс уменьшает использование сервиса на 0.2-0.6 %
В следующих постах будем рассматривать описанное выше подробно.
Вступительный пост с определениями и понятиями по тематике канала.
Определим ML (machine learning/машинное обучение) как процесс создания математической модели и ее использования для моделирования какого бы то ни было процесса, при этом любую ML систему (очень условно) можно описать как состоящую из (в нашем случае, мы обычно говорим про supervised learning системы - т.н. "обучение с учителем"):
• Feature Engineering - создание т.н. "фичей" или "признаков" (features) - чисел, скармливаемых модели, полученных из сырых входных данных о моделируемой системе. Сюда же включим создание данных для обучения и валидации модели из этих фичей (т.н. "разметка" - data labeling).
• Model Training/Validation - обучение модели на "размеченных" фичах (то есть "объясненных учителем" модели какой набор данных к какому результату приводит) и валидация ее производительности на заранее известных данных.
• Model Inference - "генерация" моделью результата с использованием фичей рассчитанных во время запроса.
Тогда (еще более условно) Real-Time ML (смежные понятия - Online/Streaming) можно описать как концепцию состоящую из:
• Real-time feature engineering - вычисление фичей в реальном времени используя потоковые/онлайн данные с минимальной задержкой и большой точностью для мгновенного инференса. Здесь можно вводить огромное количество более детальных категорий (свежесть фичи, время вычисления/запроса, вычисление скопом (batch) или событийно (event-based), какой вычислительный движок используется и т.д.)
• Real-time learning (так же continual learning, adaptive learning, incremental learning, online learning) - "адаптивное" изменение модели (например, переобучением или до-обучением) для отражения статистических изменений в данных (data drift) и/или фундаментальных изменений процессообразующих систем (concept drift) c течением времени.
Каждая из этих частей является отдельной инженерной областью, а префикc "real-time" вносит огромный ряд концептуальных изменений по сравнению с обычными "статическими" ML системами, на уровнях от логического до инфраструктурного (которые мы будем детально рассматривать на этом канале).
Почему это важно
В реальном мире не все ML системы имеют прямую пользу от real-time, однако на интуитивном уровне понятно, что целый ряд случаев может иметь огромное преимущество, а именно:
• Fraud Detection - анти-фрод системы (анти-мошенничество), особенно превентивного реагирования
• Recommender Systems - рекомендательные системы, особенно с живой лентой (feed)
• Personalized Search - улучшение релевантности результатов в поисковых системах
• IoT Anomaly Detection - мониторинг интернета вещей (сервера, датчики) на предмет аномалий (сбои, поломки)
• Estimated Time of Arrival (ETA) - расчет времени/скорости доставки чего либо (райдтех, фудтех)
• Dynamic Pricing - динамическое ценообразование чего-либо (ad-tech, ride-tech)
• Credit Risk - подсчет риска в кредитовании для услуг требующих быстрого реагирования
• Retrieval Augmented Generation - энтерпрайз-готовые RAG системы всегда оперируют самыми свежими данными для формирования контекста при запросе к LLM
И немного цифр почему real-time это важно:
• Рекомендательная система Monolith от TikTok увеличила эффективность на 18% (CTR AUC) в онлайн режиме
• Google: увеличение задержки поискового запроса c 100 мс до 400 мс уменьшает использование сервиса на 0.2-0.6 %
В следующих постах будем рассматривать описанное выше подробно.
👍1
Volga: Data & Feature Engine for Real-Time AI/ML. Что, как и почему
Предыдущий пост кратко прошелся по Real-Time AI/ML: что это, для чего и какие инженерные области покрывает, а также выделил два основных направления в этой области: real-time feature engineering и real-time learning.
На практике, основной проблемой при создании real-time ML систем является первая часть (построение real-time feature пайплайнов) - real-time learning носит более исследовательский характер (хотя не всегда). В итоге, когда мы говорим о real-time ML, мы в первую очередь хотим создать real-time feature platform (не путать с feature store: feature platform = feature store + compute engine).
3 типа фичей по скорости вычисления (latency/freshness)
Выделим 3 основных (по требованию к задержке/скорости вычисления) типа ML фичей которые диктуют инфраструктурные потребности платформы:
• Offline Features (также Batch, Backfill)
Вычисляются в оффлайн режиме на исторических данных, используются для обучения/валидации модели. Задержка - от минут до дней. Вычисляются на (feature compute engine) - Spark.
• Online Features (также Streaming, Near-Real Time)
Вычисляются как только приходят данные (event based), используются для инференса. Задержка - от миллисекунд до секунд. Вычисляются на - Flink (иногда Spark Streaming).
• On-Demand Features (также Real-Time)
Вычисляются в момент запроса/инференса модели и зависят от данных известных только в этот момент (GPS координаты, ответы других моделей). Сюда же относим слой feature serving. Задержка - миллисекунды. Вычисляются на - кастомные дата сервисы (Go, Java).
Требования к real-time feature platform
• Поддерживает все 3 типа фичей.
• Решает проблему train/predict inconsistency - фичи для обучения и для инференса должны считаться одним и тем же образом.
• Имеет такую модель данных, API описания фичей (feature definitions) и вычислительный слой/движок(ки) чтобы мы одним и тем же образом могли описать и вычислять фичи online и offline (выводится из предыдущего) с гарантированным постоянством результатов, на Python, с интеграцией ML экосистемы.
• Поддерживать разные хранилища данных для фичей - в зависимости от типа фичи, скорость чтения/записи должны быть соответствующими.
• Типичные требования к платформе - отказоустойчивость, масштабируемость, поддержка многих пользователей с логической изоляцией.
Проблема
С существующими open-source инструментами, создание и поддержка такой системы это очень нетривиальная задача: основная проблема это скоординировать и поддерживать несколько гетерогенных (разнородных) систем (Spark + Flink + кастомные сервисы, на разных языках), при этом предоставляя удобную модель данных и API для описания вычислений, а также интеграцию с Python/ML экосистемой и гарантию консистентности результатов.
Как результат, на рынке появились облачные платформы (managed feature platforms): Tecton.ai, Fennel.ai, Chalk.ai - предоставляют нужную инфраструктуру, но ведут к зависимости от вендора (vendor lock-in).
В итоге мы имеем ситуацию, что если вы хотите сделать real-time ML у вас 2 (неидеальных) выхода:
• Облачное решение и вендор-лок.
• Построение и поддержка сложной архитектуры которая не всегда (а по опыту - никогда) поддерживает все требования описанные выше и требует больших человеко-ресурсов.
Volga
Volga ставит целью решить эту проблему. Основная задача - предоставление однородного слоя вычислений для всех типов фичей с Python-native рантаймом, удобными моделями данных и API - движка для обработки данных/вычисления фичей в режиме реального времени (Real-time Data Processing/Feature Calculation Engine), который может стать полноценной альтернативой Flink/Spark Streaming с фокусом на Python и ML и быть основой и стандартом при построении open-source аналогов платформам Tecton, Fennel, Chalk.
Забегая вперед, Volga использует акторную модель на Ray, Rust для производительности, работает на Kubernetes и многое другое (в будущих постах). Больше о проблеме и мотивации в блог посте.
Предыдущий пост кратко прошелся по Real-Time AI/ML: что это, для чего и какие инженерные области покрывает, а также выделил два основных направления в этой области: real-time feature engineering и real-time learning.
На практике, основной проблемой при создании real-time ML систем является первая часть (построение real-time feature пайплайнов) - real-time learning носит более исследовательский характер (хотя не всегда). В итоге, когда мы говорим о real-time ML, мы в первую очередь хотим создать real-time feature platform (не путать с feature store: feature platform = feature store + compute engine).
3 типа фичей по скорости вычисления (latency/freshness)
Выделим 3 основных (по требованию к задержке/скорости вычисления) типа ML фичей которые диктуют инфраструктурные потребности платформы:
• Offline Features (также Batch, Backfill)
Вычисляются в оффлайн режиме на исторических данных, используются для обучения/валидации модели. Задержка - от минут до дней. Вычисляются на (feature compute engine) - Spark.
• Online Features (также Streaming, Near-Real Time)
Вычисляются как только приходят данные (event based), используются для инференса. Задержка - от миллисекунд до секунд. Вычисляются на - Flink (иногда Spark Streaming).
• On-Demand Features (также Real-Time)
Вычисляются в момент запроса/инференса модели и зависят от данных известных только в этот момент (GPS координаты, ответы других моделей). Сюда же относим слой feature serving. Задержка - миллисекунды. Вычисляются на - кастомные дата сервисы (Go, Java).
Требования к real-time feature platform
• Поддерживает все 3 типа фичей.
• Решает проблему train/predict inconsistency - фичи для обучения и для инференса должны считаться одним и тем же образом.
• Имеет такую модель данных, API описания фичей (feature definitions) и вычислительный слой/движок(ки) чтобы мы одним и тем же образом могли описать и вычислять фичи online и offline (выводится из предыдущего) с гарантированным постоянством результатов, на Python, с интеграцией ML экосистемы.
• Поддерживать разные хранилища данных для фичей - в зависимости от типа фичи, скорость чтения/записи должны быть соответствующими.
• Типичные требования к платформе - отказоустойчивость, масштабируемость, поддержка многих пользователей с логической изоляцией.
Проблема
С существующими open-source инструментами, создание и поддержка такой системы это очень нетривиальная задача: основная проблема это скоординировать и поддерживать несколько гетерогенных (разнородных) систем (Spark + Flink + кастомные сервисы, на разных языках), при этом предоставляя удобную модель данных и API для описания вычислений, а также интеграцию с Python/ML экосистемой и гарантию консистентности результатов.
Как результат, на рынке появились облачные платформы (managed feature platforms): Tecton.ai, Fennel.ai, Chalk.ai - предоставляют нужную инфраструктуру, но ведут к зависимости от вендора (vendor lock-in).
В итоге мы имеем ситуацию, что если вы хотите сделать real-time ML у вас 2 (неидеальных) выхода:
• Облачное решение и вендор-лок.
• Построение и поддержка сложной архитектуры которая не всегда (а по опыту - никогда) поддерживает все требования описанные выше и требует больших человеко-ресурсов.
Volga
Volga ставит целью решить эту проблему. Основная задача - предоставление однородного слоя вычислений для всех типов фичей с Python-native рантаймом, удобными моделями данных и API - движка для обработки данных/вычисления фичей в режиме реального времени (Real-time Data Processing/Feature Calculation Engine), который может стать полноценной альтернативой Flink/Spark Streaming с фокусом на Python и ML и быть основой и стандартом при построении open-source аналогов платформам Tecton, Fennel, Chalk.
Забегая вперед, Volga использует акторную модель на Ray, Rust для производительности, работает на Kubernetes и многое другое (в будущих постах). Больше о проблеме и мотивации в блог посте.
GitHub
GitHub - volga-project/volga: Real-time data processing/feature engineering tailored for modern AI/ML systems.
Real-time data processing/feature engineering tailored for modern AI/ML systems. - volga-project/volga
❤1
TikTok's Monolith и почему рекомендации без реал-тайма - прошлый век
Прочитал знаменитый пейпер от тик тока про их рекомендательную систему Monolith (кстати именно из-за таких систем от тиктока, инстаграма и т.д. очень сложно оторваться), которая использует online (real-time) learning, хочу сделать небольшую выжимку: это один из самых сильных примеров в индустрии по тематике канала и real-time ML infra (детали, нерелевантные нашей тематике, буду опускать).
Пост довольно технический (уровень - продвинутый) - кому детали неинтересны, можете сразу идти в конец к результатам.
Training Pipeline (обучение)
Модель (без точных деталей) - распределенная нейронная сеть (deep learning) размером в несколько терабайт in-memory. Используют распределенное обучение с Parameter Servers: PS хранят веса модели в памяти, Training Workers (TW) читают их и обучающие данные, вычисляют градиенты (forward and backward pass) и обновляют веса назад в PS (критерий остановки не указан). Обучение всей модели идет в два этапа: в начале на исторических данных (batch), затем, после деплоя, динамически до-обучается используя фидбэк от пользователей (online): feature pipeline (ниже) динамически генерирует обучающие данные из пользовательских сигналов (click, like, etc.) и фичей, TW продолжают использовать эти данные для обновления весов которые потом используются для инференса (ниже).
Feature/Training Data Pipeline (вычисление фичей и обучающих данных)
Сама логика фичей не указана (написано categorial, видимо как в рек системах какие-то атрибуты постов+пользователей), сырые фичи кодируют в эмбедиинги (с определенными проблемами специфичными для размеров данных в тиктоке - опустим). Основное требование к пайплайну - batch и online данные для обучения должны вычисляться одинаково, что достигается с помощью использования Flink: он, по айди запроса (от пользователя к тиктоку в котнексте которого происходит рекомендация), делает join (online или batch в зависимости от контекста) пользовательских сигналов и фичей-эмбедингов, образуя размеченные данные для обучения и передает результат в Kafka (для online) или HDFS (offline), откуда TWs потом его достают.
Inference
Полная архитектура инференс системы не указана, ключевой момент: PS делятся на два типа - для обучения (Training PS) и для инференса (Serving PS), первые периодически обновляют веса вторым, что и дает эффект real-time. Процесс синхронизации не совсем тривиальный из-за большого объема данных (пропустим), важный момент по их экспериментам: частота синхронизации весов должна быть в минутах (для sparse фичей, dense - часы).
Результаты
Измеряли эффективность предсказания Click-Through Rate на пост (CTR) в зависимости от sync interval между TS и PS (как быстро фидбэк от пользователя доходит до модели):
>We discovered that a higher parameter synchronization frequency is always conducive to improving online serving AUC
>Models with smaller parameter synchronization interval performs better that those with larger interval
>18.081% AUC Improvement of Online Training over Batch Training
Таким образом, чем чаще система синхронизирует веса модели на основе фидбэка, тем больше улучшение, доходя до 18% по сравнению с batch/offline-only.
Отличный пример того, что именно улучшение инфраструктуры, а не тюнинг модели/алгоритмов, дает колоссальный эффект, да и вообще инженерная работа вызывает уважение.
Прочитал знаменитый пейпер от тик тока про их рекомендательную систему Monolith (кстати именно из-за таких систем от тиктока, инстаграма и т.д. очень сложно оторваться), которая использует online (real-time) learning, хочу сделать небольшую выжимку: это один из самых сильных примеров в индустрии по тематике канала и real-time ML infra (детали, нерелевантные нашей тематике, буду опускать).
Пост довольно технический (уровень - продвинутый) - кому детали неинтересны, можете сразу идти в конец к результатам.
Training Pipeline (обучение)
Модель (без точных деталей) - распределенная нейронная сеть (deep learning) размером в несколько терабайт in-memory. Используют распределенное обучение с Parameter Servers: PS хранят веса модели в памяти, Training Workers (TW) читают их и обучающие данные, вычисляют градиенты (forward and backward pass) и обновляют веса назад в PS (критерий остановки не указан). Обучение всей модели идет в два этапа: в начале на исторических данных (batch), затем, после деплоя, динамически до-обучается используя фидбэк от пользователей (online): feature pipeline (ниже) динамически генерирует обучающие данные из пользовательских сигналов (click, like, etc.) и фичей, TW продолжают использовать эти данные для обновления весов которые потом используются для инференса (ниже).
Feature/Training Data Pipeline (вычисление фичей и обучающих данных)
Сама логика фичей не указана (написано categorial, видимо как в рек системах какие-то атрибуты постов+пользователей), сырые фичи кодируют в эмбедиинги (с определенными проблемами специфичными для размеров данных в тиктоке - опустим). Основное требование к пайплайну - batch и online данные для обучения должны вычисляться одинаково, что достигается с помощью использования Flink: он, по айди запроса (от пользователя к тиктоку в котнексте которого происходит рекомендация), делает join (online или batch в зависимости от контекста) пользовательских сигналов и фичей-эмбедингов, образуя размеченные данные для обучения и передает результат в Kafka (для online) или HDFS (offline), откуда TWs потом его достают.
Inference
Полная архитектура инференс системы не указана, ключевой момент: PS делятся на два типа - для обучения (Training PS) и для инференса (Serving PS), первые периодически обновляют веса вторым, что и дает эффект real-time. Процесс синхронизации не совсем тривиальный из-за большого объема данных (пропустим), важный момент по их экспериментам: частота синхронизации весов должна быть в минутах (для sparse фичей, dense - часы).
Результаты
Измеряли эффективность предсказания Click-Through Rate на пост (CTR) в зависимости от sync interval между TS и PS (как быстро фидбэк от пользователя доходит до модели):
>We discovered that a higher parameter synchronization frequency is always conducive to improving online serving AUC
>Models with smaller parameter synchronization interval performs better that those with larger interval
>18.081% AUC Improvement of Online Training over Batch Training
Таким образом, чем чаще система синхронизирует веса модели на основе фидбэка, тем больше улучшение, доходя до 18% по сравнению с batch/offline-only.
Отличный пример того, что именно улучшение инфраструктуры, а не тюнинг модели/алгоритмов, дает колоссальный эффект, да и вообще инженерная работа вызывает уважение.
🔥2
Spade - real-time анти-фрод на динамических графах в Grab
Прочитал пейпер про алгоритм Spade, используемый для fraud detection в Grab (южно-азиатский убер). Статья не про ML или инфрастуктуру, однако полезно для общего кругозора в real-time fraud-detection: проблема актуальна для e-com, ride/food-tech платформ и т.д. Основной топик - алгоритмы поиска на графах.
Типы фрода
• customer-merchant collusion - продавец и покупатель сговариваются, делают много фиктивных транзакций, получают бенефит от системы бонусов.
• deal-hunter - группа покупателей, ищущих промоушены/бонусы предназначенные для маленького числа покупателей, и, за счет скорости, выжимающих их в убыток продавцу/платформе.
• click-farming - продавец нанимает ботов-покупателей, которые делают много фиктивных заказов с целью повысить рейтинг/популярность продавца.
Текущее решение
Нахождение вышеперечисленных сценариев сводится к проблеме поиска "плотных" подграфов в графе (dense subgraphs).
Строится граф транзакций между продавцами и покупателями, вводится метрика "плотности"/density (определяется произвольной функцией от значений вершин графа и/или весов ребер). На практике, density function определяет "подозрительность" подграфа (точных эвристик нет). Как только подграф найден - передается дальше в фрод пайплайн на ревью к людям (ML нет, хотя может просто упрощенно описали).
Проблема
Существующие алгоритмы поиска плотных подграфов (graph peeling algorithms) работают на статических графах, в риал-тайме граф постоянно меняется. В масштабе граба - 6 миллионов вершин и 25 млн ребер - существующие алгоритмы занимают по 30 секунд, за это время система пропускает много плохих транзакций.
>During the time period T1 T2 there are 720 potential fraudulent transactions generated
Решение
Предлагают новый фреймворк Spade, предназначенный для инкрементализации существующих алгоритмов поиска (т.е. при добавлении новых ребер алгоритм не пересчитывает все заново, а только обновляет релевантные результаты), с помощью его API можно добавлять кастомные suspiciousness ("подозрительность") метрики и запускать сущетсвующие алгоритмы с сильным ускорением - дает разработчикам возможность покрывать много фрод сценариев в условиях риал-тайма.
В детали алгоритма не вдавался - не распределенный, запускается на одной машине.
Результаты
>Our experiments show that Spade speeds up fraud detection up to 6 orders of magnitude and up to 88.34% fraud activities can be prevented
• ускорение пайплайна на 6 порядков (с секунд до микросекунд)
• улучшение точности fraud detection не показано, просто up to 88.34%
Было бы интересно посмотреть как это можно встроить в ML, например генерировать новые фичи на основе плотных подграфов.
Прочитал пейпер про алгоритм Spade, используемый для fraud detection в Grab (южно-азиатский убер). Статья не про ML или инфрастуктуру, однако полезно для общего кругозора в real-time fraud-detection: проблема актуальна для e-com, ride/food-tech платформ и т.д. Основной топик - алгоритмы поиска на графах.
Типы фрода
• customer-merchant collusion - продавец и покупатель сговариваются, делают много фиктивных транзакций, получают бенефит от системы бонусов.
• deal-hunter - группа покупателей, ищущих промоушены/бонусы предназначенные для маленького числа покупателей, и, за счет скорости, выжимающих их в убыток продавцу/платформе.
• click-farming - продавец нанимает ботов-покупателей, которые делают много фиктивных заказов с целью повысить рейтинг/популярность продавца.
Текущее решение
Нахождение вышеперечисленных сценариев сводится к проблеме поиска "плотных" подграфов в графе (dense subgraphs).
Строится граф транзакций между продавцами и покупателями, вводится метрика "плотности"/density (определяется произвольной функцией от значений вершин графа и/или весов ребер). На практике, density function определяет "подозрительность" подграфа (точных эвристик нет). Как только подграф найден - передается дальше в фрод пайплайн на ревью к людям (ML нет, хотя может просто упрощенно описали).
Проблема
Существующие алгоритмы поиска плотных подграфов (graph peeling algorithms) работают на статических графах, в риал-тайме граф постоянно меняется. В масштабе граба - 6 миллионов вершин и 25 млн ребер - существующие алгоритмы занимают по 30 секунд, за это время система пропускает много плохих транзакций.
>During the time period T1 T2 there are 720 potential fraudulent transactions generated
Решение
Предлагают новый фреймворк Spade, предназначенный для инкрементализации существующих алгоритмов поиска (т.е. при добавлении новых ребер алгоритм не пересчитывает все заново, а только обновляет релевантные результаты), с помощью его API можно добавлять кастомные suspiciousness ("подозрительность") метрики и запускать сущетсвующие алгоритмы с сильным ускорением - дает разработчикам возможность покрывать много фрод сценариев в условиях риал-тайма.
В детали алгоритма не вдавался - не распределенный, запускается на одной машине.
Результаты
>Our experiments show that Spade speeds up fraud detection up to 6 orders of magnitude and up to 88.34% fraud activities can be prevented
• ускорение пайплайна на 6 порядков (с секунд до микросекунд)
• улучшение точности fraud detection не показано, просто up to 88.34%
Было бы интересно посмотреть как это можно встроить в ML, например генерировать новые фичи на основе плотных подграфов.
Написал пост в основной блог про On-Demand Compute Layer в Волге - один из двух ключевых компонентов системы. В посте обзор что такое on-demand фичи в real-time ML системах, для чего они, как используются, а так же технические детали про архитектуру, API и т.д. Рад фидбэку!
https://volgaai.substack.com/p/volga-on-demand-compute-in-real-time
https://volgaai.substack.com/p/volga-on-demand-compute-in-real-time
Substack
Volga - On-Demand Compute in Real-Time AI/ML - Overview and Architecture
Exploring use cases and architecture for Volga's On-Demand Compute Layer
🔥1
Forwarded from Nafig
An extremely interesting project for offline/realtime data processing with Ray:
https://github.com/volga-project/volga
I am building very similar systems at work. Might take some inspiration from them.
https://github.com/volga-project/volga
I am building very similar systems at work. Might take some inspiration from them.
GitHub
GitHub - volga-project/volga: Real-time data processing/feature engineering tailored for modern AI/ML systems.
Real-time data processing/feature engineering tailored for modern AI/ML systems. - volga-project/volga
👍2
Второй пост про On-Demand Compute Layer в Волге c акцентом на произовдительность и цифры в условиях, приближенных к реальному использованию. Запускаем на EKS и Ray, храним данные в Redis, создаем нагрузку в Locust.
https://volgaai.substack.com/p/benchmarking-volgas-on-demand-compute
https://volgaai.substack.com/p/benchmarking-volgas-on-demand-compute
Substack
Benchmarking Volga’s On-Demand Compute Layer for Feature Serving: Latency, RPS, and Scalability on EKS
Evaluating system performance and horizontal scalability using EKS, Ray, Locust, and Redis under real-world conditions.
👍4🔥1
Поучаствовал в MLечном пути 2025 от Selectel в секции pitch - Volga заняла 2е место! Спасибо организаторам и фотографу за отличный кадр.
https://selectel.ru/blog/mlpathway/
https://selectel.ru/blog/mlpathway/
👍5❤3🔥1
Выступил на DataFest 2025 в секции Open-Source. В докладе обзор проблем, связанных с инфраструктурой для real-time обработки данных в общем и для AI/ML в частности, архитектуры и производительности Volga, a так же существующих open-source (Flink, Spark Streaming, Chronon) и open-core (Feldera, Arroyo, RisingWave, ByteWax) систем.
YouTube
Андрей Новицкий | Volga: движок для обработки real-time данных с фокусом на AI/ML системы
Спикер: Андрей Новицкий, Независимый разработчик, Volga
Data Fest 2025, Cекция Open Source: https://ods.ai/tracks/df25-opensource
Тезис: Построение систем искусственного интеллекта и машинного обучения (AI/ML), работающих в режиме реального времени - непростая…
Data Fest 2025, Cекция Open Source: https://ods.ai/tracks/df25-opensource
Тезис: Построение систем искусственного интеллекта и машинного обучения (AI/ML), работающих в режиме реального времени - непростая…
👍4🔥3
Volga теперь на 100% Rust! 🦀
Завершил миграцию движка с Ray+Python на Rust и существенно переработал архитектуру, вдохновляясь идеями OpenMLDB и Chronon.
Что под капотом сейчас:
• SQL-пайплайны: полная поддержка через Apache DataFusion.
• Формат данных: нативный Apache Arrow.
• Консистентные streaming+batch вычисления через Dataflow модель и watermarks.
• Remote State: удаленное хранение состояния с помощью SlateDB (LSM-дерево поверх S3).
• Сервинг данных через Request Mode и queryable state без необходимости в отдельном сервисе и KV хранилище.
• ML-ориентированный SQL: специфические функции для фич-инжиниринга (top, _cate, _cate_where).
• Производительность: оптимизация длинных оконных агрегаций через Tiling.
В статье — технические детали, разбор архитектуры и сравнение с Flink, Spark, Arroyo, Chronon и OpenMLDB.
https://volgaai.substack.com/p/volga-a-rust-rewrite-of-a-real-time
Завершил миграцию движка с Ray+Python на Rust и существенно переработал архитектуру, вдохновляясь идеями OpenMLDB и Chronon.
Что под капотом сейчас:
• SQL-пайплайны: полная поддержка через Apache DataFusion.
• Формат данных: нативный Apache Arrow.
• Консистентные streaming+batch вычисления через Dataflow модель и watermarks.
• Remote State: удаленное хранение состояния с помощью SlateDB (LSM-дерево поверх S3).
• Сервинг данных через Request Mode и queryable state без необходимости в отдельном сервисе и KV хранилище.
• ML-ориентированный SQL: специфические функции для фич-инжиниринга (top, _cate, _cate_where).
• Производительность: оптимизация длинных оконных агрегаций через Tiling.
В статье — технические детали, разбор архитектуры и сравнение с Flink, Spark, Arroyo, Chronon и OpenMLDB.
https://volgaai.substack.com/p/volga-a-rust-rewrite-of-a-real-time
Substack
Volga: A Rust Rewrite of a Real-Time AI/ML Data Engine (DataFusion, Arrow, SlateDB) with a Chronon + OpenMLDB–Style Architecture
Rewriting Volga in Rust with DataFusion, Arrow, and SlateDB — combining ideas from Chronon and OpenMLDB, and comparing with streaming engines like Flink, Spark, and Arroyo.
❤2
Как выглядят современные движки обработки данных, если изначально проектировать их под AI/ML-нагрузки, а не как general-purpose решения?
На Хабре вышла подробная статья про Volga.
Разобрали:
— мотивацию и историю разработки (от Python к Rust)
— архитектуру и ключевые технические решения
— сравнение с general-purpose системами (Flink, Spark, Arroyo)
— сравнение с AI/ML-нишевыми решениями (Chronon, OpenMLDB)
Если вам интересны системы обработки данных, стриминговые и батч-движки и их применение в AI/ML — приглашаю к прочтению.
https://habr.com/ru/articles/1021290/
На Хабре вышла подробная статья про Volga.
Разобрали:
— мотивацию и историю разработки (от Python к Rust)
— архитектуру и ключевые технические решения
— сравнение с general-purpose системами (Flink, Spark, Arroyo)
— сравнение с AI/ML-нишевыми решениями (Chronon, OpenMLDB)
Если вам интересны системы обработки данных, стриминговые и батч-движки и их применение в AI/ML — приглашаю к прочтению.
https://habr.com/ru/articles/1021290/
Хабр
Volga: движок обработки real-time данных для AI/ML — аналог Spark и Flink на Rust (Arrow + DataFusion)
TL;DR Volga — open-source движок обработки данных, созданный как альтернатива Apache Spark и Apache Flink и ориентированный на требования real-time AI/ML систем: консистентное вычисление фичей между...
❤1