AWS based risk engine (part 1)

Наконец-то с коллегами осуществили вывод в прод написанного за 5 месяцев с нуля risk engine (не знаю точного перевода на русский, но среди русскоговорящих коллег мы называем это “риск-движок”) для нигерийского финтеха.

Что это такое и для чего нужно?
Risk engine - это совокупность скоринговых моделей, антифрод моделей и правил (они называются policies или по-нашему “политики”), которые в определенной последовательности обрабатывают заявки клиентов на выдачу кредитов и принимают решение о выдаче, а также сроке и процентной ставке, если решение о выдаче положительное.

Как это работает?
Клиент отправляет заявку на кредит через мобильное приложение или сайт, по предоставленной клиентом информации запрашивается его кредитная история из БКИ, обогащается данными с его мобильного устройства, дополнительно запрашиваются данные из баз о мошенниках и из прочих источников. Все эти данные идут на вход риск-движка. Сначала он поочередно опрашивает антифрод модели, которые определяют вероятность мошенничества, затем скоринговые модели, которые прогнозируют вероятность невозврата кредита. Ответы от моделей используются политиками (которые представляют собой около сотни правил вроде “если возраст < 25 лет, то ставку нужно поднять” и т.д.) для принятия решения о выдаче. Решение отдается в бэкенд, и далее уже запускается механизм выдачи кредита или информирования об отказе.

Как это работало до нас?
Использовалась кастомная платформа (примеры: раз, два). Они все как один заявляют, что если вы дадите им ведро денег, то они вам все настроят один раз, а дальше вы будете как в зерокодинге соединять квадратики стрелочками, ничего программировать не надо, и никакие дорогостоящие инженеры вам не понадобятся! Как оно оказалось на самом деле? Комментировать особо не стану, легко можно догадаться, что почти так же, как и с зерокодингом:) Упомяну лишь, что задеплоить простой логрег на десяток фичей занимало до 2 недель. Зато без дорогих инженеров!

AWS based risk engine (part 2)

Что сделали?

- За основу взяли AWS Step functions (SF), на которые идеально ложится логика работы движка, по сути это граф или блок-схема, состоящая из логических блоков. Словами эти блоки можно описать так:
Возьми входной джейсон. Если такая заявка уже была, то сходи в S3 за ее логами и верни как ответ. Если нет, то вызови скоринговую модель, затем антифрод модель передай ответы в политики. Выполни цепочку из политик (последняя из них собирает решения всех предыдущих блоков и принимает решение). Залогируй ответ и отдай его бэкенду.

- Каждый блок SF может быть lambda (политики и простые модели), sagemaker endpoint (модели посложнее), внешнее API (запросы внешних данных) или тоже SF, которые в свою очередь состоят из аналогичных элементов.

- На этапе прототипирования, когда нужно было доказать руководству жизнеспособность этого решения, эти блоки создавались вручную через AWS консоль. Но, понятное дело, что далеко так не уйдешь. Поэтому для промышленного решения после одобрения все блоки прописывали в CloudFormation (амазоновский аналог Terraform), для создания однотипных блоков вроде лямбд взяли jinja, настроили CI/CD и тесты.

AWS based risk engine (part 3)

Результаты?

- Сокращение инфраструктурных затрат почти в 20 раз! Serverless решает, когда вам не нужно что-то эдакое, где AWS упирается в потолок возможностей.
- Выкатка новой модели - 1 час вместо недели. Да, для этого нужен дорогостоящий инженер. Но зато только один, и платить нужно только за один его час, а не за неделю:)
- Возможность мгновенно развернуть несколько независимых контуров (по сути копий движка), обычно это dev, stage, prod.
- Возможности масштабирования, задеплоить можно хоть сотню моделей
- Тесты, которые спасают от сердечных приступов при выкатке в прод

Недостатки есть?

Конечно, я же не продаю вам коробочки со стрелками за ведро денег :)

- AWS Step functions имеет лимит на размер входного джейсона в 256Кб, что не так уж много, поэтому много данных передать таким способом не получится.
- Пока не знаем, как подружить Grafana с CloudWatch (это встроенный сервис логирования в AWS), а мониторинг очень нужен. Ну и встроенный в Sagemaker мониторинг моделей уж очень убогий.
- Графы в Step functions описываются своим собственным языком, который очень далек от идеала и можно провести часы, роясь в доке, чтобы вкурить, что не так. И да, ChatGPT вам тут не сильно поможет, т.к. на этом языке не так много всего в мире написано.

Скоро выложим статью с подробностями.

Любопытная статья (сорри, пэйволл) про добавление монотонных ограничений в бустинговые модели. Показан пример с ценами на недвижку, где по балльной оценке ее "состояния" от 1 до 10 и цене, за которую ее агентство изначально покупало, строится модель оценки цены, за которую ее можно перепродать. Логично, что конечная цена должна монотонно зависеть и от начальной цены и от состояния, но из-за шума в данных и небольшой выборки эти правила могут нарушаться при обучении модели. Тогда можно добавить искусственные ограничения на монотонность, что при фикс начальной цене, конечная цена монотонно растет при росте начальной цены, что звучит вплоне логично. Т.е. мы как бы искуственно добавляем наши доменные знания в модель, которые она может и не "добыть" исключительно из данных, если их немного и/или они некачественные.

Другой пример, с которым лично столкнулся недавно. В кредитном скоринге обычно участвует доход заемщика (опустим сейчас детали, как именно он может быть получен, когда заемщик в анкете врет). Модель показала, что с ростом доходов надежность заемщика сначала растет, но потом неожиданно начинает снижаться, что странно. Продакт, принимающий модель, указал на эту проблему и обоснованно потребовал переделать модель так, чтобы с ростом дохода благонадежность тоже монотонно росла. Но как быть, если модель - лог рег, основанный на биннинге + WOE? Оказывается, либа для биннинга, которую недавно обсуждали, например тут, тоже так умеет! Для этого нужно поставить нужное значение параметра monotonic_trend , тогда вещ фича будет разбита на интервалы так, что средний таргет изменяется монотонно, без максимумов/минимумов где-то посередине

Вакансия (и не одна) DS в ASML

Доклад про Polars c Датафеста-2024

Женя - очень крутой лидер, именно с ним мы последние полгода делали риск-движок для нигерийского банка, о котором я упоминал выше. И, в отличие от меня, он в Нигерии прям живет, и в этом подкасте рассказывает много интересного не только про рабочие будни, но и про жизнь в этой стране, о которой мы, выходцы из стран СНГ, практически ничего не знаем.

Эксклюзивный контент!

Ищем в наш нигерийский банк DS с уклоном в риск-аналитику.

Задачи - развивать риск-движок, "пополнять" его новыми моделями, интегрировать новые истоники данных и многое другое.
Подойдет тем, кто хочет в перспективе выйти на международный рынок труда, освоить "мировые" облачные технологии (AWS) и при этом работать на удаленке из РФ. Год назад здесь не было буквально ничего, так что работать еще есть над чем, многое предстоит сделать с нуля.
Точно не подойдет, если вы привыкли, что все данные разложены по полочкам, все процессы выстроены и каждый занимается только своими задачами. Плюс много общения с нигерийцами, что требует много усилий и терпения.

Писать в личку.

Простая на первый взгляд задачка

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

по ссылке обзор развития компьютерной лингвистики от ранних моделей до трансформеров, которые появились как способ улучшить качество гугл-переводчика, расцвет ABBYY как одной из самых успешных российских ИТ-компаний, почти академическая культура физтехов внутри, «горький урок» больших данных и сгоревшие сотни миллионов долларов на амбициозную попытку построить дерево онтологий всех языков сразу (ABBYY compreno).

про мегапроект ABBYY compreno я когда-то очень давно случайно увидел статью и будучи студентом физиком, конечно, был очарован масштабом. это же такая мечта технаря в вакууме: давайте мы все тексты сведем к логическим инвариантам, соединим их стрелочками и построим граф всего языка. то есть к сущностям типа собака / стол / книга, которые не теряют своей сути при переезде между странами. тогда для перевода между языками можно будет делать преобразование в этот мета-язык и из него в еще один шаг переводить тексты в любой другой. впечатлился, посмотрел на страшные диаграммы простых предложений (скину их в комменты, зацените) и забыл об этом на долгие годы. но конечно и представить не мог, сколько копий было поломано и сколько ресурсов потрачено (получается, что впустую).

а самое забавное, что современные большие языковые модели примерно так и работают — все тексты переводят в свой мета-язык и обратно, только этот язык
1) математический (операции над текстом превращаются в операции над векторами в многомерных пространствах, писал об этом)
2) не интерпретируемый, то есть не сводимый к человеческим интуициями

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

очень рекомендую прочитать целиком: https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/

ML and LLM system design: 500 case studies to learn from

How do companies like Netflix, Airbnb, and Doordash apply AI to improve their products and processes? We put together a database of 500 case studies from 100+ companies that share practical ML use cases, including applications built with LLMs and Generative AI, and learnings from designing ML and LLM systems.

Navigation tips. You can play around with the database by filtering case studies by industry or ML use case. We added tags based on recurring themes. This is not a perfect or mutually exclusive division, but you can use the tags to quickly find:
- Generative AI use cases. Look for tags “generative AI” and “LLM” to find examples of real-world LLM applications.
- ML systems with different data types: computer vision (CV) or natural language processing (NLP).
- ML systems for specific use cases. The most popular are recommender systems, search and ranking, and fraud detection.
- We also labeled use cases where ML powers a specific user-facing "product feature": from grammatical error correction to generating outfit combinations.

Link: Site

Navigational hashtags: #armknowledgesharing #armsites
General hashtags: #mlsystemdesign #ml #systemdesign #llm

Почти в каждом deep learning-based продукте, над которым я работал, на каком-то этапе где-то сбоку появляется небольшая линейная модель, обучаемая отдельно, иногда даже на классических фичах. Она, конечно, не может решать основную сложную задачу, но внезапно сильно помогает с каким-нибудь корнеркейсом. Например:
- определять резкую смену контекста (и необходимость сбросить стейт),
- детектить потенциальные ошибки или аномалии,
- слегка уточнять результаты сложного пайплайна,
- роутить инпут между компонентами,
- заполнять недостающий параметр, если в API вдруг не приходит какое-то поле, а менять что-то на клиенте слишком дорого,
- подсвечивать потенциальные проблемы человекам in the loop.

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

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

Как LLM могут помочь в классическом ML?

По статистике, специалисты по Data Science тратят до 70% рабочего времени на этап Feature Engineering, то есть отбирают наиболее важные признаки в данных и формируют новые, более информативные, датасеты. Кажется, с этой рутинной задачей отлично справится LLM. Но нет — в итоге 64% времени уйдёт на подготовку промптов.

Исследователи предлагают новые решения проблемы, одно из них — FELIX (Feature Engineering with LLMs for Interpretability and Explainability). Всё, что нужно для получения готовых фич — сам датасет и его короткий контекст. Дальше FELIX делает следующее:

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

Метод эффективен для текстовых данных и сильно превосходит TF-IDF и трансформерные эмбеддинги от RoBERT. Если вам интересно, расскажем и о преобразовании других типов данных в новых постах!

Каюсь, лежит у меня этот плейлист запланированным для просмотра довольно давно, но только сейчас дошли руки начать смотреть. И это просто кайф! Павел Кикин на проятяжении 10 роликов рассказывает о том, как должен быть устроен нормальный ML в компании. При этом Павел сам в ML пришел из бэкэнда, а поэтому очень много про версионирование, стиль кода, документацию, управление зависимостями... Очень структурированный и полезный материал! Смотрю уже четвертое занятие - еле оторвался мини-пост написать 🙂
MLOps и production подход к ML исследованиям 2.0