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

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

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

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

Не все хорошие модели относятся к моделям машинного обучения

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

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

Другой ключевой момент заключается в том, что бэктестинг, основной продукт строгой статистики, применяется к моделям, основанным на правилах, а не только к изученным моделям. Бэктестинг означает использование модели для прогнозирования прошлых случаев с известными результатами и сравнение прогнозов с известными результатами. Это можно сделать с помощью моделей, основанных на правилах, и все те же показатели точности, которые используются для изученных моделей (AUC, F1, r2, MSE…), можно вычислить для моделей, основанных на правилах. Не только можно провести бэктестинг для моделей, основанных на правилах, но его следует сделать для предотвращения переобучения.

Модели, основанные на правилах, имеют преимущества перед машинным обучением

  1. Модели на основе правил требуют знания предметной области. Чтобы решить, какими должны быть правила, продуктовая группа должна кое-что знать о проблемном пространстве. Это полезное ограничение. Это способствует более глубокому пониманию варианта использования модели и пользователей, а также побуждает команду разработчиков к постоянному совершенствованию своего понимания. Есть несколько проблем, при которых наивное применение изученной модели к отраслевому набору данных существенно поможет пользователям - к сожалению, такие низко висящие плоды уже были собраны в большинстве отраслей.
  2. Для моделей, основанных на правилах, обычно требуется меньше данных. Модели, основанные на правилах, не нужно обучать! Это особенно полезно для новых приложений или стартапов, где могут быть глубокие знания предметной области, но мало данных.
  3. Модели, основанные на правилах, как правило, легче отлаживать. Их легче рассуждать, чем изученные модели, потому что модели, основанные на правилах, отражают только ассоциации, которые люди закодировали в них. Причем эти ассоциации выражаются непосредственно в коде. И наоборот, в усвоенной системе ассоциации выражаются не в коде, а в коэффициентах, которые может быть трудно найти, трудно понять и нестабильно во времени. Когда производственная модель начинает плохо себя вести в 3 часа ночи, и команда разработчиков просыпается, чтобы исправить это, гораздо предпочтительнее искать неисправность, которая гарантированно существует где-то в читаемом человеком коде.

Когда вы должны использовать модель машинного обучения

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

1. Приемлемо ли вероятностное или непонятное обоснование?

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

Когда Netflix дает мне плохие, не интуитивные рекомендации, я не чувствую, что мои ценности были нарушены. Ставки низкие, и нет «общественного договора», в котором говорилось бы, что я имею право понимать мои рекомендации по фильму. Заманчиво экстраполировать, что мы должны использовать вероятностное обоснование только в ситуациях с низкими ставками. К сожалению, не все так просто. Возьмем медицину, где широко признано, что статистические (вероятностные) результаты - лучший способ принять жизненно важные решения, такие как одобрение новых лекарств. Приемлемо ли вероятностное обоснование - это вопрос ценностей, а не вопрос масштаба или серьезности.

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

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

Ценности людей различаются, поэтому всегда будут большие серые зоны, но мы должны начать процесс исследования машинного обучения с вопроса «согласуется ли вероятностное решение с нашими ценностями?»

2. Точно ли данные представляют реальный мир?

Для модели требуются данные двух типов: метки (также известные как «истина», «результаты», зависимая переменная) и характеристики (также называемые «входные данные», «независимые переменные»).

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

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

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

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

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

3. Допустим ли тихий отказ?

Вот страшная ситуация, с которой мы сталкиваемся в Opendoor, компании, где я работаю. Мы создаем новую модель оценки жилья, которая повышает точность тестирования на исторических данных и A / B-тестирования. Мы масштабируем его, а это значит, что мы начинаем приобретать дома по ценам, прогнозируемым нашей моделью, принимая на себя значительный балансовый риск. Затем модель тихо выходит из строя.

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

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

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

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

Примеры использования в реальном мире

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

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

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

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

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