Развертывание модели

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

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

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

Пример: Поиск стоковых фотографий

Рассмотрим в качестве примера сайт стоковых фотографий, таких как Shutterstock, Pexels или Pixabay, где пользователи могут искать фотографии для иллюстрации своей работы. Поиск изображений по ключевым словам может быть сложной задачей. Часто авторам приходится помечать свои изображения разными ключевыми словами. Здесь модели обнаружения объектов с машинным обучением могут помочь автоматически определить, что находится на изображении, чтобы включить текстовый поиск. Обнаружение объектов — довольно стандартная задача машинного обучения, где современные модели достигают высокого уровня точности. Точно так же вторую модель можно обучить обнаруживать общие ориентиры разных городов. Модели могут быть автоматически интегрированы на сайт стоковых фотографий в фоновом режиме для создания (скрытых или видимых) тегов для каждого изображения или могут использоваться для предложения тегов авторам при загрузке новых изображений, среди многих других вариантов дизайна. В любом случае модели будут использоваться как части внутри более крупной системы.

Функция вывода модели

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

Например, простая модель классификации, использующая два входных числовых признака в scikit Learn, так же проста в использовании, как:

>>> from sklearn.linear_model import LogisticRegression
>>> model = … # learn model or load serialized model …
>>> def infer(feature1, feature2):
>>>     return model.predict(np.array([[feature1, feature2]])

Для обнаружения объектов с помощью TensorFlow это может выглядеть так (более полный пример см. в документации по tensorflow):

>>> import tensorflow as tf
>>> detector_model = … # load serialized model…
>>> def detect_objects_in_img(path):
>>>     # load image
>>>     img = tf.image.decode_jpeg(tf.io.read_file(path), 
                                   channels=3)
>>>     converted_img = tf.image.convert_image_dtype(img,
                                  tf.float32)[tf.newaxis, …]
>>>    # make prediction
>>>     result = detector_model(converted_img)
>>>     return set(result[‘detection_class_entities’].numpy())
>>> # example use
>>> image_url = "https://upload.wikimedia.org/wikipedia/"+
                         "commons/6/60/Naxos_Taverna.jpg"
>>> downloaded_image_path = download_and_resize_image(image_url,           
                                  1280, 856, True)
>>> detect_objects_in_image(downloaded_image_path)
{b’House’, b’Chair’, b’Flower’, b’Window’, b’Tree’, b’Toy’, b’Houseplant’, b’Building’, b’Tent’, b’Coffee table’, b’Flowerpot’, b’Plant’, b’Kitchen & dining room table’, b’Umbrella’, b’Furniture’, b’Table’}

Вывод модели можно легко инкапсулировать в виде функции, которая принимает некоторые пользовательские данные и возвращает прогнозы в формате, используемом приложением.

Кодирование функций

Почти во всех настройках есть этап кодирования объекта, который берет исходные входные данные (например, изображение в формате JPEG, координаты GPS, предложение, строку из таблицы базы данных) и преобразует их в объект вектор в формате, ожидаемом моделью. Разработка признаков может быть простой, например нормализация значения, представляющего возраст человека, в диапазоне от -1 до 1, или может быть более сложной, выполняя нетривиальные преобразования, нетривиальную агрегацию данных или даже применяя другие модели с машинным обучением.

В сценарии с нашей стандартной фотографией нам нужно по крайней мере обрезать или изменить размер модели до размера, ожидаемого моделью обнаружения объектов (например, 300 x 300 пикселей), а затем преобразовать ее в вектор, представляющий три цветовых компонента каждого пикселя ( например, вектор размером 270 000 байт, представляющий три цвета 300 x 300 пикселей). В этом примере мы могли бы дополнительно (1) написать код для анализа файла изображения для метаинформации для извлечения геокоординат EXIF, если они есть, (2) использовать модель значимости для определения точек фокусировки изображения для его автоматической обрезки. перед обнаружением объекта, или (3) собрать данные о том, какие другие стоковые фотографии часто просматривали или лайкали вместе с другими стоковыми фотографиями, используя дорогостоящие запросы к большим файлам журналов или базам данных. То есть даже в нашем простом сценарии со стоковой фотографией есть несколько правдоподобных нетривиальных шагов кодирования признаков.

Если рассматривать вывод модели как компонент внутри системы, кодирование признаков может происходить с компонентом вывода модели или за него может нести ответственность клиент. То есть клиент либо предоставляет необработанные входные данные (например, файлы изображений; пунктирная рамка на рисунке выше) службе вывода, либо клиент отвечает за вычисление признаков и предоставляет вектор признаков службе вывода (пунктирная рамка). Кодирование функций и вывод модели могут быть даже двумя отдельными службами, которые последовательно вызываются клиентом. Какая альтернатива предпочтительнее, является конструктивным решением, которое может зависеть от ряда факторов, например, хранятся ли и как векторы признаков в системе, насколько дороги вычисления кодирования признаков, как часто меняется кодирование признаков, сколько моделей используют та же функция кодирования и так далее. Например, в нашем примере со стоковой фотографией наличие функции кодирования, являющейся частью службы логического вывода, удобно для клиентов и упрощает обновление модели без смены клиентов, но нам пришлось бы отправлять по сети все изображение, а не только гораздо меньший вектор признаков для уменьшенных 300 x 300 пикселей.

Кодирование функций во время обучения и логического вывода

Важно отметить, что кодирование входных данных в качестве функций одинаково для обучающих данных во время обучения и для данных логического вывода во время выполнения в рабочей среде. Использование несовместимого кодирования между обучением и выводом опасно и может привести к неправильным прогнозам, поскольку данные времени выполнения не соответствуют данным обучения. Это может варьироваться от незначительных несоответствий, таких как непоследовательное масштабирование одной функции, до полной шифровки входных данных, таких как изменение порядка кодирования цветов между временем обучения и выводом. Несогласованное кодирование между обучением и выводом известно как перекос между обучением и обслуживанием. Чтобы предотвратить эту проблему, обычной практикой является написание кода кодирования признаков в виде повторно используемой функции, которая используется как при обучении, так и во время логического вывода. Это может быть так же просто, как функция Python, импортированная как в обучающий код, так и в код логического вывода. В идеале этот код версионируется вместе с моделью (см. также главу Управление версиями, происхождение и воспроизводимость).

Магазины функций

В более крупных организациях может быть дополнительно желательно собирать и повторно использовать код для кодирования функций, чтобы его можно было повторно использовать в разных проектах. Например, нескольким моделям может потребоваться изменение размера и кодирование изображений или извлечение и кодирование координат GPS из метаданных изображения. Вместо того, чтобы несколько команд повторно реализовывали одни и те же или похожие реализации кодирования функций, может быть выгодно собрать их в центральном месте и сделать их легко обнаруживаемыми. Это особенно верно для более сложных кодировок, которые могут включать сами модели с машинным обучением, например, использование модели значимости для определения и обрезки ключевой области изображения, или кодировок, требующих нетривиальных запросов к базе данных, таких как сбор метаданных обо всех других изображениях. загружены тем же автором. Документирование различных фрагментов кода разработки функций может дополнительно помочь в их обнаружении и повторном использовании в нескольких моделях и проектах.

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

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

Существует множество конкурирующих проектов с открытым исходным кодом, таких как Feast и Tecton, и многие коммерческие платформы машинного обучения имеют встроенные хранилища функций, такие как AWS SageMaker Feature Store.

Инфраструктура обслуживания модели

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

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

Общие формы обслуживания модели

Распространены как минимум четыре схемы предложения вывода модели в системе.

Вывод модели как библиотека. В простых случаях модель и функция вывода могут быть просто встроены в целевую систему, например библиотека. Модель и функция вывода загружаются в память компонента с помощью функции и просто доступны как вызовы функций. Модель может поставляться как часть компонента или загружаться по сети. В некоторых случаях, например в мобильных приложениях, один исполняемый файл может содержать весь код приложения и модель. Существует множество библиотек, упрощающих встраивание сериализованных моделей определенных форматов, таких как TensorFlow Lite (мобильные приложения) и TensorFlow.js (развертывание в браузере на стороне клиента).

Вывод модели как услуга. Вероятно, наиболее распространенной формой развертывания модели с машинным обучением является предоставление выделенного сервера, который отвечает на сетевые клиентские запросы через REST API. Внутри сервер загружает модель в память, чтобы быстро отвечать на запросы. Как уже говорилось, служба может получать необработанные входные данные и выполнять кодирование признаков перед выводом или может напрямую получать закодированные векторы признаков в качестве входных данных. Несколько экземпляров такой службы вывода моделей можно запускать локально или в какой-либо облачной инфраструктуре для масштабирования системы, часто используя виртуализацию контейнеров.

Пакетная обработка. Если логический вывод модели выполняется для больших объемов входных данных, обычно предпочтительнее разработать рабочие процессы, которые могут выполнять логический вывод рядом с данными, используя пакетную обработку, например как задача map в среде MapReduce. Использование логических выводов в пакетной обработке позволяет избежать отправки всех данных по сетевым подключениям в службы логических выводов, а вместо этого отправляет в данные меньшие модели и код логических выводов. См. главу «Масштабирование системы» для более подробной информации.

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

Конечно, гибридные подходы для всего этого существуют.

Вывод модели как услуга в облаке

В последние годы была разработана большая инфраструктура для развертывания и масштабирования вычислений в облаке, добавления дополнительных вычислительных ресурсов по мере необходимости и согласования вычислительных потребностей с различными характеристиками оборудования (например, большой объем памяти или высокая производительность ЦП или доступный графический процессор). В частности, микросервисы и бессерверные функции являются распространенными шаблонами для развертывания вычислений в облаке, которые хорошо подходят для предоставления выведения модели как услуги.

Мы рассмотрим это более подробно в главе Масштабирование системы, но вкратце микросервис — это независимо развертываемый процесс, предоставляющий функции, которые могут вызываться другими компонентами системы по сети (обычно HTTP-запросы в стиле REST). ). Микросервис, как правило, небольшой и сосредоточен на одной функции или наборе тесно связанных функций; его можно разрабатывать независимо от других сервисов в системе, другой командой и с использованием другого стека технологий. Сервис вывода по одной модели хорошо вписывается в идею микросервисов с учетом очень небольшого объема сервиса — он предоставляет единую функцию для предсказаний. Масштабируемость достигается за счет запуска нескольких экземпляров службы за балансировщиком нагрузки; Общая инфраструктура облачных вычислений предоставляет средства для автоматического масштабирования службы путем эластичного развертывания большего или меньшего количества экземпляров в соответствии с изменяющимся спросом. Кроме того, бессерверные вычисления — это распространенный шаблон для развертывания сервисов в облаке, когда облачная инфраструктура полностью автоматически масштабирует сервис в зависимости от количества запросов.

Предлагать вывод модели как услугу с современной инфраструктурой несложно. Как правило, разработчики заключают функцию вывода модели в API, который можно вызывать удаленно, настраивают эту службу как контейнер (например, Docker) и развертывают контейнер службы на виртуальных машинах или облачных ресурсах.

Написание собственной службы вывода модели. Хотя многие фреймворки автоматизируют многие из этих шагов, полезно понять, как мы могли бы создать свою собственную: простая программа на Python может загрузить модель и реализовать функцию вывода модели. как обсуждалось выше (с кодом кодирования функций или без него, в зависимости от дизайна). Затем он может использовать библиотеку flask для приема HTTP-запросов на указанном порту и для каждого запроса запускать функцию вывода модели и возвращать результат в виде HTTP-ответа. Для нашей настройки обнаружения объектов это может выглядеть примерно так: следующий код (выполняется с помощью flask run --host 0.0.0.0 --port 4040), который создает API, в который файлы изображений могут быть отправлены с помощью почтовых запросов на http://‹ip›:4040/get_objects.

from flask import Flask, escape, request
app = Flask(__name__)
app.config['UPLOAD_FOLDER'] = '/tmp/uploads'
detector_model = … # load model…
# inference API that returns JSON with classes found in an image
@app.route(‘/get_objects’, methods=[‘POST’])
def pred():
    uploaded_img = request.files["images"]
    coverted_img = … # feature encoding of uploaded img
    result = detector_model(converted_img)
    return jsonify({"response":result['detection_class_entities']})

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

Конечно, такой API также может быть спроектирован так, чтобы делать несколько прогнозов в одном вызове, чтобы уменьшить нагрузку на сеть, связанную с отдельными вызовами. Например, клиент может отправить несколько изображений в одном запросе и получить обнаруженные объекты для всех изображений в результате.

Чтобы сделать службу переносимой, обычно ее виртуализируют в контейнере, который можно легко развернуть на разных машинах. Например, следующий Dockerfile можно использовать для виртуализации нашего простого сервера логических выводов на основе фляг:

FROM python:3.8-buster
RUN pip install uwsgi==2.0.20
RUN pip install numpy==1.22.0
RUN pip install tensorflow==2.7.0
RUN pip install flask==2.0.2
RUN pip install gunicorn==20.1.0
COPY models/model.pf /model/
COPY ./serve.py /app/main.py
WORKDIR ./app
EXPOSE 4040
CMD ["gunicorn", "-b 0.0.0.0:4040", "main:app"]

Инфраструктура для развертывания служб вывода моделей. Обслуживание моделей является распространенной проблемой, и многие настройки различных служб вывода моделей аналогичны: (1) нам нужно написать функции вывода, которые почти всегда имеют одинаковую структуру загрузка модели, возможно, вызов кодирования признаков и передача векторов признаков в модель, возвращающую результат. (2) Нам нужно написать код, который принимает запросы REST и отвечает на них, вызывая функцию вывода. (3) Нам нужно написать спецификации контейнера, чтобы обернуть все это, и нам нужно выяснить, как развертывать локально или в облаке. (4) Мы можем захотеть дополнительно инвестировать в код для мониторинга, автоматического масштабирования и A/B-тестирования. Все эти задачи довольно стандартны и повторяются, поэтому они являются хорошими кандидатами на абстракцию и автоматизацию.

Существует множество инфраструктурных проектов, которые стандартизируют и упрощают развертывание моделей без необходимости писать собственные функции вывода, код flask или файлы Docker. Например, многие поставщики облачных услуг предоставляют инфраструктуру для развертывания бессерверных функций, которые оборачивают код, написанный на языке программирования (например, Python, Go, Java, C), и оборачивают его автоматически сгенерированным кодом для обслуживания запросов через REST API внутри контейнера, обычно уже оптимизированный по пропускной способности, задержке, надежности, отслеживаемости и другим качествам.

Некоторые проекты специализируются на обслуживании моделей с машинным обучением напрямую, так что даже функция вывода будет генерироваться автоматически из метаданных, описывающих форматы ввода и вывода, без единой строки кода. Некоторые из них даже напрямую интегрируются с хранилищами моделей и службами обнаружения, которые показывают списки доступных моделей. Примеры включают BentoML (создание, развертывание службы с низким кодом, реестр моделей, информационные панели), Cortex (автоматическое развертывание и масштабирование моделей на AWS), инфраструктуру Tensorflow Обслуживание моделей TFX (высокопроизводительная структура для служб tensorflow GRPC) и Seldon Core (сервис модели без кода и много-много дополнительных сервисов для мониторинга и работы в Kubernetes). Также в этом пространстве конкурируют многие коммерческие сервисы.

Компромиссы архитектуры развертывания

Хотя техническое развертывание вывода модели как библиотеки или службы довольно просто, выбор таких вопросов, как развертывание в качестве библиотеки или службы и где развертывать, может быть нетривиальным проектным решением во многих системах, требующих компромисса между различными качествами.

Развертывание на стороне сервера против развертывания на стороне клиента

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

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

Развертывание модели на стороне сервера. Если вывод модели развернут как служба в службе, другие компоненты на сервере, а также компоненты на устройстве, обращенном к пользователю, могут выполнять прогнозы с помощью удаленных вызовов процедур.

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

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

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

Развертывание модели на стороне клиента. Кроме того, модель можно развернуть на устройстве, обращенном к клиенту, обычно в виде двоичного файла, который считывается из библиотеки, связанной с приложением.

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

Когда модели развертываются на стороне клиента, целевые устройства должны иметь достаточные вычислительные ресурсы для вывода модели; сам вывод зачастую медленнее, чем на выделенном сервере. Например, смартфоны обычно не имеют мощных графических процессоров для дорогостоящих задач вывода моделей. Если аппаратное обеспечение клиентских устройств неоднородно, например, приложения должны быть развернуты на многих разных мобильных телефонах, задержка логического вывода и взаимодействие с пользователем могут существенно различаться между пользователями, что приводит к непоследовательному взаимодействию с пользователем. Однородная среда с предсказуемой задержкой вывода обычно возможна только в том случае, если устройство, обращенное к клиенту, находится под управлением, например, в общественных киосках или беспилотных автомобилях, или если программное обеспечение работает только в избранных средах, например, только в двух поколениях умных часов одного поколения. единственный производитель. Встроенные модели также увеличивают размер загрузки и требования к хранилищу для содержащих их приложений, например, иногда существенно увеличивая размер мобильных приложений для загрузки и обновлений. Для устройств с батарейным питанием затраты энергии на вывод модели также могут быть проблемой. Для глубоких нейронных сетей с интенсивными вычислениями и памятью размер модели часто намеренно сжимается после обучения на этапе, называемом дистилляция знаний. Такие библиотеки, как Tensorflow Lite и Tensorflow.js, специально разработаны для запуска глубоких нейронных сетей на мобильных устройствах или в браузерах.

Если пользователи имеют доступ к клиентскому устройству, например, на своих настольных компьютерах или мобильных телефонах (а не в общедоступных киосках), опытные пользователи могут получить доступ к самим моделям (часто хранящимся в стандартных форматах), что может вызвать опасения по поводу интеллектуальная собственность и состязательные атаки (см. также главу «Безопасность и конфиденциальность»). Например, исследователи извлекли тысячи моделей Tensorflow, встроенных в приложения Android и веб-страницы; Имея доступ к внутренним компонентам модели, гораздо проще создавать вредоносные входные данные, чем при необходимости неоднократно проверять серверную службу вывода модели.

Развертывание гибридных моделей. Существует множество возможных схем, в которых модели развертываются как на серверах, так и на устройствах, обращенных к пользователю (или в другой сетевой инфраструктуре). Распространенным сценарием является развертывание модели меньшего размера или модели специального назначения на стороне клиента и модели большего размера на сервере, где модель меньшего размера используется во многих настройках в качестве первого шага, а модель большего размера на стороне сервера используется для более сложных задач. входы. Например, умные колонки с голосовым управлением часто имеют небольшую модель на стороне клиента для обнаружения последовательности активации, такой как «Alexa» или «Привет, Siri», и отправки последующего звука с основной командой на сервер для анализа.

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

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

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

Анализ сценариев: перевод дополненной реальности

Поскольку все вычисления выполняются на стороне сервера в сценарии со стоковыми фотографиями, давайте обсудим второй пример, в котором вычисления разбросаны по нескольким устройствам. Чтобы проиллюстрировать некоторые компромиссы и инженерные решения, необходимые в процессе проектирования систем с поддержкой машинного обучения, давайте рассмотрим нетривиальный пример развертывания моделей в сценарии трансляции дополненной реальности на умных очках. Рассмотрим следующий сценарий: вы прогуливаетесь как турист по чужой стране и испытываете трудности с навигацией, не понимая языка. Приложение для перевода на вашем телефоне помогает, и вы даже можете делать снимки, где приложение идентифицирует и переводит текст на знаках. Тем не менее, мы хотим пойти дальше и проецировать живые переводы поверх исходного текста непосредственно в смарт-очках, чтобы было удобно просматривать переведенный текст во время перемещения в реальном мире, как форму дополненной реальности.

Хотя мы не знаем о каких-либо существующих продуктах, подобных этому, ингредиенты есть. Например, Google Translate может автоматически распознавать и переводить текст на изображениях и даже выполнять перевод в реальном времени на основе живого видео, поступающего с камеры телефона, заменяя исходный текст в отснятой сцене наложенным переведенным текстом. Умные очки в настоящее время, вероятно, наиболее известны благодаря Google Glass 2013–2015 годов от Google, где видеовход записывается с камеры в очках, а изображения можно проецировать с помощью оптического дисплея, закрепленного на голове. Хотя Google Glass больше не доступны, в настоящее время несколько компаний работают над соответствующей технологией.

Наш сценарий перевода дополненной реальности немного сложнее, чем простое решение «клиент-сервер», описанное выше. В дополнение к облачному серверу и самим очкам, обращенным к пользователю, обычно очки подключаются к смартфону через Bluetooth, который обеспечивает доступ к Интернету в мобильных настройках (исходные Google Glass имели подключение через Bluetooth и Wi-Fi, но не имели мобильных данных). ).

Кроме того, система такого типа, вероятно, нуждается в нескольких моделях с машинным обучением. Среди прочего, нам, вероятно, потребуется как минимум (1) модель оптического распознавания символов (OCR), которая определяет, какой текст находится на изображении и где, (2) модель перевода для перевода распознанного текста и (3) некоторую модель отслеживания движения или модели стабилизации изображения, которая может определить, как объекты движутся в видео, чтобы мы могли перемещать переведенный текст без необходимости запускать OCR и перевод на каждый кадр видео.

Для каждой из этих трех моделей нам нужно будет принять решение о развертывании, должны ли мы развертывать ее в нашей облачной инфраструктуре, на телефоне или на самих очках?

Как и в любом обсуждении архитектуры, важно начать с понимания требований к качеству системы. Конечно, нам нужен очень точный перевод текста в видеовходах. Кроме того, нам нужно предлагать переводы относительно быстро (задержка перевода), поскольку текст появляется и исчезает из поля зрения, и нам нужно очень быстро обновлять местоположение, где отображается текст, чтобы избежать артефактов движения и кибертоски — технологическая версия укачивания, распространенная в виртуальной и дополненной реальности, возникающая, когда восприятие и движение не совпадают. Мы хотим, чтобы переводы обеспечивали приемлемое взаимодействие с пользователем офлайн или, по крайней мере, в ситуациях с медленным подключением к мобильной сети. Из соображений конфиденциальности мы не хотим постоянно отправлять отснятые видео в облако. Учитывая, что и смартфон, и очки питаются от батареи, нам необходимо учитывать потребление энергии; нам также необходимо справиться с доступными аппаратными ресурсами в умных очках и с большим разнообразием аппаратных ресурсов в смартфонах. Напротив, предположим, что нас не слишком беспокоят эксплуатационные расходы на облачные ресурсы и нам не нужны частые обновления модели (может быть достаточно ежемесячных обновлений или меньше). Телеметрия — это хорошо, но не в приоритете.

Эти требования и цели в области качества уже указывают на то, что полное развертывание модели OCR на стороне сервера вряд ли будет хорошим выбором, если только мы не пойдем на компромисс в отношении цели конфиденциальности и возможности работы в автономном режиме. В то же время низкий приоритет частоты обновлений и телеметрии позволяет нам рассматривать развертывание на стороне клиента как вероятные варианты.

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

Понимание аппаратных ограничений. Google Glass 2014 года имели 5-мегапиксельную камеру и экран с разрешением 640 x 360 пикселей, 1 ГБ оперативной памяти и 16 ГБ встроенной памяти. Тестирование производительности может выявить аппаратные возможности и энергопотребление для вывода моделей различных типов. Например, как часто мы можем запускать стандартную модель OCR изображения камеры очков на умных очках с одним зарядом аккумулятора, как часто мы можем делать это на малобюджетном смартфоне?
Понимание требований к задержке. Мы можем провести онлайн-исследование, чтобы получить приблизительное представление о том, какую задержку нам нужно обеспечить: задержка в 200 миллисекунд заметна для речевых пауз, 20 миллисекунд воспринимается как задержка видео, а 5 миллисекунд иногда упоминается как порог киберболезни для виртуальной реальности. В наших настройках дополненной реальности мы можем обойтись задержкой в 10 миллисекунд, но требуется дополнительное тестирование. Вероятно, целесообразно провести собственные тесты с простыми демонстрациями или другими приложениями на целевом оборудовании, изменив частоту обновления, чтобы проверить, что приемлемо для тестируемых пользователей, прежде чем проектировать и строить реальную систему.
Понимание сетевой задержки. В онлайн-документации показано, что ожидаемая задержка Bluetooth составляет от 40 мс до 200 мс для двусторонних сообщений. Задержка интернет-соединений (Wi-Fi или мобильные данные) может значительно различаться. Вероятно, мы можем получить хорошее представление о том, какая задержка является реалистичной в хороших и менее идеальных условиях.
Знакомство с ограничениями пропускной способности. Быстрое онлайн-исследование может показать, что Bluetooth имеет пропускную способность до 3 Мбит/с, но для потоковой передачи видео требуется от 4 до 10 Мбит/с для видео низкого и среднего качества, а неподвижные изображения имеют размер от 4 до 8 мегабайт на изображение.

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

Наш первоначальный анализ показывает, что полный анализ видеовхода на стороне сервера нереалистичен. У нас просто нет пропускной способности, а задержка, вероятно, слишком высока. В то же время нехватка ресурсов, доступных на очках, может помешать нам выполнять вывод для всех трех моделей непрерывно на очках на каждом кадре видео.

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

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

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

Вывод модели в системе

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

Разделение моделей и бизнес-логики

Разработчики систем с поддержкой ML обычно рекомендуют разделять модели и бизнес-логику внутри системы. Это согласуется с классическими подходами к проектированию систем, которые обычно стремятся разделить задачи, такие как разделение внешнего интерфейса, бизнес-логики и хранилища данных в трехуровневой архитектуре, упомянутой в главе Мыслить как архитектор программного обеспечения. Такое разделение, если оно сделано правильно, упрощает инкапсуляцию изменений и независимое развитие ключевых частей системы.

В системах с поддержкой ML разделение между моделями и бизнес-логикой, как правило, осуществляется легко, потому что компонент вывода модели естественно модульный, а код, который реализует логику, интерпретирующую предсказание модели, в первую очередь использует другую технологию, чем сама модель. Например, в сценарии стоковой фотографии компонент, отличный от службы вывода модели, должен отправить запрос модели, применить некоторые проверки санитарии или правила преобразования к извлеченным идентифицированным объектам и записать результаты в базу данных. В этом примере логика, отличная от ML, может отбросить прогнозы, обнаруживающие реку и небо в одной и той же области изображения, и может добавлять теги Питтсбург и Пенсильвания всякий раз, когда ориентир город был идентифицирован — это жестко запрограммированные правила, написанные разработчиками (знание предметной области или бизнес-правила), а не машинное обучение на основе каких-то данных. Во многих системах бизнес-логика может быть намного более сложной, чем в сценарии со стоковыми фотографиями — например, система управления запасами может автоматизировать заказы на основе текущих запасов и прогнозируемых продаж на основе некоторых написанных от руки правил; система автономного вождения может планировать рулевое управление и ускорение на основе правил, объединяющих прогнозы от нескольких компонентов с жестко запрограммированными мерами безопасности.

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

Составление нескольких моделей

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

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

Разложение проблемы, последовательное. Несколько моделей работают вместе для достижения цели, где каждая модель вносит свой вклад в свой аспект. Например, в подписях к изображениям детектор объектов может сначала обнаруживать объекты, за ними следует языковая модель, генерирующая правдоподобные предложения, а затем еще одна модель для выбора наилучшего предложения для изображения (см. пример). Как уже упоминалось, в нашем сценарии стоковой фотографии мы можем использовать модель значимости для определения точек фокусировки изображения, чтобы автоматически обрезать его до обнаружения объекта. При таком подходе мы разбиваем более сложную проблему на части, которые можно изучать независимо друг от друга, возможно, добавляя знания предметной области о том, как решить проблему, и в целом делая проблему более доступной. Для данного входа вывод нескольких моделей выполняется последовательно, где выходные данные одной модели используются в качестве входных данных для следующей. Также распространено чередование моделей с бизнес-логикой, отличной от ML, такой как написанные от руки правила и преобразования между различными моделями. Это характерно для многих подходов к автономному вождению, что видно в архитектуре Apollo, показанной ранее в главе Мыслить как архитектор программного обеспечения.

Каскадное/двухфазное прогнозирование. Несколько задач обучаются для одной и той же задачи, но вместо параллельного выполнения логического вывода, как в ансамблевых моделях, логический вывод выполняется последовательно, когда выходные данные модели определяют, выполняется ли логический вывод. на следующей модели. Это в основном используется для снижения затрат на вывод, включая затраты, связанные с отправкой запросов в облачную службу. Последовательный двухэтапный план обычно делает большинство прогнозов с помощью небольшой и быстрой модели, но часть прогнозов перенаправляется в более крупную и меньшую модель. Это особенно характерно для гибридных развертываний, когда небольшая модель развертывается на клиентском устройстве, а более крупная — в облаке. «алекса», «окей, гугл») на устройстве, после чего отправляя только выбранный звук на более крупные модели.

Документирование интерфейсов вывода модели

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

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

В традиционных программных компонентах более распространена документация по интерфейсам между компонентами (также часто называемая API). Традиционно описания интерфейса включают сигнатуру типа, а также описание функциональности функций компонента (обычно в текстовом виде, но возможны и более формальные описания пред- и постусловий). Качества традиционных программных компонентов могут быть частью описания интерфейса или описаны в соглашениях об уровне обслуживания (SLA). Например, соглашение об уровне обслуживания может характеризовать ожидаемую задержку или пропускную способность функции компонента, доступность, если она размещена как услуга, или надежность.

{
  "mid": string,
  "languageCode": string,
  "name": string,
  "score": number,
  "boundingPoly": {
    object (BoundingPoly)
  }
}

Выдержка из технической документации, часто используемой для описания интерфейса службы вывода моделей, здесь из общедоступного API обнаружения объектов Google. API описывает URL-адрес для конечной точки, аутентификацию и формат, в котором необходимо отправить запрос (объект JSON, в котором изображения представляют собой строки в кодировке base64), и то, что API будет возвращать идентифицированные объекты как объект LocalizedObjectAnnotation, показанный на этом рисунке. описание объекта, уверенности и ограничивающей рамки.

Документация по компонентам вывода модели и их атрибутам качества. В текущей практике требования модели могут обсуждаться заинтересованными сторонами, но редко документируются в явном виде. Хотя дать техническое объяснение того, как вызвать функцию или службу вывода модели, какие параметры она ожидает и что она возвращает, довольно просто, предоставить исчерпывающую документацию может быть очень сложно.

Предполагаемые варианты использования модели и ее возможности могут быть очевидны для создателя, но не для разработчика приложения, который ищет модель для поддержки конкретной задачи. Например, модель обнаружения объектов в нашем сценарии стоковой фотографии может быть предназначена ее разработчиками для обнаружения повседневных предметов, но не ориентиров, и на нее не следует полагаться для распознавания объектов, таких как оружие, в критически важных условиях. Такое описание также может способствовать обсуждению этических соображений использования модели.
Поддерживаемое целевое распределение, для которого была обучена модель, часто трудно зафиксировать и описать. Целевое распределение примерно эквивалентно предварительным условиям в традиционном программном обеспечении и спрашивает, какие входные данные поддерживаются моделью, а какие выходят за рамки. Например, должен ли детектор объектов работать со всеми типами фотографий или он ожидает, что интересующий объект будет хорошо освещен и центрирован? Он также предназначен для работы с чертежами? Обычно целевое распределение описывают краткой текстовой характеристикой или косвенно, описывая распределение обучающих данных.
Как мы обсудим в следующих главах, точность модели трудно зафиксировать и передать. Тем не менее, документация по интерфейсу должна содержать некоторое описание ожидаемой точности для сложных вариантов использования или целевых дистрибутивов. Обычно для этого требуется описание того, как оценивалась модель (особенно на основе каких данных). Это может включать в себя отдельные отчеты о точности для разных типов входных данных, например, отдельные результаты точности для модели распознавания лиц по полу, возрасту и этническим группам.
Службы логического вывода модели Задержка, пропускная способность и доступность могут быть задокументированы с помощью традиционных соглашений об уровне обслуживания, если компонент логического вывода размещается как служба. Если он предоставляется в виде библиотеки, документирование связанных со временем качеств и требований к ресурсам может предоставить пользователям полезную информацию.
Другие технические качества модели, такие как объяснимость, надежность и калибровка, должны быть задокументированы и оценены, если они доступны.
Принимая во внимание различные риски использования машинного обучения в производственной среде, которые будут обсуждаться позже, ответственные инженеры должны широко рассматривать этику и справедливость, безопасность, безопасность и, в частности, конфиденциальность. Обмен соображениями и оценками на стороне модели помогает пользователям при выработке аналогичных соображений для компонентов, использующих модель и систему в целом.

Ученые и практики предложили несколько форматов для документирования моделей. Наиболее известным, вероятно, является предложение Model Cards от группы этического ИИ Google: оно предлагает шаблон для краткого (1–2 страницы) описания моделей, включая предполагаемое использование, данные обучения и оценки, рассмотренные демографические факторы, результаты оценки с разбивкой по демографии, этические соображения и ограничения. В этом предложении особое внимание уделяется соображениям справедливости (обсуждаемым в последующих главах). Предложение FactSheets от IBM аналогичным образом рекомендует шаблон для документации модели, включая предполагаемые приложения, результаты оценки, а также вопросы безопасности, объяснимости, справедливости, безопасности и происхождения.

На момент написания этой статьи методы документирования моделей были довольно плохими. Наши собственные интервью с практиками показали, что компоненты вывода модели почти никогда не документируются в явном виде в производственных проектах внутри организаций и между ними, но трения между командами, разрабатывающими модель, и командами, использующими модель, изобилуют этим интерфейсом. Публичные API-интерфейсы для моделей, такие как модель обнаружения объектов Google, обычно документируют, как вызывать службу и какие типы данных передаются правильно, но лишь немногие API-интерфейсы предоставляют подробную информацию о других аспектах, включая предполагаемое использование, целевое распространение, оценку, надежность и этические соображения. Предложения карточка модели и информационный бюллетень для типовой документации часто обсуждаются, но очень редко принимаются — наше собственное исследование показало, что, не считая менее дюжины флагманских примеров, даже когда предложенный шаблон карты модели принят, документация часто неглубокая.

Мы считаем, что документирование моделей (и других компонентов машинного обучения) является сегодня одной из больших открытых практических задач при создании систем с поддержкой машинного обучения. Документация недооценена, но важна на этом важном этапе координации между командами. Индуктивный характер машинного обучения без четких спецификаций (см. главы Введение и Качество модели: определение правильности и соответствия) поднимает новые проблемы при описании целевых распределений и ожидаемой точности, а также множество дополнительных проблем, связанных с справедливостью, надежностью и безопасностью, которые могут сложно точно зафиксировать — если они вообще рассматривались и оценивались.

Краткое содержание

Концептуально вывод модели является простым и свободным от побочных эффектов, и, следовательно, его легко масштабировать при наличии достаточных аппаратных ресурсов. Особое внимание следует уделить управлению кодом кодирования функций, чтобы обеспечить согласованность между обучением и выводом, здесь хранилища функций предоставляют повторно используемое решение. Обертывание модели с помощью REST API и развертывание ее в качестве микросервиса на сервере или в облачной инфраструктуре концептуально просто, и было разработано большое количество инфраструктурных проектов, чтобы упростить развертывание и управление сервисом в облаке. При правильной инфраструктуре теперь можно развернуть модель с машинным обучением в качестве масштабируемой веб-службы с помощью нескольких строк кода конфигурации и одной инструкции командной строки.

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

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

Дальнейшее чтение

Подробное обсуждение различных стратегий развертывания и телеметрии, а также подходов к составлению моделей: Hulten, Geoff. «Создание интеллектуальных систем: руководство по машинному обучению.» Апресс, 2018 г.
Сообщество MLOps разработало огромное количество инструментов и инфраструктуры для простого развертывания моделей с машинным обучением. Для хорошего ознакомления см. https://ml-ops.org/ и https://github.com/visenger/awesome-mlops и https://github.com/kelvins/awesome-mlops.
В книге обсуждаются несколько распространенных решений, связанных с развертыванием, в том числе функции обслуживания без сохранения состояния, пакетное обслуживание, хранилища функций и управление версиями моделей в качестве шаблонов проектирования с иллюстративными примерами кода: Лакшманан, Валлиаппа, Сара Робинсон и Майкл Мунн. Шаблоны проектирования машинного обучения. О'Рейли Медиа, 2020.
Конкретное предложение по архитектуре для систем с поддержкой ML, включая отделение бизнес-логики от вывода модели, дополненное иллюстративным конкретным примером: Yokoyama, Haruki. «Архитектурный шаблон системы машинного обучения для повышения операционной стабильности». В 2019 г. Международная конференция IEEE по компаньону архитектуры программного обеспечения (ICSA-C), стр. 267–274. ИИЭР, 2019.
Предложения по шаблонам для документации модели: Митчелл, Маргарет, Симона Ву, Эндрю Залдивар, Паркер Барнс, Люси Вассерман, Бен Хатчинсон, Елена Спитцер, Иниолува Дебора Раджи и Тимнит Гебру. «Модельные карточки для модельных отчетов.» В материалах конференции по справедливости, подотчетности и прозрачности, стр. 220–229. 2019 г. и Арнольд, Мэтью, Рэйчел К.Э. Беллами, Майкл Хинд, Стефани Худ, Самип Мехта, Александра Мойсилович, Рави Наир, Картикеян Натесан Рамамурти, Даррелл Реймер, Александра Олтеану, Дэвид Пиорковски, Джейсон Цай и Куш Р. Варшней. «Информационные бюллетени: повышение доверия к услугам ИИ посредством деклараций о соответствии поставщиков.» Журнал исследований и разработок IBM 63, вып. 4/5 (2019): 6–1.
Интервью с поиском проблем с документацией модели на стыке команд: Нахар, Надя, Шуруи Чжоу, Грейс Льюис и Кристиан Кестнер. «Проблемы совместной работы при создании систем с поддержкой машинного обучения: общение, документация, разработка и процесс.» В материалах 44-й Международной конференции по программной инженерии (ICSE), май 2022 г.

Как и все главы, этот текст выпущен под лицензией Creative Commons 4.0 BY-SA.