Разработка инфраструктуры для измерения точности работы нейронных сетей на ИИ-ускорителях

1.1 Разработка программы должна быть в выполнена в формате консольного приложения на языке Python.

1.2 Приложение должно быть совместимо с Python 3.5 и выше.

1.3 Приложение должно осуществлять взаимодействие с ИИ-акселераторами (Intel CPU, Intel , FPGA Arria 10 development kit,Intel® CPU, Intel® Integrated Graphics, Intel® FPGA, Intel® Movidius™ Neural Compute Stick, Intel® Neural Compute Stick 2 and Intel® Vision Accelerator Design with Intel® Movidius™ VPU) с помощью OpenVINO Python API.

1.4 Приложение должно работать под Windows 10 (x64), Ubuntu 16.04, Ubuntu 18.04

1.5 Конфигурация инструмента должна быть описана с помощью YAML-файла.

1.6 Установка приложения в пространство пользователя должна выполняться с помощью setuptools.

1.7Входной точкой в приложение должен служить консольный скрипт.

2. Пользовательские требования:

2.1 Конфигурационный файл:

2.1.1 Приложение должно принимать на вход конфигурационный файл в формате YAML

2.1.2 Конфигурационный файл должен содержать список описаний набора валидационных параметров для моделей.

2.1.3 Обязательные поля для описания параметров валидации модели:

- name - имя модели

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

- datasets - специфичная для используемого датасета информация: путь до валидационного сета и разметки для него, набор функций для препроцессинга данных и постпроцессинга результатов инференса, метрики.

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

2.1.5 Пользователь должен иметь возможность выносить наиболее часто используемые части валидационного конфига в глобальную предопределенную конфигурацию и использовать ее как параметры по-умолчанию.

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

2.1.7 Указанная пользователем конфигурация должна проверяться на валидность.

2.1.8 Все элементы конфигурационного файла, описанные в виде списков (модели, лаунчеры, препроцессоры, постпроцессоры, метрики) должны исполняться последовательно в строго определенном в конфигурационном файле порядке.



2.2 Интерфейс командной строки

2.2.1 Приложение должно принимать на вход следующие аргументы:

Обязательный аргумент - конфигурационный файл.

Опциональные:

- пути, используемые в качестве префикса для указанных в конфиге

- путь до глобальной конфигурации

- параметры для фильтрации запусков

2.2.2 Прогресс запуска должен отображаться в виде прогресс-бара или строки с количеством обработанных данных, выбирается пользователем.

2.2.3 По завершению валидации затраченное время и результаты в виде значений метрик должны быть отображены.

2.2.4 В случае, если пользователь указал значение для сравнения метрики в конфиге, приложение должно сравнить полученный результат с ожидаемым и вывести PASSED в случае успешности проверки и FAILED при наличии расхождений.

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

2.2.6 В случае расхождения результатов, информация о разнице между ожидаемым результатом и полученным должна быть отображена.

2.2.7 Вывод информации о запуске должен осуществляться в одном из 2 режимов: вывод на экран консоли и запись в лог-файл.

2.3 Backend для запуска модели.

2.3.1 Приложение должно запускаться на исходном фреймворке модели: Caffe, Tensorflow, Tensorflow Lite, MxNet, Pytorch, Caffe2.

2.3.2 Приложение должно поддерживать запуск на ИИ-ускорителях.

2.3.3 Приложение должно уметь вызывать Model Optimizer для конвертации моделей.

2.3.4 Приложение должно быть совместимо со всеми параметрами Model Optimizer.

2.4 Поддерживаемые форматы датасетов

В зависимости от задач компьютерного зрения, инструмент должен уметь работать со следующими датасетами:

Image Classification: ImageNet, CIFAR10

Object detection: Pascal VOC, MS COCO, WIDER Face

Semantic Segmentation: CityScapes, Pascal VOC

Instance Segmentation: CityScapes, MS COCO

Face Recognition: LFW

Landmarks Regression: VGG Face 2

Person Reidentification Market 15.01, Mars

Text detection & Text recognition: ICDAR

Pose Estimation: MS COCO

2.5 Препроцессинг

Функционал должен содержать, но может не ограничиваться следующими техниками: resize, crop, padding, flip, normalization

2.6 Постпроцессинг

Функционал должен содержать, но может не ограничиваться следующими техниками:

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

- Non-Maximum Suppression

- Работа с сегментационными масками: ресайз, кроп, получение классов по цветовой схеме датасета.

2.7 Метрики

В зависимости от задач, список поддерживаемых метрик должен быть следующим:

Classification Accuracy

Binary Multilabel Classification: Precision, Recall, F-measure

Regression: Mean Absolute Error (MAE), Mean Square Error (MSE) Root Mean Square Error (RMSE), Normed Error (NE)

Object Detection: Mean Average Precision (mAP), Recall, Miss rate

Semantic Segmentation: Mean intersection over union (mean iou), pixelwise accuracy, frequency weighted accuracy

Object Reidentification: Cumulative matching characteristics. pairwise accuracy

2.2 Функциональное описание

Принцип работы разрабатываемого приложения можно описать следующей схемой:

Рисунок 6. Схема работы Accuracy Checker

Как видно из диаграммы, приложение принимает на вход представление сверточной нейронной сети (например, файлы в формате prototxt с описанием топологии и caffemodel, хранящий натренированные веса модели для фреймворка Caffe) и набор данных для валидации. На основе представления модели создается инференс лаунчер, назначение которого быть посредником между инструментом и исполняющей средой (фреймворком для запуска модели). Валидационный сет, как правило, содержит непосредственно данные для запуска модели и ground truth разметку для них. Практика показывает, что не существует единого формата хранения размеченных данных, и каждый датасет может использовать свой собственный формат (определенный формат файла или файлов, внутренняя структура каталогов, формат описания объекта в рамках аннотационного файла и др. особенности), поэтому для функциональной поддержки работы с несколькими датасетами нам необходимо представлять аннотационную составляющую датасетов в едином виде в рамках решения одной задачи. Для приведения аннотации в формат внутреннего представления используется вспомогательная сущность, называемая конвертер аннотаций. Данные для запуска модели, для задач компьютерного зрения, это изображения или кадры видеофайла, подготавливаются к инференсу и передаются на вход лаунчеру, запускающему модель. Результат запуска, prediction, передается механизму, ответственному за подсчет метрики для итеративного обновления или накопления результатов. После запуска модели на всем валидационном датасете в качестве результата работы приложения мы имеем собранное значение метрики.

2.3 Используемые инструменты

1. язык программирования python (версия 3.5).

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

2. библиотеки чтения и обработки изображений OpenCV и Pillow.

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

3. библиотека для работы с yaml-файлами (PyYAML)

YAML -- «дружественный» формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. Синтаксис YAML минималистичен, особенно по сравнению с XML-синтаксисом. к основным достоинствам YAML можно отнести:

- читабельность и лаконичность

- легкость в реализации и использовании

- поддержка потоковой обработки

- выразительность и расширяемость

- поддержка структур данных родных для языков программирования

- переносимость между языками программирования

4. фреймворки для тренировки и запуска нейронных сетей Caffe, Tensorflow, MxNet, Pytorch.

5. Deep Learning Deployment Toolkit для работы с ИИ-ускорителями.

Inference Engine написан на C++, но предоставляет API для разработки на языке python, упрощенный интерфейс для функций Inference Engine, который позволяет:

- операции с моделями

- загрузка и настройка подключаемых плагинов Inference Engine

- выполнить инференс в синхронном и асинхронном режимах с произвольным числом запросов.



2.4 Архитектура продукта

Проект имеет модульную архитектуру, что позволяет упростить тестирование программы и обнаружение ошибок. Аппаратно-зависимые подзадачи могут быть строго отделены от других подзадач, что улучшает мобильность создаваемой программы. Главное достоинство модульной архитектуры заключается в возможности обновления (замены) модуля, без необходимости изменения остальной системы, что делает Accuracy Checker гибким и легко расширяемым.

Важной особенностью служит использование Dependency Injection. Dependency Injection (DI) - это метод разработки программного обеспечения для определения зависимостей между объектами. По сути, это процесс предоставления ресурса, который требует данный фрагмент кода. DI управляет определением зависимых ресурсов и предоставляет способы их создания. Контейнер зависимостей (DC, Dependency Container) используется для реализации этого поведения и содержит карту зависимостей для компонентов.

Базовую структуру проекта можно найти в приложении 1.

Основные компоненты Accuracy Checker:

CONFIG - определение всех шагов, необходимых для валидации топологии.

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

ADAPTER - класс ответственный за конвертацию сырых результатов инфера во внутреннее представление инструмента (representation)

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

ANNOTATION CONVERTERS - специализированный класс, конвертирующий оригинальный формат аннотации во внутренний поддерживаемый метрикой формат (representation)

PREPROCESSING / POSTPROCESSING - функции вызываемый перед запуском модели для подготовки данных и после запуска для подготовки внутренних представлений к подсчету метрики, опциональны.

METRICS - классы, представляющие метрики качества.

2.5 Руководство пользователя

1. Установка

1.1 Python3

Для начала необходимо убедиться, что у вас установлен python3 и его основные компоненты:

sudo apt-get install python3 python3-dev python3-setuptools python3-pip

1.2 Виртуальное окружение

Для работы с AccuracyChecker мы рекомендуем использовать виртуальное окружение. Для установки виртуального окружения необходимо выполнить следующие команды:

python3 -m pip install virtualenv

python3 -m virtualenv -p `which python3` <directory_for_environment>

Перед началом работы виртуальное окружение должно быть активировано с помощью команды:

source <directory_for_environment>/bin/activate



При завершении работы вы можете деактивировать виртуальное окружение с помощью команды:

deactivate

1.3 Установка фреймворков

Следующий шаг - установка бекэнда для запуска Accuracy Checker.

Пожалуйста, воспользуйтесь документацией к продуктам для корректной установки.

1.4 Установка AccuracyChecker

для установки инструмента воспользуйтесь следующей командой:

python setup.py install

2. Использование

Командная строка для запуска приложения выглядит следующим образом:

accuracy_check -c path/to/config_file -m path/to/models -s

/path/to/source/data -a path/to/annotation

Аргументы командной строки:

- c, -config путь до конфигурационного файла.

- m, -models директория, где расположена указанная в конфиге модель

- s, -source директория для поиска входных данных

- a, -annotations директория для поиска сконвертированной аннотации.

Вы можете использовать команду -h --help для получения подсказки о возможных аргументах. Некоторые опциональные аргументы:

- e, -extensions директория, где расположена библиотека с реализацией кастомных слоев для исполнения на CPU с помощью Inference Engine.

- b, -b itstreams директория для поиска битстримов (для запуска на FPGA).

- C, -converted_models директория, куда будут сохранен IR (intermediate representation) модели сконвертированной с помощью Model Optimizer.

- tf, -target_framework фильтр для конфигурационного файла по фреймворку запуска

- td, -target_devices фильтр девайсов для запуска.



3. Конфигурация

Конфигурационный файл описывает все шаги валидационного пайплайна. Входной точкой для описании конфигурации служит список моделей для валидации “models”. Каждая модель имеет имя “name”, список лаунчеров для запуска “launchers” и список датасетов “datasets”.

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

Пример конфигурации:

models:

- name: model_name

launchers:

- framework: caffe

model: public/alexnet/caffe/bvlc_alexnet.prototxt

weights: public/alexnet/caffe/bvlc_alexnet.caffemodel

adapter: classification

batch: 128

datasets:

- name: dataset_name

3.1 Лаунчер

Лаунчер - это описание того, как ваша модель должна быть запущена.

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

3.1.1 DLDT Launcher

Для выбора OpenVINO™ в качестве бекенда для запуска модели необходимо указать framework: dlsdk в секции launchers конфигурационного файла и предоставить следующие параметры:

- device - указывает какая платформа будет использована для запуска модели. Поддерживаются все платформы, на которых может быть запущен DLDT (CPU, GPU, FPGA, MYRIAD, HDDL плагины и их комбинации в гетерогенном режиме, указанные как HETERO:target_device,fallback_device).

- model - путь до xml-файла, содержащего определение графа модели в формате IR.

- weights - путь до bin-файла, содержащего веса для запускаемой топологии

Пути до определения запускаемой модели могут быть относительным, префикс задается с помощью ключа командной строки -m,--models. Опционально вы также можете указать параметры модели в формате исходного фреймворка, вместо готового IR. В этом случае, перед запуском модели будет вызван ModelOptimazier. Если вы хотите использовать данную опцию, пожалуйста внимательно изучите Model Optimizer Developer Guide, поскольку это может потребовать от вас дополнительной установки зависимостей.

Вы можете воспользоваться следующими опциями:

- caffe_model и caffe_weights для модели в формате Caffe (*.prototxt and *.caffemodel).

- tf_model для TensorFlow модели (*.pb, *.pb.frozen, *.pbtxt, *.tflite).

- tf_meta для предоставление модели в формате мета-графа Tensorflow.

- mxnet_weights для MXNet params (*.params).

- onnx_model для модели в формате ONNX (*.onnx).

- kaldi_model для Kaldi модели (*.nnet).

Если также для конвертации модели вам необходимо предоставить дополнительные параметры (например input_shape для указания размеров входного блоба сконвертированной модели), используя mo_params для аргументов, требующих ввода значений и mo_flags для флагов (например --reverse_input_channels). Полный список опций может быть найден в Model Optimizer Developer Guide. Модель будет сконвертирована заново при каждом запуске. Вы можете определить директорию, в которой будут сохранены сконвертированные модели, используя -C аргумент командной строки. По-умолчанию, используется Model Optimizer из <OPENVINO_INSTALL_DIR>/deployment_tools/model_optimizer, вы можете переопределить путь для поиска используя аргумент командной строки -M.

- adapter - подход, как сырой выход модели должен быть конвертирован в специфичное для задачи представление. Более подробную информацию вы можете найти в разделе Адаптер.

- allow_reshape_input - позволяет динамически изменять размер входного слоя модели.(по-умолчанию значение False).

- batch - размер входного батча (опциональный параметр, по-умолчанию определяется из модели).

Дополнительно вы можете предоставить специфичные для запуска:

- cpu_extensions - путь до скомпилированной библиотеки, содержащей реализацию кастомных слоев для запуска на CPU *.so для Linux и *.dll для Windows). Вы можете использовать специальное значение AUTO, для возможности определения нужной реализации библиотеки, среди поставляемых в пакетe. (выбор основывается на используемой операционной сис темы и поддерживаемых инструкциях для CPU (avx512, avx2, sse4)

- gpu_extensions - путь для *.xml файла с описанием кастомных ядер OpenCL для GPU. Пути для файлов с расширениями может быть префиксирован с помощью аргумента командной строки -e

- bitstream - битстрим для запуска на FPGA. Путь может быть префиксирован с помощью -b ключа командной строки. Также для программирования битстрима вам может понадобится определить путь до пргарамматора, используя - aocl аргумент командной строки. Вы также можете запрограммировать битстрим перед запуском самостоятельно. Пожалуйста, используйте переменную окружения AOCL_COMPI

3.1.2 Caffe Launcher

Для выбора Caffe в качестве бекенда для запуска модели необходимо указать framework: caffe в секции launchers конфигурационного файла и предоставить следующие параметры:

- device - указывает какая платформа будет использована для запуска модели. Поддерживаются cpu и gpu_<i>, где i - номер девайса в мульти-GPU системе (по-умолчанию 0)

- model - путь до prototxt-файла, содержащего определение модели.

- weights - путь до caffemodel-файла, содержащего веса для запускаемой топологии.

- adapter - подход, как сырой выход модели должен быть конвертирован в специфичное для задачи представление. Более подробную информацию вы можете найти в разделе Адаптер.

- allow_reshape_input - позволяет динамически изменять размер входного слоя модели.(по-умолчанию значение False).

- batch - размер входного батча (опциональный параметр, по-умолчанию 1).

3.1.3 TensorFlow Launcher

Для выбора TensorFlow в качестве бекенда для запуска модели необходимо указать framework: tf в секции launchers конфигурационного файла и предоставить следующие параметры:

- device - указывает какая платформа будет использована для запуска модели. Поддерживаются cpu и gpu.

-model - путь до файла, содержащего веса замороженного графа (frozen.pb),.

- adapter - подход, как сырой выход модели должен быть конвертирован в специфичное для задачи представление. Более подробную информацию вы можете найти в разделе Адаптер.

- output_names определяет имена выходных слоев. (опционально, по умолчанию может быть определено из графа)

3.1.4 TensorFlow Lite Launcher

Для выбора TensorFlow Lite в качестве бекенда для запуска модели необходимо указать framework: tf_lite в секции launchers конфигурационного файла и предоставить следующие параметры:

- device - указывает какая платформа будет использована для запуска модели. Поддерживаются cpu и gpu.

- model - путь до файла, содержащего модель в формате tflite,.

- adapter - подход, как сырой выход модели должен быть конвертирован в специфичное для задачи представление. Более подробную информацию вы можете найти в разделе Адаптер.

3.1.5 MxNet Launcher

Для выбора MxNet в качестве бекенда для запуска модели необходимо указать framework: mxnet в секции launchers конфигурационного файла и предоставить следующие параметры:

- device - указывает какая платформа будет использована для запуска модели. Поддерживаются cpu и gpu.

- model - путь до файла, содержащего параметры mxnet-модели (*.params)

- adapter - подход, как сырой выход модели должен быть конвертирован в специфичное для задачи представление. Более подробную информацию вы можете найти в разделе Адаптер.

- batch - размер входного батча (по-умолчанию 1

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

- name - имя слоя

- type - указывает тип заполнения входного блоба (CONST_INPUT - заполнение константой, указанной в конфигурационном файле, INPUT - вход для основных данных, IMAGE_INFO - специальный вид входа, которому необходимо подать размер входного изображения в качестве данных.

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

- shape - список разделенных запятой размеров слоя, исключая размерность, отвечающую за размер батча.

- layout - макет размещения входных данных (опционально, по-умолчанию NCHW, где N - батч, С - каналы изображения, H и W - высота и ширина соответственно)

3.1.6 OpenCV Launcher

Для выбора MxNet в качестве бекенда для запуска модели необходимо указать framework: mxnet в секции launchers конфигурационного файла и предоставить следующие параметры:

- device - указывает какая платформа будет использована для запуска модели. Поддерживаются cpu, gpu и gpu_16

- backend - позволяет выбрать бекенд для запуска DNN модуля. В качестве него могут быть использованы ocv для запуска через OpenCV и ie для запуска с помощью OpenVINO Inference Engine.

- model - путь до файла, содержащего описание модели, в случае если это необходимо для запуска модели в формате исходного фреймворка. (Например, для моделей Caffe и OpenVINO IR)

- weights - путь до файла, содержащего веса модели.

- adapter - подход, как сырой выход модели должен быть конвертирован в специфичное для задачи представление. Более подробную информацию вы можете найти в разделе Адаптер.

- batch - размер входного батча (по-умолчанию 1)

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

- name - имя слоя

- type - указывает тип заполнения входного блоба (CONST_INPUT - заполнение константой, указанной в конфигурационном файле, INPUT - вход для основных данных, IMAGE_INFO - специальный вид входа, которому необходимо подать размер входного изображения в качестве данных.

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

- shape - список разделенных запятой размеров слоя, исключая размерность, отвечающую за размер батча.

- layout - макет размещения входных данных (опционально, по-умолчанию NCHW, где N - батч, С - каналы изображения, H и W - высота и ширина соответственно)

3.2 Адаптер

Адаптер - это функция, которая преобразовывает сырой результат работы нейронной сети в формат, поддерживаемый метрикой. Существует 2 способа задания адаптера для топологии:

1. Определение в виде строки: adapter: <adapter_name>

2. Определение в виде словаря. Данный сопособ позволяет задать дополнительные аргументы (например, имя выходного слоя, зависит от реализации адаптреа):

- adapter:

- type: adapter_name

- adapter_parameter: value

Accuracy Checker поддерживает следующий список адаптеров:

- classification конвертирует выход классификационных моделей в ClassificationPrediction.

- segmentation конвертирует выход сегментационных моделей в SegmentationPrediction.

- reid конвертирует выход моделей для задачи реидентификации объектов в ReIdentificationPrediction.

- grn_workaround позволяет обработать выход модели, применяя к нему Global Region Normalization.

- landmarks_regression конвертирует выход модели для распознавания лицевых ленмарок в FacialLandmarksPrediction.

- ssd конвертирует выход моделей для детектирования объектов, основанных на подходе single stage detection в DetectionPrediction.

- tiny_yolo_v1 конвертирует выход Tiny YOLO v1 модели в DetectionPrediction.

- yolo_v2 конвертирует выход моделей семейства YOLOv2 в DetectionPrediction.

- classes - количество классов для детектирования (по-умолчанию 20, используется для моделей натренированных на Pascal VOC датасете. Также может быть заменено на 80, для моделей обученных на MS COCO).

- anchors - anchor values предоставленных через запятую или одно из предустановленных значений (yolo_v2, tiny_yolo_v2).

- num - num parameter из DarkNet конфигурационного файла (по-умолчанию, 5).

- yolo_v3 конвертирует выход семейства моделей YOLO v3 в DetectionPrediction.

- classes - количество классов для детектирования (по-умолчанию, 80).

- anchors - anchor values предоставленных через запятую или предустановленное значение yolo_v3.

- num - num parameter из DarkNet конфигурационного файла (по-умолчанию, 3).

- threshold - минимальная уверенность предсказания для валидного объекта (default 0.001).

- super_resolution конвертирует выход модели для задачи single image super resolution в SuperResolutionPrediction

- text_detection конвертирует выход модели для распознавания областей, где расположен текст, основанных на подходе PixelLink в TextDetectionPrediction.

- pixel_class_out - имя слоя, содержащего информацию о классификации текст/не_текст классификации для каждого пикселя изображения.

- pixel_link_out - имя слоя содержащего информацию для определения связей между соседними пикселями.

- human_pose_estimation конвертирует выход модели для определения позы человека в PoseEstimationPrediction.

- part_affinity_fields_out - имя выходного слоя с попарным отношением ключевых точек (part affinity fields).

- keypoints_heatmap_out - имя выходного слоя с тепловой картой ключевых точек.

- beam_search_decoder - реализация CTC Beam Search decoder для распознавания последовательности символов, конвертирует выход модели в CharacterRecognitionPrediction.

- beam_size - размер beam для декодирования (по-умолчанию, 10).

- blank_label - индекс для CTC blank label.

- softmaxed_probabilities - служит индикатором, что к выходу модели был применена операция SoftMax т.к. по-умолчанию данный адаптер работает с вероятностью, представленной в виде логитов (по-умолчанию, False).

- lpr конвертирует выход модели для распознавания номерных знаков в CharacterRecognitionPrediction.

- face_person_detection конвертирует результат работы модели для детектирующей людей и их лица, имеющей 2 выходных слоя в ContainerPredition, где имена слоев (берутся из face_out и person_out) используются в качестве идентификаторов для DetectionPrediction в контейнере.

- face_out - имя выходного слоя, содержащего предсказания для лиц.

- person_out - имя выходного слоя, содержащего предсказания для класса person.

- vehicle_recognition конвертирует выход модели для распознавания аттрибутов транспортных средств (тип и цвет) в ContainerPrediction, где имена выходных слоев используются в качестве идентификатора для ClassificationPrediction в контейнере.

- color_out - имя выходного слоя, содержащего информацию о цвете автомобиля.

- type_out-имя выходного слоя, содержащего информацию о типе автомобиля.

- head_pose конвертирует выход модели для распознавания угла наклона головы в ContainerPrediction, где имена выходных слоев используются в качестве идентификаторов для RegressionPrediction в контейнере.

- angle_pitch - имя выходного слоя, содержащего информацию об pitch угле.

- angle_yaw- имя выходного слоя, содержащего информацию об yaw угле.

- angle_roll - output layer name for roll angle.

- age_gender конвертирует выход модели для определения пола и возвраста человека в ContainerPrediction с ClassificationPrediction (идентификатор gender_classification) для распознавания пола, ClassificationPrediction (идентификатор age_classification) для классификации пола на 4 категории (child, young, middle, old) и RegressionPrediction (идентификатор age_regression) для задачи регрессии возраста.

- age_out - имя слоя для распознавания возраста.

- gender_out - имя слоя для распознавания пола.

- gaze_estimation конвертирует выход модели для оценки направления взгляда в GazeVectorPrediction.

- action_detection конвертирует выход модели для детектирования людей и распознавания их действий в ContainerPrediction с DetectionPrdiction для детектирования людей (идентификатор person_detection) и DetectionPrediction (идентификатор action_recognition) для распознавания действий.

- priorbox_out - имя слоя, содержащего prior boxes в формате SSD.

- loc_out - имя слоя, содержащего координаты локализации для boxes в формате SSD.

- main_conf_out - имя слоя, содержащего степень уверенности для детектирования людей.

- add_conf_out_prefix - префикс для генерации имен слоев, содержащих имена слоев содержащих вероятности для действий.

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

- num_action_classes - количество классов для распознавания действий.

- detection_threshold - минимальный уровень уверенности для того, чтобы считать предсказание валидным.

- person_attributes конвертирует выход модели для распознавания аттрибутов человека в MultiLabelRecognitionPrediction.

- preson_attributes_out - имя выходного слоя, содержащего вероятности наличия аттрибутов.

3.3 Датасет

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

Если ваш датасет является хорошо известной проблемой для deep learning competitions (COCO, Pascal VOC, ...) и / или могут быть потенциально использованы повторно для других моделей разумно объявить его в неком глобальном конфигурационном файле. Таким образом, в вашем локальном файле конфигурации вы можете предоставить только имя и все необходимые шаги будут выбраны из глобального. Чтобы передать путь к этой глобальной конфигурации, используйте аргумент командной строки --definition.

Каждый датасет должен иметь:

- name: уникальный идентификатор вашего датасета.

- data_source: путь к каталогу, где хранятся входные данные. Может быть относительным и префиксироваться с помощью ключа командной строки -s, --source

- metrics: список метрик, которые должны быть вычислены.

И опционально:

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

- postprocessing: список шагов постобработки.

- reader: задает как будет осуществлен процесс чтения данных.

Кроме того, определение датасета должно включать информацию о том, как получить ground truth данные в формате специфичном для задачи.

Вы можете сконвертировать аннотацию прямо непосредственно во время запуска:

- annotation_conversion: параметры для конвертации аннотации (Более подробно см. в разделе конвертация аннотаций) или использовать заготовленные заранее файлы

- annotation: pickle-файл, содержащий аннотацию в формате поддерживаемом метрикой. Путь к файлу может быть относительным, префикс определяется с помощью аргумента командной строки -a, --annotation.

- dataset_meta: файл в формате json, содержащий мета информацию о датасете (например, label_map - маппинг между числовым и строковым представлением классов датасета, background_label - id вспомогательного класса, соответствующего заднему плану, segmentation_colors - цветовое представление, в котором закодированы классы семантической сегментации и др.) Путь к файлу может быть относительным, префикс определяется с помощью аргумента командной строки -a, --annotation.

Пример конфигурации датасета:

- name: dataset_name

annotation: annotation.pickle

data_source: images_folder

preprocessing:

- type: resize

dst_width: 256

dst_height: 256

- type: normalization

mean: imagenet

- type: crop

dst_width: 227

dst_height: 227

metrics:

- type: accuracy

3.3.1 Конвертация аннотаций

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

Процесс конвертации может быть осуществлен двумя способами:

- объявление в файле конфигурации

- с помощью консольного скрипта

программный ускоритель искусственный нейронный сеть

3.3.1.1 Описание конвертации аннотации в конфигурационном файле

Процесс преобразования аннотации должен быть описан в разделе datasets. Он будет осуществлен непосредственно перед каждым запуском. Каждая конфигурация должна иметь поле converter, содержащее имя конвертера, который будет использоваться и специфичные для конвертации параметры (зависят от выбранного конвертера). Все пути могут быть относительными, префикс задается с помощью аргумента -s, --source командной строки.

Вы также можете использовать дополнительные параметры, такие как:

- subsample_size - размер валидационного сабсета, выбранного случайным образом из полного валидационного сета и subsample_seed - сид для генерации данного сабсета.

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

Пример использования

annotation_conversion:

converter: sample

data_dir: sample/sample_dataset

3.3.1.2 Конвертация аннотаций с помощью консольного скрипта

Для вызова конвертации используется команда convert_annotation. Аргументы командной строки формируются следующим образом:

convert_annotation <converter_name> <converter_specific parameters>

<converter_name> - название используемого конвертера,

<converter_specific_parameters> - специфичные для использования данного конвертера параметры, могут отличаться в зависимости от реализации конвертера.

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

Некоторые опциональные аргументы доступные при конвертации:

-o, --output_dir - Директория для сохранения сконвертированной аннотации и метаданных датасета.

-a, --annotation_name - имя файла для сконвертированной аннотации.

-m, --meta_name - имя файла для сохранения метаданных датасета.

-ss, --subsample_size - размер валидационной выборки.

Список поддерживаемых конфигурации и параметров для конвертации можно найти в приложении 1.

3.3.2 Чтение данных

Выбор функционала для чтения данных задается в разделе датасета reader.

Доступны следующие конфигурации для чтения данных:

- opencv_imread - чтение изображений с помощью OpenCV (по умолчанию). Цветовая схема, прочитанного изображения BGR.

- pillow_imread - чтение изображений с помощью Pillow. Цветовая схема, прочитанного изображения RGB.

- opencv_capture - захват кадров из видео с помощью OpenCV, цветовая схема, прочитанного кадра BGR.

- json_reader - чтение данных, хранящихся в формате json.

- numpy_reader - чтение данных, хранящихся в виде numpy-файлов.

- combine_reader - позволяет задать сложную схему для чтения данных и использовать разные подходы в зависисмости от формата файла.

3.3.3 Препроцессинг

Препроцессор - функция, которая подготавливает данные перед запуском модели. Каждый препроцессор имеет параметры, доступные для конфигурации.

Шаги препроцессинга описываются в секции preprocessing в виде списка. Описание каждого препроцессора должно начинаться с декларации типа препроцессора type: preprocessor_name, после чего должно следовать описание аргументов препроцессора, если они необходимы.

Список поддерживаемых функций препроцессинга может быть найден в приложении 3.

3.3.4 Постпроцессинг

Постпроцессор-это функция, которая обрабатывает результат работы модели после инференса и / или аннотации перед вычислением метрики. Для корректной работы постпроцессоров требуется определенный формат представления. (например, постпроцессор, скалирующий детекционные боксы ожидает DetectionAnnotation и DetectionPrediction для обработки).

Описание каждого постпроцессора должно начинаться с декларации типа постпроцессора type: postprocessor_name, после чего должно следовать описание аргументов постпроцессора, если они необходимы.

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

3.3.5 Метрики

Для корректной работы метрик требуется определенный формат представления. При желании вы можете указать контрольное поле для метрики reference, если вы хотите, чтобы вычисленная метрика была проверена на соответствие конкретному значению и приемлемому порогу отклонения метрики от контрольного значения threshold.

Каждая метрика может иметь параметры доступные для конфигурации.

AccuracyChecker поддерживает следующий набор метрик:

accuracy - метрика точности для задачи классификации, определяемая как отношение числа верных предсказаний к общему числу предсказаний. Принимает на вход ClassificationAnnotation и ClassificationPrediction.

Параметры:

- top_k - количество классов с наибольшей вероятностью, которое будет использоваться для определения правильности прогноза

accuracy_per_class - метрика точности классификации, которая представляет результаты для каждого класса в отдельности. Параметры и принимаемые представления аналогичны accuracy метрике.

character_recognition_accuracy - метрика точности для задачи распознавания символов. Принимает на вход: CharacterRecognitionAnnotation, CharacterRecognitionPrediction.

mae - Средняя обсолютная ошибка. Поддерживаемые представления: RegressionAnnotation, RegressionPrediction.

mse - Средняя квадратичная ошибка. Поддерживаемые поддерживаемые представления: RegressionAnnotation, RegressionPrediction.

rmse - Квадратный корень из среднеквадратичной ошибки. Поддерживаемые значения: RegressionAnnotation, RegressionPrediction.

normed_error - Нормированная ошибка для задачи измерения качества позиции лицевых лендмарок, определяемая по формуле:

Формула 9 Normed Error

Поддерживаемые представления: FacialLandmarksAnnotation, FacialLandmarksPrediction.

- calculate_std - позволяет дополнительно посчитать среднеквадратичное отклонение для используемых при подсчете метрики значений. (Опционально, по-умолчанию False)

percentile - позволяет дополнительно посчитать уровень ошибки для конкретного перцентиля.

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

Формула 10 PSNR

Поддерживаемые представления; SuperResolutionAnnotation, SuperResolutionPrediction.

f1_score - F score метрика. Поддерживаемые представления: MultiLabelRecognitionAnnotation, MultiLableRecognitionPrediction.

cmc - Commulative matching characteristics. Поддерживаемые представления: ReidentificationAnnotation, ReidentificationPrediction.

- top_k - количество семплов с наивысшим рангом, для определения соответствия объектов.

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

- single_gallery_shot - каждая единица для идентификации должна иметь только один объект в галерее.

- first_match_break - позволяет прекратить поиск соответствий после нахождения первого соответствующего семпла галереи.

reid_map - mean average precision для задачи реидентификации. Поддерживаемые представления: ReidentificationAnnotation, ReidentificationPrediction.

pairwise_accuracy - классификация пар для задачи реидентификации. Поддерживаемые представления: ReidentificationClassificationAnnotation, ReidentificationPrediction.

Метрики для задачи детектирования объектов: map, recall, miss_rate, detection_accuracy. Принимают на вход данные в формате DetectionAnnotation, DetectionPrediction. Имеют следующий набор аргументов:

Метрики для задачи семантической сегментации изображений:

segmentation_accuracy, mean_iou, mean_accuracy, friquency_weighted_accuracy. Принимают на вход данные в формате SegmentationAnnotation, SegmentationPrediction.

coco_precision, coco_recall - реализация метрик популярного датасета MSCOCO. Поддерживаемые данные: PoseEstimationAnnotation + PoseEstimationPrediction, DetectionAnnotation+DetectionPrediction, CocoInstanceSegmentationAnnotation+CocoInstanceSegmentationAnnotation.

text_detection - f-score для задачи детектирования области текста. Поддерживаемые типы данных: TextDetectionAnnotation, TextDetectionPrediction.



4. Запуск примера

В данном примере будут разобраны типичные шаги, необходимые для запуска DL топологии. Мы попробуем запустить SampleNet в качестве примера. Для запуска нам понадобится установленный фреймворк Caffe и/или OpenVINO.

Шаг 1. Скачать и разархивировать датасет.

В качестве примера мы будет использовать игрушечный датасет, который содержит 10 тысяч изображений, разбитый на 10 классов (задача классификации). Это CIFAR10 датасет, сконвертированный в формат png (конвертация изображений будет выполнена автоматически в момент запуска).

Вы можете скачать оригинальный датасет с официального сайта (CIFAR-10 python version) https://www.cs.toronto.edu/~kriz/cifar.html

После загрузки датасет необходимо распаковать в папку sample:

tar xvf sample/sample_dataset.tar.gz -C sample

Шаг 2. Запустить пример

Для запуска модели обычно вам нужно написать конфигурационный файл описывающий запуск модели. ДЛя запуска примера AccuracyChecker имеет заготовленный конфигурационный файл sample_config.yml для запуска SampleNet используя OpenVINO фреймворк, внимательно ознакомьтесь с его содержанием. Данная конфигурация запускает модель, сохраненную в формате фреймворка Caffe, используя ModelOptimizer для конвертации ее во внутреннее представление (IR) OpenVINO. Данный шаг может потребовать от вас установки Caffe. Запуск примера в командной строке выглядит следующим образом:

accuracy_check -c sample/sample_config.yml -m data/test_models -s sample

-a sample/annotation

Используемые опции:

-c - путь до конфигурационного файла (пример конфигурационного файла см. приложение 5)

-m путь до директории, где расположены модели

-s директория, где расположен датасет.

Если все шаги выполнены корректно, вы должны получить 75.02% accuracy.

Теперь вы можете самостоятельно отредактировать конфигурацию для запуска SampleNet на другом девайсе (например GPU) или фреймворке (Caffe, OpenCV, MxNet) и/или переходить к тестированию собственной модели.

Пример полученного результата:



5. Тестирование новой модели

Типичный алгоритм добавления новой модели выглядит следующим образом:

1. Конвертация аннотации датасета. Используйте один из представленных в annotation_converters директории или напишите свой собственный конвертер аннотаций.

2. Выберите адаптер, подходящий своей модели или напишите свой собственный. Адаптер преобразует необработанный результат работы модели в высокоуровневое представление, используемое для вычисления метрики (например, ClassificationPrediction, DetectionPrediction и др.)

3. Воспроизведите метрики, шаги препроцессинга и постпроцессинга, используемые в оригинальном процессе валидации (например, указанные в первоисточной статье к модели)

4. Составьте файл конфигурации и запустите.



6. Расширение функциональности

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

1. Создать класс, который будет реализовывать новую функциональность. Для этого требуется отнаследоваться от базового класса в модуле (н отличается от доступных модификаций наличием поля __provider_type__) и переопределить абстрактные методы.

2. Задать имя нового элемента, по которому он будет описан в конфиге. Для этого нужно вписать его в поле __provider__.

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

4. Импортировать готовую новую функциональность в __init__.py расширяемого модуля инструмента. После чего, функциональность считается добавленной и может быть использована при дальнейшей работе инструмента.

В качестве примера см. sample_converter.py (приложение 6)



Заключение

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

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

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



Список литературы

1. Pooja Jawandhiya, “Hardware design for machine learning”, International Journal of Artificial Intelligence and Applications (IJAIA), Vol.9, No.1, January 2018 [Online]

2. Yann LeCun “Deep Learning Hardware: Past, Present, and Future”, 2019 IEEE International Solid- State Circuits Conference - (ISSCC)(2019, 17 Feb)

3. Jihan Zhu and Peter Sutton, “FPGA Implementations of Neural Networks - A Survey of a Decade of Progress”, Y.K. Cheung P., Constantinides G.A. (eds) Field Programmable Logic and Application, FPL 2003, Lecture Notes in Computer Science, vol. 2778. Springer, Berlin, Heidelberg.

4. Linda Barney, (2017, March 21), “Can FPGAs beat GPUs in accelerating next-generation deep learning?”, The Next Platform. [Online].

5. Utku Aydonat, Shane O'Connell, Davor Capalija, Andrew C. Ling, Gordon R. Chiu, “An OpenCL Deep Learning Accelerator on Arria 10”, 2017[Online]

...