Сложности применения технологий OCR в DLP-системах, или Как мы OCR готовим
Решение задачи распознавания изображений (OCR) сопряжено с различными сложностями. То картинку не получается распознать из-за нестандартной цветовой схемы или из-за искажений. То заказчик хочет распознавать все изображения без каких-либо ограничений, а это далеко не всегда возможно. Проблемы разные, и решить их сходу не всегда удается. В этом посте мы дадим несколько полезных советов, исходя из опыта разруливания реальных ситуаций у заказчиков.
Но сначала немного истории. Прошло немало времени с момента выхода статьи о том, как мы переписывали сервис фильтрации. В ней мы немного рассказали о фильтрации и обработке сообщений, о том, как устроен наш сервис фильтрации в целом. В этот раз мы постараемся ответить на вопрос «А как же мы обрабатываем изображения, как взаимодействуют сервисы, и что происходит с системой под нагрузкой?» Если оперировать статьей про сервис фильтрации, то сейчас мы будем рассматривать только одну ветку взаимодействия сервисов – это взаимодействие сервиса фильтрации и OCR.
Что такое OCR?
Прежде чем говорить о взаимодействии сервисов и проблемах применения OCR попробуем понять, что такое OCR. Возьмем сложное определение из Википедии.
Оптическое распознавание символов (англ. optical character recognition, OCR) — механический или электронный перевод изображений рукописного, машинописного или печатного текста в текстовые данные, использующиеся для представления символов в компьютере (например, в текстовом редакторе).
Если говорить просто, то взяли картинку, отправили на распознавание, дальше магия вне Хогвартса и получили текст.
Еще можно взять опредление OCR с сайта ABBYY, которое выглядит проще.
Оптическое распознавание символов (англ. Optical Character Recognition – OCR) – это технология, которая позволяет преобразовывать различные типы документов, такие как отсканированные документы, PDF-файлы или фото с цифровой камеры, в редактируемые форматы с возможностью поиска.
А зачем оно (распознавание изображений) нам нужно?
Распознавание изображений мы можем использовать хоть на домашнем ПК для преобразования цифровых изображений в редактируемые текстовые данные.Но стоящая перед нами задача гораздо шире (DLP-система все-таки): нам нужно контролировать поток информации в организации.
DLP-системы давно появились на рынке и сейчас входят в привычный арсенал корпоративных СЗИ (средств защиты информации). Перед DLP стоит задача контроля движения графической информации (отсканированных документов, скриншотов, фотографий). Причем не просто контроля движения графических файлов, а в первую очередь, анализа их содержимого. Система должна уметь понимать, с какой именно информацией она столкнулась, сравнить с образцами защищаемой информации и обеспечить возможности для дальнейшего поиска этой информации пользователем. Применение других средств анализа, таких, как сравнение с цифровыми отпечатками, вычисление хэша, анализ по формату, размеру и структуре файла, также являются ценными источниками информации, но не позволяют ответить на вопрос: «а какой текст передается в данной картинке?» А между тем текст все еще является самым распространённым носителем структурированной информации, в том числе в графических файлах.
Традиционно для распознавания графической информации используют технологию OCR (что это такое мы уже определили). На самом деле OCR – это вообще единственный класс технологий, которые предоставляют возможности извлечения текстовой информации из изображений. Поэтому тут речь не то чтобы о традиционном подходе, а скорее об отсутствии выбора.
Сколько изображений приходит на обработку в DLP-систему?
Неужели нельзя обойтись без OCR? На самом ли деле так много изображений приходит в DLP, что нужно применять OCR? Ответ на этот вопрос – «Да!». За сутки в систему может попадать более миллиона изображений, и во всех этих изображениях может содержаться текст.
OCR в составе DLP-системы «Ростелеком–Солар» используются в компаниях нефтегазовой отрасли и госструктурах. Все заказчики используют возможности OCR для детектирования конфиденциальных данных в отсканированных документах. Что может содержаться в такой «графике»? Да все, что угодно. Это могут быть сканы различных внутренних документов, например, содержащие ПДн. Или информация из категории коммерческой тайны, ДСП (для служебного пользования), финансовая отчетность и т.п.
Как OCR распознает изображения?
Процесс выглядит следующим образом: DLP перехватывает сообщение, содержащее изображение (скан документа, фотографию и т.п.), определяет, что изображение действительно есть в сообщении, извлекает его и отправляет на распознавание в модуль OCR. На выходе DLP получает информацию о содержимом изображения (да и сообщения в целом) в виде извлеченного TEXT/PLAIN.
Если говорить о взаимодействии сервисов непосредственно в нашей системе Solar Dozor, то сервис фильтрации отправляет изображения (если они есть) из сообщения в сервис извлечения текста изображений (OCR). Последний, после завершения распознавания, отдаёт полученный текст в mailfilter. Получается что-то вроде жонглирования изображениями и текстом.
Рассмотрим механизм распознавания глубже на примере работы OCR-технологий ABBYY, которые мы используем в собственной DLP.
Пожалуй, главной проблемой для OCR при распознавании текста является написание того или иного символа. Если взять любую букву алфавита (например, русского или английского), то для каждой мы найдем несколько вариантов написания. OCR-движки решают эту задачу несколькими способами:
Про работу OCR достаточно много различных статей. Подробно о работе OCR можно почитать, например, здесь https://sysblok.ru/knowhow/iz-pikselej-v-bukvy-kak-rabotaet-raspoznavanie-teksta/
Как готовить OCR в целом для распознавания?
Мы уже выяснили, что в DLP может попадать более миллиона изображений. Но все ли изображения из этого миллиона нам полезны?
Ответ на вопрос более чем очевиден – конечно, нет. Но почему нам будут полезны не все изображения? Ответ на этот вопрос тоже достаточно прозрачен: в почте «гуляет» очень много картинок из подписей в сообщениях. Наверное, 90% сообщений (если не больше) будут содержать логотип компании.
Подобные картинки слишком мелкие для распознавания, текста в них может не быть совсем. Здесь мы можем посоветовать (и даже настойчиво порекомендовать) задавать ограничения на размер распознаваемых изображений. При этом ограничения необходимо задавать как по нижней границе, так и по верхней. Вероятность отправки на обработку тяжелых файлов ниже, чем для картинок из подписи, но все же достаточно высока.
Стоит отметить, что цифровые изображения часто имеют разные дефекты. Маловероятно, что в DLP всегда будут попадать сканы документов в хорошем разрешении. Скорее наоборот, сканы всегда будут не в лучшем качестве и с большим количеством дефектов.
Например, в цифровом фото может быть искажена перспектива, оно может оказаться засвеченным или перевернутым, строки скана – изогнутыми. Такие искажения могут усложнять распознавание. Поэтому OCR-движки могут предварительно обрабатывать изображения, чтобы подготовить их к распознаванию. Например, изображение можно покрутить, преобразовать в ч/б, инвертировать цвета, скорректировать перекосы строк. Все это можно задать в настройках OCR и, как следствие, эти инструменты могут помочь улучшить распознавание текста в изображениях.
В итоге мы пришли к базовым принципам подготовки OCR к распознаванию:
Какие челленджи возможны при эксплуатации OCR в DLP под большой нагрузкой?
1. Слишком широкие лимиты на размеры распознаваемых изображений
Начнем с того, о чем мы уже упомянули, – с лимитов.
Исходя из нашей практики, заказчики часто устанавливают слишком широкие лимиты на размеры распознаваемых графических файлов. Да, чтобы OCR работал хорошо, нужно ограничивать размеры изображений. Но заказчики стремятся контролировать все подряд, полагая, что даже в картинке размером 100×100 pixels и 5 Кб могут утечь ценные данные. В целом, конечно, 100х100 pixels и 5 Кб тоже ограничения, но слишком уж низки эти пороги.
Другая крайность – стремление распознать тяжелые файлы по несколько сотен Мб. Понятно, что через корпоративную почту такие изображения не пролезут из-за ограничений на размер пересылаемых сообщений. Но вот по другим каналам перехвата (например, с корпоративных сетевых шар) увесистые файлы настойчиво стремятся распознавать. Если же заказчик хочет добавить к этому еще и большой объем high-res изображений, то для этого нужно иметь соответствующие серверные мощности. В итоге, при столь широких минимальных и максимальных порогах на размер распознаваемых файлов создается высокая нагрузка на процессор на серверах, что замедляет работу всех подсистем.
Что здесь можно порекомендовать? Прежде всего проанализировать, в какой используемой в компании «графике» содержатся конфиденциальные данные, после чего прикинуть разумные минимальные и максимальные ограничения на размеры контролируемых изображений. Обычно мы рекомендуем заказчикам зафиксировать нижнюю границу разрешения изображения от 200 pixels, в идеале от 400 pixels (по осям X и Y), и размера файлов не меньше 20 Кб, лучше больше. Также не имеет смысла отправлять в OCR тяжеловесные изображения – они элементарно перегрузят ваши сервера и не факт, что будут распознаны.
2. Очереди на фильтрацию и таймауты обработки запросов
Чрезмерная нагрузка на серверы, возникающая по вышеописанным причинам, ведет по цепочке к увеличению времени распознавания изображений и обработки запросов в целом. В результате в DLP-системе начинает увеличиваться очередь сообщений на фильтрацию. Кроме того, в OCR-модуль могут приходить графические файлы, которые в принципе невозможно распознать (тяжелые файлы, низкое качество и т.п.), в результате чего возникают таймауты обработки изображений. Если нераспознаваемых файлов поступает много, а в системе установлены высокие таймауты на распознавание, сервис фильтрации ждёт, пока этот таймаут наступит, и только потом приступает к обработке следующего запроса. Весь процесс обработки может серьезно тормозиться.
Что можем посоветовать? При возникновении очереди на обработку графических изображений нужно посмотреть настройки OCR в DLP-системе и попробовать найти причину торможения. Это может происходить, например, из-за проблем межпроцессного взаимодействия на самом сервере. Вообще, эти проблемы заслуживают отдельного разговора. Некоторые подробности по общим вопросам можно узнать из статьи «Знакомство с межпроцессным взаимодействием на Linux».
Кроме этого важным моментом при настройке OCR является выставление адекватных таймаутов на распознавание изображений. В общем случае достаточно 90 секунд, чтобы изображение точно распозналось. Если из изображения не извлекся текст за 90 секунд, то можно предположить, что OCR не распознает изображение в принципе. В этом месте также могут возникать проблемы конфигурирования OCR, когда выставляют высокие таймауты на распознавание и тем самым делаются попытки распознать нераспознаваемое.
Что еще может стать причиной таймаута? Здесь мы снова вернемся к вопросу конфигурирования системы. Сервис фильтрации, как и сервис OCR, оперирует тредами, которые обрабатывают сообщения и изображения. Система может быть некорректно сконфигурирована в части количества обработчиков сервиса фильтрации и количества обработчиков OCR. Например, у сервиса фильтрации будет много тредов-обработчиков, а у OCR всего один. В такой ситуации в какие-то моменты OCR может просто не успевать обрабатывать все запросы на распознавание, и таким образом будут появляться таймауты обработки изображений.
Подобное поведение системы наводит на мысли о проблемах проектирования и багах в архитектуре, но на самом деле это не так. Архитектура нашей DLP предоставляет возможности гибкой конфигурации системы и настройки её под нужды заказчиков. Например, мы можем достаточно просто настроить один OCR на работу с двумя сервисами фильтрации без ущерба производительности.
3. Нераспознаваемые изображения
Если в DLP-систему попадает на анализ изображение, которое OCR не может распознать, существует несколько вариантов решения проблемы.
По каким причинам изображения могут не распознаваться? Например, по следующим:
1. Нестандартная цветовая схема изображения.
2. Низкое разрешение изображения.
3. Неправильная ориентация изображения и содержащегося в нем текста в пространстве.
4. Перекосы строк и искажения пропорций текста в изображении и др.
Приведем пример: у одного из заказчиков в процессе мониторинга выяснилось, что OCR не распознает pdf-документы, выполненные в нестандартной цветовой схеме. То есть изображение извлекалось из PDF-документа в штатном режиме, но когда дело доходило до обработки OCR-модулем, тот не понимал цветовую схему картинки и выдавал на выходе «квадрат Малевича». В нашем интерфейсе картинка выглядела примерно так:
В OCR-движках заложены различные функции автоматической коррекции изображения, которые сильно повышают шансы на успешное распознавание содержащегося в нем текста. Однако, на практике эти волшебные инструменты не всегда срабатывают. В данном конкретном случае мы донастроили для заказчика OCR-модуль таким образом, чтобы он распознавал эту нестандартную цветовую схему.
5. Несоответствие одного из параметров документа заданным размерам распознаваемых
изображений.
Например, в конфигурации системы заданы границы размеров распознаваемых изображений 200х1000 pixels, а в OCR поступил файл размером 500х1500 pixels (верхний лимит превышен). В этом случае необходимо исправить настройки OCR для распознавания таких изображений.
Это, пожалуй, один из самых популярных сценариев донастройки системы после того, как нам говорят, что OCR не работает.
Почему OCR не на агентах?
OCR в DLP-системах реализуется в двух вариантах – на агентах и на серверах. Мы являемся сторонниками второго подхода, поскольку распознавание изображений прямо на рабочей станции создает высокую нагрузку на ее процессор и, соответственно, тормозит работу других приложений. OCR сама по себе весьма прожорливая технология даже для серверов, и её применение требует правильного планирования процессорных мощностей и контроля эффективности.
При этом многие отечественные компании, в особенности в госсекторе, до сих пор владеют достаточно старым парком ПК. Что происходит в этом случае? Пользователи начинают жаловаться ИТ-подразделению на «торможение» ПК, а айтишники в конце концов выясняют, что причиной торможения является OCR-модуль DLP-системы. Это раздражает и их, и пользователей, которые не могут оперативно решать рабочие задачи. В конечном итоге все это складывается в головную боль для безопасника, у которого и других задач полно.
Использование OCR на агентах оправдано лишь тогда, когда DLP-система работает «в разрыв». В этом случае распознавание изображения должно происходить ровно в тот момент, когда пользователь совершает действия с этим графическим файлом на своей рабочей станции. То есть DLP-система должна мгновенно решить судьбу документа, содержащего это изображение – разрешить его к отправке/копированию или запретить. Но на практике только единицы заказчиков используют DLP-систему в режиме активной блокировки, и это касается не только нашей собственной DLP. Здесь работает принцип «все, что можно вынести для проверок на сервер, должно выполняться на сервере».
Итого
Технологии OCR предоставляют возможности распознавания графических изображений, а мы в дополнение всегда даем общие рекомендации по конфигурированию системы. Однако в конкретном проекте может возникать необходимость донастройки работы OCR-модуля под специфические потребности заказчика как на этапе пилотирования и внедрения решения, так и на этапе его промышленной эксплуатации. Это не просто нормально – это единственно верный путь, который даст ощутимый результат, сделает работу OCR в компании максимально эффективной и снизит до минимума утечки конфиденциальной информации через графические изображения.
Никита Игонькин, ведущий инженер сервиса компании «Ростелеком-Солар»
Машинное обучение: от Ирисов до Телекома
Мобильные операторы, предоставляя разнообразные сервисы, накапливают огромное количество статистических данных. Я представляю отдел, реализующий систему управления трафиком абонентов, которая в процессе эксплуатации у оператора генерирует сотни гигабайт статистической информации в сутки. Меня заинтересовал вопрос: как в этих Больших Данных (Big Data) выявить максимум полезной информации? Не зря ведь одна из V в определении Big Data — это дополнительный доход.
Я взялся за эту задачу, не являясь специалистом в исследовании данных. Сразу возникла масса вопросов: какие технические средства использовать для анализа? На каком уровне достаточно знать математику, статистику? Какие методы машинного обучения надо знать и насколько глубоко? А может лучше для начала освоить специализированный язык для исследования данных R или Python?
Как показал мой опыт, для начального уровня исследования данных нужно совсем не много. Но мне для быстрого погружения не хватало простого примера, на котором наглядно был бы показан полный алгоритм исследования данных. В этой статье на примере Ирисов Фишера мы пройдем весь путь начального обучения, а далее применим полученное понимание к реальным данным оператора связи. Читатели, уже знакомые с исследованием данных, могут сразу переходить к главе, посвященной Телекому.
Термины
Для начала давайте разберемся с предметом изучения. Сейчас термины Искусственный Интеллект, Машинное Обучение, Глубокое Машинное Обучение зачастую используются как синонимы, но на самом деле существует вполне определенная иерархия:
Без учителя (самообучение) – это поиск скрытых закономерностей в данных. К таким алгоритмам относится кластеризация. Например, все крупные торговые сети ищут закономерности в покупках своих клиентов и пытаются работать с целевыми группами покупателей, а не с общей массой.
Регрессия, классификация и кластеризация являются основными алгоритмами исследования данных, поэтому их и будем рассматривать.
Исследование данных
Алгоритм исследования данных состоит из определенной последовательности шагов. В зависимости от задачи и имеющихся данных набор шагов может меняться, но общее направление всегда определенное:
А мы начинаем наше исследование!
Сбор и очистка данных
В примере с Ирисами для нас все данные собрали и заполнили. Просто загружаем их и смотрим:
Видим, что набор данных состоит из длины/ширины двух типов лепестков Ириса: sepal и petal. Не спрашивайте меня, где они находятся у Ириса). Целевая переменная — это сорт Ириса: 0 — Setosa, 1 — Versicolor, 2 — Virginica. Соответственно, наша задача — по имеющимся данным попробовать найти зависимости между размерами лепестков и сортами Ирисов.
Для удобства манипулирования данными делаем из них DataFrame:
Вроде получилось, то что хотели:
Описательные статистики
Посмотрев на такие гистограммы, опытный исследователь может сразу делать первые выводы. Я вижу только, что распределение у некоторых переменных похоже на нормальное. Попробуем сделать более наглядно. Строим таблицу с зависимостями между признаками и раскрашиваем точки в зависимости от сортов Ирисов:
Тут уже даже неискушенному исследователю видно, что «petal width (cm)» и «petal length (cm)» имеют сильную зависимость — точки вытянуты вдоль одной линии. И в принципе по этим же признакам можно строить классификацию, т.к. точки по цвету сгруппированы достаточно компактно. А вот, например, с помощью переменных «sepal width (cm)» и «sepal length (cm)» качественную классификацию не построить, т.к. точки, относящиеся к сортам Versicolor и Virginica, перемешаны между собой.
Зависимость между переменными
Теперь посмотрим на математические значения зависимостей:
В более наглядном виде построим тепловую карту зависимости признаков:
Значения коэффициента корреляции интерпретируются следующим образом:
Отбираем и создаем признаки
В первом приближении можно просто включить все переменные в модель и посмотреть, что будет. Далее можно будет подумать, какие признаки убрать, а какие создать.
Данные для обучения и тестовые данные
Разделяем данные на данные для обучения и тестовые данные. Обычно выборку разделяют на обучающую и тестовую в процентном соотношении 66/33, 70/30 или 80/20. Возможны и другие разбиения в зависимости от данных. В нашем примере на тестовые данные отводим 30% от всей выборки (параметр test_size = 0.3):
Цикл построения моделей – оценка результата
Переходим к самому интересному.
Линейная регрессия – LinearRegression
Как наглядно представить линейную регрессию? Если смотреть на зависимость между двумя переменными, то это проведение линии так, чтобы расстояния по вертикали от линии до точек были в сумме минимальные. Самый распространенный способ оптимизации – это минимизация среднеквадратичной ошибки по алгоритму градиентного спуска. Объяснение градиентного спуска есть много где, например тут в разделе “Что такое градиентный спуск?”. Но можно не читать и воспринимать линейную регрессию как абстрактный алгоритм нахождения линии, которая наиболее точно повторяет направление распределения объектов. Строим модель, используя переменные, которые, как мы поняли ранее, имеют сильную зависимость — это «petal length (cm)» и «petal width (cm)»:
Смотрим на метрики качества модели:
Видим, что, действительно, найденная линия регрессии хорошо повторяет направление распределения точек. Теперь, если у нас будет в наличии, например, длина листочка pental, мы сможем с большой точностью определить, какая у него ширина!
Классификация
Как интуитивно представить классификацию? Если смотреть на задачу разделения на два класса объектов, которые имеют два признака (например, нужно разделить яблоки и бананы, если известны их размеры), то классификация сводится к проведению линии на плоскости, которая делит объекты на два класса. Если надо разделить на большее число классов, то проводится несколько линий. Если смотреть на объекты с тремя переменными, то представляется трехмерное пространство и задача проведения плоскостей. Если переменных N, то нужно просто вообразить гиперплоскость в N-мерном пространстве).
Итак, берем самый известный алгоритм обучения классификации: стохастический градиентный спуск (Stochastic Gradient Descent). С градиентным спуском мы уже встречались в линейной регрессии, а стохастический говорит о том, что для быстроты работы используется не вся выборка, а случайные данные. И применяем его для метода классификации SVM (Support Vector Machine):
Смотрим на метрики качества модели:
На самом деле, оценить модель можно, не особо разбираясь в сути значений метрик: если accuracy, precision и recall больше 0.85, то это хорошая модель, если больше 0.95, то отличная.
Если кратко, то используемые в примере метрики отражают следующее:
Таким образом, видим, что значения метрик на нашем примере очень хорошие. Посмотрим на график. Для наглядности выборку рисуем в двух координатах и раскрашиваем по классам.
Сначала отобразим тестовую выборку, как она есть:
Потом, как ее предсказала наша модель. Видим, что точки на границе (которые я обвел красным) были классифицированы неправильно:
Но при этом большинство объектов предсказано правильно!
Cross-Validation
Как-то уж очень подозрительно хороший результат… Что может быть не так? Например, мы случайно хорошо разбили данные на обучающую и тестовую выборку. Чтобы убрать эту случайность применяют так называемую кросс-валидацию. Это когда данные разбиваются несколько раз на обучающую и тестовую выборку, и результат работы алгоритма усредняется.
Проверим работу алгоритма на 10 случайных выборках:
Смотрим на результат. Он ожидаемо ухудшился: 0.860909090909
Подбор оптимальных параметров алгоритма
Что еще можно сделать для оптимизации алгоритма? Можно попытаться подобрать параметры самого алгоритма. Видим, что в алгоритм передаются alpha=0.001, n_iter=100. Давайте найдем для них оптимальные значения.
На выходе получаем модель с оптимальными параметрами:
SGDClassifier(alpha=0.00089999999999999998, average=False, class_weight=None,
epsilon=0.1, eta0=0.0, fit_intercept=True, l1_ratio=0.15,
learning_rate=’optimal’, loss=’hinge’, n_iter=96, n_jobs=1,
penalty=’l2′, power_t=0.5, random_state=0, shuffle=True, verbose=0,
warm_start=False)
Видим, что в ней alpha=0.0009, n_iter=96. Подставляем эти значения в модель:
Смотрим, стало немного лучше: 0.915505050505
Отбираем и создаем признаки
Пришло время поэкспериментировать с признаками. Давайте уберем из модели менее значимые признаки, а именно «sepal length (cm)» и «sepal width (cm)». Загоняем в модель:
Смотрим, стало еще немного лучше: 0.937727272727
Для иллюстрации подхода, давайте сделаем новый признак: площадь листка petal и посмотрим, что получится.
Подставляем в модель:
Забавно, но в нашем примере получается, что площадь лепестка petal (вернее, даже не площадь, т.к. лепестки не прямоугольники, а «произведение длины на ширину») наиболее точно предсказывает сорт Ириса: 0.942373737374
Наверно, это можно объяснить тем, что переменные ‘petal length (cm)’ и ‘petal width (cm)’, и так неплохо разделяет Ирисы на классы, а их произведение еще «растягивает» классы вдоль прямой:
Мы познакомились с основными способами оптимизации моделей, теперь рассмотрим алгоритм кластеризации — пример машинного обучения без учителя.
Кластеризация — K-means
Суть кластеризации крайне проста — необходимо разделить имеющиеся объекты на группы, так чтобы в группы входили похожие объекты. У нас теперь нет правильных ответов для обучения модели, поэтому алгоритм должен сам группировать объекты по «близости» расположения объектов друг к другу.
Для примера, рассмотрим самый известный алгоритм K-средних. Он не зря называется K-средних, т.к. метод основан на нахождении K центров кластеров так, чтобы среднее расстояния от них до объектов, которые им принадлежат были минимальные. Сначала алгоритм определяет K произвольных центров, далее все объекты распределяются по близости к этим центрам. Получили K кластеров объектов. Далее в этих кластерах заново вычисляются центры по среднему расстоянию до объектов, и объекты снова перераспределяются. Алгоритм работает до тех пор, пока центры кластеров не перестанут сдвигаться на какую-то определенную дельту.
Смотрим на результаты:
Видим, что даже с параметрами по умолчанию получается очень неплохо: accuracy, precision и recall больше 0.9. Убеждаемся на картинках. Видим достойный, но не везде точный результат:
У алгоритма есть недостаток — для его работы нужно задавать число кластеров, которое мы хотим найти. И если оно будет неадекватное, то результаты работы алгоритма будут бесполезны. Посмотрим, что будет, если задать число кластеров, например, 5:
Видим, что на практике результат не применим. Существуют алгоритмы определения оптимального числа кластеров, но в этой статье мы не будем на них останавливаться.
Заключение по исследованию Ирисов
Итак, на примере Ирисов мы рассмотрели три основных метода машинного обучения: регрессию, классификацию и кластеризацию. Провели оптимизацию алгоритмов и визуализацию результатов. Получили очень хорошие результаты, но это и было ожидаемо на специально подготовленном наборе данных.
Полный Python Notebook можно найти на Github. Переходим к Телекому.
Телеком
В Телекоме есть задачи, которые с помощью анализа данных решают и в других сферах (банки, страхование, ретейл):
Для соблюдения конфиденциальности все данные для исследования были обезличены и заменены на случайные значения с соблюдением формата. Посмотрим на данные:
Какие алгоритмы машинного обучения можно применить к этим данным? Можно, например, агрегировать потребление трафика разного типа по абонентам за определенный период и провести кластеризацию. Должна получиться примерно такая картинка:
Т.е. если, например, результат кластеризации показал, что абоненты разделились на группы, которые по-разному используют Youtube, соцсети и слушают музыку, то можно сделать тарифы, которые учитывают их интересы. Предполагаю, что операторы связи так и поступают, выпуская линейки тарифов с дифференциацией оплаты по типу трафика.
Что еще можно проанализировать в имеющихся данных? Есть несколько кейсов с оборудованием абонентов. Оператор знает модель устройства абонента и может, например, предлагать определенные услуги только пользователям Samsung. Или, зная координаты базовых станций, можно нарисовать тепловую карту распределения телефонов Samsung (у меня нет реальных координат, поэтому карта к действительности не имеет отношения):
Может так получиться, что в каком-то регионе их окажется в процентном отношении больше, чем в других. Тогда эту информацию можно предложить Samsung-у для проведения рекламных акций или открытия салонов по продаже смартфонов. Далее можно посмотреть, на Top моделей устройств, с которых абоненты заходят в интернет:
Для маскировки современного положения вещей была взята устаревшая база IMEI, но сути подхода это не меняет. По списку видно, что большинство устройств — это Apple, модемы и Samsung-и, в конце появляются Meizu, Micromax и Xiaomi.
Собственно, это все применения исходным данным, которые я смог найти за короткое время. Конечно, по этим данным можно смотреть на разнообразные статистики и временные ряды, анализировать выбросы т.п., но вот так чтобы выявить какую-нибудь зависимость средствами машинного обучения… к сожалению, я не нашел пока, как это сделать.
Таким образом, вывод по исследованию Телеком данных такой: для полноценного решения задач оператора связи нужны данные из всех имеющиеся информационных систем, т.к. только имея доступ ко всем данным, можно эффективно стоить модели.
