aerubanov / proj_air_quality Goto Github PK

Добавить запуск экспериментов из experiments/ в DVC pipline (https://dvc.org/doc/start/experiments, https://dvc.org/doc/start/data-pipelines)

Попробовать моделировать измение концентрации частиц с помощью gaussian processes как описано в статье https://www.aaai.org/ocs/index.php/AAAI/AAAI15/paper/viewPDFInterstitial/9712/9309

При использовании pandas==1.1.4 ломается скрипт create_dataset.py с ошибкой AssertionError: <class 'numpy.ndarray'> на вызове local_data = local_data[str(start_date):].resample('5T').mean() в строке 31, в версии 1.0.5 все работает. Нужно разобраться что не так, и если дело в pandas то сделать минимальный пример и открыть issue.

Add features of weather to GP covariance function (wind speed, temperature, pressure, precipitation, humidity etc.)

Вкачестве prior distribution мы используем гаусовский процесс, который определяется ковариационной функций. В работе https://www.aaai.org/ocs/index.php/AAAI/AAAI15/paper/viewFile/9712/9309 используют комбинацию Matern3/2 и Periodic функций. Нужно подумать как выбрать гиперпараметры для них, возможно есть смысл задавать prior и для гиперпараметр тоже. Или вообще какие-то другие ковариационнный функции использовать.
Ссылки по теме:
https://docs.pymc.io/api/gp/cov.html#covariance-functions
https://www.cs.toronto.edu/~duvenaud/cookbook/

https://docs.python.org/3/library/functions.html#property

Save prediction during cross-validation to make it available for further analysis.

добавить с CI/CD пайплайн black https://github.com/psf/black как pre-commit

Обновить версии / убрать то что не используется

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

Используя sparce aproximation и variational inference в модели gpflow мы можем добовлять в модель новые данные (см. #114), но нужно понимать насколько мы при этом проигрываем в качестве модели по сравнению с полным баесовским выводом в pymc3. Нужено подобрать число inducing points.

Нужно добавить метод для сохрания модели в

Calculate ACF (https://www.statsmodels.org/devel/generated/statsmodels.tsa.stattools.acovf.html) and power spectral density (PSD) for PM2.5 and PM10 and to get periodicity in data (hourly, daily, weekly, annually).

Добавить тесты (сейчас они есть, но покрывают не все возможные случаии), воможно так же нужно поиграться с интервалом, в котором проверяется значение

В src/web/bot/level_tracker.py есть код, который должен отслеживать измение уровня AQI и если он изменился, то пользователю нужно отправить уведомления.
Но они приходят гораздо реже чем должны по-идее

Я бы начал с дописывания нормальных тестов, т.к. то что есть не покрывает все возможные варианты. Плюс вызывается оно с помощью модуля schedule черезкаждые 20 мин, и возможно проблема с этим какая-то тоже может быть. Типа почему-то состояние между вызовами не сохраняется.
это в src/bot/bot.py строка 200

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

Попробовать добавить в модель признаки пространственного положения сенсоров

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

Сделать страницу, где бы отображалась статистика по годам/месяцам. За основу можно взять то, что есть в EDA.

В статье https://www.aaai.org/ocs/index.php/AAAI/AAAI15/paper/viewFile/9712/9309 используется схема валидации, где выбираются два временных окна (t1, t2) и (t2, t3) , данные из первого используются кака обучающая выборка а из второго как валидационная. В процессе кросс-валидации окна смещаются по всей выборке, соттветсвенно то что было в валидационной выборке попадаетв в обучающую, модель дообучается на них, а для валидационной используются новые данные. Выглядит достаточно разумно и нужно реализовать этот подход у нас.

Для удобства работы с данными нужно создать класс(-ы) для работы с датасетом, чтобы можно было:

• выбирать данные по времени, местоположению, sensor_id
• создавать fake data путем сэмплирования из распределения с заданными параметрами (для отладки модели)
• юнит-тесты для всего этого
• м.б. ещё что-то, будет видно в процессе

Мы строим GP модель на некотором наборе данных, и потом нужно использовать полученный posterior как prior на новом наборе данных, чтобы не переобучать модель целиком. В pymc3 это вроде бы нельзя реализовать. Возможно стоит посмотреть в сторону GPy, или придумать другие варианты для этого.

Нужно из отдельных файлов данных (DATA/raw/) собрать датасет, где для разных сенсоров в разные моменты времени будут собраны показание сенсора, признаки местоположения сенсоров, признаки погоды. В результате должгна быть dvc stage, которая это делает.

Построить модель на основе GP для прогнозирования показаний сенсоров в различных пространственных точках в фиксированный (случайно выбранный) момент времени. Можно ориентироваться на https://www.aaai.org/ocs/index.php/AAAI/AAAI15/paper/viewFile/9712/9309

Посмотреть, как соотносятся друг с другом данные с сенсоров breath.moscow и мосэкомониторинга

Сейчас все что относиться к веб части свалено в кучу в src/web. Но логически там есть три отделных компонента - это бот, веб клиент и сервер, который загружает данные, запускает ML модели, реализует API для доступа к данным. Было бы неплохо, чтобы структура папок в проекте этому соответствовала.

Нужно выбрать метрику для сравнения posterior predictive distributions c валидационной выборкой, учитывая что мы предсказываем распределение величины, а не точечную оценку. В статье https://www.aaai.org/ocs/index.php/AAAI/AAAI15/paper/viewFile/9712/9309 используется Q-Q plot и RMSE, но м.б. есть смысл использовать что-то ещё.

Кажется, что должно быть быстрее

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

Сейчас всякие конфигурационные переменные, используемые в pipline, лежат в https://github.com/aerubanov/Proj_Air_Quality/blob/master/src/data/config.py, но многие из них так же повторяются и в https://github.com/aerubanov/Proj_Air_Quality/blob/master/dvc.yaml. Это потенциальный источник ошибок (в одном месте поменяли, а в другом забыли). Нужно это исправить с помощью https://dvc.org/doc/user-guide/project-structure/pipelines-files#templating, чтобы они были только в файле параметров.