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

Тем не менее, компании все чаще встраивают статистические функции или функции искусственного интеллекта / машинного обучения непосредственно в свои продукты. Это может сделать наши приложения менее детерминированными - мы можем не знать точно, как приложения ведут себя с течением времени или в конкретных ситуациях - и труднее объяснить. Это также требует от менеджеров по продуктам более непосредственного взаимодействия с аналитиками данных по вопросам моделей, предсказуемости, того, как продукты работают в производстве, как / почему пользователи взаимодействуют с нашими продуктами и как наши конечные пользователи измеряют успех. (Подсказка: большинство пользователей не понимают F1-баллы и не заботятся о них; они просто хотят получить правильный ответ.)

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

1. Обеспечьте гораздо более глубокий контекст, чем традиционные программные проекты, особенно варианты использования и бизнес-цели.

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

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

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

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

  • Расскажите команде DS о подробных сценариях использования. Кто такие игроки и как мы их называем? Что происходит, когда? Куда можно внедрить идеи на основе моделей или машинное обучение (ML)? Ключевые ограничения или нормативные обязательства?
  • Изучите показатели успеха, бизнес-цели и экономику. Предназначено ли это улучшение для увеличения доходов от лицензий от новых клиентов, уменьшения оттока клиентов или повышения удовлетворенности клиентов? Почему платящие клиенты будут заботиться о них или какую конкретную боль мы облегчаем? Как мы измерим их и сколько улучшений будет достаточно? Будьте готовы объяснить качественные вещи командам DS в количественном выражении.
  • Поделитесь своими активами проверки / исследования пользователей: записями интервью, видео пользователей, которые борются с вашим интерфейсом, сравнения продуктов, прогнозов доходов, продаж, всего, что эмоционально соединит команду DS с вашими конечными пользователями.

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

Легко предположить хорошие результаты, не проведя предварительного расследования DS. Конечно этот набор данных позволит спрогнозировать удовлетворенность клиентов; что процесс машинного обучения выявит неэффективность производства; какой-нибудь инструмент искусственного интеллекта поможет вылечить рак! Но реальный мир мешает нам: грязные данные, модели с плохой оценкой прогнозов, совершенно очевидные результаты, существующие человеческие процессы, которые уже работают чертовски хорошо. Мы можем позволить нашему энтузиазму и настойчивости опередить реальные результаты. Итак, планируйте:

  • Сформулируйте гипотезу на языке науки о данных: «Я думаю, что набор данных X поможет предсказать Y». Это дает всем общую отправную точку - что-то конкретное для критики. И вы преодолеете культурные разрывы, разговаривая как специалист по данным.
  • Пусть ваша команда DS поэкспериментирует с несколькими наборами данных. Что (если есть) выглядит интересным и предсказуемым? Стоит ли объединить несколько наборов данных?
  • Не назначайте окончательные сроки поставки, пока мы не узнаем, что у нас есть что-то работоспособное.
  • Попросите свою команду DS рассказать вам их 4 С: охват, полнота, правильность, актуальность. [Не имеет отношения к 4C алмазной отрасли.]

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

3. Выбор / доступ к наборам данных имеет решающее значение.

Проекты в области науки о данных успешны или терпят неудачу на основе реальных наборов данных и моделей, а не намерений или интуиции. Некоторые наборы данных лучше других: более доступны, полны, чище. Кроме того, данные могут быть скрыты за организационными или нормативными стенами: у вас могут возникнуть проблемы с использованием истории потребительской электронной коммерции вашей компании без проверки конфиденциальности с учетом GDPR. Или генеральному директору продаж в США не нравится управляющий директор по продажам в ЕС, поэтому он отказывается делиться. Или получение разрешений на доступ от ИТ занимает 6 месяцев. Так что может быть полезно:

  • Изучите права собственности и разрешения для внутренних наборов данных в начале проекта. С чем столкнулись подобные команды в последнее время
  • Для внешних источников данных проверьте допустимое использование и коммерческие условия. Разрешено ли нам встраивать их в наши продукты или получать прибыль? Какие-либо обязательные уведомления в документации или раскрытия юридической информации?
  • Будьте особенно осторожны с идентифицируемыми данными потребителей и разрешениями конечных пользователей.

4. Опишите, насколько точным должно быть это приложение, и предвидите, как будут поступать «неправильные» ответы.

Некоторым проектам DS нужно только немного больше информации; у других есть огромные недостатки, когда мы ошибаемся. Итак, уровень точности - важный аспект в самом начале любого проекта в области науки о данных. Мы можем потратить год и 2 миллиона долларов на тренировочные данные, когда достаточно точности несколько лучше, чем подбрасывание монеты… или подвергнуть риску жизни приложение для медицинских прогнозов с большим количеством ложноотрицательных результатов.

Например, мы могли бы оптимизировать маршруты для городских грузовиков, доставляющих посылки. Сортировка посылок по нужным грузовикам и упорядочение остановок доставки могут сэкономить много времени, топлива и денег, даже если это далеко не идеально. Точность 70% может сократить наши маршруты на 20 минут в день и снизить эксплуатационные расходы на миллион долларов. Обсуждая это с нашей командой DS, мы избегаем позолоченных решений, которым требуется дополнительный год проверки - достаточно хорошо, достаточно хорошо.

Машинный анализ отчетов о качестве воды должен быть гораздо более точным: неспособность идентифицировать свинец в питьевой воде (ложные отрицательные результаты) имеет серьезные последствия, в то время как неправильное включение сигналов тревоги качества воды в безопасных зонах (ложные срабатывания) ) создает ненужное беспокойство. У нас должны быть некоторые энергичные аргументы в отношении точности 98% против 99% против 99,95% и того, как наши пользователи будут применять наши прогнозы на практике.

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

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

А анализ (здесь, здесь) предлагает обратить внимание на различные предубеждения или ошибки в нашем ипотечном приложении:

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

Нам понадобится план рассмотрения жалоб / эскалаций людьми; способ объяснить результаты людям-заемщикам; а также график пересмотра и периодического восстановления наших моделей. Скайнет не может отвечать за наши кредитные решения.

5. «Готово» означает задействование, а не только понимание

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

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

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

  • Где в производстве будут жить модели и процессы искусственного интеллекта? Как мы включаем / выключаем эти процессы, защищаем их, управляем емкостью, исправляем / обновляем базовые инструменты?
  • Как сигналы (решения) передаются от модели к основному приложению: API, обмен файлами, ночные аналитические прогоны?
  • Какое время отклика требуется от моделей данных для других производственных модулей?
  • Наши автоматизированные наборы тестов гарантируют, что традиционные изменения кода не нарушат работу системы. Как мы будем отслеживать неожиданное поведение DS / AI?
  • У кого есть полномочия и права доступа к системе для отключения некорректных моделей? Можем ли мы провести несколько тренировок DevOps, чтобы убедиться, что это работает?

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

Звуковой байт

Приложения, управляемые данными, сложнее детерминированных программных продуктов. А работа с специалистами по обработке данных связана с некоторыми уникальными проблемами. Мы должны подойти к ним вдумчиво, распознать закономерности и уважать особые таланты каждой группы.

Первоначально опубликовано на https://www.mironov.com 16 сентября 2019 г.