Наш Sibyl API может предоставлять прогнозы ИИ с временем отклика 50 миллисекунд. Разработчик, вызывающий Sibyl API, должен указать только идентификатор объекта (например, дать мне прогноз для человека 0989k3dd84) вместо указания всех входных параметров модели. Sibyl поддерживает множество предикторов со многими версиями каждого и предлагает ученым, работающим с данными, надежный рабочий процесс для развертывания модели.

Представляем Сивиллу

Создание и производство полезной системы искусственного интеллекта включает как минимум три этапа:

  1. Подготовьте данные, на которых ИИ будет учиться. Это сложнее, чем просто направить систему ИИ на вашу базу данных, и, вероятно, потребуется, чтобы специалист по данным тщательно обрабатывал данные, чтобы максимизировать способность ИИ учиться на них. Это очень интересный и тонкий процесс, но его детали выходят за рамки данной статьи.
  2. Создайте, обучите и оцените модель. Скорее всего, специалист по данным будет тестировать разные алгоритмы и разные параметры этих алгоритмов, и на самом деле это будет итеративный процесс, взаимодействующий с шагом 1. Это, опять же, увлекательная тема, но это следующий шаг, на котором Сивилла сосредоточится. и которые мы опишем в этой статье.
  3. В конечном счете, Data Scientist создал полезную модель ИИ с высокой прогностической силой; теперь вам нужно развернуть эту модель, доступную для масштабного использования в ваших производственных системах. Это то, для чего предназначена Сивилла и что мы обсудим в оставшейся части этой статьи.

(Что такое ИИ?)

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

Искусственный интеллект — чрезвычайно широкая тема, охватывающая множество потенциальных подходов и приложений. Для целей этой статьи нас интересует то, что известно как машинное обучение, которое использует математические методы для анализа набора данных, чтобы «учиться» на нем и строить модель, которую можно использовать для прогнозирования на основе других, похожих. данные, не будучи специально запрограммированы для этого.

Sibyl Design Цели и успехи

При обсуждении машинного обучения термин «модель» используется в нескольких различных и контекстно-зависимых смыслах, поэтому, чтобы избежать путаницы, мы неформально определим несколько терминов, которые будем использовать ниже:

  1. «Модель» — это фактический объект Python, который был разработан и обучен специалистом по данным и предоставляет метод «прогнозирования».
  2. «Экземпляр предиктора» — это модель плюс связанные метаданные и артефакты, включая функцию препроцессора, информацию о версии/происхождении и данные, на которых проводилось обучение.
  3. «Предиктор» определяется конкретной темой и может быть реализован одной или несколькими версиями предиктора.

Так, например, у вас может быть предиктор «LTV», реализованный двумя разными «экземплярами предиктора», которые принимают разные входные данные, используют разные алгоритмы и были обучены на разных данных.

Ладно, вернемся к Сивилле. Когда мы приступили к разработке Sibyl, у нас было несколько основных целей:

  1. Развертывание Sibyl должно поддерживать множество предикторов и фактически множество версий каждого предиктора.
  2. Клиенты должны обслуживаться самой новой версией предиктора по умолчанию, но при желании должны иметь возможность запрашивать конкретную версию.
  3. Развертывание нового предиктора и/или экземпляра предиктора в рабочей среде не должно требовать обновления или повторного развертывания самой Sibyl, а только загрузки артефактов (функции препроцессора и самой модели) и метаданных.
  4. Модель и препроцессор должны быть развернуты именно в том состоянии, в котором они используются и подготовлены Data Scientist, чтобы избежать дублирования работы или внесения ошибок.
  5. В наиболее распространенном случае запрос прогнозов о существующем объекте на платформе Ro (например, участнике или плане лечения) API должен быть примерно таким же быстрым, как высокопроизводительные маркетинговые API, около 50 миллисекунд (0,05 секунды).
  6. При запросе прогноза в этом общем случае клиент должен иметь возможность идентифицировать интересующий объект с помощью идентификатора (например, UUID, используемого для его идентификации в бэкэнде Ro), а не самостоятельно собирать и вычислять параметры модели.
  7. Производственная система должна автоматически масштабироваться, чтобы поддерживать широкий спектр потенциальных рабочих нагрузок без ручного вмешательства.

Зачем строить дома?

Мы, конечно, далеко не первая организация, внедрившая ИИ, и существует множество доступных продуктов, которые призваны сделать его практически простым нажатием кнопки — подумайте о таких предложениях, как DataRobot или Amazon Sagemaker. Так почему же мы решили создать собственную систему?

Отчасти потому, что мы можем сделать это более экономично, особенно учитывая высокий спрос и использование, которое мы ожидаем от этой системы. Что еще более важно, потому что готовые системы не соответствовали бы некоторым из целей, которые мы описали выше.

Например, готовая система может не поддерживать модели управления версиями: если вы загружаете новую версию, старая становится недоступной. Вы можете обойти это с помощью именования (поместите версию в имя модели), но тогда клиенты, которым нужна новая версия, должны обновить свой код, чтобы явно запросить новую версию и адаптироваться к любым изменениям в требуемых данных.

Говоря об этом, готовая система потребует от вас передать параметры именно так, как их ожидает модель, что может включать десятки или даже сотни значений. Это значительно усложняет интеграцию, чем если бы клиент мог просто передать идентификатор. Вы снова можете обойти это, например, предоставив API, который возвращает параметры для данного объекта. Однако это добавляет некоторую задержку (ваш клиент теперь делает два запроса, один для получения параметров и один для вызова модели), и на этом этапе запуск модели самостоятельно не добавит сложности. Даже если ваш внутренний сервис только вычисляет параметры, вам все равно придется заниматься масштабированием, версионированием (через имена или отдельную концепцию) и так далее.

Что дальше?

В будущих статьях мы рассмотрим более технические аспекты реализации Sibyl и наш общий рабочий процесс для производства моделей машинного обучения.

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