Участники фестиваля Rucode строили модели машинного обучения, определяющие вероятность принятия или отклонения государственного законопроекта на основе датасетов ИНИД с НПА за девять лет и сводных отчётов ОРВ за шесть лет.
Всего в соревновании участвовало более 20 команд и индивидуальных программистов со всей России. Четверым участникам, занявшим призовые места, удалось создать модели с точностью от 0.89 до 0.90.
О поставленной задаче и возможных подходах к её решению
Перед разработчиками ML-моделей стояла задача определить, будет ли принят нормативно-правовой акт (НПА) или нет. Для этого ИНИД предоставил им данные в виде нескольких csv-таблиц, где содержалась информация о проектах нормативно-правовых актов за период с 2012 по 2021 год, а также сводных отчётов об оценке регулирующего воздействия за период с 2015 по 2021 год.
Метрикой качества моделей был выбран показатель ROC AUC, который может принимать значение в виде дробных чисел от 0 до 1, при этом чем оно выше, тем лучше точность прогнозирования.
Решения участников загружались в Kaggle и те из них, которые получили наиболее высокий score (score — это точность ML-модели) на private leaderboard, были презентованы 20 ноября — в финальный день направления «Искусственный интеллект» Всероссийского учебного фестиваля RuCode 4.0.
«Задача достаточно сложная. Данные разнородные: как текстовые, так и табличные. Некоторые участники решали эту задачу как задачу ML: занимались выбором наиболее подходящих моделей и оптимизацией гиперпараметров. Другие же пытались понять природу данных, найти корреляцию между отдельными признаками и тем, будет ли проект НПА принят в качестве закона или нет, т. е. по сути занимались конструированием признаков», — рассказал дата-аналитик ИНИД Константин Глонин, член жюри RuCode 4.0.
О предложенных решениях
Третье место
Татьяна Аюева
Score: 0.89055
«Самыми важными являются признаки ФИО создателя проекта и ответственного за него. При добавлении этих признаков, качество улучшается на 7-8%. Я оставила ФИО только тех, у кого не меньше трёх проектов.
Из названий актов я выделила те, которые начинаются «на внесение изменений в» и среди них выделила несколько категорий: «федеральный», «приказ», «правила», «отдельные», «постановление». Это тоже дало улучшение результата где-то на 1%.
Также важным показателем является год, в котором был опубликован проект. Он тоже даёт прирост к качеству около 1%.
Заполняемость последних пяти колонок (problem_addressed, act_objectives, persons_affected_by_act, relations_regulated_by_act, act_significance) очень коррелированна. Я оставила только 1 показатель, а именно факт заполняемости колонки act_objectives («Краткое изложение целей регулирования»). Этот показатель также дал небольшой прирост в качестве.
Не улучшило результат:
Татьяна Аюева
Второе место
Команда DarkSide (Данил Вагапов, Никита Понькин и Василий Челпанов)
Score: 0.89204
«Фичи из таблиц ria_reports имели в большинстве своём низкий приоритет. Мы объединили их в одну на основе уникального идентификатора. Возможно, на высокий private score, который нам удалось достигнуть, повлиял наш подход к заполнению пропусков в данных — мы их заполняли самыми частыми значениями по столбцу. Те проекты, для которых в данных были пропуски, принимались чаще. Возможно, для CatBoost, который мы использовали для построения модели, работает какой-то триггер, что если он встречал значение, которое много раз уже было на обучающей выборке, значит, проект, вероятнее всего, будет принят».
Данил Вагапов, команда DarkSide
Первое место
Дмитрий Кузюрин
Score: 0.89862
«Наиболее сильное влияние на целевой признак оказали:
Также заметное влияние на принятие НПА оказывает количество просмотров страницы, на которой размещён проект НПА (чем больше просмотров, тем с большей вероятностью будет принят проект), степень регулирующего воздействия проекта НПА и заключение Минэкономразвития об оценке регулирующего воздействия.
Несомненное влияние оказывает и тематика законопроекта. Так, проекты НПА, посвященные изменению образовательных или профессиональных стандартов, принимаются с меньшей вероятностью, чем проекты других тематик».
Дмитрий Кузюрин
Константин Глонин, аналитик данных ИНИД, член жюри RuCode 4.0:
«Мне понравилась идея Дмитрия Кузюрина применить кластеризацию по признаку act_title (название законопроекта). Он попытался выделить кластеры из текстового описания заголовка законопроекта и их уже использовать в качестве фичей для обучения модели. Дмитрий был единственным, кто применил такой подход, и хотя его модель получила второе место по Score, мы решили поощрить его, присудив ему первое место, чтобы он разделил его с Константином Тихоновым, показавшим наилучший результат на private leaderboard. У Константина, в свою очередь, было хорошее решение с точки зрения разделения на тестовую и обучающую выборки, он был единственным, кто использовал кросс-валидацию, и, возможно, именно это объясняет то, что у него получилась более устойчивая модель с самым высоким Score».
Константин Тихонов
Score: 0.90220
«Моя финальная модель получилась компактной и состояла из 25 переменных, в основной массе полученных из файла regulations.csv, и добавленных к ним двух переменных, построенных из текста правового акта (тип НПА и длина текста), а также двух переменных на основе дополнительного файла ria_reports_main.csv (наличие соисполнителей и средний показатель прохождения НПА с данными соисполнителями). Такая компактность стала результатом удаления после многочисленных тестов тех переменных, которые лишь портили модель, и перевода больших групп фиктивных переменных в одну категориальную.
На пике модель состояла из 240 переменных, но было понятно, что если выкинуть, скажем, половину из них в соответствии с feature_importance, то результат будет только лучше. Выкидывать переменные в соответствии с feature_importance не хотелось, так как этот показатель, прямо скажем, не очень релевантен. От решения трудоёмкой задачи отбора переменных меня спас переход с классификатора XGBoost к CatBoost. Хотя результаты работы практически не изменились, сам процесс стал занимать меньше времени, а главное — появилась возможность передавать классификатору категориальные переменные, что не только сократило число фичей, но и впоследствии заметно улучшило результат.
Если говорить о самих НПА, а не о моей модели, то оказалось, что для принятия акта очень важно, чтобы он разрабатывался Росгвардией, Минпросвещения, Рособрнадзором, Роскосмосом или Росграницей. Если же правовой акт разрабатывался ЦБ РФ, Роспотребнадзором, Минстроем, ФСТ, Следственным комитетом или ФСБ, то шансы на его принятие минимальны. Интересно, что среди людей, выдвинувших наибольшее количество НПА, встречаются те, у кого ни один из предложенных НПА принят не был. В целом переменные added_by, developer и responsible оказались наиболее значимыми в моей модели.
Стоит отметить, что перед началом фестиваля у меня не было большого опыта решения задач классификации, поэтому в поисках оптимальной модели я решил ограничиться лишь наиболее «рейтинговыми» алгоритмами градиентного бустинга, проигнорировав нейронные сети, случайный лес и многие другие».
Константин Тихонов
Можно ли действительно предсказать, какие законопроекты примут, а какие — нет?
Мария Василевская, руководитель дата-отдела ИНИД, член жюри RuCode 4.0:
«Если мы говорим об экономическом регулировании, то ответ на этот вопрос должен быть в большой части случаев положительным: законопроект должен приниматься тогда, когда выгоды от его введения превышают издержки, а методы, которыми он оперирует, являются компромиссными для всех заинтересованных участников экономических отношений.
Для того чтобы решение о принятии такого «экономического» НПА действительно основывалось на подобных соображениях, в Минэкономразвития ввели процедуру оценки регулирующего воздействия, собирающую в себе экспертизу и общественное обсуждение проектов нормативных актов. Получается, что, анализируя документацию и другие «цифровые следы», которые оставляет процедура ОРВ, мы должны с хорошей точностью предсказывать целесообразность НПА, а значит, вероятность его принятия. Это и попытались сделать участники фестиваля Rucode на данных, которые мы в ИНИД собрали из Федерального реестра нормативно-правовых актов.
Если посмотреть только на результаты победителей RuCode на лидерборде (0.9 по метрике ROC AUC считается отличным качеством предсказания), кажется, что всё так и получилось. Однако переменные, которые в моделях оказались значимыми, вовсе не связаны с выгодами, издержками и вообще напрямую с качеством изучаемых НПА. Заполненность отчётов, длина текста проекта, министерство-разработчик (и даже фамилии конкретных разработчиков), месяц и год создания, упоминание постановлений Правительства — эти признаки, обеспечивающие большую часть предсказательной силы моделей, ничего нам не говорят о сути принимаемого проекта. Характеристики же последствий принимаемого регулирования не вошли ни в одну из полученных моделей, в частности, потому что их почти никогда не заполняют.
Эти результаты согласуются с исследованием процедуры ОРВ, которое недавно проводил ЦПУР. Это здорово, ведь когда в социальных науках исследователи хотят измерить вклад того или иного фактора (без анализа причинности) в изучаемую величину, они, как правило, пользуются простыми линейными моделями. Часто остаётся вопрос: а может быть, связь переменных просто сложнее и наши модели недостаточно чуткие для того, чтобы её уловить? Однако по крайней мере в этом случае, получилось, что и нелинейные ансамблевые модели — в частности, градиентного бустинга — показывают примерно такие же результаты, хоть и обладают большей точностью предсказания. Это говорит о том, что мы все в целом смотрим на ситуацию в правильном направлении».
Как вы в целом оцениваете фестиваль RuCode 4.0?
Алексей Клёсов, менеджер проектов ИНИД, член жюри RuCode 4.0:
«Фестиваль RuCode 4.0 был очень интересным и полезным мероприятием. Во-первых, мы довольны тем, что нашу задачу решило более 20 команд. На старте мы не ожидали, что будет столько команд, так как наша задача очень нестандартная. И был риск, что эта тема мало кого заинтересует. К счастью, наши опасения не подтвердились, и мы безусловно рады, что тема «принятия и отклонения законопроектов» вызвала интерес среди разработчиков.
Во-вторых, мы также довольны организацией и подготовкой фестиваля. ИНИД впервые участвует в этом мероприятии, и с первого дня организаторы много помогали нам, начиная с постановки задачи и заканчивая участием в жюри финальной защиты проектов. Поэтому сотрудничеством мы полностью удовлетворены. Желаем фестивалю RuCode 4.0 дальнейшего развития и успехов».
Сотрудники ИНИД также участвовали в трансляции финального дня Всероссийского учебного фестиваля RuCode.
