это архитектура проекта ML датчика IOT:

  1. создать виртуальную среду с помощью python
  2. добавить файл readme.md, файл git ignore и файл requirements.txt
  3. следующий шаг самый важный… файл SETUP.PY:
  4. этот сценарий установки является центром всей деятельности по сборке, распространению и установке модулей. Основная цель сценария установки — описать распространение вашего модуля в Distutils, чтобы различные команды, работающие с вашими модулями, выполняли правильные действия.
  5. папка датчика является главной папкой, и мы создаем свой собственный пакет, все будет внутри этой папки датчика
  6. конвейер: у нас может быть обучающий конвейер как для прогнозирования, так и для обучения
  7. ML: любая пользовательская модель, точность, график или код, связанный с проектированием функций, помещается в папку ML (для обучения модели мы пишем код в папке ml\model), а код оценочных метрик пишем внутри ml\metric.
  8. entity: папка объекта для определения структуры ввода и вывода каждого компонента ML. в компонентах ML у нас есть несколько компонентов в конвейере, поэтому мы должны определить, что является входом и выходом каждого компонента.
  9. data_access: если наши данные находятся в базе данных mongo db, мы должны извлечь из нее, поэтому мы пишем эти коды здесь
  10. константа: это то, что не изменится, например, имя модели имени файла или имя базы данных, но мы должны решить изначально
  11. конфигурация: чтобы поддерживать всю конфигурацию соединения, связанную с проектом, и код, связанный с соединением, мы будем писать его в папке конфигурации.
  12. компоненты: конвейеры машинного обучения состоят из нескольких последовательных шагов, которые выполняют все, от извлечения данных и предварительной обработки до обучения модели, мы будем писать здесь компоненты ML.
  13. cloud_storage: о том, как мы можем управлять файлами в облаке, например, загружать или скачивать файл, мы можем написать код, и это будет сделано автоматически.
  14. регистратор: это часть каждого проекта, все, что происходит внутри вашего кода, должно регистрироваться.
  15. исключение: это часть каждого проекта, если происходит аномалия, мы должны ее правильно зафиксировать, чтобы мы могли изменить наш код, чтобы та же ошибка не повторялась снова с регистратором и исключением, мы можем проверить код, чтобы выяснить процесс проекта работает
  16. util: когда нам требуется общий код в нескольких местах, мы пишем внутри него функцию и используем ее для вызова везде, где хотим
  17. оценка: в этом файле мы назначим пользовательскую функцию отображения для целевой переменной

Поток кода высокого уровня для обнаружения неисправности датчика

сборка каждого компонента начинается с: константы (конвейер обучения) -> сущность (конфигурация/артефакт) -> компоненты

прием данных:

шаг 1:

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

шаг 2:

  1. а затем мы инициируем операции приема данных. Прежде всего, мы извлекаем данные из mongo db и создаем файл sensor.csv.

шаг 3:

  1. экспортировать данные в хранилище функций, если у него есть 2 операции для выполнения

шаг 3.1:

  1. извлекать данные из базы данных mongo db и сохранять их в папке хранилища функций через ((артефакт приема данных/с отметкой времени/хранилище функций/в виде файла .csv))

шаг 4:

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

шаг 5:

  1. из sensor.csv мы разделили его на train.csv и test.csv с коэффициентом разделения 0,2 и сохранили его в папке с данными с помощью (( хранилище функций/с отметкой времени/как разделение поезда и теста))

валидация данных:

шаг 1:

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

шаг 2:

  1. а затем мы инициируем операции проверки данных и получаем данные из артефакта приема данных / из папки приема данных
  2. мы получаем файл csv для обучения и тестирования из папки с данными и для чтения данных

шаг 3:

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

шаг 4:

  1. in (существует ли числовой столбец) мы проверим наличие всех числовых столбцов в файле train и test csv, если столбцы отсутствуют в файле обучения или теста, результат перейдет в статус проверки и вызовет ошибку проверки.

шаг 5:

  1. в статусе проверки, если какой-либо из столбцов отсутствует в поезде или тесте, это вызовет ошибку проверки или, если все это правда, мы перейдем к дрейфу данных

шаг 6:

  1. при обнаружении дрейфа набора данных мы проверим статус дрейфа данных, а затем перейдем к артефакту проверки данных, и файл report.yaml с отметкой времени будет сохранен.

преобразование данных:

шаг 1:

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

шаг 2:

  • TRAIN DATAFRAME: мы получаем набор данных поезда и собираемся начать его обработку

шаг 2а, шаг 3а:

  • мы разделяем входную функцию и целевую функцию
  1. для INPUT FEATURE мы применим преобразование данных
  2. для TARGET FEATURE мы отображаем его категориальное значение, например (0 = положительное, 1 = отрицательное)

шаг 4:

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

шаг 5:

  1. используя SMOTETOMEK, мы будем обрабатывать набор данных дисбаланса и балансировать наши классы.

шаг 6:

  1. после этого мы соединим нашу входную функцию и целевую функцию набора данных обучения и тестирования и сохраним ее как массив train.numpy и тестовый массив .numpy в папке артефактов преобразования данных.

обучение модели данных:

шаг 1:

  1. мы должны установить конфигурацию тренажера модели с основными путями к файлам, в этом компоненте модель будет обучаться с использованием лучшей модели мл, которая дала лучший результат в части EDA.
  2. после конфигурации тренажера модели мы запускаем тренажер модели и получаем данные массива np для обучения и тестирования из артефакта преобразования данных, для этого мы будем использовать данные массива load numpy после того, как этот поезд будет разделен как x_train и y_train , тест будет разделен как y_train и y_test

шаг 2:

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

шаг 3:

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

оценка данных:

шаг 1:

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

шаг 2:

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

толкатель модели датчика:

шаг 1:

  1. мы должны настроить файл конфигурации толкателя модели, и после запуска толкателя модели цель состоит в том, что он создаст папку, сохраненную модель внутри, модель будет сохранена, и мы получим артефакт толкателя модели.
  2. после этого мы должны установить переменную env для секретных ключей AWS, и мы переместим нашу папку всех артефактов в корзину s3, а также мы отправим нашу сохраненную модель в корзину s3.
  3. затем мы можем запустить все это в AWS EC2, чтобы мы могли его докеризовать, и с помощью конвейера CI / CD из действий github мы можем выполнять эти операции.