Хабрахабр

Управление проектами машинного обучения с высокой ценой ошибки. Лекция в Яндексе

Модели машинного обучения нужно уметь не только разрабатывать, но и «продавать» заказчику. Если у него не будет понимания, почему предлагается именно такое решение, то всё закончится статьёй в журнале и выступлением на конференции. Директор компании Loginom Алексей Арустамов обращает внимание на ключевые моменты, которые важно отразить в описании модели. Это выступление прошло пару недель назад на конференции Яндекса из серии «Data & Science».

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

— Меня зовут Алексей Арустамов, я из компании Loginom. Раньше мы назывались BeseGroupLabs. Вещами, связанными с анализом данных, мы занимаемся достаточно давно — наверное, лет 20. Все это время мы ничем, кроме аналитики, не занимались.

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

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

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

Структура особо не поменялась, приблизительно то же самое. Это данные Росстата за 2016 год. п. Как несложно увидеть, 80% всего, что связано с экономикой, связано с традиционными отраслями типа строительства, банков, торговли и т.

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

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

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

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

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

Чтобы это понять, я бы предложил обратить внимание на это определение Пятецкого-Шапиро, что такое data mining.

Для людей, которые специализируются на data science, — для них, к сожалению, что важно? Обратите внимание на то, что выделено красным цветом, — «делать доступным для интерпретации». Взяли данные, зарядили 500 атрибутов, зарядили желательно нейросеть, иначе будет позорище без нейросети, построили модель, которая непонятно что делает для пользователя, но зато это круто, можно рассказать коллегам.

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

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

Почему это не становится массовым, хотя, вроде бы, должно? В чем проблема? Основная проблема в доверии.

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

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

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

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

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

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

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

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

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

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

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

Он делится на этапы, которые надо аккуратно описывать в этом документе.

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

Например, телефон 12345678. Второй блок — проверка бизнес-гипотез, когда есть данные, которые выглядят недостоверно. Или email 1@1. Такой телефон может существовать, но скорее всего, это какой-то фейк. Тоже похож на правду, но вряд ли. 1. Обязательно надо убедиться, что данные достоверны, что с точки зрения бизнеса им можно доверять.

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

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

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

В первую очередь — плохая статистика. Понятно, что объяснения простые. Или какая-то дисперсия. Нужно обязательно в документе написать, что 50% пропусков не годится.

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

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

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

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

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

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

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

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

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

Клиент придумал собственное правило подсчета оттока. У нас был реальный случай: мы прогнозировали отток клиентов, там была построена одна модель, мы считали оттоком одно, а клиент — другое. Это должно быть согласовано. Конечно, они не совпали, нам сказали — вы дураки, все сделали неправильно. Есть разные методы, есть разные способы определения. Оно может быть задано хоть ручками, хоть экспертами — все равно. Но важно, чтобы они были зафиксировано.

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

Оно состоит из нескольких вещей. Наконец, мы добрались до моделирования.

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

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

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

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

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

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

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

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

Тут сказано, что модель должна соответствовать экономическому смыслу. После всех перечисленных телодвижений последнее — финальная проверка. Мы же математики, зачем нам экономический смысл, нам нужно, чтобы AUС был большой, Джини, все дела. Что это значит? Мы бы это просто закодировали, ввели куда-то баллы и не парились. Но в голове у рисковиков, которые находятся в этом бизнесе, нет готовой формулы или правила, иначе все это было бы не нужно. Считается, что в этом диапазоне, плюс-минус километр, наверное, да. Но дело в том, что у них в голове есть облако допущений. Нужно, чтобы эта штука не вызывала хотя бы явного отторжения. Если оно выходит за границу, то это вызывает подозрение. Этого вполне достаточно, чтобы повысить доверие.

Во-первых, мы указываем область применения и все ограничения, которые на эту систему накладываются. Нам нужно превратить модель из черного ящика в ящик, который можно хоть как-то интерпретировать. Очень часто это упускают. Во-вторых, обязательно укладываем все преобразования. Никто не говорит, как эта выборка была подготовлена. Люди считают, что мы подготовили данные, подали на вход выборки. Подготовка данных — самое трудное, там обязательно будут какие-то проблемы. Возможно, это связано с тем, что специалисты по data science взяли на Kaggle какую-то выборку, пульнули ее в какую-то модель, и дальше соревнуются, у кого больше AUС, хотя никто не говорит, как данные были подготовлены. Если будет неправильное преобразование, то все остальное вообще не поможет.

Люди должны понимать, что мы сделали преобразование таким-то образом. Вопрос в том, что они должны быть предсказуемые. Чем больше соломы вы вокруг постелите, тем лучше. Понятно, что нужно рассказать обо всех граничных ситуациях. Нужно объяснить все факторы, аргументировать это дело. Если упадете, то будете знать, где. К сожалению, это возможно не всегда, но чем больше аргументов, которые более-менее хорошо интерпретируются, вы приведете — тем лучше. И нужно объяснить модель, если это возможно. Надо обязательно использовать все варианты тестирования, какие будут поблизости.

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

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

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

Люди думали, что machine learning — это же круто, сейчас подадим данные, и система начнет ратовать за все хорошее, светлое и прекрасное. Немного анекдотичный случай.

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

Увеличивайте доверие всеми возможными способами. Если мы хотим превратить анализ данных, продвинутую аналитику и машинное обучение в ежедневную потребность, то я призываю вас смотреть на все с точки зрения бизнеса, возможностей и готовности использовать доверие к системе в продакшене. Сначала надо придумать, как ее защитить. Если вы не придумаете способ, как обосновать и повысить доверие, думаю, не стоит делать эту модель. Тут то же самое. Это чем-то напоминает test-driven development: сначала придумываем тесты, а потом думаем, как их провести. Я закончил, спасибо. Сначала думаем, как будем аргументировать, потом под эти аргументы подводим данные.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»