Новые технологии или трудности с внедрением "железного коня"
По работе возникают забавные вопросы, связанные с новыми технологиями. Местами напоминает "Записки юного врача" и прочие заметки профессионалов. Думал на эту тему писать короткие рассказики, но мотивации недостаточно, да и я на Булгакова не тяну, так что будет "в сухую", без художественности.
Три вопроса технологий Machine Learning:
1. Не возникает новых знаний. То есть если мы строим предсказательную модель и она получается хорошей, заказчик получает способность предсказывать. Например отток. Или ДТП. При этом модель не дает никакого ответа на тему того, каковы причинно-следственные связи. Более ли менее тривиально выявить сильные факторы, но т.к. корреляция это не причинно-следственная связь, знаний все равно получить не удается. Наличие хорошей модели и отсутствие ее понимания часто заказчика напрягает. По результатам общения с другими поставщиками решений ясно, что это общая проблема, не имеющая хорошего решения. Коллеги имитируют знания, наукообразно объясняя модель и предъявляя сильные факторы. Мы стараемся пока такого не делать, но может быть придется. В качестве сколько-то здорового выхода - включать в проект еще один этап, по исследованию модели и построению теории моделируемого явления. В точности история с паровым автомобилем, спереди которого должен идти сигнальщик с флажком.
2. A/B тестирование как необходимый элемент. Предположим мы сделали хорошую модель, которая что-то полезное рекомендует. Например она рекомендует лечение для пациента. Далее мы должны ее тестировать. Причем если первый раз это еще понятно как делать - мы внедряем улучшение и ожидаем, что станет лучше, то далее надо тестировать ее рутинным образом. Например модель способствует точной диагностике, давая измеримый результат, ну например +5% к выживаемости пациентов. Измерили, показали, доказали, внедрили. Теперь надо мерять ее качество, не испортилось ли оно. И пробовать вносить правки. Делаем A/B тест - то есть некоторая часть выборки (пациентов) обслуживается без модели и прогнозируемо теряет те самые 5% к выживаемости. Вроде как так нельзя. И без этого нельзя. Предположим медицина это самый острый случай, но даже идея прогнозируемо уронить продажи ради измерения качества модели не вызывает восторга.
3. Восприятие прогноза. Заказчики тяготеют не к прогнозам, а к предвидениям. Предсказываем, например, churn. Предположим у заказчика 100 000 клиентов, из них в ближайшее время уйдет ("сгорит") 1 000. И вот заказчик предпринимает кампанию поддержания лояльности. Поскольку выделить тех, кто уйдет, заказчик не может, приходится вести ее на всю клиентскую базу. Тут приходим мы и делаем модель, которая 90% (900 человек) "горящих" собирает в группу из 10 000 "подозрительных". Аналитик рассказывает заказчику, что мы сделали прекрасную модель, у которой "вероятность ошибки 91%". С точки зрения заказчика "91% ошибок" это вообще не прогноз. Когда объясняешь, что в результате использования модели он сможет сконцентрировать свои усилия по повышению лояльности вместо всей клиентской базы в 100 000 на группе в 10 раз меньшей, восприятие меняется. В целом очень мешает отсутствие опыта работы с предсказаниями и присутствие опыта работы с предвидениями :)
Три вопроса технологий Machine Learning:
1. Не возникает новых знаний. То есть если мы строим предсказательную модель и она получается хорошей, заказчик получает способность предсказывать. Например отток. Или ДТП. При этом модель не дает никакого ответа на тему того, каковы причинно-следственные связи. Более ли менее тривиально выявить сильные факторы, но т.к. корреляция это не причинно-следственная связь, знаний все равно получить не удается. Наличие хорошей модели и отсутствие ее понимания часто заказчика напрягает. По результатам общения с другими поставщиками решений ясно, что это общая проблема, не имеющая хорошего решения. Коллеги имитируют знания, наукообразно объясняя модель и предъявляя сильные факторы. Мы стараемся пока такого не делать, но может быть придется. В качестве сколько-то здорового выхода - включать в проект еще один этап, по исследованию модели и построению теории моделируемого явления. В точности история с паровым автомобилем, спереди которого должен идти сигнальщик с флажком.
2. A/B тестирование как необходимый элемент. Предположим мы сделали хорошую модель, которая что-то полезное рекомендует. Например она рекомендует лечение для пациента. Далее мы должны ее тестировать. Причем если первый раз это еще понятно как делать - мы внедряем улучшение и ожидаем, что станет лучше, то далее надо тестировать ее рутинным образом. Например модель способствует точной диагностике, давая измеримый результат, ну например +5% к выживаемости пациентов. Измерили, показали, доказали, внедрили. Теперь надо мерять ее качество, не испортилось ли оно. И пробовать вносить правки. Делаем A/B тест - то есть некоторая часть выборки (пациентов) обслуживается без модели и прогнозируемо теряет те самые 5% к выживаемости. Вроде как так нельзя. И без этого нельзя. Предположим медицина это самый острый случай, но даже идея прогнозируемо уронить продажи ради измерения качества модели не вызывает восторга.
3. Восприятие прогноза. Заказчики тяготеют не к прогнозам, а к предвидениям. Предсказываем, например, churn. Предположим у заказчика 100 000 клиентов, из них в ближайшее время уйдет ("сгорит") 1 000. И вот заказчик предпринимает кампанию поддержания лояльности. Поскольку выделить тех, кто уйдет, заказчик не может, приходится вести ее на всю клиентскую базу. Тут приходим мы и делаем модель, которая 90% (900 человек) "горящих" собирает в группу из 10 000 "подозрительных". Аналитик рассказывает заказчику, что мы сделали прекрасную модель, у которой "вероятность ошибки 91%". С точки зрения заказчика "91% ошибок" это вообще не прогноз. Когда объясняешь, что в результате использования модели он сможет сконцентрировать свои усилия по повышению лояльности вместо всей клиентской базы в 100 000 на группе в 10 раз меньшей, восприятие меняется. В целом очень мешает отсутствие опыта работы с предсказаниями и присутствие опыта работы с предвидениями :)