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

Classification

Новые возможности анализа табличных данных с алгоритмами машинного обучения в Elastic

11.03.2021 12:11:09 | Автор: admin


Elastic stack, также известный как ELK Stack (аббревиатура из программных компонентов: Elasticsearch, Kibana и Logstash), это платформа построения озера данных с возможностью аналитики по ним в реальном масштабе времени. В настоящее время широко применяется для обеспечения информационной безопасности, мониторинга бесперебойности и производительности работы ИТ-среды и оборудования, анализа рабочих процессов, бизнес-аналитики.


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


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


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


  1. Обнаружение аномалий на потоке данных (Anomaly detection)
  2. Аналитика табличных данных (Data frame analytics)

Примечание: Попрактиковаться в использовании перечисленных выше наборов инструментов анализа данных можно будет 24 марта. Совместно с коллегами Elastic мы продемонстрируем, как применять Anomaly detection и Data frame analytics для выявления инцидентов информационной безопасности. Ссылка на регистрацию.

Об инструментах обнаружения аномалий Elastic ранее уже писали на Хабре. С того времени (Elastic версии 7.1) они продолжали активно развиваться, было улучшено качество алгоритмов и удобство их применения для прикладных задач. Но в этой статье мы решили осветить совершенно новый набор функций анализа табличных данных, появившийся в версиях с 7.2 до 7.11.


Data frame analytics это набор функций Elasticsearch и визуализаций Kibana, позволяющих проводить анализ данных без их привязки к временным меткам. В отличии от Anomaly detection, где предполагается временная последовательность анализируемых данных.


Работа с Data frame analytics осуществляется через графический интерфейс с пошаговым мастером настройки. При этом, за счёт автоматической оптимизации параметров обучения (hyperparameters) пользователю не требуются глубокие знания стоящих за ними математических алгоритмов.


Возможности Data frame analytics Elastic версии 7.11 включают в себя:


  1. Выявление отклонений в значениях параметров (outlier detection) с использованием алгоритмов машинного обучения без учителя (unsupervised)
  2. Построение моделей машинного обучения с учителем (supervised) для решения задач:


    a) Регрессии (regression), как определение зависимости одного значения от одного или нескольких других значений


    b) Классификации (classification), как определение принадлежности произвольного объекта к одному из заданных классов



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


Выявление отклонений с использованием алгоритмов машинного обучения без учителя (Outlier detection)


Функция Outlier detection, как и ранее существовавшая в Elastic anomaly detection, предназначена для выявления аномальных значений (выбросов) каких-либо параметров и не предполагает обучение с учителем модель строится каждый раз при запуске. Но в отличие от anomaly detection, значения признаков (фич, особенностей, характерных черт анализируемых объектов) в ней анализируются без учета временной последовательности.


Исходными данными для функции выступает массив записей (JSON документов), в котором данные представлены в виде полей и их значений (поддерживаются числовые и логические типы значений). Каждая запись характеризует поведение какого-либо объекта. Поля в записи включают в себя поле, идентифицирующее объект, и поля со значениями, указывающими на аномальное поведение объекта, их называют признаками (feature).


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


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


  • Метод ближайшего соседа (distance of Kth nearest neighbor)
  • Метод K ближайших соседей (distance of K-nearest neighbors)
  • Локальный уровень выброса (local outlier factor)
  • Локальный уровень выброса на основе расстояния (local distance-based outlier factor)

Подробнее про алгоритмы можно почитать здесь и здесь.


Для оценки и интерпретации результатов выявления отклонений Elastic рассчитывает степень влияния признаков на искомое значение.


В качестве иллюстрации приведём несколько примеров применения Outlier detection:


  • анализ метрик производительности для выявления отклонений в нагрузке на сервера со стороны сразу нескольких приложений (здесь);
  • анализ отпечатков бинарных гистограмм исполняемых файлов для обнаружения обфусцированных и вредоносных файлов (здесь);
  • анализ публичных объявлений airnbnb.com (insideairbnb.com) для поиска необычных предложений (здесь).

Ниже рассмотрим функцию анализа выбросов на примере из документации Elastic.



Цель анализа в этом примере выявить необычное поведение пользователей интернет-магазина. Из магазина в систему поступают события оформления заказа продукции, каждое из которых содержит полное имя заказчика (customer_full_name.keyword), количество покупок в заказе (products.quantity), стоимость заказа (products.taxful_price), id заказа (order_id).


Документы в исходном индексе выглядят так
{  "_index": "kibana_sample_data_ecommerce",  "_type": "_doc",  "_id": "_mXypHcB6S7rlhJIFCvB",  "_version": 1,  "_score": null,  "_source": {    "category": [      "Women's Clothing",      "Women's Accessories"    ],    "currency": "EUR",    "customer_first_name": "Sonya",    "customer_full_name": "Sonya Smith",    "customer_gender": "FEMALE",    "customer_id": 28,    "customer_last_name": "Smith",    "customer_phone": "",    "day_of_week": "Saturday",    "day_of_week_i": 5,    "email": "sonya@smith-family.zzz",    "manufacturer": [      "Oceanavigations",      "Pyramidustries"    ],    "order_date": "2021-03-06T23:31:12+00:00",    "order_id": 592097,    "products": [      {        "base_price": 28.99,        "discount_percentage": 0,        "quantity": 1,        "manufacturer": "Oceanavigations",        "tax_amount": 0,        "product_id": 19238,        "category": "Women's Clothing",        "sku": "ZO0265502655",        "taxless_price": 28.99,        "unit_discount_amount": 0,        "min_price": 13.05,        "_id": "sold_product_592097_19238",        "discount_amount": 0,        "created_on": "2016-12-31T23:31:12+00:00",        "product_name": "Vest - red/white",        "price": 28.99,        "taxful_price": 28.99,        "base_unit_price": 28.99      },      {        "base_price": 13.99,        "discount_percentage": 0,        "quantity": 1,        "manufacturer": "Pyramidustries",        "tax_amount": 0,        "product_id": 13328,        "category": "Women's Accessories",        "sku": "ZO0201102011",        "taxless_price": 13.99,        "unit_discount_amount": 0,        "min_price": 6.86,        "_id": "sold_product_592097_13328",        "discount_amount": 0,        "created_on": "2016-12-31T23:31:12+00:00",        "product_name": "Across body bag - aqua ",        "price": 13.99,        "taxful_price": 13.99,        "base_unit_price": 13.99      }    ],    "sku": [      "ZO0265502655",      "ZO0201102011"    ],    "taxful_total_price": 42.98,    "taxless_total_price": 42.98,    "total_quantity": 2,    "total_unique_products": 2,    "type": "order",    "user": "sonya",    "geoip": {      "country_iso_code": "CO",      "location": {        "lon": -74.1,        "lat": 4.6      },      "region_name": "Bogota D.C.",      "continent_name": "South America",      "city_name": "Bogotu00e1"    },    "event": {      "dataset": "sample_ecommerce"    }  },  "fields": {    "order_date": [      "2021-03-06T23:31:12.000Z"    ],    "products.created_on": [      "2016-12-31T23:31:12.000Z",      "2016-12-31T23:31:12.000Z"    ]  },  "sort": [    1615073472000  ]}

Начнём с подготовки данных для анализа. Так как мы сравниваем между собой заказчиков, то исходные события необходимо группировать по полю customer_full_name.keyword. Признаками поведения заказчиков будут выступать суммарные значения количества заказов, количества покупок, стоимость заказов.


Чтобы сгруппировать события, используем функцию трансформации transforms, которая позволяет на лету формировать и сохранять в Elasticsearch результаты агрегации ранее собранных данных.


Примечание: Для расчёта нужных признаков используем функции Elastic по агрегации: числовые значения считаем через products.quantity.sum и products.taxful_price.sum, а количество заказов order_id.value_count.



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



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



Чтобы просматривать индекс встроенными средствами Kibana, а не только через API, можно включить опцию "Create index template". Тогда соответствующий шаблон отображения индекса будет доступен в Kibana Discovery и при создании дашбордов в Kibana.


Опция "Continuous mode" включит выполнение трансформации в непрерывном режиме. Это обеспечит автоматическое обновление данных в индексе ecommerce_customers_outlier_detection с заданной периодичностью.


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


Документы в результирующем индексе ecommerce_customers_outlier_detection выглядят следующим образом
{  "_index": "ecommerce_customers_outlier_detection",  "_type": "_doc",  "_id": "QWoH6FA5JvsfN4JjO_LF32QAAAAAAAAA",  "_version": 1,  "_score": 0,  "_source": {    "customer_full_name": {      "keyword": "Abd Adams"    },    "order_id": {      "value_count": 2    },    "products": {      "taxful_price": {        "sum": 98.9765625      },      "quantity": {        "sum": 4      }    }  }}

Теперь самое интересное запускаем задачу машинного обучения (job в терминах Elastic ML). Мастер создания задачи позволяет отфильтровать данные для анализа с использованием встроенных в Elasticsearch языков запросов KQL (Kibana query language) или Lucene.



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



С помощью Advanced configuration параметров создания модели мы можем включить/выключить расчёт степени влияния признаков на модель (Compute feature influence), задать минимальное значение выброса для расчёта этого влияния (Feature influence threshold), а также объём выделенной под модель оперативной памяти (Model memory limit) и количество используемых заданием потоков процессора (Maximum number of threads), тем самым снижая или увеличивая нагрузку на кластер Elasticsearch.



Блок Hyperparameters используется для управления параметрами обучения. Здесь можно выбрать:


  • математический алгоритм (Method) обнаружения отклонений (lof, ldof, distance_kth_nn, distance_knn) или использования ансамбля алгоритмов (ensemble), когда значения отклонений определяются путём комбинации и оценки их результатов;
  • количество используемых в расчётах соседей (N neighbors);
  • переключатель использования предварительной стандартизации значений (Standardization enabled).

Подробнее о параметрах и их значениях можно почитать в референсах на соответствующий эндпоинт API.


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



После запуска, задание проходит через этапы:


  • создание результирующего индекса и добавление в него исходных данных (reindexing);
  • загрузка данных из индекса (loading data);
  • анализ данных и расчёт оценок выбросов (analyzing);
  • запись значений оценок выбросов в результирующий индекс (writing results).


Результаты работы задания можно подробно рассмотреть через интерфейс Kibana Data frame analytics.



На таблице с результатами анализа видим значение совокупной оценки выброса для каждого заказчика (ml.outlier_score) и оценку влияния признаков по насыщенности цвета соответствующей ячейки. Соответствующее числовое значение оценки сохраняется в служебном индексе с результатами анализа в поле ml.feature_influence.


В итоговом индексе результат работы алгоритма выглядит следующим образом
 {  "_index": "ecommerce_customers_outlier_detection_results",  "_type": "_doc",  "_id": "RQzr5SwrcdFVVAr9s9NEOwAAAAAAAAAA",  "_version": 2,  "_score": 1,  "_source": {    "customer_full_name": {      "keyword": "Elyssa Tran"    },    "order_id": {      "value_count": 4    },    "products": {      "taxful_price": {        "sum": 223.9921875      },      "quantity": {        "sum": 5      }    },    "ml__incremental_id": 926,    "ml": {      "outlier_score": 0.9770675301551819,      "feature_influence": [        {          "feature_name": "order_id.value_count",          "influence": 0.9383776783943176        },        {          "feature_name": "products.quantity.sum",          "influence": 0.05973121151328087        },        {          "feature_name": "products.taxful_price.sum",          "influence": 0.0018910884391516447        }      ]    }  },  "sort": [    1,    0.9770675301551819  ]}

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



И включить отображение размера точек в соответствии со значением отклонения.



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


Регрессия и классификация с учителем


Рассмотрим следующий набор функций Data frame analytics контролируемое обучение (обучение с учителем). Они предоставляют пользователю возможность обучить в Elastic свою собственную модель и использовать её для автоматического предсказания значений. Модель можно загружать и выгружать из системы, а также оценивать её качество. Кроме того, через Eland поддерживается импорт в Elastic моделей, обученных с помощью библиотек scikit-learn, XGBoost или LightGBM. Вместе с возможностями платформы по сбору и обработке данных эти функции помогают реализовать в ней подход CRISP-DM (Cross-Industry Standard Process for Data Mining).


В Elastic две функции обучения с учителем регрессия и классификация. Если говорить проще, то цель функций определение неизвестного значения объекта по значениям влияющих на него признаков. В случае регрессии речь идёт о предсказании числового значения, как характеристики объекта, а в случае классификации об определении класса (группы), к которой относится объект.


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


Схема реализации функций в Elastic


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


Обе функции используют собственные алгоритмы Elastic, построенные на базе градиентного бустинга деревьев решений XGBoost. Также возможно определение важности признаков по методу SHapley Additive exPlanations (SHAP).


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


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


Регрессия


С помощью регрессионного анализа попробуем предсказать продолжительность задержки рейса, на примере из документации Elastic. Для анализа используем метеоданные, данные с табло вылета/прилёта и стоимость билетов.


Документы в исходном индексе выглядят так
{  "_index": "kibana_sample_data_flights",  "_type": "_doc",  "_id": "lmX0pHcB6S7rlhJI2kVr",  "_version": 1,  "_score": null,  "_source": {    "FlightNum": "6GZQTCH",    "DestCountry": "IT",    "OriginWeather": "Thunder & Lightning",    "OriginCityName": "Tokyo",    "AvgTicketPrice": 849.1194483923543,    "DistanceMiles": 6127.633563869634,    "FlightDelay": false,    "DestWeather": "Rain",    "Dest": "Pisa International Airport",    "FlightDelayType": "No Delay",    "OriginCountry": "JP",    "dayOfWeek": 2,    "DistanceKilometers": 9861.470310212213,    "timestamp": "2021-02-17T15:41:38",    "DestLocation": {      "lat": "43.683899",      "lon": "10.3927"    },    "DestAirportID": "PI05",    "Carrier": "ES-Air",    "Cancelled": false,    "FlightTimeMin": 493.07351551061066,    "Origin": "Narita International Airport",    "OriginLocation": {      "lat": "35.76470184",      "lon": "140.3860016"    },    "DestRegion": "IT-52",    "OriginAirportID": "NRT",    "OriginRegion": "SE-BD",    "DestCityName": "Pisa",    "FlightTimeHour": 8.217891925176845,    "FlightDelayMin": 0  },  "fields": {    "hour_of_day": [      15    ],    "timestamp": [      "2021-02-17T15:41:38.000Z"    ]  },  "sort": [    1613576498000  ]}

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



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



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



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


Следующий шаг после выбора признаков настройка параметров.



Advanced configuration:


  • количество признаков, для которых в результирующий индекс будет записано значение влияния соответствующего признака на результат предсказания (Feature importance values);
  • имя поля, в которое будет записан результат предсказания (Prediction field name);
  • лимит на объём используемой заданием оперативной памяти (Model memory limit);
  • максимальное количество используемых заданием потоков процессора (Maximum numbers of threads).

Hyperparameters:


  • коэффициент регуляризации Лямбда (Lambda);
  • максимальное количество деревьев для бустинга (Max trees);
  • коэффициент регуляризации Гамма (Gamma);
  • размер градиентного шага Эта (Eta);
  • доля выборки (Feature bag fraction);
  • псевдослучайное число, используемое при выборе из датасета документов для обучения модели (Randomize seed).

Примечание: Описание применения в Elastic этих и дополнительных гиперпараметров приведено в документации к API.


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



Здесь можно увидеть новые, по сравнению с датасетом, поля:


  1. Отметка об использовании данных для обучения (ml.is_training)
  2. Результаты предсказания задержки рейса (ml.FlightDelayMin_prediction)

Если при создании задания было указано количество признаков, для которых будет рассчитано значение их влияния на результат (Feature importance values), в таблице отобразятся соответствующие значения для каждого признака (ml.feature_importance), а в результатах бар-чарт средних значений по всему датасету.



При клике на поле ml.feature_importance увидим наглядный график принятия решения алгоритмом SHAP.



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


Результаты доступны для просмотра и другими средствами визуализации Kibana

Например, в Kibana Lens. Ниже построен бар-чарт фактических и предсказанных задержек рейсов с разбивкой по погоде в пункте назначения.



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


В этом же отчете можно увидеть метрики качества модели:


  • среднеквадратическая ошибка (Mean Squared Error, MSE);
  • коэффициент детерминации (R-squared, R2 );
  • псевдо-функция потерь Хьюбера (Pseudo-Huber loss);
  • среднеквадратичная логарифмическая ошибка (Mean squared logarithmic error, MSLE).


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


После того как модель сформирована, она может применяться для предсказания значений по новым данным. Для этого в Elasticsearch есть две возможности:


  • анализ поступающих в Elasticsearch данных (Inference processor);
  • анализ ранее сохранённых в Elasticsearch данных (Inference aggregation).

Пример c Inference processor
POST /_ingest/pipeline/_simulate{  "pipeline" : {    "description" : "Flight delay prophecy",    "processors" : [       {          "inference": {           "model_id":"flights_delay_prophecy-1613827670191",           "inference_config": {             "regression": {               "results_field": "FlightDelayMin_prediction"             }           }         }       }    ]  },  "docs": [    {      "_index": "index",      "_id": "id",      "_source": {          "FlightNum" : "9HY9SWR",          "Origin" : "Frankfurt am Main Airport",          "OriginLocation" : {            "lon" : "8.570556",            "lat" : "50.033333"          },          "DestLocation" : {            "lon" : "151.177002",            "lat" : "-33.94609833"          },          "DistanceMiles" : 10247.856675613455,          "FlightTimeMin" : 1030.7704158599038,          "OriginWeather" : "Sunny",          "dayOfWeek" : 0,          "AvgTicketPrice" : 841.2656419677076,          "Carrier" : "Kibana Airlines",          "FlightDelayMin" : 0,          "OriginRegion" : "DE-HE",          "FlightDelayType" : "No Delay",          "DestAirportID" : "SYD",          "timestamp" : "2021-02-08T00:00:00",          "Dest" : "Sydney Kingsford Smith International Airport",          "FlightTimeHour" : 17.179506930998397,          "DistanceKilometers" : 16492.32665375846,          "OriginCityName" : "Frankfurt am Main",          "DestWeather" : "Rain",          "OriginCountry" : "DE",          "DestCountry" : "AU",          "DestRegion" : "SE-BD",          "OriginAirportID" : "FRA",          "DestCityName" : "Sydney"        }    }  ]}

Пример c Inference aggregation
GET kibana_sample_data_flights/_search{  "size":0,  "query": {    "term": {      "FlightNum": {        "value": "00HGV4F"      }    }  },   "aggs": {    "res": {       "composite": {         "size": 1,        "sources": [          {            "FlightNum": {              "terms": {                "field": "FlightNum"                              }            }          }        ]      },      "aggs" : {        "AvgTicketPrice": {          "max": {            "field": "AvgTicketPrice"          }        },       "Dest": {           "scripted_metric": {             "init_script": "state.Dest = ''",             "map_script": "state.Dest = params._source.Dest",             "combine_script": "return state.Dest",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "DestAirportID": {           "scripted_metric": {             "init_script": "state.DestAirportID = ''",             "map_script": "state.DestAirportID = params._source.DestAirportID",             "combine_script": "return state.DestAirportID",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "DestRegion": {           "scripted_metric": {             "init_script": "state.DestRegion = ''",             "map_script": "state.DestRegion = params._source.DestRegion",             "combine_script": "return state.DestRegion",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "DistanceKilometers": {          "max": {            "field": "DistanceKilometers"          }        },        "DistanceMiles": {          "max": {            "field": "DistanceMiles"          }        },        "FlightDelayType": {           "scripted_metric": {             "init_script": "state.FlightDelayType = ''",             "map_script": "state.FlightDelayType = params._source.FlightDelayType",             "combine_script": "return state.FlightDelayType",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "FlightTimeMin": {          "max": {            "field": "FlightTimeMin"          }        },        "Origin": {           "scripted_metric": {             "init_script": "state.Origin = ''",             "map_script": "state.Origin = params._source.Origin",             "combine_script": "return state.Origin",             "reduce_script": "for (d in states) if (d != null) return d"           }         },         "OriginAirportID": {           "scripted_metric": {             "init_script": "state.OriginAirportID = ''",             "map_script": "state.OriginAirportID = params._source.OriginAirportID",             "combine_script": "return state.OriginAirportID",             "reduce_script": "for (d in states) if (d != null) return d"           }         },        "OriginRegion": {           "scripted_metric": {             "init_script": "state.OriginRegion = ''",             "map_script": "state.OriginRegion = params._source.OriginRegion",             "combine_script": "return state.OriginRegion",             "reduce_script": "for (d in states) if (d != null) return d"           }         },        "FlightDelayMin_prediction" : {          "inference": {            "model_id": "flights_delay_prophecy-1613827670191",             "buckets_path": {               "AvgTicketPrice": "AvgTicketPrice",               "Dest": "Dest.value",               "DestAirportID": "DestAirportID.value",               "DestRegion": "DestRegion.value",               "DistanceKilometers": "DistanceKilometers",               "DistanceMiles": "DistanceMiles",               "FlightDelayType": "FlightDelayType.value",               "FlightTimeMin": "FlightTimeMin",               "Origin": "Origin.value",               "OriginAirportID": "OriginAirportID.value",               "OriginRegion": "OriginRegion.value"             }          }        }      }     }  }}

Классификация


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


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



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



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


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



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


  • отметка об использовании данных для обучения (ml.is_training);
  • предсказанный статус отмены рейса (ml.Cancelled_prediction);
  • вероятность предсказания (ml.prediction_probability);
  • влияние признаков на результат (ml.feature_importance);
  • оценка предсказания для всех искомых классов (ml.prediction_score).

Пример сохраненных результатов расчётов ml.prediction_score
"top_classes": [        {          "class_probability": 0.9617513617353418,          "class_score": 0.24080996012552122,          "class_name": false        },        {          "class_probability": 0.03824863826465814,          "class_score": 0.03824863826465814,          "class_name": true        }      ]

В понимании параметров оценки поможет документация Elastic.


Как и в регрессии, в результатах доступен график усреднённых значений важности признаков.



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


  • матрица ошибок (Confusion matrix);
  • площадь кривой ошибок (area under receiver operating characteristic curve, AUC ROC).

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



Кривая ошибок и значение площади AUC ROC в версии 7.11 не отображается, но значения можно получить через API. В 7.12 такая возможность уже будет добавлена.


Пример запроса AUC ROC
POST _ml/data_frame/_evaluate{   "index": "cancelled_flights_prediction_2",   "evaluation": {      "classification": {          "actual_field": "Cancelled",          "predicted_field": "ml.Cancelled_prediction",          "metrics": {           "auc_roc": {             "class_name": "true"           }          }      }   }}

и ответа
{  "classification" : {    "auc_roc" : {      "value" : 0.8240223547611558    }  }}   

Сохранённая модель доступна для использования в Inference processor и Inference aggregation, как в предыдущем примере.


Заключение


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


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


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

Подробнее..

Как работать с иерархической структурой классов

22.04.2021 14:23:53 | Автор: admin

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

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

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

Это звучит понятно в школьном учебнике, но в контексте машинного обучения возникает множество вопросов:

  • Как с этим всем обращаться?

  • Какие классы предсказывать?

  • Сколько моделей тренировать для решения задачи?

  • Как работать с данными?

  • Как вносить изменения в иерархию классов и как реагировать на эти изменения с точки зрения модели?

Все эти проблемы мы разберем на примере задачи классификации, которую мы решаем в Контуре.

Постановка задачи

Мы работаем с чеками. В каждом чеке может встретиться много разных товаров, которые можно сгруппировать множеством разных способов. На данный момент нам интересно группировать эти товары с помощью дерева категорий, которое мы будем называть KPC (Khajiit Product Classification). Это здоровенное дерево, состоящее из 683 категорий.

Для этих категорий у нас есть Golden Set, наш размеченный набор данных (штрихкод категория KPC) для обучения. В датасете почти три миллиона записей и мы постоянно работаем над его дополнением и улучшением разметки.

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

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

Разметка данных

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

Так появились статусы категорий. Они помогают понять, в каком состоянии категория прямо сейчас. Благодаря статусам мы можем отдельно обрабатывать только что появившиеся категории или категории, которые скоро будут удалены. На текущий момент мы выделяем четыре статуса категорий:

  • Активный.

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

  • Архивный категория, которую решено было удалить, но товары из категории еще не переразметили.

  • Удаленный.

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

Также стоит упомянуть две отдельные группы категорий:

  • свалка (например Одежда (свалка)) группа для логического удаления некоторых товаров, которые невозможно категоризировать. Например, у нас есть товар Полное тестирование Тест 2 10шт, у которого из какого-то источника данных стоит категория Одежда. Наш аналитик данных понимает, что по факту категории у такого товара нет, поэтому такой товар отправляется в свалку, которая при обучении не рассматривается.

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

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

Добавление категории

Добавить категорию мы можем в любое время, но для того, чтобы товары начали в неё попадать, необходимо:

  • Добавить категорию в KPC.

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

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

Удаление категории

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

Для удаления категории необходимо:

  • Перевести категорию в статус Архивная.

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

  • Заменить удаляемую категорию у товаров в Golden Set.

  • Указать дочерним категориям новую родительскую категорию или её отсутствие (если дочерняя категория должна стать категорией верхнего уровня).

  • Переобучить модель, чтобы она перестала классифицировать товары в удаляемую категорию (и начала классифицировать эти товары в новые категории).

  • Перевести категорию в статус Удаленная.

Разбиение категории

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

  • Обновить категории в Golden Set, чтобы отнести товары к новым категориям.

  • Переобучить модель, чтобы она научилась классифицировать товары в новые категории.

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

Обучение модели

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

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

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

Алгоритм разрешения конфликтов

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

Для разрешения этих ситуаций мы будем маппить категории (то есть переносить все товары из одной категории в другую), а после обновлять наше дерево категорий (оставлять в рассмотрении только те категории, которые представлены в Golden set), проверяя, остались ли коллизии.

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

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

Future/Active на схеме это статусы категорий Запланированная/Активная, а present/NOT present in GS представлена ли категория в Golden set.

Еще один вопрос, который важно разобрать что мы хотим делать с Запланированными категориями? И что мы хотим делать с их детьми?

Есть несколько вариантов. Мы можем:

  • Использовать эти категории в классификации.

  • Не классифицировать и выбросить категории из GS.

  • Переразмечать эти категории в категорию-родителя.

  • Переразмечать эти товары в категорию другое/другие (например Молочные продукты, сыры и яйцо (другое))

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

  1. Убрать удаленные, редко встречающиеся (меньше 10 товаров в golden set) и те категории, у которых в названии есть свалка.

  2. Если все дети категории в статусе Запланированный, то дочерние категории маппятся в родителя. Это происходит итеративно, так как после первого маппинга может возникнуть аналогичная ситуация на другом уровне дерева.

  3. Смаппить запланированные категории в sibling-категорию с другое/другие в названии, если такая есть.

  4. Удалить из Golden Set категории, у которых есть категории-потомки с товарами в Golden Set. Здесь происходит то самое разрешение конфликтов.

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

Валидация модели

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

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

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

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

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

'errors' - sum of errors of confusing two labels,
'label_1_confuse' - count(true=label_1, pred=label_2) / 'errors',
'label_2_confuse' - count(true=label_2, pred=label_1) / 'errors',
'fraction_of_error_to_label_1' - count(true=label_1, pred=label_2) / total_label_1,
'fraction_of_error_to_label_2' - count(true=label_2, pred=label_1) / total_label_2,
'fraction_of_all_errors' - 'errors' / total_errors,
'fraction_of_all_errors_cumulative'

Выводы

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

  2. При валидации стоит агрегировать метрики для родительских категорий, чтобы иметь возможность сравнить две модели с разными наборами классов.

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

Подробнее..

Создание автоматической системы борьбы с злоумышленниками на сайте (фродом)

29.08.2020 12:21:18 | Автор: admin
Последние примерно полгода я занимался созданием системы борьбы с фродом (fraudulent activity, fraud, etc.) без какой-либо начальной инфраструктуры для этого. Сегодняшние идеи, которые мы нашли и реализовали в нашей системе, помогают нам обнаруживать множество мошеннических действий и анализировать их. В этой статье я хотел бы рассказать о принципах, которым мы следовали, и о том, что мы сделали для достижения текущего состояния нашей системы, не углубляясь в техническую часть.


Принципы нашей системы


Когда вы слышите такие термины, как automatic и fraud, вы, скорее всего, начинаете думать о машинном обучении, Apache Spark, Hadoop, Python, Airflow и других технологиях экосистемы Apache Foundation и области Data Science. Я думаю, что есть один аспект использования этих инструментов, который, обычно, не упоминается: они требуют наличия определенных предварительных условий в вашей корпоративной системе, прежде чем начать их использовать. Короче говоря, вам нужна корпоративная платформа данных, которая включает озеро данных и хранилище. Но что, если у вас нет такой платформы, и вам все еще нужно развивать эту практику? Следующие принципы, о которых я рассказываю ниже, помогли нам достичь момента, когда мы можем сосредоточиться на улучшении наших идей, а не на поиске работающей. Тем не менее, это не плато проекта. В плане еще много вещей с технологической и продуктовой точек зрения.

Принцип 1: ценность для бизнеса в первую очередь


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

Принцип 2: Расширенный интеллект человека (augmented intelligence)


Бьюсь об заклад, большинство людей, которые не вовлечены глубоко в разработку решений машинного обучения, могут подумать, что замена людей это цель. На самом деле, решения машинного обучения далеки от совершенства и только в определенных областях возможна замена. Мы отказались от этой идеи с самого начала по нескольким причинам: несбалансированные данные о мошеннической деятельности и невозможность предоставить исчерпывающий список функций для моделей машинного обучения. В отличие от этого, мы выбрали вариант с расширенным интеллектом. Это альтернативная концепция искусственного интеллекта, которая фокусируется на вспомогательной роли ИИ, подчеркивая тот факт, что когнитивные технологии предназначены для улучшения человеческого интеллекта, а не для его замены. [1]

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

Принцип 3: платформа обширных аналитических данных


Самая сложная часть нашей системы это сквозная проверка рабочего процесса системы. Аналитики и разработчики должны легко получать наборы данных за прошлые периоды со всеми метриками, которые использовались для анализа. Кроме того, платформа данных должна предоставлять простой способ дополнить существующий набор показателей новым. Процессы, которые мы создаем, а это не только программные процессы, должны позволять легко пересчитывать предыдущие периоды, добавлять новые метрики и изменять прогноз данных. Мы могли бы добиться этого, накапливая все данные, которые генерирует наша производственная система. В таком случае данные постепенно стали бы помехой. Нам нужно было бы хранить растущий объем данных, которые мы не используем, и защищать их. В таком сценарии со временем данные будут становиться все более и более нерелевантными, но по-прежнему требуют наших усилий для управления ими. Для нас накопление данных (data hoarding) не имело смысла, и мы решили использовать другой подход. Мы решили организовать хранилища данных в реальном времени вокруг целевых сущностей, которые мы хотим классифицировать, и хранить только те данные, которые позволяют проверять самые последние и актуальные периоды. Сложность этих усилий заключается в том, что наша система является неоднородной с несколькими хранилищами данных и программными модулями, которые требуют тщательного планирования для согласованной работы.

Конструктивные концепции нашей системы


У нас есть четыре основных компонента в нашей системе: система приема (ingestion system), вычисления (computational), анализ (BI analysis) и система отслеживания (tracking system). Они служат для конкретных изолированных целей, и мы держим их изолированными, следуя определенным подходам в разработке.

image

Дизайн на основе контрактов


Прежде всего, мы договорились, что компоненты должны полагаться только на определенные структуры данных (контракты), которые передаются между ними. Это позволяет легко интегрировать между ними и не навязывать конкретный состав (и порядок) компонентов. Например, в некоторых случаях это позволяет нам напрямую интегрировать систему приема с системой отслеживания предупреждений. В таком случае это будет сделано в соответствии с согласованным контрактом на оповещения. Это означает, что оба компонента будут интегрированы с использованием контракта, который может использовать любой другой компонент. Мы не будем добавлять дополнительный контракт на добавление предупреждений в систему отслеживания из системы ввода. Такой подход требует использования заранее определенного минимального количества контрактов и упрощает систему и коммуникации. По сути, мы используем подход, который называется Contract First Design, и применяем его к контрактам потоковой передачи данных. [2]

Стриминг везде


Сохранение и управление состоянием в системе неизбежно приведет к усложнениям в ее реализации. В общем случае, состояние должно быть доступным из любого компонента, оно должно быть согласованным и предоставлять наиболее актуальное значение для всех компонентов, и оно должно быть надежным с правильными значениями. Кроме того, наличие вызовов к постоянному хранилищу для получения последнего состояния увеличит количество операций ввода-вывода и сложность алгоритмов, использующихся в наших конвейерах реального времени. Из-за этого мы решили убраться хранение состояния, по возможности, полностью из нашей системы. Этот подход требует включения всех необходимых данных в передаваемый блок данных (сообщение). Например, если нам нужно вычислить общее количество некоторых наблюдений (количество операций или случаев с определенными характеристиками), мы вычисляем его в памяти и генерируем поток таких значений. Зависимые модули будут использовать разбиение (partition) и пакетирование (batch) для дробления потока по сущностям и оперирования последними значениями. Этот подход устранил необходимость иметь постоянное дисковое хранилище для таких данных. Наша система использует Kafka в качестве брокера сообщений, и его можно использовать как базу данных с KSQL. [3] Но его использование сильно связало бы наше решение с Kafka, и мы решили не использовать его. Выбранный нами подход позволяет заменить Kafka другим брокером сообщений без серьезных внутренних изменений системы.

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

Проблемы нашей системы


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

  • Нам все еще необходимо определить процессы и политики, которые способствуют накоплению значимых и актуальных данных для нашего автоматического анализа, обнаружения и исследования данных.
  • Внедрение результатов анализа человеком в процесс автоматической настройки системы для её обновления на последних данных. Это не только обновление нашей модели, но также обновление процессов и улучшение понимания наших данных.
  • Нахождение баланса между детерминированным подходом IF-ELSE и ML. Кто-то сказал: ML это инструмент для отчаявшихся. Это означает, что вы захотите использовать ML, когда больше не понимаете, как оптимизировать и улучшить свои алгоритмы. С другой стороны, детерминированный подход не позволяет обнаружение аномалий, которые не были предвидены.
  • Нам нужен простой способ проверить наши гипотезы или коореляции между метриками в данных.
  • Система должна иметь несколько уровней истинно положительных (true positive) результатов. Случаи мошенничества это лишь часть всех случаев, которые можно считать положительными для системы. Например, аналитики хотят получать все подозрительные случаи для проверки, и лишь небольшая часть из них мошенничество. Система должна эффективно предоставлять аналитикам все случаи, независимо от того, является ли это реальным мошенничеством или просто подозрительным поведением.
  • Платформа данных должна позволять получать наборы данных за прошлые периоды с вычислениями, созданными и рассчитанными на лету.
  • Простое и автоматическое развертывание любого из компонентов системы как минимум в трех различных средах: производственной, экспериментальной (бета) и для разработчиков.
  • И последнее, но не менее важное. Нам необходимо создать обширную платформу проверки производительности, на которой мы сможем анализировать наши модели. [4]


Ссылки


  1. What is Augmented Intelligence?
  2. Implementing an API-First Design Methodology
  3. Kafka Transforming Into Event Streaming Database
  4. Understanding AUC ROC Curve
Подробнее..

Распознавание мяча в волейболе с OpenCV и Tensorflow

17.08.2020 06:18:36 | Автор: admin
После первого опыта распознавания спортивных движений у меня зачесались руки сделать что-нибудь еще в этом направлении. Домашняя физкультура уже казалась слишком мелкой целью, так что я замахнулся на игровые виды спорта.

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


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

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

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

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

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

Австрийское видео имеет свои особенности. Главных деталей три:

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

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

    mask = backSub.apply(frame)    mask = cv.dilate(mask, None)    mask = cv.GaussianBlur(mask, (15, 15),0)    ret,mask = cv.threshold(mask,0,255,cv.THRESH_BINARY | cv.THRESH_OTSU)

Таким образом вот эта, например, картинка:



Превращается в такую маску:



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

Это коненчно не всегда так. Например, здесь верхний контур оказался плечом судьи:



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

Датасет верхнего контура выглядит разнопланово:



Но с точки зрения нейросетей представляет собой не более чем бинарную классификацию цветных картинок. Таким образом за основу модели я взял известную задачу Котики-против-Собак.

Вариантов реализации миллион, самая популярная архитектура VGG, хорошо описана в этой статье блога Keras.

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

   model = Sequential([        Convolution2D(32,(3,3), activation='relu', input_shape=input_shape),        MaxPooling2D(),        Convolution2D(64,(3,3), activation='relu'),        MaxPooling2D(),        Flatten(),        Dense(64, activation='relu'),        Dropout(0.1),        Dense(2, activation='softmax')      ])    model.compile(loss="categorical_crossentropy", optimizer=SGD(lr=0.01), metrics=["accuracy"])

Как я ни крутил модель, добиться лучшег чем 20% ложно-отрицательных и 30% ложно-положительных не удалось.

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



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

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

В общем, на коленке пришлось сделать некий фреймворк управления траекториями.

Вот записанные траектории за розыгрыш:


(cиним кандидаты в траектории, зеленым статические пятна, серым случайные).

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

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



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

И в завершение еще несколько ссылок на подобные изыскания:

Подробнее..

Категории

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

  • Имя: Макс
    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