это архитектура проекта ML датчика IOT:
- создать виртуальную среду с помощью python
- добавить файл readme.md, файл git ignore и файл requirements.txt
- следующий шаг самый важный… файл SETUP.PY:
- этот сценарий установки является центром всей деятельности по сборке, распространению и установке модулей. Основная цель сценария установки — описать распространение вашего модуля в Distutils, чтобы различные команды, работающие с вашими модулями, выполняли правильные действия.
- папка датчика является главной папкой, и мы создаем свой собственный пакет, все будет внутри этой папки датчика
- конвейер: у нас может быть обучающий конвейер как для прогнозирования, так и для обучения
- ML: любая пользовательская модель, точность, график или код, связанный с проектированием функций, помещается в папку ML (для обучения модели мы пишем код в папке ml\model), а код оценочных метрик пишем внутри ml\metric.
- entity: папка объекта для определения структуры ввода и вывода каждого компонента ML. в компонентах ML у нас есть несколько компонентов в конвейере, поэтому мы должны определить, что является входом и выходом каждого компонента.
- data_access: если наши данные находятся в базе данных mongo db, мы должны извлечь из нее, поэтому мы пишем эти коды здесь
- константа: это то, что не изменится, например, имя модели имени файла или имя базы данных, но мы должны решить изначально
- конфигурация: чтобы поддерживать всю конфигурацию соединения, связанную с проектом, и код, связанный с соединением, мы будем писать его в папке конфигурации.
- компоненты: конвейеры машинного обучения состоят из нескольких последовательных шагов, которые выполняют все, от извлечения данных и предварительной обработки до обучения модели, мы будем писать здесь компоненты ML.
- cloud_storage: о том, как мы можем управлять файлами в облаке, например, загружать или скачивать файл, мы можем написать код, и это будет сделано автоматически.
- регистратор: это часть каждого проекта, все, что происходит внутри вашего кода, должно регистрироваться.
- исключение: это часть каждого проекта, если происходит аномалия, мы должны ее правильно зафиксировать, чтобы мы могли изменить наш код, чтобы та же ошибка не повторялась снова с регистратором и исключением, мы можем проверить код, чтобы выяснить процесс проекта работает
- util: когда нам требуется общий код в нескольких местах, мы пишем внутри него функцию и используем ее для вызова везде, где хотим
- оценка: в этом файле мы назначим пользовательскую функцию отображения для целевой переменной
Поток кода высокого уровня для обнаружения неисправности датчика
сборка каждого компонента начинается с: константы (конвейер обучения) -> сущность (конфигурация/артефакт) -> компоненты
прием данных:
шаг 1:
- мы определим значения для этих переменных ((каталог приема данных, путь к файлу хранилища функций, путь к файлу обучения, путь к файлу тестирования, коэффициент разделения теста обучения, имя коллекции)) для нашей конфигурации приема данных (IN CONFIG_ENTITY)
шаг 2:
- а затем мы инициируем операции приема данных. Прежде всего, мы извлекаем данные из mongo db и создаем файл sensor.csv.
шаг 3:
- экспортировать данные в хранилище функций, если у него есть 2 операции для выполнения
шаг 3.1:
- извлекать данные из базы данных mongo db и сохранять их в папке хранилища функций через ((артефакт приема данных/с отметкой времени/хранилище функций/в виде файла .csv))
шаг 4:
- и ненужные столбцы удаляются с помощью сценария, который мы написали в файле схемы, который находится в папке конфигурации.
шаг 5:
- из sensor.csv мы разделили его на train.csv и test.csv с коэффициентом разделения 0,2 и сохранили его в папке с данными с помощью (( хранилище функций/с отметкой времени/как разделение поезда и теста))
валидация данных:
шаг 1:
- мы определим значения для этих переменных ((каталог проверки данных, действительный каталог данных, недопустимый каталог данных, действительный путь к файлу обучения, неверный путь к файлу обучения, недопустимый путь к тестовому файлу, путь к файлу отчета о дрейфе)) для нашей конфигурации проверки данных (IN CONFIG_ENTITY )
шаг 2:
- а затем мы инициируем операции проверки данных и получаем данные из артефакта приема данных / из папки приема данных
- мы получаем файл csv для обучения и тестирования из папки с данными и для чтения данных
шаг 3:
- при проверке количества столбцов мы проверим наличие всех столбцов в обучающем и тестовом CSV-файле, если столбцы отсутствуют в обучающем или тестовом файле, результат перейдет в статус проверки и вызовет ошибку проверки.
шаг 4:
- in (существует ли числовой столбец) мы проверим наличие всех числовых столбцов в файле train и test csv, если столбцы отсутствуют в файле обучения или теста, результат перейдет в статус проверки и вызовет ошибку проверки.
шаг 5:
- в статусе проверки, если какой-либо из столбцов отсутствует в поезде или тесте, это вызовет ошибку проверки или, если все это правда, мы перейдем к дрейфу данных
шаг 6:
- при обнаружении дрейфа набора данных мы проверим статус дрейфа данных, а затем перейдем к артефакту проверки данных, и файл report.yaml с отметкой времени будет сохранен.
преобразование данных:
шаг 1:
- мы установим конфигурацию преобразования данных с необходимыми файлами, а затем начнем преобразование данных
- мы получаем обучающий и тестовый файл из артефакта проверки данных, а затем читаем данные
шаг 2:
- TRAIN DATAFRAME: мы получаем набор данных поезда и собираемся начать его обработку
шаг 2а, шаг 3а:
- мы разделяем входную функцию и целевую функцию
- для INPUT FEATURE мы применим преобразование данных
- для TARGET FEATURE мы отображаем его категориальное значение, например (0 = положительное, 1 = отрицательное)
шаг 4:
- надежный скейлер используется для обнаружения и обработки выбросов и уменьшения каждой функции до аналогичного масштаба и более простого импутера для обработки пропущенных значений.
- после этого мы получаем объект предварительной обработки, с помощью которого мы собираемся преобразовать наш набор данных для обучения и тестирования.
шаг 5:
- используя SMOTETOMEK, мы будем обрабатывать набор данных дисбаланса и балансировать наши классы.
шаг 6:
- после этого мы соединим нашу входную функцию и целевую функцию набора данных обучения и тестирования и сохраним ее как массив train.numpy и тестовый массив .numpy в папке артефактов преобразования данных.
обучение модели данных:
шаг 1:
- мы должны установить конфигурацию тренажера модели с основными путями к файлам, в этом компоненте модель будет обучаться с использованием лучшей модели мл, которая дала лучший результат в части EDA.
- после конфигурации тренажера модели мы запускаем тренажер модели и получаем данные массива np для обучения и тестирования из артефакта преобразования данных, для этого мы будем использовать данные массива load numpy после того, как этот поезд будет разделен как x_train и y_train , тест будет разделен как y_train и y_test
шаг 2:
- после того, как мы подгоним модель для обучения данных с помощью лучшего алгоритма, мы проверяем оценку метрик, если оценка метрик данных поезда равна ‹= с ожидаемой точностью, мы вызовем исключение, если оно будет передано
- затем мы сопоставляем тестовые данные и проверяем оценку метрик, после чего мы проверяем на переоснащение и несоответствие, и разница должна быть › значением, которое мы установили
шаг 3:
- после того, как мы получим лучшую модель, мы должны сохранить (лучшую модель и предварительно обработанный объект) в файле модели датчика с именем.
оценка данных:
шаг 1:
- Конфигурация оценки модели должна быть настроена с упомянутыми основными файлами и инициировать оценку модели, и мы получаем входные данные от артефакта проверки данных и артефакта тренажера модели.
- мы получаем действительный путь к файлу поезда и теста из артефакта проверки данных и объединяем их, назначая им целевое сопоставление
шаг 2:
- а затем мы получаем ранее сохраненную модель датчика и оцениваем текущую модель с моделью датчика
- затем мы проверим метрическую оценку текущей модели, если метрика выше и улучшится, затем мы нажмем это на артефакт оценки модели.
толкатель модели датчика:
шаг 1:
- мы должны настроить файл конфигурации толкателя модели, и после запуска толкателя модели цель состоит в том, что он создаст папку, сохраненную модель внутри, модель будет сохранена, и мы получим артефакт толкателя модели.
- после этого мы должны установить переменную env для секретных ключей AWS, и мы переместим нашу папку всех артефактов в корзину s3, а также мы отправим нашу сохраненную модель в корзину s3.
- затем мы можем запустить все это в AWS EC2, чтобы мы могли его докеризовать, и с помощью конвейера CI / CD из действий github мы можем выполнять эти операции.