Принятие решений на основе ИИ: автоматизация рекомендаций машинного обучения в критической системе
Автоматизация и машинное обучение стали модными словечками в технологической индустрии, но они предлагают больше, чем просто шумиху. Эти технологии могут революционизировать то, как мы работаем, делая задачи быстрее, эффективнее и точнее.
Автоматизация может выполнять повторяющиеся задачи, оставляя время для более сложной и творческой работы. Алгоритмы машинного обучения могут анализировать огромные объемы данных и делать прогнозы или решения, которые люди не могут принять самостоятельно.
По мере того, как компании растут и у них появляется больше клиентов, они не могут масштабироваться без этих процессов автоматизации.
Так что автоматизация - это здорово! Но как насчет проблем автоматизации? Когда все происходит так быстро и без участия человека, могут возникнуть критические ошибки. Автоматизация в критических системах может нанести большой ущерб за долю секунды.
В этой статье я расскажу о нашем пути к автоматическому применению рекомендаций машинного обучения в критической системе. Я сосредоточусь на проблемах, с которыми мы столкнулись, и на том, как мы к ним подошли.
Наш путь к самооптимизирующейся системе
Все началось два года назад. Тогда у нас была ручная система настройки оптимизации. Наши операционные пользователи использовали наше бэк-офисное приложение для применения этих конфигураций. Чтобы понять, что это за конфигурации и как они влияют на наш доход, вам сначала нужно понять, как работает решение Riskified гарантия возврата платежа.
С Riskified продавцы контролируют, какие заказы отправляются на проверку. Каждый отправленный заказ быстро анализируется нашей системой с использованием моделей машинного обучения, гибкой привязки, поведенческого анализа и других методов обнаружения мошенничества, в результате чего принимается решение «одобрить» или «отклонить». Мы подтверждаем наши утверждения гарантией. Другими словами, если вы подвергнетесь возврату платежа, связанному с мошенничеством, по одобренному нами заказу, вам будет возмещена сумма — автоматически. (*взято из блога Riskified)
Несмотря на то, что механизм принятия решений Riskified основан на машинном обучении, для оптимизации решений моделей необходимо еще многое настроить. Поскольку эти конфигурации могут иметь большое влияние на ставки «возвратных платежей» и поскольку Riskified предлагает решение с гарантией возвратных платежей, эти конфигурации могут иметь большое влияние на наш доход.Проще говоря, Другими словами, изменения в этих конфигурациях могут привести к большему количеству возвратных платежей, а большее количество возвратных платежей означает увеличение расходов.
Поскольку эти изменения конфигурации очень рискованны и напрямую влияют на доход компании, каждое изменение необходимо вносить очень осторожно. Мы использовали предварительный механизм, который включал моделирование, чтобы попытаться предсказать влияние такого изменения на систему, и изменения могли быть применены только после того, как они были рассмотрены.
Проблема заключалась в том, что это решение нельзя было масштабировать.
По мере роста Riskified требовалось больше изменений в конфигурации, и нам нужно было нанять и обучить больше людей для управления этими конфигурациями. Было очевидно, что для масштабирования нам нужно было автоматизировать эти процессы.
В этот момент мы решили начать свой путь к автоматизации. Мы знали, что это будет непросто, так как мы имели дело с рискованными изменениями, и каждая ошибка может сильно повлиять на доход компании, поэтому мы решили разделить этот путь на этапы.
Фаза первая: полуавтоматизация
Целью этого этапа было создание полуавтоматической системы. Система рекомендует изменения конфигурации, а пользователи операций Riskified могут просмотреть эти изменения и решить, применять эти изменения или нет.
Чтобы рассчитать эти рекомендации, мы сотрудничали с командой специалистов по обработке и анализу данных. Компания DS разработала алгоритм для выдачи рекомендаций. Мы использовали Apache Airflow в качестве оркестратора рабочего процесса для запуска их процесса.
Airflow — это платформа управления с открытым исходным кодом для конвейеров обработки данных, которая использует прямые ациклические графы (DAG) для управления оркестровкой рабочих процессов. Airflow имеет множество встроенных операторов, таких как операторы HTTP. Таким образом, мы могли бы легко вызвать их работу, и они могли бы вызвать нас обратно в случае успеха или неудачи. С помощью Airflow мы также можем добавить повторные попытки, если задача не удалась, и установить время ожидания для каждой задачи.
Некоторое время это работало хорошо, но по мере того, как Riskified продолжал расти, это решение было недостаточно масштабируемым, поэтому мы решили сделать следующий шаг к полностью автоматизированной системе.
Второй этап: полная автоматизация
Сложные требования к самооптимизирующейся системе
Когда дело доходит до проектирования системы, можно разделить требования на две группы:
- Функциональные требования: требования, предъявляемые конечным пользователем.
- Нефункциональные требования: требования, описывающие работу системы (например, скорость, доступность, надежность и т. д.)
Обычно нефункциональные требования являются самыми сложными. В нашем случае функциональными требованиями были:
- Система должна была иметь возможность периодически запускаться на основе некоторой конфигурации.
- Система должна была рассчитать оптимизацию конфигурации и применить эти рекомендации.
- Если что-то пошло не так, мы должны были иметь возможность быстро и легко вернуться в прежнее состояние.
Нефункциональными требованиями были:
- Нам нужно было спроектировать систему, которая не только использовалась бы для этой оптимизации конфигурации. Эта система должна была заложить основу для любых будущих процессов автоматизации.
- Нам нужно было создать масштабируемую систему, которая позволяла бы выполнять большое количество оптимизаций.
- Система должна была быть отказоустойчивой и отказоустойчивой
-отказоустойчивость означает способность системы продолжать нормально работать в случае отказа некоторых ее компонентов
– отказоустойчивость означает, сколько ошибок система может допустить. - Мониторинг и оповещения — нам нужно было иметь возможность обнаруживать неправильные рекомендации по оптимизации. Проблема здесь заключалась в том, как определить, была ли конкретная рекомендация неверной, поскольку могло пройти некоторое время, прежде чем мы увидели влияние неправильной конфигурации на наш доход. Мы также хотели иметь возможность отката в случае предупреждения.
Проектирование системы полной автоматизации
Мы решили использовать архитектуру, управляемую событиями, используя Apache Kafka, между всеми нашими службами, чтобы добиться следующего:
- Постоянство — в случае событий, если одна служба не работает, брокер может сохранять событие до тех пор, пока служба не вернется в оперативный режим для получения события. Это позволяет избежать единой точки отказа и повышает долговечность.
- Масштабируемость — мы могли бы параллельно оптимизировать процессы разных клиентов, используя разделы.
- Развязка: службам больше не нужно знать о существовании других служб, чтобы работать вместе. Если бы мы хотели переключить службу, другие службы не пострадали бы.
Мы создали 2 новых сервиса — сервис оптимизация-оркестратор и оптимизация-потребитель:
- Оптимизация-организатор будет отвечать за запуск процесса путем планирования заданий на основе некоторых конфигураций. Кроме того, он также будет отвечать за мониторинг процесса, проверку наличия сбойных или зависших процессов и повторную попытку запуска процесса в случае сбоя.
- Потребитель оптимизации будет отвечать за бизнес-логику оптимизации. Он будет отвечать за получение рекомендаций по оптимизации от DS и их применение в системе.
Мы использовали monorepo для этих сервисов. Таким образом, мы могли бы повторно использовать общий код, но по-прежнему иметь разные развертывания для каждой службы. Это всегда позволяло нам масштабироваться, если мы хотели добавить больше потребителей.
Мы решили сохранять историю каждого запуска и всех изменений в системе по двум причинам:
- В случае сбоя мы хотели иметь возможность понять, на каком шаге мы потерпели неудачу и каковы данные для этого шага. Кроме того, организатор оптимизации будет использовать эти данные для восстановления после сбоя или зависания процесса.
- В случае предупреждения служба оптимизации будет использовать эти данные для автоматического возврата системы в состояние, которое было до процесса автоматизации.
Это привело нас к использованию источников событий.
Что такое источник событий?Это альтернативный способ сохранения данных. В отличие от сохраняемости, ориентированной на состояние, при которой сохраняется только последняя версия состояния объекта, источник событий хранит каждую мутацию состояния в виде отдельной записи, называемой «событием».
Для этого мы публиковали в Kafka событие на каждом шаге со всеми соответствующими данными. Оптимизатор-оркестратор потребляет все события и сохраняет их в своей БД.
Подведение итогов
Когда вы думаете об автоматизации критически важных систем, вы должны делать это осторожно, а не просто думать о счастливом потоке. Подумайте о последствиях сбоев и о том, как спроектировать отказоустойчивую систему. Мониторинг, возврат и наблюдаемость имеют решающее значение в таких системах.
Рим не сразу строился…
Не пытайтесь сразу перейти к конечному решению. Сложные изменения проще вносить постепенно, шаг за шагом.
