Модели машинного обучения необходимо иметь возможность не только разрабатывать, но и «продавать» заказчику.
Если у него нет понимания, почему предлагается именно это решение, то все закончится статьей в журнале и выступлением на конференции.
Директор Логинома Алексей Арустамов обращает внимание на ключевые моменты, которые важно отразить в описании модели.
Это выступление состоялось пару недель назад на Конференции Яндекса из серии «Data & Science» .
Если ваша цена ошибки невелика, то не важно, что вы там интерпретируете.— Меня зовут Алексей Арустамов, я из компании Логином.Вы дали неправильную рекомендацию - ну и бог с ней.
В поиске что-то вывели - ну ничего страшного.
Но все меняется, когда дело касается вещей, связанных с большими затратами, где цена ошибки очень высока.
И потом, люди не очень любят доверять черному ящику.
Это просто здравый смысл.
Раньше нас называли BeseGroupLabs. Мы занимаемся вещами, связанными с анализом данных, довольно давно — наверное, около 20 лет. Все это время мы не занимались ничем, кроме аналитики.
Я хотел бы поговорить об опыте, который мы накопили за это время, и о том, как вести такие проекты, как уметь их реализовывать.
Для начала давайте посмотрим, какие задачи чаще всего решаются в системах и проектах, связанных с машинным обучением.
Если вы обратите внимание, значительная часть задач вращается вокруг этого пула.
Вещи, связанные с поиском, различные варианты рекомендаций, пополнения, чаще всего из соцсетей, да и из других источников тоже.
Много обработки изображений и тому подобное, подобные задачи.
На первый взгляд это круто, но с другой стороны, мы говорим о том, что машинное обучение и анализ данных должны принести пользу бизнесу.
Если мы об этом говорим, то было бы неплохо понять, где вообще находится бизнес.
Структура российской экономики выглядит примерно так: 
Это данные Росстата за 2016 год. Структура особо не изменилась, примерно такая же.
Как несложно заметить, 80% всего, что связано с экономикой, связано с традиционными отраслями, такими как строительство, банки, торговля и т. д. Если мы обратим внимание на эти отрасли экономики, то быстро увидим, что задачи, которые там ставятся, не похожи на поиск или «разбор изображения» или что-то в этом роде.
Они звучат примерно так.
Задачи, вокруг которых чаще всего все вращается: оптимизация запасов, управление рисками, оптимизация производства, логистики, транспорта, перевозки людей и т. д. Если вы выйдете и зайдете в другую компанию, спросите, делали ли они что-нибудь в этом направлении, вы, скорее всего, услышите, что ничего не было сделано, ситуация с анализом совсем плохая.
И это звучит странно.
Вроде бы сколько программистов, давайте сейчас закодируем, обрадуются, почему в большинстве случаев ничего не взлетает? Что еще странно в этом деле, так это то, что люди занимаются задачей дать нам по лицу угадать, какое у человека настроение.
Круто, но не понятно, какое это имеет отношение к бизнесу.
Если увеличить товарооборот на 1%, уверяю вас, все эти образы, весь экономический эффект накроет их, как бык овцу.
Эффект ни с чем не сравнить.
Казалось бы, у нас есть потребность, люди этого хотят, все горит синим пламенем, почему не начинается? Даже когда они пытаются все сделать, эта штука не реализуется нормально.
Чтобы это понять, я бы предложил обратить внимание на такое определение Пятецкого-Шапиро, что такое интеллектуальный анализ данных.
Обратите внимание на то, что выделено красным.
Сделайте его доступным для интерпретации.
Для людей, которые специализируются на data science — для них, к сожалению, что важно? Мы взяли данные, зарядили 500 атрибутов, желательно зарядили нейросеть, иначе без нейросети будет позор, построили модель, которая не понимает, что она делает для пользователя, но это круто, можете рассказать коллегам.
Когда Пятецкий-Шапиро это написал, это не было глупостью.
Каждое слово.
Умение интерпретировать полученные результаты очень важно.
Если ваша цена ошибки невелика, то не важно, что вы там интерпретируете.
Вы дали неправильную рекомендацию - ну и бог с ней.
В поиске что-то вывели - ну ничего страшного.
Но все меняется, когда дело касается вещей, связанных с большими затратами, где цена ошибки очень высока.
И потом, люди не очень любят доверять черному ящику.
Это просто здравый смысл.
Готовы ли вы поставить свою машину на кон и сказать, что построите модель, которая что-то предсказывает? Или что-то дорогое.
Скорее всего, так не получится.
Предприятия не хотят этим пользоваться; риски для них очень высоки.
И тогда всякие варианты типа черного ящика не особо работают. Они будут слушать, цокать языком.
Если это делается за чужой счет, они обязательно это сделают, они любят повозиться с чем-нибудь интересным.
Но если это ваши деньги, то особого энтузиазма это не вызовет. 
В чем проблема? Почему это не получает широкого распространения, хотя кажется, что должно? Основная проблема – доверие.
Каждый раз, когда вы заталкиваете людей в черный ящик с неизвестной магией внутри, люди не могут ему доверять – прежде всего потому, что они не понимают, что делает черный ящик.
А доверие формируется прежде всего за счет предсказуемости.
Люди должны понимать, почему было принято именно это решение.
В противном случае они не будут использовать его в нормальном бизнесе, пока не преодолеют психологический порог в цене.
Когда дешево, все хорошо, но где-то есть предел, начиная с которого люди не будут всем этим пользоваться, потому что боятся.
Что создает предсказуемость? Мы понимаем ограничения и все шаги между ними.
Причем желательно, чтобы они были как-то аргументированы и объяснены, чтобы было понятно, почему было принято такое решение и что его необходимо проверить.
Еще одна важная вещь, о которой часто забывают, — это поведение в нестандартных ситуациях.
Всякие граничные условия и все такое.
Это одна из проблем, с которой вы, скорее всего, столкнетесь, как только возьметесь за реальный проект. Первые же входные данные будут кривыми, что-то обязательно будет не так, что-то сломается.
Поэтому очень важно обеспечить предсказуемость.
Это единственный способ повысить доверие.
Чтобы это было более-менее похоже на правду, приведу один случай, как обеспечить предсказуемость - из черного ящика нужно сделать хотя бы серый ящик, чтобы было понятно плюс-минус, что происходит внутри .
Давайте возьмем кредитный скоринг в качестве примера.
Таких задач много, но возьмем для примера эту, так как у нас большой опыт в этой области, я знаю, как это делается.
Как развивалась эта система в России? Я думаю, что в мире примерно то же самое, но что мы увидели?
Когда у банков возникали вопросы, связанные с кредитованием, первое, что они делали, — применяли строгие правила: сел эксперт и сказал, что это надо выдавать, а это выдавать нельзя.
Обычно доверие к этим правилам высокое, ведь нет ничего проще, чем убедить себя в том, что вы приняли правильное решение.
Существует большое доверие.
Когда все это отработано, люди прошли этот этап, дальше идут типовые модели.
Чаще всего их готовит бюро кредитных историй, и такие обобщенные модели строятся на общем пуле, который собирается по всей стране.
Почему здесь возникает доверие? По большому счету это доверие к власти.
По сути, люди не понимают, как была построена модель, но думают, что ее построили умные люди.
Обоснование следующее: если авторитетный человек сказал, что все хорошо, то я тоже предположу, что этому можно поверить.
Следующим шагом стало то, что люди начали строить свои собственные индивидуальные модели.
Сначала они были небольшими, но затем их становилось все больше и больше.
Здесь доверие было обеспечено за счет того, что обычно при построении модели идет активное общение с клиентом, объясняющее, почему и как было сделано именно так.
Фактически клиент проходит все этапы построения модели вместе с вами.
Последнее, к чему все движется, — это промышленное моделирование.
Это ситуация, в которой мы вынуждены строить десятки, тысячи моделей, и вы уже не можете корпеть над каждой моделью и объяснять, почему это было сделано так или иначе.
Поэтому важно доверять, но не конкретной модели, а процессу.
Есть определенное количество шагов — если следовать им, то можно узнать, что на выходе будет что-то более-менее похожее на истину.
Как это можно доказать? Вот наш метод доказательства.
Мы называем это паспортом скоринговой модели.
К нему должен быть подготовлен здоровый документ и какой-то контрольный список того, что должно быть в этом документе, чтобы можно было убедить людей.
Паспорт скоринговой модели — это способ доказать ее адекватность, работоспособность и повысить доверие к системе.
В чем он состоит? Во-первых, необходимо указать сферу применения.
Многие люди обычно упускают это из виду.
Они построили какую-то модель, и не указывают, какие ограничения, для каких полов, возрастов, регионов, на какие суммы это делается.
Каждый из перечисленных пунктов очень важен, ведь все, о чем вы умолчите, сыграет против вас.
Кроме того, это помогает клиенту понять, куда применить данное дело.
Чем больше ограничений вы опишете, тем лучше.
Вы оградили свой сад и не должны выходить за его пределы.
По крайней мере, к вам будет меньше претензий, если возьмут модель и начнут использовать ее на своем и не том месте.
После того, как мы определили все, что связано с доменом, следующим большим блоком будет подготовка данных.
Это один из самых долгих и тоскливых.
Он разделен на этапы, которые необходимо тщательно описать в этом документе.
Первый – это первичный аудит. Когда поступают какие-то данные, сначала нужно понять, есть ли в них хоть что-то похожее на правду? Проверяются стандартные статистические вещи: количество пропусков, аномалий, выбросов, дублей и т. д. Если мы что-то делаем с этими данными, говорим, что они подходят или не подходят, то нам нужно объяснить, почему они не подходят. Речь идет о проверке статистических гипотез.
Второй блок — проверка бизнес-гипотез при наличии данных, которые выглядят недостоверными.
Например, номер телефона 12345678. Такой номер телефона может существовать, но скорее всего это какая-то подделка.
Или напишите по адресу [email protected]. Тоже похоже на правду, но маловероятно.
Крайне важно убедиться, что данные надежны и что с точки зрения бизнеса им можно доверять.
Второй блок касается оценки качества данных при обнаружении противоречивых данных.
Если вы встретите их, обязательно опишите их.
Непоследовательные данные — это данные, которые по отдельности кажутся нормальными, но не сочетаются друг с другом.
Например, у человека есть телефон из одного региона, но он живет в другом регионе.
В принципе, так оно и есть, но возникают некоторые подозрения.
Этот вопрос необходимо описать.
Следующий блок касается подготовки данных — вам нужно объяснить, почему исключен тот или иной атрибут, и так по каждому атрибуту, так как тогда у вас возникнут вопросы.
Понятно, что объяснения просты.
Во-первых, плохая статистика.
В документе необходимо написать, что 50% пропусков не подходят. Или какая-то дисперсия.
Не менее важная вещь, которую люди часто упускают, называется «данные из будущего».
Я приведу пример, чтобы было понятно.
Когда дело доходит до подсчета очков, есть два варианта подсчета очков.
Один прикладной, второй поведенческий.
Заявление — это когда человек только пришел к нам, мы ничего о нем не знаем и пытаемся сделать о нем какое-то заключение на основании его анкеты и внешней информации.
А поведенческий – это когда он уже взял у нас кредит и обслуживается, но через какое-то время мы смотрим, как он платит, и оцениваем, нормально это или нет. Для оценки приложений часто берутся поведенческие данные.
Получается, что он пришел к нам, мы не знаем его поведения и не можем использовать данные из будущего для оценки вероятности риска.
Если они присутствуют в системе и мы строим модель приложения, то надо исключить данные из будущего.
Другое дело – несоответствие бизнес-требованиям.
Мы говорим, что не используем эти данные, потому что структура их сбора неясна, мы не можем быть уверены, что они собираются нормально.
Есть претензии бизнеса – причины, по которым этим данным нельзя доверять.
Необходимо их описать.
Следующая важная вещь — это умение справляться с редкими ситуациями.
Их обязательно нужно выделить и рассказать, что с ними делать.
Например, вы можете исключить записи, содержащие поле, сильно отличающееся от всех остальных.
Или предположите, что это на самом деле пропуск, и относитесь к ним так, как если бы это были пропуски.
Или придумать и использовать какое-то правило, согласно которому это может происходить.
Это нормально, но самое главное, чтобы люди понимали, почему было принято такое решение.
Если мы исключили, то почему? Если его заменили или обработали, то почему и что мы с ним сделали? 
Следующее — генерация атрибутов.
Если у нас есть входные данные, чаще всего из них делаются производные данные.
Например, по адресу можно узнать регион и место проживания.
Многое можно узнать по телефону, по дате.
Вам нужно сгенерировать много подобных данных.
Факторы также часто генерируются на основе поведенческих показателей.
Это когда мы берем, например, не только структуру, не только сами выплаты, а сколько в среднем заплатил человек, какие были задержки, каково в среднем соотношение расходов к доходам и т.д. Их много, и нам нужно описать, откуда все эти атрибуты возникли.
Нам также необходимо объяснить правило, по которому создаются перекрестные характеристики, когда мы что-то умножаем на что-то.
Вместо одного поля для пола и другого для возраста мы получаем смесь этих вещей.
Вперед, продолжать.
Мы еще даже не дошли до моделирования.
Работа с необходимыми атрибутами.
Еще нужно понимать, что с ними делать, ведь они могут быть связаны с бизнесом, могут быть требования к документообороту, требования законодательства.
Вы должны это принять во внимание и сказать, что именно используется и как это может попасть в систему.
Значимость с точки зрения рисков данных.
Вы можете подумать, что по статистике это все ерунда, что нет никакой корреляции и до свидания.
Но эксперты по рискам могут счесть этот факт существенным и его обязательно следует учитывать.
Дайте тем, кто рискует, понять, что вы не упустили из виду важный фактор.
Следующий этап этапа подготовки данных — идентификация событий, вещь сложная и нетривиальная.
Не совсем понятно, что такое значение по умолчанию.
Когда человек платит один раз, платит в следующем месяце, а потом не платит — это дефолт или не дефолт? И таких шуток очень много.
Идентификация событий очень важна, потому что мы фактически их предсказываем.
Если мы не объяснили, как мы их предсказываем, то ничего хорошего мы не сделаем.
У нас был реальный кейс: мы прогнозировали отток клиентов, там строили одну модель, мы считали оттоком одно, а клиент — другое.
Клиент придумал свое правило расчета оттока.
Они, конечно, не совпали, нам сказали — вы дураки, вы все сделали не так.
Это должно быть согласовано.
Его можно установить как вручную, так и специалистами – не имеет значения.
Есть разные методы, есть разные способы определения.
Но важно, чтобы они были зафиксированы.
Мы подошли к подготовке образца, на котором будем строить модель.
Когда это подготовлено, нужно также собрать всю статистику и описать, как формируются наборы обучающих тестов, какая статистика по различным атрибутам.
Наконец мы переходим к моделированию.
Он состоит из нескольких вещей.
Во-первых, это подбор фактов.
Здесь все более-менее понятно, это соответствует тому, что используется в data science, любом корреляционном анализе.
Понятно, что в скоринге происходит оценка значимости поля, предсказательной силы, известных вещей.
Все рассчитывается по определенным формулам.
Когда мы строим, мы должны говорить, что этот фактор имеет такое-то значение, рисуются графики, соотношение такое-то.
Нам нужно, чтобы люди понимали, почему мы удалили тот или иной атрибут. 
Следующий шаг – построение самой модели.
Конечно, начинать нужно с простой и понятной модели, принятой в этой отрасли.
Если мы говорим о банках, нам обязательно нужно начать с логистической регрессии и ни в коем случае не пропускать ее.
Почему? Есть три причины.
Во-первых, эта вещь общепринята и знакома любителям риска, поэтому изначально к ней как к алгоритму есть доверие.
Не факт, что она идеальна, но ей доверяют и это круто.
Вторая причина заключается в том, что логистическую регрессию легко интерпретировать.
Сначала получаются коэффициенты логистической регрессии, затем они преобразуются в скоринговые баллы, и это тоже понятно.
Чем выше балл, тем выше риск этого события.
Прохладный.
Немаловажно и то, что именно эта модель должна быть основой для сравнения.
Не нужно браться за все навороченные вещи: если вы используете навороченный алгоритм, он должен давать какое-то преимущество.
Почему мы использовали простой алгоритм, а не сложный? Если есть существенная разница, то есть повод заняться этим делом.
Если существенной разницы нет, непонятно, зачем придумывать головную боль в виде всяких алгоритмов.
Еще одна важная вещь, на которой построена модель, — это определение порогового балла.
Это связано с экономикой.
Берутся исторические данные, на основе которых мы разбираем точки отсечения и смотрим, что получим в итоге.
Это тоже интересная тема, поскольку пороговый балл следует выбирать в зависимости от бизнес-задачи.
Например, мы хотим повысить рентабельность — тогда будет одна точка отсечения.
Или мы хотим увеличить рынок, тут другой момент. Это необходимо объяснить.
Чем ниже порог отсечения, тем больше людей не будут погашать кредит. И мы должны понимать, что делаем это осознанно.
Конечно, когда мы все построили, мы можем использовать стандартные методы оценки качества, индекс Джини, всякие методы.
Должно быть включено все, что поможет вам доказать правильность модели.
Все тесты, которые вы можете пройти.
Это очень важно.
Чем больше тестов, тем лучше.
Мониторинг.
Если мы построили модель, она все равно через какое-то время умрет — у любой модели есть срок жизни.
Но обязательно нужно включить в систему механизмы, которые подскажут, когда ее необходимо заменить.
Если этого не сделать, люди будут использовать его неизвестно сколько лет, потом будут ругаться, что все дураки и модель не работает должным образом.
У нас был случай — мы построили модель, пользовались ею три года, а потом возникли претензии, что она всем понравилась.
Это основано на данных пятилетней давности.
На самом деле, это, наверное, наша проблема.
Нам пришлось создать какой-то механизм оповещения с помощью индикаторов, заставить саму систему кричать, что ее нужно менять.
Если это не так, то как только начнется плохое поведение, доверие к системе снизится.
Тебя снова будут ругать, ты будешь во всем виноват. После всех перечисленных движений последнее – финальная проверка.
Здесь сказано, что модель должна соответствовать экономическому смыслу.
Что это значит? Мы математики, зачем нам экономический смысл, нам нужно, чтобы АУК была большой, Джини, вот и все.
Но у рисковых людей, которые занимаются этим бизнесом, нет в голове готовой формулы или правила, иначе во всем этом не было бы необходимости.
Мы бы просто закодировали это, ввели куда-нибудь точки и не беспокоились об этом.
Но дело в том, что у них в голове туча предположений.
Считается, что в этом диапазоне плюс-минус километр, наверное, да.
Если он уедет за границу, это вызовет подозрения.
Необходимо, чтобы эта вещь не вызывала хотя бы явного отторжения.
Этого вполне достаточно для повышения доверия.
Нам нужно превратить модель из черного ящика в ящик, который можно хоть как-то интерпретировать.
Сначала укажем область применения и любые ограничения, которые накладываются на данную систему.
Во-вторых, обязательно включите все преобразования.
Это очень часто упускают из виду.
Люди думают, что мы подготовили данные и предоставили образцы в качестве входных данных.
Никто не говорит, как был подготовлен этот образец.
Возможно, это связано с тем, что специалисты по data science взяли какую-то выборку из Kaggle, закинули ее в какую-то модель, а потом соревнуются, у кого больше AUC, хотя никто не говорит, как были подготовлены данные.
Подготовка данных — самое сложное; обязательно будут какие-то проблемы.
Если будет неправильная конвертация, то всё остальное вообще не поможет. Вопрос в том, что они должны быть предсказуемыми.
Люди должны понять, что именно таким образом мы осуществили трансформацию.
Понятно, что нужно говорить обо всех пограничных ситуациях.
Чем больше соломы вы набросите, тем лучше.
Если ты упадешь, ты узнаешь, где.
Необходимо объяснить все факторы и аргументировать данный случай.
И вам нужно объяснить модель, если это возможно.
К сожалению, это не всегда возможно, но чем больше аргументов, которые будут более-менее правильно интерпретированы, вы сможете привести, тем лучше.
Обязательно использовать все варианты тестирования, которые есть поблизости.
Будут добавлены различные индикаторы, связанные с оценкой качества модели и мониторингом самой ситуации.
Финал должен стать подтверждением того, что мы принимаем это дело как правило.
Нужно понимать, что доверие к модели просто так не возникает. Это специалисты по обработке данных, которые приходят и хвалят крутой алгоритм.
Но бизнесу все равно, какие алгоритмы используются.
Доверие необходимо культивировать.
Надо начинать с понятных вещей и постепенно, по мере привыкания людей, давать им следующее.
Если вы сделаете слишком большой скачок, скорее всего, что-то пойдет не так.
Скорее всего, найдутся недовольные, и на вас повалятся все собаки.
Немного анекдота.
Люди думали, что машинное обучение — это круто, теперь давайте подаём данные, и система начнёт ратовать за всё хорошее, яркое и красивое.
Пару лет назад была такая ситуация: Microsoft выпустила бота на основе машинного обучения.
Видимо никаких ограничений не было, все было отлично.
Она начала учиться на твитах, разговаривать с людьми, как будто она говорила обо всем хорошем.
Менее чем за сутки эта нейросеть превратилась в нациста и женоненавистника, готового убить всех.
В течение одного дня.
Даже в этом случае легко наступить на некоторые ошибки.
Если мы хотим сделать анализ данных, расширенную аналитику и машинное обучение повседневной необходимостью, тогда я призываю вас взглянуть на все с точки зрения бизнеса, возможностей и готовности использовать доверие к системе в производстве.
Повышайте доверие всеми возможными способами.
Если вы не можете найти способ оправдать и повысить доверие, я не думаю, что стоит делать эту модель.
Сначала нам нужно придумать, как его защитить.
Это чем-то напоминает разработку через тестирование: сначала мы придумываем тесты, а потом думаем, как их провести.
Здесь то же самое.
Сначала мы думаем о том, как будем спорить, затем предоставляем данные в поддержку этих аргументов.
Я закончил, спасибо.
Теги: #Машинное обучение #Управление проектами #наука о данных #нейронные сети #работа с заказчиком
-
Чего Вы Ожидаете От Google Chrome Os?
19 Oct, 24 -
Телевизионный «Кинематографический» Формат
19 Oct, 24 -
Многопользовательский Wordpress
19 Oct, 24 -
Они Не Покупают Музыку, Но Скачивают Ее
19 Oct, 24
