Русский
Русский
English
Статистика
Реклама

Большие данные

Математика и пандемия COVID-19

23.11.2020 14:22:47 | Автор: admin

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


Тоже слежу за этим с самого начала и заметил некоторые особенности распространения коронавируса в мире, о них и поговорим.


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


Первой переменной в нашем "уравнении" будет витамин D.

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


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


Вот мы и перешли ко второй переменной солнечный свет.

Здесь немного подробнее.


Начнем с географии. Как известно, условная линия сечения, которая называется экватором делит Землю на две половины Северное полушарие и Южное полушарие (Рис 1).


image

Рис 1. Территория Северного полушария (выделена желтым) и Южного полушария

Тепловые пояса (или пояса освещенности). В зависимости от количества солнечного света, падающего на поверхность Земли, на земном шаре выделяют 5 тепловых поясов: тропический, два умеренных, два полярных пояса.


image

Рис 2. Тепловые пояса Земли

Астрономия и смена времен года на Земле. Наклон оси вращения Земли главная причина смены времён года. Из-за него к источнику тепла полушария приближаются по очереди во время вращения планеты вокруг Солнца. На получающей большую часть тепла половине небесного тела наступает лето, а другая в этот период прогревается слабее, что приводит к наступлению зимы.


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


image

Рис 3. Смена времен года в Северном полушарии и Южном полушарии

У нас есть две переменные солнечный свет, витамин D, а также зависимость: больше солнечного света (нахождения на свету) больше витамина D в организме.
Теперь возьмем по три страны Южного и Северного полушарий и рассмотрим график распространения коронавирусной инфекции по месяцам:


image
image
image

Рис 4. Распространение коронавируса в Австралии, Южной Африке, Аргентине

Как видно из Рис 4. рост количества заражений в Южной Африке и Австралии пришелся на холодный зимний период для Южного полушария (июнь, июль, август), а уже с началом весны пошел спад (сентябрь). В Аргентине рост также пришелся на аргентинскую зиму, а спад пошел с середины весны (октябрь).


image
image
image

Рис 5. Распространение коронавируса в Великобритании, Канаде, России


Как видно из Рис 5. после летнего спада рост количества заражений в Великобритании, Канаде и России, как и в Северном полушарии в целом пришелся уже на начало осени (сентябрь).


Выводы:

В осенне-зимний период меньше солнечных дней, соответственно меньше витамина D в организме человека.


Здесь мы получаем "производную" нашего "уравнения" (функции) степень заразности коронавируса в зависимости от числа носителей с дефицитом витамина D. Людей с дефицитом этого витамина в это время года становится больше, а значит коронавирус легче распространяется среди населения.


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


Решение:


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

Для этого необходимо:


1 сделать доступным (по финансам и времени) анализ на содержание витамина D в организме для всех групп населения.
2 следить, чтоб в аптеках и в магазинах лекарства (БАД тоже) и продукты его содержащие также были доступны.
3 поддержка со стороны государства и СМИ этой акции.

Подробнее..

Математика и пандемия COVID-19. Часть 2

25.11.2020 20:07:40 | Автор: admin
Это мой второй материал на этом ресурсе посвященный пандемии COVID-19. Очень понравилось, что первый материал был не только прочитан большим количеством пользователей, но и еще у некоторых возникали вопросы, которые они оставили в после прочтения. Постараюсь ответить на эти вопросы в русле отмеченных там наблюдений.

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

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

Поехали!

Сезонность и витамин D

Вернемся снова к Северному и Южному полушарию Земли (Рис. 1). Это строгое разделение на полушария условно и переход от одного к другому (по климату, по животному и растительному миру) плавный, как на Рис. 2 с тепловыми поясами.

image
Рис 1. Территория Северного полушария (выделена желтым) и Южного полушария

image
Рис 2. Тепловые пояса Земли

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

Упрощение состоит в том, чтобы рассматривать эту модель Мира, как разделенную на два полушария и при таком разделении мы увидим, как распространение коронавируса одномоментно обострилось именно с началом осенне-зимнего сезона в каждом полушарии, а спало уже весной-летом. А если смотреть частности, то это хорошо видно по крайним странам, которые дальше от экватора (поэтому в прошлый раз выбрали Австралию, ЮАР, Аргентину, Великобританию, Канаду и Россию).

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

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

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

Нет никаких повальных анализов на витамин D, возможно эти исследователи поэтому и не могут найти связи

Испания, Италия И Узбекистан.

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

Чем больше изучаешь эту тему, тем больше открытий для себя. Удивительным оказалось, что большой процент населения стран средиземного моря и вообще южных стран испытывает недостаток витамина D в организме, имея при этом более 300 солнечных дней в году за окном. В каждой стране есть свои особенности этого явления, где-то это сиеста (продленный обеденный перерыв), где-то это повсеместное использование крема от загара (более 90% защиты от ультрафиолета), где-то традиционная одежда (в странах востока, где носят закрытую одежду), а кое-где даже гастрономические особенности (оказалось, что помидоры защищают от ультрафиолета).

Но есть и общее это фототипы кожи.

Шкала Фитцпатрика или шкала фототипов кожи Фитцпатрика, также тест Фитцпатрика числовая шкала, основанная на классификации цвета кожи человека.

image
Рис 3 Фототипы кожи по Фитцпатрику

image
Рис 3.1 Фототипы кожи по Фитцпатрику

Классификация фототипов кожи по Фитцпатрику:

Кельтский. Люди этого фототипа имеют самый светлый оттенок кожи. Они практически никогда не загорают (их кожа не принимает загар), риск возникновения солнечных ожогов (обгорания) очень велик.

Светлый европейский. Кожа этого типа также характеризуется светлым оттенком и высокой чувствительностью к УФ-излучению. Риск обгорания велик, как и в предыдущем случае. Однако светлый европейский фототип кожи незначительно, но принимает загар.

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

Средиземноморский. Светло-коричневый оттенок кожи. Шанс солнечного ожога минимальный. Загар на кожу ложится всегда хорошо.

Средне-восточный. Коричневый оттенок кожи. Люди с этим фототипом кожи практически никогда не обгорают на солнце. Загар характеризуется тёмным оттенком.

Африканский. Люди этого фототипа имеют наиболее тёмный оттенок кожи. Шанс обгорания на солнце практически нулевой. Загар лишь делает кожу ещё темнее.

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

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

Теперь перейдем к следующей зависимости. Различные иностранные источники сообщают, что в на Западе повышенная заболеваемость и смертность от коронавируса наблюдается среди темнокожих (и вообще среди южных мигрантов).
И основной вывод, что все это происходит из-за классового неравенства. Но дело возможно в другом

image
Рис 4. Карта Мира по уровню солнечной инсоляции

Здесь вспоминаем про шкалу Фитцпатрика, смотрим на Рис 4. карту Мира по уровню солнечной инсоляции на регион в котором сформировалась негроидная раса (Африка) и регион в котором некоторые ее представители проживают сейчас (США, Канада, Европа) и понимаем, что людям этого фототипа кожи в этих широтах хронически не хватает солнца, а с ним, как следствие и витамина D в организме.

У медали две стороны, если одна сторона медали США с афроамериканцами и хроническим недостатком солнца для их типа кожи, то вторая это Австралия и Новая Зеландия, где большинство это белые европейцы с переизбытком солнца для их типа кожи и как следствие, Австралия и Новая Зеландия являются одними из лидеров по количеству заболеваний меланомой.

Продолжение следует
Подробнее..

Перевод Мониторинг качества воздуха c помощью данных TROPOMI в Google Earth Engine

01.07.2020 20:13:32 | Автор: admin


Доступ к воздуху, безопасному для дыхания, очень важен для планеты и её жителей. Однако сейчас во многих частях света люди и хрупкие экосистемы страдают от воздействия загрязнённой атмосферы. В одних только США плохое качество воздуха ежегодно становится причиной около 60,000 случаев преждевременной смерти и обходится государству более чем в 150 млн. долларов, которые тратятся на лечение связанных с этим недугов.


Сейчас, в период социального дистанцирования и перекрытых границ, во многих регионах происходит снижение выбросов загрязняющих веществ. Фактически мы наблюдаем новое состояние качества воздуха, связанное с отсутствием характерных выбросов от транспорта и иных источников. Атмосфера очищается, и спутники NASA и ESA регистрируют снижение концентрации NO2 над многими городами и транспортными коридорами.



Средняя континентальная концентрация диоксида азота в тропосфере, март 2019. Концентрация увеличивается вдоль градиента от пурпурного к жёлтому.


Контролируя качество воздуха, метеорологи могут прогнозировать и предупреждать периоды его ухудшения, когда людям следует оставаться внутри помещений. Кроме того, учёные отслеживают историю изменений качества воздуха, чтобы понять влияние антропогенных и природных процессов на выбросы загрязняющих веществв атмосферу. Для некоторых веществ такие изменения в концентрации фиксируются спутниками. Одним из устройств, которые собирают такие замеры, является прибор для изучения тропосферыTROPOMI (Tropospheric Monitoring Instrument),установленный на борту космического аппаратаSentinel-5 Precursor (S5P), который в настоящее время находится на орбите.


СпутникS5P был запущен в октябре 2017 года для обеспечения непрерывности сбора данных после вывода из эксплуатации аппаратов Envisat (ESA) и Aura (NASA), а также в преддверии запуска Sentinel-5. S5Pимеет на борту многоспектральный датчик TROPOMI, который регистрирует отражательную способность длин волн, взаимодействующих с различными составляющими атмосферы, включая аэрозоли, моноокисьуглерода, формальдегид, диоксид азота, озон, диоксид серы и метан. S5P также позволяет оценивать некоторые характеристики облачности. Цель этой статьи предоставить краткий обзор данных о выбросах, которые регистрирует TROPOMI, а также продемонстрировать возможности использования платформы Earth Engine для анализа и отображения этой информации. Приведённые ниже сведения следует рассматривать как общее руководство для практического использования данных и платформы, но не как источник выводов о последствиях социального дистанцирования и его влиянии на качество воздуха.


Атмосферные выбросы от лесных пожаров


Горение биомассы в результате пожара может привести к выбросу большого количества дымовых аэрозолей. Отслеживать перенос такого аэрозольного шлейфа в течение дней и даже недель позволяет ежедневная частота и глобальный охват измерений с S5P. На рисунке нижеанимация временного ряда изображений, отражающихциркуляцию аэрозолей, вызванных мощными пожарами австралийских кустарников 20192020 годов, которые в итоге повлияли на качество воздуха в городах Южной Америки. Результаты измерений УФ-аэрозольного индекса, которые использовались в этом случае, применяются и для отслеживания других аэрозольных выбросов, таких как песчаные бури и вулканический пепел.



Аэрозольный шлейф от мощных австралийских кустарниковых пожаров 20192020 годов, распространяющийся на восток через Тихий океан. Анимация по мотивам исследований Сары Апарисио (Sara Aparcio).


Анимация отличное средство визуализации данных, но для количественной оценки временных изменений в загрязнении воздуха зачастую целесообразно использовать растровую алгебру (image math). В следующем примере вычитаются данные на две даты, характеризующие концентрацию угарного газа (CO) до и во времяпожаров в лесах Амазонки в 2019 году. Цель выделить те регионы, где концентрация увеличилась в два и более раз, в результате чего Всемирная организация здравоохранения выпустила предупреждение о чрезмерном загрязнении воздуха.



Разница в концентрациях оксида углерода до и во время пожаров в Амазонке в 2019 году. На картах до (Before) и во время (During) концентрация увеличивается вдоль градиента от фиолетового к жёлтому, а для карты разница (Difference) от чёрного к белому (карта отмаскирована для выделения областей, в которых во время пожаров произошло как минимум удвоение концентрации угарного газа).


Антропогенные атмосферные выбросы


Сжигание ископаемого топлива для нужд промышленности, транспорта и генерации тепла способствует загрязнению воздуха. Слой с данными о концентрации диоксида азота (NO2) хорошо подходит для анализа подобных типов выбросов, поскольку этот газ имеет короткий срок существования, и, как следствие, регистрируется вблизи источника выбросов. К примеру, визуализируя плотность населения (Gridded Population of World dataset) и высокие концентрации NO2 относительно друг друга, можно выявить пространственную корреляцию между плотностью населения и концентрациями NO2 на восточном побережье США.



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


На сдвоенной карте сверху и на диаграмме снизу показано, что с увеличением плотности населения усиливается и концентрация NO2 (подробнеео построении графиков в Earth Engine читайте в соответствующем разделе документации).



Связь между плотностью населения и концентрацией тропосферного диоксида азота (NO2) в зимний период в США к востоку от р. Миссисипи. Интерполированные графики NO2 для среднего и межквартального диапазона представлены для интервалов плотности населения от 0 до 20,000 человек/км2 с шагом 2,000 человек/км2, где последний интервал представляет районы с плотностью более 20 000 человек / км2.


В настоящее время большая часть мира практикует социальное дистанцирование с целью снижения воздействия нового типа коронавируса. С уменьшением числа людей, которые ездят на работу, снижаются и атмосферные выбросы диоксида азота (см. интерпретацию от NASA). Использование данных TROPOMI и платформы Earth Engine позволяет учёным исследовать подобные взаимосвязи и закономерности практически в режиме реального времени, а также в региональном и глобальном масштабах. Один из пользователей, Кристина Вринчану (Cristina Vrinceanu), создала приложение Earth Engine, в котором реализован виджет-слайдер для визуализации снижения концентрации диоксида азота в регионах, находящихся на карантине. Так, в приложении Кристины и сопутствующей статье в Medium исследуется регион севера Италии, который в борьбе с распространением вируса применяет в том числе и карантинные ограничения.



Приложение Earth Engine демонстрирует применение виджета-слайдера для сравнения концентрации NO2 за два различных периода времени. (Приложение от Кристины Вринчану).


Ещё один наглядный способ визуализации изменений концентрации загрязняющих веществ в воздухе с течением времени это годовой график. Следующая диаграмма демонстрирует и этот подход, сравнивая по дням концентрацию диоксида азота в период с 2019 по 2020 год в северной Италии.



Среднегодовые временные ряды NO2 в сравнении со значениями концентрации 2020 года и 2019 года, представленные для Паданской низменности на севере Италии (включает Милан, Болонью и Венецию).


Важные дополнения


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


В некоторых регионах мира определённые сочетания экологии, климата, погоды, географии и выбросов приводят к вариациямконцентрации загрязняющих веществ. Так, для китайской провинции Хубэй характерны сезонные тренды концентраций NO2, что видно на следующем рисунке, на котором изображена серия наблюдений за последний 21 месяц, подкреплённая гармонической линией тренда. Линия трендаполезна для выделения регулярных сезонных колебаний, а также для обособления высокой дисперсии в зимние месяцы, вызваннойсменой погоды. Для того, чтобы не делать выводов на основе отдельных измерений, которые могут представлять аномальные наблюдения, связанные с погодой, рекомендуется использовать линии тренда и вычислять скользящие средние за недели или месяцы наблюдений. Ламсай и др (Lamsai et al., 2010) приводят подробный анализ сезонных тенденций в отношении NO2.



Концентрация NO2 в южной провинции Хэбэй, Китай. Точками представлены результаты измерений; линия представляет собой функцию гармонического тренда для иллюстрации сезонных колебаний.


Точно так же сезонные колебания характеры и для концентраций озона, что показано на следующем графике, который отражает фактические и гармонически интерполированные данные наблюдений атмосферы над районом Великих озёр в Соединённых Штатах (подробнее о гармоническом моделировании в Earth Engine читайте в соответствующем разделе документации).



Временные ряды концентрации озона для района Великих озер в США. Точками представлены результаты измерений; линия представляет собой функцию гармонического тренда для иллюстрации сезонных колебаний.


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



Динамика изменений среднего и межквартального диапазона облачной фракции для продукта NO2, представленная для региона северной Италии. Доля облачности может значительноварьироваться по времени, поэтому,чтобы обеспечить надёжную оценку изменений качества воздуха, рекомендуется ограничивать данные наблюдений S5P выборкой безоблачных или малооблачных условий.


Приложение TROPOMI Explorer


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



Интерактивное приложение для исследования данных TROPOMI, созданное с использованием Google Earth Engine Apps.


Хотя многие сейчас находятся на самоизоляции, сообщество пользователей и разработчиков платформы Earth Engine продолжает активно обмениваться идеями. Посмотрите, как другие анализируют и изучают данные S5P TROPOMI с помощью Earth Engine:



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


Перевод подготовлен преподавателями Инженерной академии Российского университета дружбы народов Василием Лобановым и Ярославом Васюниным.


Эта работа лицензируется в соответствии с Creative Commons Attribution 4.0 International License (CC BY 4.0)

Подробнее..

Как стартап находит ground truth данные в сельском хозяйстве

25.11.2020 18:12:55 | Автор: admin

Компания OneSoil разрабатывает бесплатные приложения для фермеров, которыми пользуются более чем в 180 странах мира. В своей работе мы используем большие данные и машинное обучение, и отдельный квест для нас найти ground truth данные. Рассказываем, как мы решаем эту нетривиальную задачу.

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

Разберёмся на примере определения границ полей по спутниковым снимкам. Для фермера обвести границы своего поля это самый первый шаг в процессе цифровизации своего хозяйства. Это краеугольный камень, без которого никакая другая работа в приложениях невозможна. И задача не такая простая: раньше фермеры решали её за счёт того, что объезжали на квадроциклах свои поля с GPS-трекерами, мучались с ортофотопланами, короче, это было дорого и долго. OneSoil же научился распознавать границы полей по спутниковым снимкам: открываешь приложение, нажимаешь кнопку добавить поля, выбираешь на карте с распознанным полями своё и всё.

Как мы это сделали? Сперва у нас были данные лишь от нескольких хозяйств в Беларуси и Прибалтике, по которым алгоритмы машинного обучения учились предсказывать границы полей. Это работало так: для каждого настоящего поля (границы которого мы знали благодаря хозяйствам) мы считали площадь совпадения с границами, которые предсказали алгоритмы. Если алгоритм обвёл лишние участки он за это получал штраф. Так и учился. Такой показатель называется intersection over union, он может принимать значения от 0 до 1, где 1 идеальное совпадение. У нас этот показатель варьируется от региона к региону, но в среднем составляет 0,850,88.

Потом мы начали показывать нейросети миллионы изображений сельскохозяйственных полей для того, чтобы она научилась определять, где поле, а где, нет. Алгоритм долго учится, мы смотрим на результаты и много раз улучшаем его, пока точность определения границ полей для конкретного региона не станет хорошей. Как мы понимаем, что точность улучшилась? Опять же сравниваем наши расчёты с реальными данными по полям. Сейчас стран, в которых мы хорошо определяем границы полей, 57.

Пример работы наших алгоритмов карта сельскохозяйственных полей и культур OneSoil MapПример работы наших алгоритмов карта сельскохозяйственных полей и культур OneSoil Map

Когда мы уверенно определяем поля, скажем, в Украине, это не значит, что всё будет работать так же где-нибудь в Бразилии ведь там свои поля и свои особенности сельского хозяйства. Поэтому нам снова нужны реальные данные, чтобы уточнять и улучшать наш алгоритм.

Без данных по реальным полям нам никуда. А найти их это непростая задача, приходится подключать самые разные ресурсы. Как мы это делаем? Рассказываем дальше.

Мы получаем данные от пользователей

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

На всякий случай, сделаем одно банальное уточнение. Все данные пользователей поступают в наши алгоритмы в общем виде. Нам (точнее, нашим нейросетям), совершенно не важно, кому принадлежат поля. Алгоритму нужно знать, что растёт на полях в регионе в принципе. Иными словами, не важно, что поле кукурузы принадлежит Марье Ивановне из деревни Иваново под Черниговом. Важно, сколько полей кукурузы в Черниговской области есть в целом. Нас не интересуют детали, нас интересует большая картина. Поэтому данные пользователей в приложениях OneSoil находятся в безопасности, и при этом ещё помогают нейросетям становиться умнее.

133 млн га | 2,8 млн полей данные, которые пользователи занесли в платформу OneSoil. Ноябрь 2020 г.

Мы общаемся

Наша R&D команда постоянно знакомится с институтами и отдельными исследователями, которые работают в том же направлении, что и мы. Часто они находят нас сами.

После выхода интерактивной карты OneSoil Map в 2018 году нам написал Гвидо Лемуан (Guido Lemoine), руководитель одного из подразделений в исследовательском институте Joint Research Center (JRC). А в прошлом году на конференции Европейского космического агентства (ESA) наша специалистка по Data Science Кристина Бутько познакомилась с ним лично. Они поделились списком открытых источников данных, которыми пользуются сами и которые не так-то просто найти, рассказывает Кристина. Я очень жду их уникальный датасет по фенофазам растений, которые они собирали на протяжении двух лет полевых исследований. Наша R&D команда активно решает задачу предсказания стадий роста культур по спутниковым снимкам, и датасет от JRC поможет приблизиться к успеху.

Симпозиум Living Planet от Европейского космического агентства, май 2019. Наша Кристина слеваСимпозиум Living Planet от Европейского космического агентства, май 2019. Наша Кристина слева

Мы обмениваемся

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

В прошлом году несколько десятков украинских и российских компаний в обмен на анализ своих данных предоставили нам информацию за 4 года по полям общей площадью 7 миллионов гектаров. В эту базу данных входит информация по культурам, датам сева, датам уборки и средней урожайности настоящий подарок для нашей команды R&D. Во многом благодаря анализу этих данных мы можем определять дату сева на полях Украины с точностью в 23 дня и помогать лучше планировать полевые работы. Дальше больше. В 2020 году мы проведём эксперименты по дифференцированному посеву на полях общей площадью более 100 тысяч гектаров рассказывает Сева.

Сева исследует поля для одного из экспериментовСева исследует поля для одного из экспериментов

Мы спрашиваем

В 2018 году наш CEO Слава Мазай написал письмо Канаде. Нам не хватало данных по полям и культурам в этой стране для того, чтобы проверить точность расчётов алгоритмов машинного обучения. Поэтому Слава написал в одно из министерств Канады письмо, которое так и начиналось: Уважаемая Канада. Серьёзно.

Оказывается, так можноОказывается, так можно

Чудо в том, что они ответили. Год спустя нам прислали ответное письмо. Так мы получили данные по 50 тысячам полей в трёх провинциях, которые помогли нам точнее распознавать культуры в Канаде и сделать платформу OneSoil ещё более удобной для фермеров региона.

392 млн га | 126 млн полей объём ground truth данных. Ноябрь 2020 г.

Когда у нас есть много данных из открытых источников и от разных партнёров, мы улучшаем наши алгоритмы, которые уже используем в приложениях OneSoil (или будем в ближайшем будущем). Когда у нас много данных от пользователей, мы снова-таки улучшаем точность наших расчётов. Вот так данные и технологии работают друг на друга.

Подробнее..

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

28.12.2020 20:06:16 | Автор: admin

Чтобы фермер мог следить за своими полями при помощи смартфона, компания OneSoil обрабатывает терабайты спутниковых изображений и превращает их в удобные карты NDVI. Если по-простому, это такие разноцветные картинки, по которым можно судить о здоровье посевов. Это следующий шаг после того, как фермер нашёл свои поля с предсказанными нами границами на карте мира (про это было в одном из прошлых постов).

NDVI (Normalized difference vegetation index, Нормализованный вегетационный индекс) это числовой показатель качества и количества растительности на участке поля. Он рассчитывается по спутниковым снимкам и зависит от того, как растения отражают и поглощают световые волны разной длины. Здоровое растение активно поглощает красный свет и отражает ближний инфракрасный, а больное ровно наоборот. Все эти данные улавливает спутник при помощи своих датчиков. Вообще вегетационных индексов масса, NDVI это самый распространённый.

1 просто кусочек карты мира, а 2 карта NDVI для поля, которое мы там нашли1 просто кусочек карты мира, а 2 карта NDVI для поля, которое мы там нашли

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

Шаг 1: спутники фотографируют Землю

В приложениях OneSoil мы используем изображения спутников Sentinel-2 программы Copernicus. Copernicus это спутниковая программа наблюдения и мониторинга Земли, запущенная Европейской комиссией. Снимки Sentinel-2 хорошо подходят для нужд сельского хозяйства, так как они имеют разрешение 10 метров и обновляются каждые 3-5 дней.

Спутникам нужно 10 дней, чтобы облететь Землю 143 раза по орбите. За это время они делают снимки всей поверхности Земли. Далее эти фотографии отправляются в наземные центры обработки и архивирования данных, где изображения обрабатываются, нарезаются на более мелкие квадраты и загружаются в облачное хранилище Copernicus. Туда они попадают спустя 2-12 часов после съёмки.

3 орбиты спутников Sentinel, 4 сетка снимков Sentinel-23 орбиты спутников Sentinel, 4 сетка снимков Sentinel-2

В этот момент вступаем в игру мы.

Шаг 2: Мы обрабатываем спутниковые снимки

Наша цель показать точный индекс NDVI как можно скорее. Ежедневно мы получаем около 300 гигабайтов необработанных данных. Это от 200 до 300 спутниковых изображений, каждое из которых отображает площадь 100 на 100 км. Чтобы использовать их при расчёте NDVI, мы автоматически сжимаем полученные данные и обрабатываем их.

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

Спутниковый снимок до (5) и после (6) распознавания облаков Спутниковый снимок до (5) и после (6) распознавания облаков

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

NIR ближний инфракрасный диапазон, а RED красный диапазон

Затем мы расшифровываем рассчитанные значения и задаём им цвета в диапазоне от тёмно-коричневого до ярко-зелёного. Чем зеленее, тем выше NDVI. Такую раскраску и цифровое значение индекса NDVI для полей и видят фермеры в наших приложениях.

Шаг 3: Фермер смотрит на карты вегетации и делает выводы

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

Это и есть самый базовый сценарий использования NDVI дистанционный осмотр поля. Сидя дома на диване, фермер может по индексу вегетации понять, на каких участках поля растения развиваются нормально, а на каких нет. И вот в эти проблемные участки он сразу и едет. Это сильно экономит время и деньги на оплату работы или бензин для машины. Просто представьте, что поле в 1 га это 100 на 100 метров, чуть больше, чем обычное футбольное поле. Быстрым шагом такой участок можно обойти минут за пять. Просто обойти без возможности понять, что же там в глубине происходит. Когда ты фермер, площадь твоих полей может достигать нескольких десятков тысяч гектар, а осматривать их нужно практически круглый год. Вот в таком случае и пригодятся карты NDVI, которые мы показываем в наших приложениях.

Подробнее..

Прикручиваем ИИ оптимизация работы банкоматов

20.04.2021 10:21:38 | Автор: admin
Всем привет! Это небольшой рассказ про то, как команда Центра компетенции больших данных и искусственного интеллекта в ЛАНИТ оптимизировала работу банкоматной сети. Упор в статье сделан не на описание подбора параметров и выбор лучшего алгоритма прогнозирования, а на рассмотрение концепции нашего подхода к решению поставленной задачи. Кому интересно, добро пожаловать под кат.

источник

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

Таким образом, формальная постановка задачи выглядит так.

На входе:

  • есть история снятия/приема наличности в банкоматах (в нашем случае это были данные за полтора года);
  • стоимость потерь от нахождения денег в банкоматах (от простаивающих запасов) зависит от ставки рефинансирования (параметр q); стоимость можно оценить как $S*X*(\frac{q}{365})$, где S сумма, X количество дней;
  • стоимость поездки инкассаторов, si (меняется со временем и зависит от местоположения банкомата и маршрута инкассаторов).

На выходе ожидается:

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

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

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

Предположим, что в день снимают S руб. Помимо суммы снятий, введем также переменную X число дней между инкассациями, меняя которую будем дальше искать минимум затрат банка. Логично, что сумма, которую выгоднее всего положить в банкомат, зная, что инкассация будет через X дней это S*X. При таком подходе за день до инкассации в банкомате будет находиться S руб., за два дня 2*S руб., за три дня 3*S руб. и т. д. Другими словами, наш ряд можно рассматривать, двигаясь от конца к началу, тогда это будет возрастающая арифметическая прогрессия. Поэтому за период между двумя инкассациями в банкомате будет лежать (S+S*X)/2 руб. Теперь, исходя из ставки рефинансирования, остаётся посчитать стоимость простаивающих запасов этой суммы за X дней и дополнительно прибавить стоимость совершённых инкассаторских поездок. Если между инкассациями X дней, то за n дней будет совершено $[\frac{n}{X}]+1$ (где $[\frac{n}{X}]$ это целочисленное деление) инкассаций, поскольку ещё один раз придётся приехать, чтобы вывести остаток денег.

Таким образом, получившаяся функция выглядит так:

$TotalCost(S, X, n, q, si) = (S + S*X)/2*\frac{q}{365}+si*([\frac{n}{X}]+1)$


где:

  • S сумма снятий, руб./день,
  • X количество дней между инкассациями,
  • n рассматриваемый период в днях,
  • q ставка рефинансирования,
  • si стоимость инкассации.

Однако в реальности каждый день снимают разные суммы, поэтому у нас есть ряд снятий/внесений купюр, каждый день этот ряд пополняется новыми значениями. Если это учесть, функция примет следующий вид:

$TotalCost = \sum_{i=1}^{n}Q_{i}*\frac{q}{365} + si*([\frac{n}{X}]+1) \\ q - ставка\, рефинансирования, \\ n - количество\, рассматриваемых\, дней, \\ X - количество\, дней\, между\, инкассациями, \\ Q_{i} - сумма\, в\, банкомате\, на\, iй\, день,\, Q_{i} = encash_{i} - \sum_{k=[\frac{i}{X}]*X}^{i}S_{k} \\ S_{k} - изменение\, суммы\, в\, банкомате\, на\, kй\, день, \\ encash_{i} - сумма\, последней\, на\, iй\, день\, инкассации, \\ encash_{i} = \begin{cases} \sum_{k=[\frac{i}{X}]*X}^{([\frac{i}{X}]*X+1)*X}S_{k}, \,\,\, если\,сумма\, убывающая \\ \\ \sum_{k=[\frac{i}{X}]*X}^{[\frac{i}{X}]*X+3}S_{k}^{-}, \,\,\, если\,сумма\, возрастающая \end{cases} \\ S_{k}^{-} - сумма\, снятий\, за\, kй\, день \\$


Что такое убывающие и возрастающие суммы: в зависимости от того, больше кладут или больше снимают, есть купюры, по которым сумма в банкомате накапливается, а есть купюры, по которым сумма в банкомате убывает. Таким образом формируются возрастающие и убывающие суммы купюр. В реализации было сделано три ряда: incr_sums возрастающие купюры, decr_sums убывающие купюры и withdrawal_sums ряд сумм выдач банкомата (там присутствуют купюры, которые идут только на выдачу).

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

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

  • Самое главное, сложное, и интересное в момент инкассации мы не знаем, какие это будут суммы, их нужно прогнозировать (об этом ниже).
  • Банкоматы бывают следующих типов:

    только на внос/вынос,
    на внос и вынос одновременно,
    на внос и вынос одновременно + ресайклинг (за счёт ресайклинга у банкомата есть возможность выдавать купюры, которые в него вносят другие клиенты).
  • Описанная функция также зависит от n количества рассматриваемых дней. Если подробнее рассмотреть эту зависимость на реальных примерах, то получится следующая картинка:

Рис. 1. Значения функции TotalCost в зависимости от X (Days betw incas) и n (Num of considered days)

Чтобы избавиться от n, можно воспользоваться простым трюком просто разделить значение функции на n. При этом мы усредняем и получаем среднюю величину стоимости затрат в день. Теперь функция затрат зависит только от количества дней между инкассациями. Это как раз тот параметр, по которому мы будем её минимизировать.

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

TotalCost(n, x, incr_sums, decr_sums, withdrawal_sums, si), где

  • x максимальное количество дней между инкассациями
  • n количество дней, которые отслеживаем, то есть мы смотрим последние n значений подаваемых на вход временных рядов (как написано выше, функция не зависит от n, этот параметр добавлен, чтобы можно было экспериментировать с длиной подаваемого временного ряда)
  • incr_sums ряд спрогнозированных сумм по купюрам только на внос,
  • decr_sums ряд спрогнозированных сумм по купюрам только на вынос,
  • withdrawal_sums ряд спрогнозированных сумм выдач банкомата (т.е. здесь сумма по купюрам in минус сумма по out), заполняется 0 для всех банкоматов кроме ресайклинговых,
  • si стоимость инкассации.

Функция проходит непересекающимся окном величиной X по входным рядам и считает суммы внесенных денег внутри окна. В отличие от первоначальной функции сумма арифметической прогрессии здесь превращается в обычную сумму (это та сумма, которая была заложена при инкассации). Далее внутри окна в цикле по дням происходит кумулятивное суммирование/вычитание сумм, которые ежедневно клались/снимались из банкомата. Это делается для того, чтобы получить сумму, которая лежала в банкомате на каждый день.

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

Реализация
def process_intervals(n, x, incr_sums, decr_sums, withdrawal_sums):# генератор количества сумм, которые# остаются в банкомате на каждый день# incr_sums  ряд возрастающих сумм# decr_sums  ряд убывающих сумм# withdrawal_sums  ряд сумм выдач банкомата (там присутствуют купюры, которые идут только на выдачу)# заполняется 0 для всех банкоматов кроме ресайклинговых# x  количество дней между инкассациями# n  количество дней, которые отслеживаемif x>n: returnfor i in range(n//x):decr_interval = decr_sums[i*x:i*x+x]incr_interval = incr_sums[i*x:i*x+x]withdrawal_interval = withdrawal_sums[i*x:i*x+x]interval_sum = np.sum(decr_interval)interval_sum += np.sum(withdrawal_interval[:3])for i, day_sum in enumerate(decr_interval):interval_sum -= day_suminterval_sum += incr_interval[i]interval_sum += withdrawal_interval[i]yield interval_sum# остаток сумм. Берется целый интервал.# но yield только для остатка рядаdecr_interval = decr_sums[(n//x)*x:(n//x)*x+x]incr_interval = incr_sums[(n//x)*x:(n//x)*x+x]withdrawal_interval = withdrawal_sums[(n//x)*x:(n//x)*x+x]interval_sum = np.sum(decr_interval)interval_sum += np.sum(withdrawal_sums[:3])for i, day_sum in enumerate(decr_interval[:n-(n//x)*x]):interval_sum -= day_suminterval_sum += incr_interval[i]interval_sum += withdrawal_sums[i]yield interval_sumdef waiting_cost(n, x, incr_sums, decr_sums, withdrawal_sums, si):# incr_sums  ряд возрастающих сумм# decr_sums  ряд убывающих сумм# withdrawal_sums  ряд сумм выдач банкомата (там присутствуют купюры, которые идут только на выдачу)# заполняется 0 для всех банкоматов кроме ресайклинговых# si  стоимость инкассации# x  количество дней между инкассациями# n  количество дней, которое отслеживаемassert len(incr_sums)==len(decr_sums)q = 4.25/100/365processed_sums = list(process_intervals(n, x, incr_sums, decr_sums, withdrawal_sums))# waiting_cost = np.sum(processed_sums)*q + si*(x+1)*n//xwaiting_cost = np.sum(processed_sums)*q + si*(n//x) + si# делим на n, чтобы получить среднюю сумму в день (не зависящее от количества дней)return waiting_cost/ndef TotalCost (incr_sums, decr_sums, withdrawal_sums, x_max=14, n=None, si=2500):# x  количество дней между инкассациями# n  количество дней, которое отслеживаемassert len(incr_sums)==len(decr_sums) and len(decr_sums)==len(withdrawal_sums)X = np.arange(1, x_max)if n is None: n=len(incr_sums)incr_sums = incr_sums[-n:]decr_sums = decr_sums[-n:]        withdrawal_sums = withdrawal_sums[-n:]waiting_cost_sums = np.zeros(len(X))for i, x in enumerate(X):waiting_cost_sums[i] = waiting_cost(n, x, incr_sums, decr_sums, withdrawal_sums, si)return waiting_cost_sums

Теперь применим эту функцию к историческим данным наших банкоматов и получим следующую картинку:

Рис. 2. Оптимальное количество дней между инкассациями

Резкие перепады на некоторых графиках объясняются провалами в данных. А то, что они произошли в одинаковое время, скорее всего можно объяснить техническими работами, на время которых банкоматы не работали.

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

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

Подробно останавливаться на том, как делается прогноз снятий и зачислений не буду. Если есть интерес к этой теме, то можно посмотреть видеодоклад о решении подобной задачи исследователями из Сбербанка (Data Science на примере управления банкоматной сетью банка).

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

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

Используемые признаки (всего их было 139, после признака приведено его обозначение на графике feature importance ниже)

  • Временные лаги целевых значений переменной, lag_* (их количество можно варьировать, но мы остановились на 31. К тому же, если мы хотим прогнозировать не на день вперед, а на неделю, то и первый лаг смотрится не за вчерашний день, а за неделю назад. Таким образом, максимально далеко мы смотрели на 31+14=45 дней назад).
  • Дельты между лагами, delta_lag*-lag*.
  • Полиномиальные признаки от лагов и их дельт, lag_*^* (использовались только первые 5 лагов и их дельт, обозначались).
  • День недели, месяца, номер месяца, weekday, day, month (категориальные переменные).
  • Тригонометрические функции от временных значений из пункта выше, weekday_cos и т.д.
  • Статистика (max, var, mean, median) для этого же дня недели, месяца, weekday_max, weekday_mean, (брались только дни, находящиеся раньше рассматриваемого в обучающей выборке).
  • Бинарные признаки выходных дней, когда банкоматы не работают, is_weekend
  • Значения целевой переменной за этот же день предыдущей недели/месяца, y_prev_week, y_prev_month.
  • Двойное экспоненциальное сглаживание + сглаживание по значениям целевой функции за те же дни предыдущих недели/месяца, weekday_exp_pred, monthday_exp_pred.
  • Попробовали tsfresh, tsfresh+PCA, но потом отказались от этого, поскольку этих признаков очень много, а объектов в обучающей выборке у нас было мало.

Важность признаков для модели следующая (приведена модель для прогноза снятий купюры номиналом в 1000 руб. на один день вперед):

Рис. 3.Feature importance используемых признаков

Выводы по картинкам выше наибольший вклад сделали лаговые признаки, дельты между ними, полиномиальные признаки и тригонометрические функции от даты/времени. Важно, что в своём прогнозе модель не опирается на какую-то одну фичу, а важность признаков равномерно убывает (правая часть графика на рис. 2).

Сам график прогноза выглядит следующим образом (по оси x отложены дни, по оси y количество купюр):

Рис. 4 Прогноз CatBoostRegressor

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

Ошибка по MAE там колеблется в примерном диапазоне от нескольких десятков до ста. Успешность прогноза сильно зависит от конкретного банкомата. Соответственно, величину реальной ошибки определяет номинал купюры.

Общий пайплайн работы выглядит следующим образом (пересчёт всех значений происходит раз в день).

  1. Для каждой купюры каждого atm на каждый прогнозируемый день своя модель (поскольку прогнозировать на день вперед и на неделю вперед разные вещи и снятия по различным купюрам также сильно разнятся), поэтому на каждый банкомат приходится около 100 моделей.
  2. По историческим данным банкомата при помощи функции TotalCost находится оптимальное количество дней до инкассации.
  3. Если найденное значение меньше 14 дней, то следующий день инкассации и закладываемая сумма подбираются по прогнозу, который кладется в функцию TotalCost, иначе по историческим данным.
  4. На основе прогноза либо исторических данных снятий/внесений наличности рассчитывается сумма, которую нужно заложить (т.е. количество закладываемых купюр).
  5. В банкомат закладывается сумма + ошибка.
  6. Ошибка: при закладывании денег в банкомат необходимо заложить больше денег, оставив подушку безопасности, на случай, если вдруг люди дружно захотят обналичить свои сбережения (чтобы перевести их во что-то более ценное). В качестве такой суммы можно брать средние снятия за последние 2-3 дня. В усложнённом варианте можно прогнозировать снятия за следующие 2-3 дня и дополнительно класть эту сумму (выбор варианта зависит от качества прогноза на конкретном банкомате)
  7. Теперь с каждым новым днём приходят значения реальных снятий, и оптимальный день инкассации пересчитывается. Чем ближе день инкассации, полученный по предварительному прогнозу, тем больше реальных данных мы кладём в TotalCost вместо прогноза, и точность работы увеличивается.

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

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

atm profit(relative) profit/day (руб.)
a 0.61 367
b 0.68 557
с 0.70 470
d 0.79 552
e -0.30 -66
f 0.49 102
g 0.41 128
h 0.49 98
i 0.34 112
j 0.48 120
k -0.01 -2
l -0.43 -26
m 0.127 34
n -0.03 -4
o -0.21 -57
p 0.14 24
q -0.21 -37

Подходы и улучшения, которые интересно рассмотреть, но пока не реализованы на практике (в силу комплексности их реализации и ограниченности во времени):

  • использовать нейронные сети для прогноза, возможно даже RL агента,
  • использовать одну модель, просто подавая в неё дополнительный признак, отвечающий за горизонт прогнозирования в днях.
  • построить эмбеддинги для банкоматов, в которых сагрегировать информацию о географии, посещаемости места, близости к магазинам/торговым центрам и т. д.
  • если оптимальный день инкассации (на втором шаге пайплайна) превышает 14 дней, рассчитывать оптимальный день инкассации по прогнозу другой модели, например, Prophet, SARIMA, или брать для этого не исторические данные, а исторические данные за прогнозируемый период с прошлого года/усредненный за последние несколько лет.
  • для банкоматов, у которых отрицательный профит, можно пробовать настраивать различные триггеры, при срабатывании которых работа с банкоматами ведется в старом режиме, либо инкассаторские поездки совершаются чаще/реже.

В заключение можно отметить, что временные ряды снятий/внесений наличности поддаются прогнозированию, и что в целом предложенный подход к оптимизации работы банкоматов является довольно успешным. При грубой оценке текущих результатов работы в день получается сэкономить около 2400 руб., соответственно, в месяц это 72 тыс. руб., а в год порядка 0,9 млн руб. Причём чем больше суммы денег, находящихся в обращении у банкомата, тем большего профита можно достичь (поскольку при небольших суммах профит нивелируется ошибкой от прогноза).

За ценные советы при подготовке статьи большая благодарность vladbalv и art_pro.

Спасибо за внимание!
Подробнее..

Business Intelligence на больших данных наш опыт интеграции

20.01.2021 14:20:49 | Автор: admin

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

Если вы читаете наш блог, то уже знаете о платформе Visiology хотя бы в общих чертах (если нет, это можно легко исправить, прочитав наш первый пост). Но сегодня речь пойдет не только о платформе Visiology и BI как таковых, но также о наших новых друзьях Arenadata. А точнее, об интеграции, которая позволила реализовать гибридную работу аналитики с большой скоростью и на больших объемах данных.

Зачем потребовалась интеграция Arenadata и Visiology?

Подходов к работе BI-систем на сегодняшний день несколько. Но когда речь идет о больших данных для самых разных задач, обычно используется ROLAP. Работает он достаточно просто: когда пользователь нажимает что-то на дашборде, например, выбирает какой-то фильтр, внутри платформы формируется SQL-запрос, который уходит на тот или иной бэкэнд. В принципе, под системой BI может лежать любая СУБД, которая поддерживает запросы от Postgres до Teradata. Подробнее о схемах работы OLAP я рассказывал здесь.

Преимущество интеграции BI с СУБД заключается в том, что для работы системы, по сути, нет ограничения по объему данных. Но при этом падает скорость выполнения запросов - конечно, если не использовать специализированную колоночную СУБД, например, ClickHouse или Vertica. И, хотя у ClickHouse спектр возможностей пока еще уже, чем у той же Vertica, система развивается и выглядит очень многообещающей.

Но даже с колоночной СУБД есть свои минусы при работе с BI, и самый первый из них это более низкая эффективность использования кэша на уровне платформы в целом, потому что СУБД, в отличие от самой BI-платформы, "не знает" многого о поведении пользователей и не может использовать эту информацию для оптимизации. Когда большое количество пользователей начинают работать, по-разному делать запросы и обращаться к дашбордам, требования к железу, на котором крутится СУБД даже хорошая, аналитическая и колоночная могут оказаться очень серьезными.

Второй момент это ограничение аналитической функциональности: все, что не укладывается в SQL-запрос, поддерживаемый распределенной СУБД, отсекается автоматически (например, в случае ClickHouse - это оконные функции). И это проблема, потому что в BI есть много вещей, которые с трудом транслируются в SQL-запросы или выполняются неоптимально.

Второй вариант это In-memory OLAP. Он подразумевает перенос всех обрабатываемых данных в специальный движок, который молниеносно прорабатывает базу в 200-300 Гб это порядок единицы миллиардов записей. Кстати, подробнее про ограничения In-Memory OLAP я уже рассказывал здесь. На практике встречаются инсталляции In-Memory OLAP, укомплектованные 1-2-3 терабайтами оперативной памяти, но это скорее экзотика, причем дорогостоящая.

Практика показывает, что далеко не всегда можно обойтись тем или иным подходом. Когда требуются одновременно гибкость, возможность работы с большим объемом данных и поддержка значительного количества пользователей, возникает потребность в гибридной системе, которая с одной стороны загружает данные в движок In-Memory OLAP, а с другой постоянно подтягивает нужные записи из СУБД. В этом случае движок OLAP используется для доступа ко всему массиву данных, без всяких задержек. И в отличие от чистого In-Memory OLAP, который нужно периодически перезагружать, в гибридной модели мы всегда получаем актуальные данные.

Такое разделение данных на горячие и холодные объединяет плюсы обоих подходов ROLAP и In-Memory, но усложняет проект внедрения BI. Например, разделение данных происходит вручную, на уровне ETL процедур. Поэтому для эффективной работы всего комплекса очень важна совместимость между бэкэндом и самой BI-системой. При том, что SQL-запросы остаются стандартными, в реальности всегда есть аспекты их выполнения, нюансы производительности.

Arenadata и Arenadata QuickMarts

Платформа данных Arenadata состоит из нескольких компонентов, построенных на базе открытых технологий, и используется многими российскими и зарубежными компаниями. В состав решения входит собственное MPP решение на базе Greenplum, дистрибутив Hadoop для хранения и обработки неструктурированных и слабоструктурированных данных, система централизованного управления ADCM (Сluster Management) на базе Ansible и другие полезные компоненты, в том числе Arenadata QuickMarts (ADQM).

СУБД ADQM это колоночная СУБД от Arenadata, построенная на базе ClickHouse, аналитической СУБД, которую развивает Яндекс. Изначально ClickHouse создавалась для внутреннего проекта Яндекс.Метрика, но эта СУБД очень понравилась сообществу. В результате исходный код ClickHouse был переведен в OpenSource (лицензия Apache-2) и стал популярен по всему миру. На сегодняшний день насчитывается порядка 1000 инсталляций ClickHouse по всему миру, и только 1/3 из них в России. И хотя Яндекс остается основным контрибьютором развития СУБД, лицензия Apache-2 позволяет абсолютно свободно использовать продукт и вносить изменения в проект.

Современная колоночная СУБД использует аппаратную оптимизацию CPU (SSE). ClickHouse может очень быстро выполнять запросы за счет векторных оптимизаций и утилизации всего ресурса многоядерных CPU. На базе ClickHouse работают огромные кластера сам Яндекс растягивает эту СУБД на несколько сотен серверов. Это гарантирует, что вместе с этим решением вы можете масштабироваться в достаточно больших объемах.

Но главная фича ClickHouse в нашем контексте это эффективная работа с достаточно специфическими аналитическими запросами. Если витрины уже отстроены и вам нужно предоставить доступ пользователей к BI с минимальной латентностью, эта история как раз для ClickHouse. Эта СУБД прекрасно справляется с запросами без джойнов и соединений.

Во многих сравнениях ClickHouse дает серьезную фору даже классическим СУБД, например, той же Oracle Exadata. Результаты этих тестов можно найти на ресурсах Яндекса.

Производительность QuickMarts

  • Типичные запросы быстрей чем за секунду

  • > 100 раз быстрей чем Hadoop и обычные СУБД

  • 100 млн - 1 миллиард строк в секунду на одной ноде

  • До 2 терабайт в секунду для кластера на 400 нод

Но вернемся к Arenadata QuickMarts. Это сборка ClickHouse, которая немного отличается от сборки Яндекса. Наши коллеги из Arenadata даже позже выпускают релизы, потому что проводят больше тестов, чтобы серьезные задачи в продакшене работали только на стабильных версиях.

При этом установка и настройка ADQM происходит из Arenadata Cluster Manager. Кастомизированная СУБД обладает расширенными механизмами авторизации пользователей, a также средствами мониторинга на базе Graphite и Grafana. Но самое главное, что QuickMarts изначально располагает готовыми коннекторами и прозрачно взаимодействует с другими компонентами платформы, в т.ч. с ADB (Greenplum), что позволяет по мере необходимости подгружать данные из ADB в ADQM.

В нашем случае QuickMarts используется для работы с витринами, к которым через BI обращаются сотни или тысячи пользователей. Архитектура системы позволяет выдать им данные здесь и сейчас, а не ждать 20-30 секунд, когда обработается их запрос по витринам в более медленной СУБД.

Как работает интеграция Arenadata и Visiology

Когда Visiology используется вместе с Arenadata, схема работы системы выглядит следующим образом. Основное хранилище данных может быть реализовано на базе ADB (GreenPlum), из которой создаются витрины данных, хранящиеся уже в ADQM. За счет интеграции между компонентами решения система работает как единое целое, а необходимые для запросов данные поднимаются на нужный уровень автоматически.

Фактически в аналитической системе создается только один дашборд, а графику обрабатывает движок In-Memory ViQube ядро платформы Visiology. Пользователь лишь выбирает те или иные фильтры, а задача по выгрузке самих транзакций выполняется уже на бэкенде ресурсами QuickMarts.

Раньше подобная интеграция была только с Vertica, но сейчас мы совместно с коллегами сделали интеграцию для Arenadata QuickMarts. Это радостная новость для сторонников ClickHouse, потому что BI работает с популярной СУБД по гибридной схеме. При этом Arenadata DB, выполняющая функцию корпоративного хранилища данных, обеспечивает необходимую трансформацию данных для дальнейшей работы QuickMarts и Visiology.

Все запросы BI обрабатываются движком ViQube. Если пользователь обращается к тем данным, которых нет в памяти, система автоматически генерирует SQL-запрос, который выполняется на Arenadata QuickMarts.

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

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

Развиваемся дальше

Сейчас интеграция находится на стадии версии v1.0, и мы планируем дальнейшие доработки. В частности, уже сейчас речь идет о том, чтобы расширить набор доступных аналитических возможностей, а также об интеграции в единую консоль управления (например, у Arenadata есть решение Cluster Manager (ADCM), которое позволяет управлять всеми компонентами ландшафта из единой консоли, рассматриваем это как один из вариантов).

Также на повестке дня остро стоит задача автоматизации настройки метаданных. Сейчас их нужно размечать в специальном интерфейсе - это довольно трудоемко. Хочется, чтобы система самостоятельно распознавала бы все необходимые параметры, получив путь к той или иной витрине.

В целом, мы остались очень довольны и сотрудничеством с Arenadata, и той интеграцией с ClickHouse и ADQM, которая получилась. Теперь в аналитической платформе Visiology можно одновременно работать с источниками данных любого масштаба - от Small Data (ручной ввод, Excel) до Big Data (миллиардов или даже сотни миллиардов транзакций из распределенных хранилищ данных). А гибридный режим работы, который мы реализовали вместе с Arenadata, еще и позволяет сделать это с разумными затратами на оборудование.

Будем признательны, если вы напишете в комментариях, с какими сценариями запуска BI на больших данных вы сталкивались. Ну а мы всегда готовы поделиться своим опытом в деталях!

Подробнее..

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

23.03.2021 20:04:37 | Автор: admin

Алгоритмы не работают без качественных данных. Общественность может использовать их, чтобы требовать перемен.

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

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

Теперь исследователи из Северо-Западного университета предлагают способ исправить дисбаланс сил. Они рассматривают нашу коллективную информацию как рычаг воздействия. В распоряжении технологических гигантов продвинутые алгоритмы; но они не имеют смысла без правильных данных для обучения.

На конференции Ассоциации за справедливость, подотчетность и прозрачность вычислительной техники было представлено новое исследование. Его авторы, в том числе аспиранты Николас Винсент и Ханлин Ли, предлагают три способа, которыми общественность может пользоваться для продвижения своих интересов:

  • Бойкот данных (Data strikes), вдохновленный забастовками рабочих. Он включает в себя скрытие или удаление вашей личной информации, чтобы технологическая компания не могла ее использовать. Можно покинуть платформу или установить инструменты для защиты конфиденциальности.

  • Порча данных (Data poisoning), которая включает в себя передачу бессмысленной или вредоносной информации. Так, можно пользоваться расширением для браузера AdNauseam. Оно нажимает на каждое рекламное объявление, показанное вам, и тем самым сбивает с толку алгоритмы таргетинга Google.

  • Осознанная публикация данных (Conscious data contribution), или предоставление значимых данных конкуренту платформы, против которой вы хотите протестовать. Загрузите ваши фотографии в Tumblr вместо Facebook, например.

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

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

Возможно, уже несколько раз удавалось это сделать. В январе миллионы пользователей удалили учетные записи WhatsApp и перешли к конкурентам, включая Signal и Telegram. Это произошло после того, как Facebook (владелец популярного мессенджера прим. пер) объявил, что откроет доступ к данным WhatsApp всей компании. Массовый исход вынудил Facebook отложить внесение изменений в политику.

Буквально на этой неделе Google также объявил, что прекратит отслеживать людей в сети и таргетировать рекламу. Пока неясно, реальное ли это изменение или ребрендинг. Винсент отмечает, что широкое использование инструментов вроде AdNauseam могло повлиять на это решение, так как снизило эффективность алгоритмов компании. (Конечно, точно сказать трудно. Только технологическая компания действительно знает, насколько эффективно использование данных повлияло на систему, говорит исследователь).

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

Приятно видеть такое исследование, говорит Али Алхатиб, научный сотрудник Центра прикладной этики данных Университета Сан-Франциско, не принимавший участия в исследовании. Интересно наблюдать, что авторы обращаются к коллективному или целостному подходу. Мы можем портить данные массово и предъявлять требования, угрожая этим. Потому что это наша информация, и вся вместе она формирует общий пул.

Еще предстоит проделать большую работу, чтобы развернуть эти кампании шире. Ученые могут сыграть важную роль в создании большего количества инструментов, таких как AdNauseam, чтобы помочь снизить барьер для участия. Политики тоже могут помочь. Бойкот данных наиболее эффективен, если он подкреплен строгими законами о конфиденциальности. Такими, как Общий регламент Европейского Союза о защите данных (GDPR), который дает пользователям право требовать удалить их информацию. Без регулирования сложнее гарантировать, что техническая компания позволит вам очистить ваш цифровой след, даже если вы удалите учетную запись.

Предстоит ответить еще на некоторые вопросы. Сколько человек должны участвовать в бойкоте данных, чтобы навредить алгоритмам компании? И какие данные были бы наиболее эффективными для порчи конкретной системы? Например, при моделировании алгоритма рекомендаций фильмов исследователи обнаружили, что если 30% пользователей объявят бойкот, это снизит точность системы на 50%. Но все алгоритмы машинного обучения разные, и компании постоянно обновляют их. Исследователи надеются, что участники сообществ машинного обучения смогут запускать аналогичные симуляции систем разных компаний и определять их уязвимости.

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

Он добавляет, что эта тактика может повлечь за собой последствия, которые требуют тщательного изучения. Закончится ли саботаж тем, что всего лишь добавит больше работы модераторам контента и другим людям, которым поручат очищать и маркировать данные обучения алгоритмов?

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

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


Читайте другие наши переводы на тему искусственного интеллекта:

Напоминаем, что для читателей Хабрав магазине гаджетов Madrobotsдействуетскидка 5%на все продукты.Введите промокод: HABR

Подробнее..

Перевод Участие в тестировани Incentivized Testnet глобальной децентрализованной мультиагентной системы

24.11.2020 18:14:36 | Автор: admin
Специально к старту курса Машинное обучение в этом материале знакомим читателей Хабра с Fetch.ai децентрализованной платформой для оптимизации существующих технологий с помощью искусственного интеллекта, машинного обучения и интеллектуального обмена данными. Платформу можно использовать, чтобы создать агента, например, программу, которая с учётом реальных обстоятельств рекомендует, когда сесть на поезд. Ещё один пример агент, контролирующий потребление электроэнергии. Подробности о самой Fetch.ai, датах тестирования сети агентов, список партнёров стартапа (который включает Кембриджский Университет) и ссылки на ресурсы, включая репозиторий GitHub, под катом.





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

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

Прогресс в области партнёрства где мы находимся сегодня?


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

Cambridge University, T-Labs, Batu Metallurgy, Warwick Business School, Wi-Q technologies, Hegic, Conflux Network, Waves, Ankr, Grey Swan Digital, Mobility Open Blockchain Initiative (MOBI), Sovrin Steward, Smart Dubai with Outlier Ventures, Trusted IoT Alliance, Blockchain 4 Europe.

Зачем это разработчику?



Вопрос на миллион, правда? Зачем вам присоединяться к этому в качестве разработчика? Сегодня мы в значительной степени незаметны не потому, что хотим оставаться незаметными, а потому, что хотим поддерживать дискуссию.

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

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

Но мы хотим пойти дальше. Наша цель запустить сеть Mainnet v2.0 в начале следующего года, и, чтобы не отклоняться от намеченных целей, мы разделили график разработки, разбив его на разные фазы. Сейчас мы находимся на первой фазе программы Incentivized Testnet, в которой запущен и работает Agent World 2. Если вы еще не присоединились к программе Incentivized Testnet, вы можете сделать это здесь.

В любом случае, где мы были? Мы тестируем Agent World 2 Testnet, в которой создаем агентов, помогающих решать проблемы серьёзнее, чем заказ пиццы. После начала партнёрских отношений с Datarella мы хотим использовать наших агентов для решения текущих проблем в области мобильности и изменения климата.

Имейте в виду, что агенты должны соответствовать правилам FIPA (Фонда интеллектуальных физических агентов) для ведения переговоров и заключения сделок, и мы создадим агентов-покупателей для отслеживания доставляемой информации. После завершения Agent World 2 у вас будет реальный агент, продающий реальные данные, ищущий и обнаруживающий их с помощью Simple Open Economic Framework (SOEF) в цифровом мире Fetch.ai. Если вам интересно, что означает SOEF:

OEF это протокол поиска, обнаружения и транзакций для сети Fetch. Представьте три уровня:

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

Я залогинился. Что дальше?




20 ноября мы запустили создание большой сети взаимодействующих агентов или, как мы любим ее называть, Agent World 3. Заключительный этап первой фазы программы Incentivized Testnet Agent World 3 (AW-3) планируется начать в эту пятницу, он продлится до 4 декабря. Если вы хотите стать частью команды разработчиков Fetch.ai и помочь нам создать нечто важное в экосистеме блокчейна с передовыми решениями в области искусственного интеллекта и интернета вещей, отправьте нам электронное письмо по адресу developer@fetch.ai и присоединяйтесь к нам в Discord. Не забудьте посмотреть наш репозиторий для разработчиков на docs.fetch.ai.

image



Рекомендуемые статьи


Подробнее..

Как найти нужный видос в груде видеофайлов? Проект Фабула

05.08.2020 18:06:10 | Автор: admin
image

Если человеку далеко за 20, то у него уже скопилась огромная фильмотека своей жизни, а также видеозаписей от друзей, родственников, с места работы Найти там кого-то или что-то конкретное уже невозможно. Недавно готовил видео подборку на юбилей дочери потратил неделю. Средства массовой информации тем более перегружены видеоархивами. И каждый день в мире появляются миллионы терабайт видеоконтента. И это в эпоху BIG DATA.

Пока даже Ютьюб не дает возможности сделать подборку по всем видеороликам, например, где есть маленькие собачки или встречается ваша любимая актриса. Мы не стали ждать, когда Гугл сподобиться на поиск не только по названиям к роликам И вот наша нейронная сеть для видео-архивов Фабула.

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

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

image

На этом сайте показывается, как видеозаписи раскладываются:

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

image

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

Основные направления работы Big Data МегаФона и задачи на графах

11.11.2020 18:11:34 | Автор: admin

Привет, меня зовут Рома Васильев, я Data Scientist в компании МегаФон. Здесь я и решил поделиться здесь своим докладом с Zero Day ICPC.

Слово о компании я опущу, скажу только, что сегодня МегаФон это клиентская база, в которой более 75,2миллионов пользователей, 40 тысяч сотрудников и цифровая экосистема сервисов: МегаФон ТВ, МегаФон Музыка, МегаФон Банк, МегаФон Книги и т. д.

Подходы аналитики больших данных в компании внедряются повсеместно. Пробежимся по основным стримам работы.

  • Customer profile мы выделяем интересы и потребности абонентов и стараемся строить свои продукты на их основе.

  • Development & Retention персонализируем все, что только можно как продукты, которые предлагаем абонентам, так и каналы и способы коммуникации с абонентом для увеличения NPS и LTV.

  • Geo МегаФон обладает большим количеством анонимизированных геоданных, на основе которых можно строить крутые сервисы к примеру, проект footprint, который предсказывает клиентопоток в той или иной локации, чтобы понять, где открыть новый салон ритейла.

  • Retail как я уже и говорил, количество салонов МФ Ритейл постоянно растет, и мы строим различные модели по управлению закупками, ценами, предсказанию спроса и клиентопотока салонов.

  • Infrastructure задачи, связанные непосредственно с задачами телекома. Например, с помощью машинного обучения определяем, где поставить новую вышку связи.

  • CVM B2X работаем не только напрямую с клиентами, но и генерируем персональные предложения для бизнес-клиентов.

  • Affiliated companies помогаем строить крутые модели для дочерних компаний, основываясь на своем большом опыте.

  • Data services мы, как оператор, никогда данные не продавали и продавать не будем, наш подход разработка дата-сервисов, которые помогают бизнесу решать конкретные задачи в маркетинге, управлении рисками, развитии городской инфраструктуры, развитии туризма в регионе и т.п.

  • Strategy and Marketing выделяем тренды в клиентской базе, помогаем оптимизировать затраты на маркетинг в разных каналах.

  • BigData, Enablers активно развиваем внутреннюю BigData инфраструктуру создаем много различных tool-ов, которые сокращают time-to-market моделей NBA, Real Time Marketing и т.д.

Кроме того, в компании активно развивается R&D направление любой сотрудник может прийти к руководству и предложить попробовать применить принципиально новые подходы в тех или иных направлениях.

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

Что же такое граф коммуникаций?

Это граф, в котором вершины абоненты, а ребра коммуникации между ними.

Наш граф состоит из 75,2 млн вершин, где каждая имеет в среднем порядка 10 ребер. Он постоянно меняется вместе с тем, как появляются и исчезают связи между людьми. Кроме этого каждый абонент сам по себе может быть описан множеством характеристик, которые также можно использовать. Таким образом, размер и непрерывная эволюция графа накладывают жесткие требования на используемые методы при решении задач.

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

Что же такое эмбединг?

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

Как же строить эмбединги?

Основными проблемами при обработке графов являются их масштабы и изменчивость. К примеру, если попытаться использовать классические модели машинного обучения, то непонятно, как этот граф в модель, собственно, подать. Поэтому для обработки графов очень часто используются специальные Graph Convolution Networks, которые переносят логику сверток из изображений в графы. Метод позволяет строить эмбединги вершин, основываясь в большинстве своем на локальной структуре графа для каждой вершины нужно агрегировать информацию ее соседей перед подачей в модель.

Одним из самых крутых, на наш взгляд, Open Sourse решений в этой области является метод GraphSAGE, который был представлен группой из Cтенфорда в 2017 году. Он порядком расширяет функционал GCN за счет введения новых функций агрегации. На слайде вы можете видеть схему расчета эмбединга для вершины С.

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

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

Еще одним несомненным преимуществом описанного подхода является то, что расчеты можно грамотно переиспользовать. К примеру, если мы уже посчитали эмбединг глубины 2 для вершин A, B и C, то при расчете эмбедингов для вершин D, E и F мы сможем использовать компоненты предыдущих расчетов, что в наших масштабах значительно увеличивает время работы алгоритма.

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

Спасибо за внимание!

Подробнее..

Как New York Times подбирает самые кликбейтные заголовки

16.04.2021 22:16:20 | Автор: admin
Лавры Buzzfeed, специалистов по треш-заголовкам, не дают покоя и более крутым спокойным медиа. Один из техноблогеров заметил, что одно из самых авторитетных в США изданий New York Times экспериментирует с заголовками статей. Он вытащил все виды заголовков и данные по их тестированию через открытые API этого СМИ и пришёл к интересным выводам. А я постарался собрать их в короткий дайджест.

Автор этого пересказа куратор новой магистратуры ВШЭ по управлению продуктом и маркетингом на основе данных.

image

  • Всех посетителей сайта в момент визита на сайт разбивают на группы (иногда до 7) и дают им разные заголовки статей с одним и тем же содержимым. Затем смотрят, на что реагируют лучше и дальше уже на всю аудиторию выкатывают самый эффективный заголовок.
  • Оказалось, статьи попадают в самые читаемые после такого A/B тестирования с вероятностью на 80% больше, чем без тестирования заголовков.
  • Где-то это подбор правильного слова, но чаще сравнение разных по эмоциональной зарядке заголовков
  • 62% аудитории NYT это платные подписки и им нет смысла гнаться за кликбейтом. Однако всё равно чаще всего побеждают и выбираются редакцией существенно более драматические заголовки, преувеличивающие драматизм статьи.
  • В среднем проверка эффекта идёт за 6 часов жизни статьи на сайте.
  • Часто NYT начинает подтюнивать уже вышедшие в топ статьи, чтобы сделать их ещё убойнее. Самый яркий пример как заголовок про Меган Маркл из Её жизнь не была сказкой, она потеряла свободу и идентичность превратился в Жизнь в королевской семье почти довела меня до самоубийства.

image

Затем он делал ещё один рисёч, где изучал что выводится на главный экран. Главный вывод в нём: 90% статей живёт на главной странице 9 часов, 10% убивают меньше чем за час

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru