Мотивация
В мире потребительского финансирования можно утверждать, что самая важная техническая проблема Affirm - не масштабирование или низкая задержка, а целостность данных. По своей сути система принятия решений о рисках Affirm использует алгоритм машинного обучения, который прогнозирует погашение кредита. Прогнозы алгоритма хороши ровно настолько, насколько хороши его данные, а это означает, что точность данных имеет первостепенное значение для дальнейшего успеха Affirm.
Согласованность данных между онлайн-прогнозами модели и автономным обучением модели имеет решающее значение. Если вы помните, Mars Climate Orbiter¹ был утерян, потому что одна система использовала обычные единицы, а другая - единицы СИ. Если ошибка того же типа затронет системы Affirm, в которых алгоритмы машинного обучения обучаются в долларах, а прогнозы делаются в центах, Affirm столкнется с реальной угрозой - ссудой денег, которые никогда не будут возвращены.
Чтобы обеспечить согласованность данных, команда разработчиков рисков реорганизовала свой код для работы как в интерактивном, так и в автономном режиме. Это заложило основу для системы тестирования, которая позволяет инженерам и специалистам по обработке данных увидеть, как изменения их кода повлияли бы на исторические онлайн-решения. Используя эту систему тестирования на истории, можно обнаружить коварные ошибки, влияющие на функции ввода машинного обучения и логику принятия решений о рисках, и сохранить целостность данных.
Вот как это работает.
Интернет-мир
Система тестирования, известная как Проверка рисков , стала возможной благодаря архитектуре нашей онлайн-службы управления рисками . Прежде чем мы смогли даже начать работу над системой тестирования, нам сначала нужно было реорганизовать наш онлайн-код, чтобы весь компонент риска мог работать в автономном режиме.
Онлайн-служба управления рисками в Affirm отвечает за принятие решений о рисках - принятие решения об одобрении или отклонении кредитных заявок. Типичный процесс принятия решений может включать получение кредитного отчета по сети, анализ отчета, запуск наших моделей кредитного и мошеннического машинного обучения, а также оценку бизнес-логики.
Чтобы обеспечить возможность переоценки логики принятия решений в автономном режиме, онлайн-компоненты риска разделены на службу побочного действия риска и чистую или не имеющую состояния библиотеку рисков . Служба выполняет операции ввода-вывода, такие как сетевые запросы, запросы к базе данных и удаленные вызовы процедур. Библиотека рисков не выполняет операций ввода-вывода; он содержит чистую логику, такую как анализ кредитного отчета, извлечение признаков и принятие решений по андеррайтингу. Любой из немногих побочных вызовов в библиотеке абстрагируется за интерфейсом, который имеет бесповоротную реализацию для автономного использования.
Служба генерирует необработанные данные: ответы от ввода-вывода. Примеры необработанных данных включают кредитный отчет в формате XML из запроса в агентство кредитной информации или событие погашения в кодировке JSON из удаленного вызова процедуры в нашу службу погашения. Служба управления рисками отвечает за все необработанные данные, связанные с рисками, включая кредитные отчеты, отчеты о мошенничестве и данные о выплатах.
Библиотека создает производные данные: полезные биты информации, обработанные из необработанных данных. Например, оценка FICO, полученная из кредитного отчета, является производными данными. Многие из полученных нами точек данных используются в качестве входных функций для наших алгоритмов машинного обучения. Библиотека рисков отвечает за вычисление всех производных данных, связанных с рисками, включая оценки FICO, оценки мошенничества и характеристики погашения.
Бизнес-логика риска находится над производными данными; именно код заявки определяет, следует ли утверждать ссуду. Код организован в ориентированный ациклический граф (или DAG, аналогичный дереву), в котором каждый узел возвращает «Утвердить» или «Отклонить» с указанием причины. Вы можете представить, что приложение может быть отклонено из-за того, что узел кредитоспособности получил отказ по причине низкой оценки FICO с использованием точки данных, полученных из оценки FICO. Если все узлы возвращают «Утвердить», то заявитель утверждается.
Запись состояния принятия решения в режиме онлайн. Нелегко.
Мост между миром Risk онлайн и офлайн - это наши записи о том, что произошло в Интернете. Для каждого решения о ссуде служба рисков создает и регистрирует денормализованный документ, который включает три основных записи: необработанные данные, производные данные и DAG бизнес-логики. Последнее включает окончательное решение об одобрении или отказе в выдаче ссуды. Мы называем этот документ журналом рисков.
Мы решили кодировать RiskLog в JSON, что привело к нескольким ошибкам. Наш монорепозитивный язык Python - это язык с динамической типизацией. Наш формат кодирования JSON имеет много типов неоднозначности. В совокупности эти варианты привели к ряду ошибок SerDes не только для проверки рисков, но и для автономного обучения модели машинного обучения.
Наш настраиваемый кодировщик JSON добавляет информацию о типе рядом с каждым значением данных (схема при чтении), но это было подвержено ошибкам при развитии восходящих моделей и схем. Формат двоичного кодирования, такой как Protocol Buffers или Apache Avro (оба имеют языки описания интерфейса), решил бы многие из этих проблем. Преимущества удобочитаемости JSON перевешиваются задержкой кодирования, размером кодирования и отсутствием определения схемы. В настоящее время мы находимся в процессе переноса нашего уровня кодирования на Protocol Buffers.
Для каждого решения по кредитной заявке служба управления рисками записывает RiskLog в файл на наших производственных серверах. Файлы RiskLog периодически переводятся в S3. Находясь в S3, они доступны для автономного использования с помощью проверки рисков.
Оффлайн мир
В офлайновом мире цель Risk Verification - дать инженерам и специалистам по обработке данных возможность увидеть, как изменения их кода повлияют на исторические онлайн-решения.
Это достигается путем сравнения результатов автономных вычислений ветви с их онлайн-аналогами. Для любых различий проверка должна дать разработчику представление о причинах этих различий и степени их влияния. Приложения для проверки включают регрессионное тестирование, тестирование алгоритмов машинного обучения на истории и подтверждение преднамеренных изменений решений. Например, если мы развертываем новую систему обнаружения мошенничества, проверку можно использовать для подтверждения того, что все производственные разрешения, которые должны были быть отклонены, будут отклонены.
Проверка рисков начинается, когда Jenkins, наш сервер сборки, запускает сборку проверки для каждой ветви, связанной с рисками. Поскольку каждый журнал RiskLog может быть проверен независимо, задача хорошо поддается распределению с использованием многопроцессорной обработки Python или, для больших рабочих нагрузок, Spark. Каждый рабочий загружает RiskLog из S3 и десериализует его, чтобы получить доступ к его основному содержимому: необработанным данным, производным данным и DAG бизнес-логики.
Прежде чем сравнивать онлайн и офлайн, верификация должна сгенерировать офлайновые выходные данные с использованием библиотеки рисков без сохранения состояния тестируемой ветви. В автономном режиме мы не можем подключиться к производственным конечным точкам, поэтому мы заглушаем производственные ответы с необработанными данными из RiskLog для любых сервисных вызовов, сделанных библиотекой рисков. Затем код библиотеки повторно вычисляет производные данные и повторно оценивает бизнес-логику, которая включает запуск всех моделей машинного обучения. После сравнения этих автономных выходных данных с производственными выходами из журнала рисков Risk Verification создает отчет.
Отчет собирает информацию из производных данных и различий бизнес-логики посредством агрегированного анализа. Примером анализа производных данных может быть 17 уменьшенных значений оценки FICO, что означает, что в филиале может быть ошибка анализа кредитного отчета. Аналогичным образом, анализ бизнес-логики может быть заменен 17 утверждениями на отказы, что, вероятно, было вызвано ошибкой синтаксического анализа кредитного отчета. Из этого отчета ясно, что в тестируемой ветке наблюдается регресс, который необходимо исправить.
Система проверки не делает никаких предположений о том, было ли различие намеренным или нет; вместо этого требуется подтверждение от разработчика, чтобы подтвердить, что разница действительно ожидалась. Используя интерактивный шаг ввода в Jenkins, авторы кода и рецензенты могут утвердить или отклонить отчет, что приведет к успешной или неудачной сборке.
Безопасность
В Affirm мы работаем с большим количеством конфиденциальных данных. Все производственные данные, используемые Risk Verification, ограничены узлом Jenkins, который предоставляет доступ только нескольким инженерам инфраструктуры - владелец филиала не может получить доступ к узлу Jenkins. Узел может получить доступ только к последним пакетам журналов риска, предназначенным для проверки; у него нет доступа ко всей истории RiskLogs из производственной среды. Отчет содержит только сводные различия; он не содержит PII.
Будущие улучшения
Будущие улучшения включают обновление пользовательского интерфейса с текстовых отчетов до веб-интерфейса, создание официальной поддержки профилирования производительности ветвей разработки и хранение отчетов в базе данных для специального анализа и аудита того, кто, какую логику и когда изменил. Мы также улучшаем наш уровень сериализации с помощью протокольных буферов.
Заключение
Тестирование с проверкой рисков было незаменимым инструментом для уверенного развертывания в производственной среде. Он обнаружил и предотвратил множество критических ошибок, которые могли обернуться катастрофой для кредитного бизнеса. По сравнению с аналогичными методологиями тестирования производственных данных, такими как Canary Analysis, он обнаруживает регрессии на гораздо более ранней стадии цикла разработки, что позволяет ускорить итерацию. Однако проверка рисков потребовала значительного рефакторинга онлайн-системы для разделения чистых и побочных компонентов. Наконец, тесно связав проверку рисков со службой управления рисками, мы получаем глубокое понимание того, как каждое изменение кода, связанного с рисками, влияет как на бизнес-логику, так и на производные данные.
Спасибо за чтение! Если вас интересуют новые методологии тестирования, системы принятия решений о рисках или инженерия машинного обучения в сфере потребительского финансирования, команда по разработке рисков нанимает!
Спасибо команде проверки рисков и друзьям за создание такой полезной системы: MG Chi, Fanshu Jiang, Howard Chen, Shane Moriah, Chad Lagore, Varun Gupta, Kristian Gampong, Anna Yan, James Lim, Elliot Babchick, Eli Бингхам и Махендра Махешвара.
использованная литература
Https://martinfowler.com/articles/microservices.html
¹ В Affirm существует культура конструктивного анализа ошибок, которые мы делаем (вскрытия), и извлечения уроков из них. Мы очень ценим отличный отчет, подготовленный JPL для обзора потери MCO, https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf.
