Хакатоны

Данная статья написана в соавторстве с тимлидом @Restlin

Выбор кейса и наше видение его решения

Изначально выбор пал на кейс МВД: Разработка автономного программного решения лингвистического анализа и преобразования в тексте лица повествования.

Формулировка кейса:

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

Нам он был близок по специализации, и было четкое представление как красиво можно решить данную задачу.

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

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

1) локальное решение, работающее без доступа в сеть;

2) интегрированные офисные пакеты посредством макросов.

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

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

Формулировка кейса:

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

Почему он? У нас было понимание как работать с электронной подписью на Open source решениях: OpenSSL. Пригодился опыт Ильи в разработке СЭД - он знал о существовании php библиотеки tcpdf для генерации файла pdf с возможностью встроить электронную подпись. Плюс на текущем проекте pirs.online мы уже копали эту тему, и оттого данной задачей заниматься было приятно вдвойне.

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

Панические атаки и ведро валерьянки

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

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

А что потом? Технические подробности

Дальше пошло по накатанной: первый чекпоинт и наши идеи по реализации, полученное одобрение экспертов и практически бессонная ночь работы.

Нам повезло: роли между командой у нас распределены четко, и каждый занимается своей задачей. Марина - презентация и вычитка спитча Ильи. Илья отвечает за спитч, архитектуру, бэк. Дима и Кирилл - фуллстеки.

С точки зрения технической реализации функционал прототипа выглядел просто:

• вход пользователя под одной из двух ролей: гость и администратор;

• формирование обращения администратору (почте РФ);

• рассмотрение обращения и формирование ответа;

• можно прикрепить файлы к обращению и ответу;

• создать сертификат пользователя в личном кабинете;

• подписать файлы ответа электронной подписью;

• выгрузить обращение с электронной подписью;

• проверить электронную подпись в обращении.

Структура базы данных прототипа уместилась всего в 3 таблицы, размещенных в PostgreSQL:

1. user - таблица пользователей с реквизитами и типами;

2. message - таблица обращений и ответов. По сути это переписка клиента и администратора;

3. file - таблица файлов, прикрепленных к обращениям и ответам.

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

Для работы с электронными подписями мы решили использовать OpenSSL, как открытый стандарт де-факто по работе с электронными подписями.

Как и ожидалось библиотека очень мощная, но из коробки не поддерживает отечественные алгоритмы шифрования. Какое-то время ушло на интеграцию и настройку криптографического движка (libengine-gost-openssl 1.1) на алгоритмы ГОСТ, в частности ГОСТ-2012. Затем мы создали и настроили удостоверяющий центр.

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

Пилим прототип дальше

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

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

Создание сертификата пользователя:

exec("openssl req -nodes -newkey gost2012_512 -keyout $eSignPath/client.key -pkeyopt paramset:A -out $eSignPath/client.csr -subj \"/C=RU/ST=Udm/L=Izhevsk/O=IT/OU=animals/CN=user-{$user->id}\" -config $caPath/openssl.cnf ");

exec("openssl ca -engine gost -keyfile $caPath/ca.key -cert $caPath/ca.crt -in $eSignPath/client.csr -out $eSignPath/client.crt -batch -config $caPath/openssl.cnf 2>&1", $output);

где $eSignPath - путь до папки с ключами пользователей, а $caPath - путь до папки удостоверяющего центра.

Удаление сертификата пользователя:

exec("openssl ca -config $caPath/openssl.cnf -keyfile $caPath/ca.key -cert $caPath/ca.crt -revoke $eSignPath/client.crt 2>&1", $output);

exec("openssl ca -gencrl -config $caPath/openssl.cnf -keyfile $caPath/ca.key -cert $caPath/ca.crt -out $caPath/crl.pem 2>&1", $output);

где $eSignPath - путь до папки с ключами пользователей, а $caPath - путь до папки удостоверяющего центра.

Подписание файла сертификатом пользователя:

exec("openssl smime -engine gost -sign -in $fp -out $fp.sig -nodetach -binary -signer $clientKeysPath/client.crt -inkey $clientKeysPath/client.key -outform SMIME 2>&1", $output);

где $fp - путь до файла, $clientKeysPath - путь до папки с ключами пользователя.

Проверка подписи файла:

$output = exec("openssl cms -engine gost -verify -in $sigPath -inform SMIME -CAfile $pathCA/ca.crt -out $fp -certsout $clientKeysPath/client.crt 2>&1");

где $fp - путь до файла, $clientKeysPath - путь до папки с ключами пользователя, $sigPath - путь до электронной подписи.

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

Появилась идея: Илья вспоминает, что в одной не самой популярной библиотеке tcpdf по формированию pdf файлов была возможность встраивания электронной подписи в pdf файл. А это значит, что можно из обращения создать pdf файл и сразу встроить в него электронную подпись.

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

Начинаем реализовывать и понимаем на сколько в библиотеке tcpdf захардкодена работа с openssl. Вылазят проблемы невозможности смены движка и другие конфликты библиотеки с нашим решением. Создаем потомка библиотеки и заменяем всю генерацию подписи с хардкода openssl на наш костыль (херак-херак, и впродакшн) через локальный метод api:

$fields = [

'r' => 'api/sign',

'filePath' => $tempdoc,

'userId' => $user->id,

];

$query = http_build_query($fields);

$ch = curl_init();

$host = \Yii::$app->params['apiHost'] ?? '';

curl_setopt($ch, CURLOPT_URL, $host . '/index.php?' . $query);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$signature = curl_exec($ch);

/*if (empty($this->signature_data['extracerts'])) {

openssl_pkcs7_sign($tempdoc, $tempsign, $this->signature_data['signcert'], array($this->signature_data['privkey'], $this->signature_data['password']), array(), PKCS7_BINARY | PKCS7_DETACHED);

} else {

openssl_pkcs7_sign($tempdoc, $tempsign, $this->signature_data['signcert'], array($this->signature_data['privkey'], $this->signature_data['password']), array(), PKCS7_BINARY | PKCS7_DETACHED, $this->signature_data['extracerts']);

}*/

И все же мы успеваем в последний момент и к утру воскресенья прототип полностью работает!

Последний рывок и мы у цели

В середине дня воскресенья Илья подключается по Zoom к защите решения, жюри неумалимы, ну а мы ждем результатов.

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

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

Офтоп: мы победители! 750 тысяч на команду, Карл! 750 за 2 дня, Карл! А значит едем на грандфинал Цифрового прорыва в Москву!

Репозиторий нашего решения

Авторы кейса для хакатона рассказали, как стать победителем IT-конкурса.

Уже завтра Нижний Новгород превратится в столицу цифровой экономики. Здесь проведут сразу два хакатона: первое в России IT-соревнование по искусственному интеллекту и полуфинал Всероссийского конкурса разработчиков Цифровой прорыв Медицина, здравоохранение, наука. Для последнего EPAM вместе с ННГУ им. Лобачевского подготовили кейс CardioSpike. На основе полученных учеными данных нужно разработать детектор ковидных аномалий в ритме сердца. Пять сотрудников EPAM практики Data Science, которые участвовали в создании датасета, войдут в состав жюри. Они рассказали, как правильно подготовиться к хакатону.

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

Даниил Гусев, Data Scientist, EPAM: Каждый хакатон это вызов вам, вашим знаниям и умениям решать проблему здесь и сейчас. Для победы нужно придумывать новые подходы, экспериментировать, но это не касается инструментов, которые вы будете использовать. У вас не будет времени на освоение новых библиотек и фреймворков. Используйте только те инструменты, которыми вам уже хорошо знакомы.

Павел Смирнов, Data Science, EPAM: Распределите роли в команде. Кто занимается внешним видом и UX? Кто занимается архитектурой и масштабирование? Кто отвечает за МЛ часть? Кто готовит презентацию? Кто питчит финальное решение перед жюри? Перечитайте постановку задачи несколько раз. Очень важно не забыть в конце, какую задачу вы решаете. Поставьте библиотеки для работы с данными (numpy, pandas и т.д. ). Познакомьтесь с целевой метрикой - https://scikit-learn.org/stable/modules/generated/sklearn.metrics.f1_score.html)/. Посмотрите на описание и документацию к классическим алгоритмам, которые можно применить для решения задачи - https://scikit-learn.org/stable/supervised_learning.html.

Михаил Терпелец, Data Science, EPAM: Всем участникам я бы посоветовал избегать процедурного спагетти и не забывать следовать DRY, KISS, YAGNI. Ну и, конечно, дважды проверять код перед запуском, чтобы в ограниченное время не допускать ошибок по невнимательности. Обученных вам моделей и оптимальных гиперпараметров!

Всеволод Мицкевич, Data Science, EPAM: Так как и задача, и состав команды известны заранее, стоит побеспокоиться о том, чтобы правильным образом делегировать задачи. Каждый из инженеров обладает сильными и слабыми сторонами в разработке. Следует поближе познакомиться между собой и выяснить, какой опыт каждого из участников команды релевантен по отношению к задаче хакатона. Кому-то стоит заняться подготовкой данных, кто-то лучше пишет код, а у кого-то обширнее теоретические знания. Правильное распределение ролей в проекте половина успеха!

Это пилотная статья. Будем благодарны за обратную связь. Если тема вызовет интерес, мы возможно примем решение выложить на GitHub наши исходники (python) и входные data-setы.

В марте 2021 г. случилось мне поучаствовать в хакатоне с задачей на комбинаторику и оптимизацию. Команду решил собрать свежую, из одиночек, дрейфующих в пуле самого хака. Довольно быстро нашлись front и back, и втроем мы принялись старательно думать, как потратим деньги, когда выиграемJ Так как сам кейс показался нам по началу не сложным. Надо сказать, что в хаках я не так давно, но уже успел поучаствовать и в ЛЦТ(Лидеры Цифровой Трансформации), и в Цифровом Прорыве. В последнем даже удалось занять бронзу в финале. Роль всегда у меня была project+product+ppt (хотя опыт в программировании у меня также имеется). Не редко в хакатонских кейсах проблемы немного надуманы, решения этих проблем немного фееричны и не несут практического смысла, а побеждает профессиональная преза и поставленный питч. Так вот этот мартовский хакатон меня заинтересовал живостью и насущностью бизнес проблем, которые там решались. Опытные хакатонщики, читающие эти строки, поймут. Но полно про хакатоны и про то, какие они бывают, а то собьемся с курса.

В этам хаке преза и даже front мало интересовали кейсодержателей. Это был натуральный бизнес хакатон с абсолютно живыми дата сетами и с натуральной бизнес болью. Кстати на хакатоне ни одна из команд не предоставила решение. Вроде одни ребята "нарисовали" в своей презе оптимизацию в минус 1 агент, но демонстрацию на защите они не представили. Наша команда не стала исключением и заняла скромное третье место (всего до защиты дошло 5 команд). Теперь наконец к условию:

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

Также предоставлена матрица 204х204 с расстояниями между точками (см. Табл.1 ниже ). Матрица не симметричная, т.к. при составлении учитывались знаки ПДД (одностороннее движение и пр.). Видимо она была получена через API Яндекс.Карт по адресам ТТ. Требовалось найти оптимальное расписание для торговых агентов (мерчендайзеров), улучшив показатели текущего AS IS (оно тоже предоставлено). Важные ограничения: каждая ТТ должна быть закреплена за определенным мерчендайзером (торговым агентом). Другими словами, если торговый агент (далее агент) посещает Магнит на улице Ленина в понедельник, то этот же Магнит в другие дни недели должен посещать именно он. Время работы каждого агента не должно превышать 9,5 часов в день с учетом работы в ТТ и перемещению между ними.

Таблица 1. Матрица расстояний между точками

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

Спустя какое-то время после хакатона наш back(python) призвал на помощь коллегу с курсов по deep learning. Парни погуглили, поискали готовый алгоритм, почитали про метод отжига, муравьев, генетику и пришли еще раз к выводу, что подходящего метода и примеров кода именно для этой задачи, куда можно было бы взять и вставить матрицу расстояний, как входной параметр на просторах интернета - нет. Если кто знает где есть поделитесь, будем благодарны.

Позднее, и даже в параллель я сам начал изучать тему Задачи коммивояжера и эвристические методы, зарекомендовавшие себя для ее решения. Но ни хабр, ни youtube, ни Википедия не давали готового ответа именно для этого частного случая. Останавливаться все равно не хотелось. Наоборот, по мере продвижения вперед интерес подогревался. Мотивации добавило то, что классическая задача коммивояжера относится к NP полным задачам. Если решать задачу полным перебором (brutal force), то уже при 66 торговых точках нужно несколько миллиардов лет и компьютер размером с Землю. Согласитесь, мощь трансвычислительных задач завораживает! И действительно, для решения классической задачи TSP (Travelling salesman problem ) существуют различные эвристические методы, такие как Метод Имитации Отжига, Муравьиный алгоритм, Генетический метод и др. Оставалось решить один вопрос: как применить что-то из этой эвристики к сквозному недельному расписанию нескольких торговых агентов с ограничением по времени. Возможно толковый математик, который кожей чувствует физический смысл дифференцирования, логарифмов, пределов, силу числа e и т.д., справился бы с этой задачей. Но я не такой математик. Формулы счастья по-прежнему в интернете не находилось. Я даже изучил основы нейросетей, но когда я начинал проектировать свою нейросеть для решения - вырастала непреодолимая стена.

И все-таки решение родилось! Ну во-первых я обратился за помощью к своему коллеге, Черкасову Евгению @eny01. Он как раз недавно прошел курсы по data science и python, и рвался в бой, чтобы применить все приобретённые навыки. К слову сказать, бОльшую часть алгоритма именно он и разработал. Себе я взял часть, отвечающую за рекурсивный метод ветвей и границ. Но об этом позже. Вдвоем мы разработали следующий план.

1. Мы декомпозировали задачу до каждого агента. Набираем ТТ сначала для одного агента до предела по очереди для всех дней недели, затем для второго и т.д.;

2. Процесс набора ТТ происходит с помощью жадного алгоритма (метод ближайшего соседа);

3. В случае, когда набор подходит к пределу (9,5 часов) - применяем оптимизацию и считаем, что для данного агента в этот день недели оптимальное расписание составлено. Переходим к следующему дню;

Алгоритм набора расписания для каждого агента более подробно можно увидеть на блок-схеме ниже:

Теперь чуть подробнее про основные моменты:

1. Ближайшие сосед:

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

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

Когда в одном из дней достигается предел рабочего времени (>=9,5 ч.), система сбрасывает точку приведшую к переполнению и пробует добрать следующую ближайшую. Кстати, мы пробовали вставлять сюда вместо оптимизации "первой точки" и ближайшего соседа полный перебор с ветвями и границами. И результат, !внимание!, получался в итоге тот же. Но времени на перебор с ветвями и границами потребовалось гораздо больше. Около 3,5 часов против 5 минут для всех 204 точек. Таким образом полный перебор был абсолютно избыточен и неэффективен при частом применении. Вследствие чего в этом месте было решено от перебора с ветвями и границами отказаться, но добавить его в финальную оптимизацию составленного расписания.

2. Метод ветвей и границ:

Ну тут все относительно просто. Утвержденное недельное расписание мы прогоняем через полный перебор, используя метод ветвей и границ. Реализация этой функции потребовала применения рекурсии. Причем если сравнивать работу полного перебора через библиотеку itertools (python), то время на перебор 8 точек составило 21 сек, в то время как наша рекурсия с ветвями и границами отрабатывала за 0.4 с. Что не может не радовать! Цель применения ветвей и границ - оптимизация уже готовых расписаний. Привязка ТТ и агентов уже не меняется, но оптимизируется время в пути (решаем классическую задачу коммивояжера).

Результаты:

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

Время работы алгоритма для всех агентов на всех днях недели составило 8 минут на домашнем ПК.

И в качестве финального аккорда мы позволили себе выкрутить лимит с 9 часов 30 минут до 9 часов 38 минут. И получили сокращение до 12 агентов с небольшой погрешностью. Из 60 дневных расписаний 14 уходят в переработки от 1 до 8 минут (51 минута в сумме).

Ждем ваших комментариев, замечаний и предложений! Ответим на все вопросы. Пишите, как бы вы решали эту задачу. Особенно ценны для нас будут мнения практиков. Как математиков, так и data science'ов. Возможно кто-то предложит существующие библиотеки python для решения задачи. Мы, как я уже сказал, подходящих библиотек не нашли. Всем спасибо, что дочитали до конца!

Всем привет! Меня зовут Андрей, недавно яприсоединился ккоманде VSRobotics изанимаюсь проектом автопостроителя сценариев диалогов робота-оператора. Вэтом посте хочу поделиться историей своего трудоустройства ирешением задачи LGD prediction, которое мне вэтом очень помогло. Несекрет, что начинающим DS-специалистам приходится преодолевать серьезные трудности, чтобы получить начальную позицию. Мнеже повезло получить офер, поучаствовав всоревновании иминовав изнурительные интервью имуки сомнений всобственной компетенции. Надеюсь, мой рассказ будет полезен иобратит внимание новичков нахакатоны иконференции как наотличные инструменты для активного поиска работы.

Вступление прошлая жизнь ипервые шаги вData Science

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

Впериод начала пандемии уменя освободилось время засчет отсутствия поездок доофиса, которое удалось использовать для изучения основ языка Python. Постигать азы начал спрочтения первого тома Лутца Изучаем Python. Летом 2020я попрощался сработой, чтобы перезарядить батарейки иуйти вперестройку. Выбрал онлайн курс поData Science иначал учиться.

Для себя ясформулировал, что хочу работать вкрупной компании, чтобы быть частью большого сообщества после учебы поставил себе цель найти подходящую позицию вСбере. Яотслеживал информацию оконференциях имероприятиях, вкоторых компания участвует. Благодаря странице https://ict2go.ru/companies/19/, яузнал, что Сбер участвует вконференции ScoringDay Весна 2021 икэтой конференции приурочен хакатон наплощадке dsbattle.com под названием LGD Prediction. Призеры соревнования (топ-3) получают бесплатный билет наконференцию ивозможность присоединиться ккоманде блока Риски. Нучтож, вызов принят!

Тяжело вучении, легко вбою!

0. Дрожащими руками, терзаемый сомнениями смогули я?, открыл ссылку сbaseline-решением наколабе. Посмотрел. Смогу. Визуальное знакомство сданными показало, что вцелом такие задачки решать яумею. Обычные табличные данные, задача регрессии, призовем CatBoost. Отмечу, что натот момент опыта участия всоревнованиях, кроме как вТитанике наKaggle, уменя небыло.

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

Целью задания было построить модель машинного обучения, предсказывающую LGD (Loss Given Default), другими словами, тудолю отвыданного кредита, которую банк потеряет вслучае дефолта заемщика. Для оценки качества модели использовалась метрика MAE mean absolute error, средний модуль отклонений.

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

1. После знакомства сдатасетом яразбил 35признаков для обучения на2группы: первая группа 24признака это финансовые показатели (выручка, чистая прибыль, совокупные активы ит.п.), вторая группа 11признаков различные прочие характеристики предприятия (срок ведения бизнеса, величина уставного капитала, объект взалоге).

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

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

Наэтапе предобработки данных важно проверить данные напропуски. Вданном случае это был ключевой момент, так как вобучающей выборке только38% объектов имели значения всех признаков, ау60% вообще отсутствовали данные изгруппы признаков финансовых показателей, только прочие характеристики. Для тестовой выборки картина была схожей.

Кроме того, япроверял данные надубликаты построкам (ихнебыло) ипостолбцам (были).

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

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

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

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

Заметно, что средний имедианный LGD укомпаний сфинансовыми данными существенно ниже, чем уоставшихся компаний.

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

Все пропуски вфинансовых данных язаполнил нулями.

Затем обратился кисследованию признаков выручка ивеличина уставного капитала. Пообоим столбцам япопытался выделить крупные компании вотдельную категорию. Исследовав медиану исредние при различных вариантах, остановился награнице в50млн руб. для выручки (больше категория corporation) и100тыс. руб. для уставного капитала (больше категория big).

Изсводных таблиц выше видно, что увыделенных категорий LGD существенно различаются.

Далее ярешил построить pairplot для признаков, которые есть увсех объектов это срок ведения бизнеса, срок смомента регистрации ОГРН, сгруппировав объекты покатегории залога.

Этот график позволил сделать следующие выводы:

• срок ведения бизнеса достаточно тесно коррелирует с целевым признаком;

• срок ведения бизнеса исрок смомента регистрации ОГРН доопределенного момента имеют тесную связь, нозначение второго ограничено сверху (поскольку пофизическому смыслу они выражают примерно одно итоже то, сколько компания существует, было принято решение остановиться наменее зашумленном признаке срок ведения бизнеса);

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

Здесь видно, что примерно после значения науровне 70срока ведения бизнеса LGD укредиторов, отдавших взалог жилое здание, падал донуля. Было только 4исключения. Ярешил ими пренебречь ивыделить такую группу вотдельную категорию безопасный заемщик.

Получилось 100 таких компаний вобучающей выборке.

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

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

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

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

Среднее качество модели, рассчитанное таким образом, составило 0.086. Затем яобучил модель навсей обучающей выборке иполучил качество 0.066.

Ниже график ошибок фактический LGD предсказание для обучающей выборки.

Заметно, что самые серьезные ошибки возникали тогда, когда модель выдавала LGD = 1, когда это небыло нужно, инепредсказывала0, когда это было нужно.

Затем ясделал предсказания для тестовой выборки, исистема показала, что ихкачество около 0.087: налицо было переобучение, нопоиграв сколичеством итераций вCatBoost ирегуляризацией, ядобился лишь небольшого улучшения 0.086. Так или иначе, оценка качества модели, сделанной пометоду берем только необходимое, оказалась выше, чем модель отбрасываем ненужное.

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

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

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

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

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

Большой итог

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

После всех докладов наконференции инаграждения (где мне также вручили приз засоответствие модели регуляторным требованиям), мне удалось приятно пообщаться спобедителем Артемом ируководителем направления вVSRobotics Александром. Выяснилось, что вкомпанию, посчастливому для меня стечению обстоятельств, нужны люди! После вопросов отом, знакомыли мне основные понятия изобласти обработки естественного языка ивообще интересноли мне это, мыобменялись контактами, ияотправил свое резюме ипортфолио нарассмотрение. Спустя некоторое время мне перезвонили, сделали предложение, ияприсоединился ккоманде VSRobotics!

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

1. Считаю, что мне вомногом повезло ссоревнованием вчастности, там было мало участников только у45человек результат оказался выше baseline. Правда, наверное, главное все-таки неколичество, акачество.

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

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

4. Лучше мало хороших признаков, чем много плохих.

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

6. Вовремя ипосле участия уменя сохранилось чувство сопричастности кчему-то объединяющему, ивсех участников ярассматривал некак конкурентов, акак товарищей, укоторых можно чему-то научиться ичем-то интересным поделиться сними.

Спасибо, что дочитали доконца! Буду рад выслушать конструктивную критику решения иответить навопросы!

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

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

Как нам пришла в голову идея провести первый онлайн-хакатон?

Помимо всего, что мы перечислили выше, перед нами стояла основная задача решить практическую проблему, к которой одна из наших команд долго не могла подступиться. У нас был корпус текстов, и на его основе нужно было создать алгоритм, который бы выбирал из этого корпуса именованные сущности, относящиеся к предметной области threat intelligence: злоумышленников (threat actors), вредоносное ПО (malwares), индикаторы компрометации (indicators of compromise) и прочие. Нюанс заключался в том, что корпус текстов был на английском языке. Задача была нетривиальная, интересная, но у нас до нее очень долго не доходили руки.

Почему именно хакатон, когда есть много других инструментов?

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

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

Как выбирали задание?

Процесс выбора задания сам по себе был увлекательным. В нем участвовали сотрудники сразу двух подразделений: Центра экспертизы и Департамента разработки. Первый помогает клиентам и партнерам выстраивать ИБ-процессы на базе наших решений, а второй разбит на команды по создаваемым продуктам. По сути департаменты и отдельные команды конкурировали друг с другом, и все они были заинтересованы в том, чтобы выбрали именно их задачу.

Мы проводили отдельную встречу, на которой желающие питчили каждый свою задачу и объясняли присутствующим, почему именно их задача должна быть выполнена на хакатоне. Например, Центр экспертизы предлагал в качестве задачи разработку нового генератора лицензий для компании. Было много интересных задач, но победила в итоге задача от команды продукта R-Vision Threat Intelligence Platform (TIP), представляющего собой платформу для управления данными киберразведки.

Суть задачи

Изначально задача в постановке команды TIP была конкретная и слишком специфичная для ИБ-сферы. Это было не очень удачно, поскольку на хакатоне предполагается определенная свобода действий для команды. Поэтому мы решили разбить задачу на две части.

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

2. Далее командам давалась полная свобода по созданию продукта. Результатом могла стать программа, ML-модель, иная реализация, которая позволила бы решать прикладные задачи сбора и анализа неструктурированных данных об ИБ-угрозах. Предпочтение планировали отдавать наиболее законченным решениям, которые закрывали бы целостную (end-to-end) задачу.

Неожиданности, с которыми мы столкнулись

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

Изначально мы рассчитывали примерно на 60 участников, то есть не более чем на 10 команд. Но из-за того, что это был первый в этом году онлайн-хакатон в России, количество претендентов превысило 200 человек. В итоге мы вынуждены были проводить отсев, потому что с точки зрения организации просто не выдержали бы такое количество команд. В конце концов мы отобрали 13 команд, из которых до фактической реализации прототипа решения дошли 9, остальные выбыли на промежуточных этапах.

С чего начали подготовку к хакатону

У нашего задания была определенная ИБ-специфика, мы поняли, что нужно доступно объяснить задачу участникам, которые вообще не знают, что такое ИБ и индикаторы компрометации. Для этого Антон Соловей aka @likeafreedom, менеджер продукта R-Vision TIP и по совместительству тамада нашего хакатона, отвечал за взаимодействие с участниками: готовил задания, презентацию, проводил питчинги с командами вместе с другими экспертами нашей компании, делал все необходимое, чтобы хакатон состоялся. Чтобы ввести в курс дела далеких от области ИБ разработчиков и дизайнеров, мы решили отойти от позиционирования наших продуктов и не объяснять, что такое IRP, SGRC, TIP, SENSE и Deception, поэтому в презентации о компании визуализировали наши решения в виде маскотов.

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

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

Хакатон в цифрах

• Длительность 45 часов.

• Более 220 заявок на участие, конкурс 4,5 человека на место.

• 13 команд, 9 из них дошли до готового решения, 6 прошли в финал, из них осталось 3 победителя.

Этапы хакатона

1. Пятница, вечер. Знакомство. Рассказ о задании, презентация компании R-Vision.

2. Пятница, ночь. Разработка прототипа.

3. Суббота, утро. Питч решения: то, что успели сделать за ночь. 5 минут на питч.

4. Суббота, весь день и ночь. Второй питч: относительно готовый вариант.

5. Воскресенье, утро. Готовое решение на оценку экспертам.

Решения, которые выполнили команды

Команды-участники прорабатывали презентации своих решений и дизайн инструмента. Из интересных можно выделить решение команды Digital Rover, которая придумала что-то вроде Алисы для инфобеза виртуальный помощник на основе искусственного интеллекта для описания угроз по реальным документам. Решение на основе языковой модели ruGPT3 представляет собой бот для Telegram, который позволяет написать что-то на нативном языке текстом либо отправить голосовой запрос. У инструмента есть весь наш корпус текстов, который он переводит на английский язык. Затем он переводит на английский полученное текстовое или аудиосообщение, анализирует соответствие запроса содержимому корпуса документа и выдает пользователю релевантную информацию. Например, можно написать или сказать: Расскажи мне про такую-то уязвимость или Напиши больше информации про такой-то индикатор компрометации, и бот будет отвечать выжимками из корпуса текстов.

У нас была опросная форма, где каждый эксперт ставил оценки по своему блоку по 10-балльной шкале, на каждом этапе эксперты выставляли промежуточные оценки. Изначально задумывался один победитель, но после финального суммирования весов (баллов) по каждой экспертизе оказалось, что у трех команд была настолько минимальная разница в баллах, что мы приняли решение определить трех победителей, которые разделили между собой призовое место. У всех были очень интересные решения, было просто невозможно выделить кого-то одного. В итоге победителями стали команды:

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

   • Создание системы фильтрации источников аналитики по ключевым словам

   • Аннотация новых отчетов для выделения терминов, имеющих отношение к ИБ-аналитике, и добавления документа в базу знаний

   • Подключение справочных систем (MITRE и MISP)

   • Визуализация взаимосвязей между сущностями предметной области ИБ

2. Stellar. Проект R-Vision Assistant cервис для сбора, визуализации и аналитики данных по угрозам кибербезопасности. Особенности сервиса удобный и понятный UX/UI-интерфейс, возможность работы с различными источниками данных о киберугрозах и добавления новых. Решение содержит много вариантов визуализации, аналитики.

3. DEV Labs. Интерфейс для полуавтоматизированного парсинга основных сущностей из неструктурированных источников данных, в рамках которых ИБ-специалист анализирует уязвимости. Программа нацелена на повышение качества данных, сохраняемых в базу знаний.

Находчивость приветствуется

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

Выводы

Что нам в итоге удалось

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

Что можно было бы сделать лучше

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

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

Планы на будущее

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

Привет, Хабр! Сегодня хотим представить вам проект студентов магистратуры Наука о данных НИТУ МИСиС и Zavtra.Online (подразделении SkillFactory по работе с университетами) созданный на внутреннем хакатоне, который прошел в марте. Команда поделится решением выбранной задачи предсказание победителя-бойца турнира UFC. Задача отличалась от прочих тем, что после написания модели из неё можно сделать целый продукт, оформив модель в приложение, готовое к использованию конечными пользователями, например теми, кто захочет обыграть букмекеров.

Гипотеза и её проверка

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

• физические параметры бойца (его рост, вес, размах рук и ног);

• возраст бойца (всё-таки со временем физически мы слабеем);

• разница в опыте соперников (вряд ли какой-то новичок без опыта одолеет Хабиба);

• характер поведения бойца на ринге (чаще обороняется или чаще нападает);

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

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

Принцип разделения прост: мы случайным образом разбиваем свои данные примерно на 70 %, используемых для обучения модели, и 30 % для тестирования модели. Однако есть нюанс... Для предсказания результата боя UFC важно, чтобы тренировочная выборка была раньше тестовой во временном периоде.

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

Разработка проекта

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

Примерно 90 % времени мы потратили на обработку данных и остальные 10 % на обучение модели. Пайплайн подготовки данных верхнеуровнево выглядел следующим образом: мы очистили датасет от пропусков и выбросов и обогатили его новыми признаками.

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

Сбор данных и статистика

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

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

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

Предобработка данных

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

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

Вторым шагом был сбор фичей с кумулятивной статистикой по всем предыдущим боям для каждого из соперников и генерации из получившейся накопленной суммы новых важных признаков, таких как серия побед, сумма побед нокаутами, сумма чистых побед, точность ударов, среднее время боя, KO/TKO и т. д. Это перечень важных показателей по уже проведённым боям, которые обычно публикуются на сайте UFC до начала боя. Затем мы посчитали разницу по физическим характеристикам бойцов, удалили коррелированные между собой величины и законсервировали данные в pkl-файл.

Случайный лес, стекинг, бэггинг и итоговая модель

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

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

Процент точности прогноза победы варьировался от 75 до 82%! Но какая разница, если обучение было неправильным?.. Модель не должна смотреть в будущее, как это было у нас. Решить эту проблему удалось достаточно просто: мы вернули даты для нашего датасета и поделили на тренировочные и тестовые по датам: данные до 2018 года взяли за тренировочные, данные после 2018 года за тестовые, и вуаля, точность упала в среднем на 5 %, однако теперь мы в ней хотя бы уверены.

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

Посмотреть на модель можно на GitHub.

Для того чтобы модель предсказала победителя на новых данных, нужно эти данные обработать таким же образом, как мы это делали в нашем ноутбуке (Jupyter Notebook) DeepOverfitting-DataPreparing, после этого просто подать эти строчки данных для двух бойцов в predict функцию нашей модели и получить предсказание, либо 0, либо 1, 0 победил 2 боец, 1 победил первый боец.

Итоги

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

Поэтому мы наметили следующий план:

1. Улучшим точность предсказаний путем более кропотливой настройки модели.

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

3. Попробуем применить нейронные сети и глубокое обучение.

4. Разработаем приложение, которое будет в удобном виде показывать, сколько и куда ставить.

5. Станем кем-то кроме букмекера, кто заработает на ставках. И, конечно, будем писать на Хабре про дальнейшее развитие проекта. Букмекеры, берегитесь, мы идём за вами.

Состав команды работавшей над проектов:

• Евгения Шикина (г. Видное)

• Оксана Евсеева (г. Барселона)

• Максим Щиколодков (г. Москва)

• Михаил Стриженов (г. Москва)

• Лев Неганов (г. Москва)

• Кирилл Плотников (г. Екатеринбург)

Узнать больше про магистратуру можно на сайтеdata.misis.ruи вTelegram канале.

Ну и конечно не магистратурой единой! Если вы хотите узнать больше про data science, машинное и глубокое обучение заглядывайте к нам на соответствующий курсы, будет непросто, но увлекательно.

Узнайте, как прокачаться и в других специальностях и навыках или освоить их с нуля:

• Профессия Data Analyst

• Курс по Data Engineering

• Курс "Математика для Data Science"

• Курс "Математика и Machine Learning для Data Science"

• Курс "Алгоритмы и структуры данных"

С мая по сентябрь 2021 годв пройдет DIGITAL SUPERHERO ежегодный марафон для IT-специалистов России, который организует группа компаний Innostage при поддержке правительства Республики Татарстан. Цель марафона создать среду для развития и пилотирования цифровых разработок в бизнес-сегменте и госсекторе.

Первое мероприятие в рамках марафона питч-сессия Fintech-проектов, которая пройдёт 27 мая. Приглашаются стартапы по трём направлениям: устойчивое развитие (ESG), Research Tools и RiskTech.

Заявки принимаются до 23 мая на сайте мероприятия.

Что получат победители:

- Компенсацию расходов на проведение пилотного внедрения (до500000 рублей)

- Экспертную и менторскую поддержку

- Возможность масштабирования решения после успешного пилотного внедрения

- Возможность пройти отбор дляучастия вDemo Day наKazan Digital Week ивыиграть 300000 рублей

- Фирменный мерч Ак Барс Банка

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

_______

Впервые марафон хакатонов DIGITAL SUPERHERO проходил с мая по сентябрь 2020 года, вот главные цифры о нём:

1 120 человек подали заявку на участие в проекте

177 команд приняли участие в проекте

42 команды стали финалистами

2,4 млн. рублей общий призовой фонд онлайн-хакатона

70 городов масштаб хакатона

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

Эта статья от том, как я организовал Хакатон для IT компании в Малайзии в самые первые месяцы пандемии. Игра была целиком посвещена Linux администрированию, траблшутингу и хакингу. При этом она позволяла поучаствовать всем сотрудникам, от junior инженера технической поддержки до senior архитектора.

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

Дано:

• Компания системный интегратор в Куала Лумпуре;

• Интернациональная команда IT-специалистов;

• 99.99% персонала внезапно ушло на удаленку.

Задачи:

• Позволить сотрудникам отвлечься от работы и снизить уровень стресса;

• Развить навыки, используя геймификацию;

• Развить внутренний бренд для будущих IT игр.

В чем заключалась сложность?

• Неравномерный уровень подготовки и квалификации.

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

• Сменный график работы сотрудников.

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

• Локальный менталитет.

К особенностям местного населения необходимо привыкнуть. Работают в компании в основном малайцы, индийцы и китайцы. Преимущественно они не задают вопросов, опасаются участвовать в чем-то новом и непонятном. Раз в неделю 80% сотрудников покидает офис на 2,5 часа по религиозным соображениям. На корпоратив добрая половина придет только если пообещать им лотерею и призы (очень популярная практика у местных компаний). Заинтересовать таких людей участием в игре было нелегко.

Мне удалось =)

А где Гарри? Шалит с новым хакатоном.

• Неразбериха из-за пандемии.

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

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

• Демотивированный персонал.

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

Еще как может! Риск не собрать аудиторию не оправдался.

Типичный сотрудник в самом начале пандемии.

План подготовки и проведения хакатона

В моем случае выполнение всех этих действий позволило мне успешно провести мероприятие.

• Разработка концепта игры.

Я решил, что темой хакатона будет Linux администрирование. Соответственно, задания должны были строиться вокруг базовых административных задач: проверялось умение использовать command line, браузерные тулзы, знание SQL, DNS, самые основы шифрования.

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

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

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

На этом же этапе была продумана система поощрений.

1. Top-3 самые ценные индивидуальные призы;

2. Top-10 дополнительный специальный пак призов;

3. Первые 50 участников гарантированные призы из дешевого ценового диапазона.

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

• Технический дизайн.

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

В качестве хостинг площадки был выбран AWS. Игровые серверы и хост с веб формой были подняты на t2.medium EC2 инстансах. К каждому инстансу был привязан 1 бесплатный домен. В качестве базы данных использовалась Amazon DynamoDB. Форма была написана на Python и фреймворке Flask. Бэкенд формы был выполнен на основе FaaS (Function as a Service) подхода с помощью связки API Gateway + Lambda + DynamoDB.

Выбор такой технологической базы был обусловлен субъективными пожеланиеми организаторов, наличием необходимой корпоративной облачной подписки, и знаменитым правилом start where you are. Последний принцип подсказал, что можно взять подходящую web форму, используемую в продакшене, и переписать ее под нужды игры. Пользуясь случаем, Алекс и Саша, огромное спасибо за помощь с AWS деплойментом и девелопментом формы. Без вас мне бы было значительно сложнее.

• Презентация концепта руководству и получение бюджета.

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

Как ощущаешь себя когда получаешь максимальный бюжет на проект.

• Разработка дизайна и внешнего вида.

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

• Выбор и заказ призов.

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

• Рассылка тизеров до начала игры.

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

• Сюжетное обрамление.

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

• Релиз.

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

• Элемент обучения.

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

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

• Организовать постоянный follow up.

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

• Выдать призы.

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

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

• Собрать обратную связь.

Действовать следовало итеративно и с фидбеком. Поэтому всем участникам был разослан опросник. 25% заполнили его. Об ответах в описании результатов.

Весь подготовительный процесс занял 2 месяца и 68 человеко-часов главного организатора. Но результат стоил того.

Результаты:

• Боевой дух команды вырос.

Игра подразумевала индивидуальное участие и решение задач. Однако, мне доподлинно известно, что люди объединялись в команды, устраивали созвоны и брейнштормы. Активным участникам точно было не скучно. Люди, которым в силу неопытности удалось прорваться только через несколько уровней, определенно научились чему-то новому. Цель отвлечь участников и снизить градус напряжения была достигнута.

• Позитивный фидбек от участников.

Одним из факторов, которые говорят о безоговорочном успехе мероприятия, является факт участия тяжелых на подъем сотрудников. Хакатон имел успех и среди линейных менеджеров, которые по долгу службы не работают с Linux напрямую, и среди инженеров-ветеранов.

Три наиболее частые причины почему участники согласились играть:

1. Возможность проверить свои скиллы;

2. Любовь к играм и соревнованиям;

3. Любопытство.

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

• Карт-бланш и бюджет на проведение новых хакатонов.

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

Личное:

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

А еще я сформулировал и взял на вооружение...

Ключевые принципы организации хакатонов.

• Знайте свою целевую аудиторию.

Хакатоны - для всех!

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

• Агитируйте правильно.

Землю - крестьянам, игры - айтишникам!

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

• Управляйте сложностью.

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

У меня есть пароль, но нет логина. Зарепортить игровой баг или поискать еще?

• Позвольте играть не так как задумано.

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

А Барсик один в игре ковыряется, посмотри на него!

• Призы хорошо, но не главное.

А как же сектор приз?

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

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

Спасибо, что прочли. Увидимся в будущих публикациях!