Оценка базовых показателей и обеспечение правильной работы модели в производственной среде и на оборудовании.
Обучение и оптимизация модели — это не зеленый свет для развертывания в рабочей среде, даже если точность набора проверки показывает, что модель хорошо обобщается.
Перед развертыванием в рабочей среде необходимо выполнить еще 2 шага, чтобы убедиться, что ваша модель механически правильна, среды настроены правильно, потребление ресурсов соответствует вашим ожиданиям, и, что не менее важно, проверка того, что ваша модель соответствует базовая проверка или лучше, чем текущая, развернутая.
Вот где Tensorflow Extended пригодится (снова).
Оценщик
Опять же, ML Medatada является резервным хранилищем как для входных, так и для выходных данных этого предоставленного компонента Apache Beam Pipeline. Входные данные — это модель, созданная Trainer-Tuner (как мы объясняли в предыдущей статье), конфигурация метрик, предоставленная инженером, и базовая модель для проверки.
Конечно, если базовая модель не найдена (подразумевается, что это первая модель, которую когда-либо обучали и развертывали в этой системе), проверяются только минимальные значения метрик. В противном случае должны быть превышены минимальные границы, а производительность должна быть выше, чем у текущей модели.
Если все проверки пройдены, модель становится благословенной, по сути, помечается как хорошее качество прогнозирования данных логического вывода.
Настроить метрики и базовые показатели анализа модели TFX довольно просто, но мы собираемся подробно изучить это в следующей статье. А пока взгляните на следующий фрагмент:
Инфравалидатор
Это расшифровывается как Инфраструктурный валидатор. Evaluator просто проверяет качество логического вывода, и теперь пришло время убедиться, что при развертывании мы не столкнемся с серьезными ошибками конфигурации, сбоями или неожиданным большим временем логического вывода.
Есть некоторые предположения, которые делает InfraValidator:
- Чтобы выходные данные этой модели также были благословлены , требуется правильная настройка производственной среды.
- Модель должна быть в формате SavedModelFormat (если вы уже используете TFX для рабочей нагрузки конвейера, вы уже используете это) и использовать подпись
serving_default. - И он должен быть упакован для обслуживания (обслуживающая подпись, оптимизированный двоичный файл модели)
Более того, детали процесса проверки можно в определенной степени контролировать:
- Проверить в простой локальной среде Docker или выполнить тестовое развертывание в промежуточном кластере Kubernetes? Проверить с помощью Tensorflow.js или TFLite?
- Проверять только загрузку модели или выполнять некоторые демо-запросы? (Единственное, что здесь проверяется, — это что-то не работает/вылетает. Качество предсказания игнорируется — это нормально, если до этого мы использовали компонент Evaluator)
- Сколько времени допустимо время загрузки модели? 10 секунд? 30 лет? Более?
- Сколько примеров вы должны протестировать?
Это все, что вы должны учитывать. На некоторые пули легко ответить. Если вы выполняете развертывание только в TFLite или Tensorflow.js, конечно, используйте их в качестве среды проверки.
TFX называет эти конфигурации ServingSpec , RequestSpec и т. д. По сути, это классы Python, которые сериализуются в формат буфера протокола.
Вывод
Пришло время, наконец, показать миру, на что способна наша модель. Читайте о развертывании модели и обслуживании Tensorflow в следующей технической статье.
Спасибо, что дочитали до конца!
