Найдите решение, прежде чем приступать к машинному обучению
Наука побуждает нас сначала попытаться объяснить новые явления, используя наши существующие знания. Если это не работает, необходимо создавать новые теории. Этот процесс оттачивается на уроках естествознания. Например, ученики редко получают на экзамене по физике задачи, точно такие же, как домашние задания. Ожидается, что студенты смогут перевести новые экзаменационные задачи в свое существующее понимание физики, чтобы решить их.
Точно так же в науке о данных наш первый инстинкт обычно состоит в том, чтобы преобразовать предложенную проблему в ранее известное решение. Это поощряется в интервью. Нам представлен кейс
Определите клиентов, которые могут уйти
и мы думаем
Хорошо, это означает классификацию: did_churn = 1, did_not_churn = 0. Я знаю, как решить эту проблему с помощью логистической регрессии, случайных лесов и т. Д.
Хотя такой подход может помочь нам получить работу, мы не должны проявлять такую бесцеремонность, когда на самом деле используем машинное обучение для создания бизнес-решений. Мы должны использовать подход сверху вниз и потратить много времени на выяснение:
- Какова реальная конечная цель?
- Какой результат мне нужен для достижения этой цели?
- Какие типы моделей дают желаемый результат?
- Какие типы входных данных помогут мне добиться желаемого результата?
- Эти данные действительны?
Давайте рассмотрим выдуманный пример того, как мы будем решать каждый из этих пунктов.
1. Какова фактическая конечная цель?
Представьте, что мы работаем в страховой компании, и кто-то говорит нам, что хотел бы знать, кто попадет в аварию в следующем месяце. Нашим первым инстинктом может быть сказать:
Эй, это как проблема с оттоком клиентов! Я создам классификатор, и все готово.
Не так быстро! Давайте спросим, почему заинтересованная сторона хочет это знать. Причин могло быть много:
- Они хотят знать, какие клиенты чаще всего попадают в аварии.
- Они хотят как-то вмешаться, чтобы предотвратить несчастные случаи.
- Они хотят поднять ставки для этих клиентов.
- Они хотят спрогнозировать ожидаемые претензии в течение следующих 6 месяцев.
- И т.д…
Каждый из этих сценариев может потребовать совершенно разных результатов, моделей и входов. Предположим, они хотят поднять ставки для этих клиентов. Это, вероятно, поднимает вопрос о том, насколько повысить ставки, как это соотносится с вероятностью несчастного случая, и множество других вопросов. Для простоты предположим, что этим занимается другой отдел, и мы должны идентифицировать только этих клиентов.
2. Какие результаты мне нужны для достижения этой цели?
Отчасти здесь вступает в игру идея информационного «продукта». Мы знаем, что заинтересованные стороны, скорее всего, определят клиентов, для которых можно повысить ставки. Хотели бы они, чтобы мы предоставили им список клиентов, которые, по нашему мнению, попадут в аварию в следующем месяце? Хотели бы они, чтобы для каждого клиента рассчитывалась «оценка несчастного случая»? Хотим ли мы позволить нетехническим людям принимать решения по техническим вопросам? Должна ли эта оценка заполнять базу данных или возвращаться через API? Должна ли оценка быть от 0 до 1? И так далее, и так далее.
Допустим, заинтересованные стороны хотят получать список клиентов, которые могут попасть в аварию каждый месяц.
3. Какие типы моделей дают желаемый результат?
Нам нужно создать список клиентов, которые, по нашему мнению, попадут в аварию. Машинное обучение часто можно разделить на классификацию, регрессию, рекомендацию и обучение с подкреплением. Эти группы не исключают друг друга (например, рекомендация может быть решена как классификация).
Наш сценарий выглядит как проблема классификации: мы должны предсказать, попадет ли клиент в аварию. Важно отметить, что нам не нужна вероятность, поэтому мы можем использовать различные функции и модели потерь, не думая о том, как преобразовать двоичный результат в вероятность.
Мы будем упрощать это и начнем с логистической регрессии.
4. Какие типы входных данных помогут мне добиться желаемого результата?
Почти в любой статье, посвященной машинному обучению, будет утверждаться, что разработка функций составляет большую часть работы, и я всегда находил, что это правда. Обдумывая входные данные для нашей модели, мы можем использовать наши знания предметной области, чтобы начать работу.
В случае аварий на ум могут прийти следующие данные:
- Количество аварий клиента
- Возраст клиента
- Автомобиль клиента
После того, как мы определили пару характеристик, мы должны выяснить, есть ли у нас данные. Наконец, мы можем попытаться построить фактические входные данные для модели с этими данными, но здесь все становится сложно.
5. Верны ли эти данные?
Даже если у нас есть данные и мы можем преобразовать их в числовую форму для ввода в модель машинного обучения, есть много способов сделать это неправильно. Часто ошибка проявляется в утечке будущего в прошлое.
Например, у нас есть красивая таблица с названием future_customer_accidents
| customer_id | date_month | had_accident_next_month | ------------------------------------------------------ | 1000001 | 08/2016 | False | | 1000001 | 09/2016 | True | | 1000001 | 10/2016 | True | | 1000002 | 07/2016 | False |
и мы хотим предсказать has_accident_next_month для каждого кортежа customer_id и date_month. Представьте, что у нас есть отдельная таблица с именем accidents:
| customer_id | date | accident_type | ----------------------------------------------- | 1000001 | 2016-10-12 | fender_bender | | 1000001 | 2016-11-24 | fender_bender | | 1000002 | 2016-09-03 | totaled |
Если мы хотим подсчитать количество несчастных случаев с клиентом, мы можем просто написать
SELECT fca.customer_id, COUNT(*) AS number_of_accidents FROM future_customer_accidents fca LEFT JOIN accidents a ON a.customer_id = fca.customer_id GROUP BY 1
Готово, да? Не совсем. Сгруппировав нашу таблицу происшествий и игнорируя даты, мы подсчитали будущие происшествия, возвращаясь к прошлым датам. Например, мы видим, что customer_id 1000001 попал в аварию и в октябре, и в ноябре. Мы посчитаем их количество несчастных случаев как 2 при прогнозировании в сентябре, когда мы не будем знать в то время, были ли они в какой-либо аварии.
Хотя это был конкретный пример, мы всегда должны учитывать достоверность наших входных данных, особенно при работе с временными данными. Помимо временных данных, нам также следует подумать о том, является ли ввод этичным. У нас может быть информация о расе, доходе, сексуальной ориентации клиента и т. Д.… Хотя использование этих данных в качестве характеристики модели может повысить предсказательную силу моделей, этично ли повышать страховые ставки для кого-то? из-за их расы? Нет. Часто предубеждения, которые могут возникнуть в модели машинного обучения, более тонкие, а иногда они явно заложены с самого начала. По сути, это активная область исследований.
Движение вперед
В следующий раз, когда вы получите запрос на решение для машинного обучения, попробуйте продумать 5 шагов, описанных выше. На этот раз вложения вперед помогут избежать головной боли в будущем. А если вам нравится анализировать объемы проектов и создавать продукты для машинного обучения, загляните на нашу страницу Карьера и приходите, чтобы помочь нам строить!
