В этом посте дается несколько советов, которые следует учитывать при создании модели машинного обучения, которая будет развернута в мобильном приложении или приложении Интернета вещей.
Эти советы актуальны, когда модель обучается в облаке, но логический вывод выполняется на мобильном устройстве или устройстве IoT.
Оптимизация модели
Одно из практических правил - использовать минимальное количество настраиваемых операций машинного обучения. Это дает вам большую гибкость, если вы хотите перенести свою модель на другую платформу. Кроме того, если вас не устраивает размер или производительность ваших моделей, ограничение пользовательских операций упрощает использование следующих советов.
Конвертация в TF Lite
Преобразование в TF Lite должно стать вашей первой оптимизацией. Это уменьшит его размер, значительно повысит производительность и позволит запускать вашу модель на графическом процессоре.
Ускорение GPU
Ускорение графического процессора в настоящее время является экспериментальной функцией, но в некоторых случаях может ускорить вывод на 50%. Он использует OpenGL на Android и Metal на iOS. Однако список операций с ускорением на GPU в настоящее время очень ограничен. Таким образом, в случае iOS может быть лучше преобразовать вашу модель TF Lite в CoreML.
Предварительная обработка входных данных
По моему опыту, можно использовать серверную модель для выполнения логического вывода в мобильном приложении. Мне удалось запустить приложения без сбоев, и я обнаружил, что они достаточно быстрые. К сожалению, прогнозы часто были довольно плохими. Дальнейшее расследование показало, что серверный код выполняет предварительную обработку данных совершенно другим способом.
Благодаря этому мы поняли, что использование правильных техник предварительной обработки наиболее существенно влияет на конечный результат. При запуске логического вывода на устройстве очень важно выполнить те же шаги, что и при обучении модели - период. Таким образом, вы должны убедиться, что шаги предварительной обработки, используемые для обучения, воспроизводимы на платформе, на которой вы хотите запустить модель. Другими словами, ограничьтесь пересечением функций, доступных на всех целевых платформах.
Предварительная обработка изображений
Давайте посмотрим на наиболее важные этапы предварительной обработки изображений, которые могут повлиять на ваши прогнозы.
Выравнивание сильно влияет на результат, особенно если модель - это модель, основанная на внимании, которая ищет определенное значение, найденное непосредственно на изображении.
Цвет заливки фона может повлиять на результаты, поскольку он может отвлекать внимание модели от важных частей изображения. Раньше это была хорошо известная ошибка (или это была особенность?) Старых версий Tesseract OCR.
Ротация определенно является проблемой, если ее не учитывает обученная модель. Имейте в виду, что обучение модели игнорированию вращения может привести к созданию более крупных моделей. Несмотря на размер, я настоятельно рекомендую добавить к вашей модели обработку поворота как минимум на ± 10 °, даже если вы решите не поддерживать вращение. На мобильном устройстве / устройстве IoT можно добиться поворота на 0 °, но это может быть дорогостоящим.
Обработка соотношения сторон должна быть точно такой же, как и серверная, иначе модели будет сложно распознать формы, для которых она была обучена. Тем не менее, если вы знаете, что ваша модель обучена квадратному размеру (например, 16 x 16 пикселей) и вы обнаруживаете прямоугольный шрифт (например, 28 x 14), вы можете просто попытаться сжать изображение, чтобы получить больше «квадратных» шрифтов. Это особенно хорошо работает с Google Mobile Vision и ML Kit Vision. Следующим шагом должно быть рассмотрение добавления шрифта к шрифтам, поддерживаемым вашей моделью.
Изменение размера изображения - это самостоятельная алхимия. Любое масштабирование изображения приводит к появлению новых артефактов в исходном изображении. Вам следует избегать изменения размера изображений, если это возможно. Например, вы можете реализовать алгоритм «скользящего окна». Примером такой разницы является использование билинейного алгоритма против бикубического и алгоритма Ланцоша. В то время как билинейный имеет тенденцию создавать «ступеньки» по краям, бикубический просто все размывает, а Ланцош сохраняет края относительно резкими, но создает «точки» по некоторым краям.
Алгоритмы сжатия - еще один источник артефактов изображения, с которым нам нужно бороться. Артефакты, созданные при уровне сжатия JPEG 60%, отличаются от артефактов, созданных при уровне сжатия 80% или 95%. Таким образом, если модель, обученная на уровне сжатия JPEG 80%, начнет получать изображения с уровнем сжатия JPEG / WebP 60% или 95%, точность прогнозирования снизится.
Цветовое пространство особенно важно, если модель обучается на одноканальных изображениях. Например: Наша первоначальная наивная реализация просто взяла зеленый канал изображения, что, очевидно, привело к очень низкой точности прогнозов. Позже я обнаружил, что нам нужно преобразовать входной RGB в оттенки серого. Это выявило еще одну проблему, поскольку «классическое» преобразование из RGB в оттенки серого на самом деле не такое уж «классическое». Даже GIMP имеет 3 алгоритма (яркость, среднее значение, яркость), которые позволяют преобразовывать изображения в зависимости от личных предпочтений.
Приложение алгоритма перекоса или перекоса должно быть точно таким же. В противном случае вы рискуете ошибиться при обнаружении объекта / классификации при сохранении очень высоких результатов оценки достоверности. Этот шаг обычно проще, если модель уже создана с некоторой терпимостью к неправильному соотношению сторон и перекосу.
Предварительная обработка текста
Предварительная обработка текста может быть особенно сложной для воспроизведения. Вам нужно быть очень осторожным, когда вы используете какие-либо библиотеки для замены синонимов или ансамблей слов. Библиотеки замены синонимов, как правило, имеют разное качество в зависимости от языка, и их довольно сложно переносить между платформами. Вы можете обойти это с помощью Word2Vec, но это приведет к необходимости обучения дополнительной модели.
Я также видел еще один «трюк», позволяющий обойти эту проблему, используя простую буквенно-цифровую карту. Этот подход работает, но может быть сложнее настроить модель для большей точности.
Оптимизация стиля кодирования
Такой подход позволяет сэкономить время обработки. Наиболее простое решение - использовать C / C ++. Это особенно полезно, если вам нужно выполнить предварительную обработку изображения. По моему личному опыту, обработка изображений в C / C ++ происходит примерно в 10 раз быстрее. Тем не менее, если вы не можете напрямую перейти с Kotlin / Swift на C / C ++, но вы можете попробовать понизить уровень до Java / Objective-C. Одно это может повысить производительность на 1-2%.
Следующий способ ускорить обработку - использовать предварительную обработку параллельного ввода при выполнении логического вывода. К сожалению, вы должны быть очень осторожны с тем, сколько потоков вы будете использовать для этого. Причина в том, что даже TF также использует распараллеливание, и поэтому чрезмерное количество запущенных потоков может действительно все замедлить. Это происходит из-за того, что больше времени тратится на переключение контекста потока, а не на обработку задачи.
Последний подход к ускорению вывода - это реализация ограниченного по времени кэширования инициализированного средства выполнения вывода. По моему опыту, первоначальная настройка и первый запуск TensorFlow может занять более чем в 2,5 раза больше времени, чем второй запуск. Таким образом, самым простым, но не очень хорошим подходом может быть инициализация TF в фоновом потоке во время запуска приложения.
Этот пост содержит несколько советов, которые я считаю полезными при обсуждении создания новой модели. Я надеюсь, что это резюме облегчит вашу жизнь, и если у вас есть несколько советов, я хотел бы их услышать.
Я хотел бы поблагодарить Роберта Рида и Эверальдо Агуи за их исправления и предложения по улучшению этого сообщения в блоге.
