После долгого пути, когда инженеры и ученые усердно работали над новым инструментом или моделью, все еще может не получиться. К сожалению, примерно 3 из 4 проектов данных терпят неудачу из-за исследований и статей, подчеркивающих сотрудничество и внедрение как общие проблемы [1][2][3][4]. Конечно, для программного обеспечения в целом вовлечение пользователей и внутренняя заинтересованность являются главными критериями успеха, а такие инструменты, как исследование пользователей, Agile и совместное проектирование, решают эти давние проблемы [5][6][ 7][8][9][10][11]. Однако, особенно в AI/ML, проекты данных сталкиваются с уникальными проблемами: неопределенность модели, механическая непрозрачность, единоличное авторство и ограниченное агентство — все это создает препятствия для взаимодействия и обратной связи. Используя один из моих недавних проектов с открытым исходным кодом в качестве примера, что команды данных могут извлечь из других дисциплин и, если совместная работа так важна, какие шаги они могут предпринять при работе с другими командами?
Задача 1. Моделирование с учетом неопределенности
Работа с неопределенностью и ее обсуждение часто создают первое препятствие. Учтите, что некоторые соавторы могут не иметь глубоких знаний вероятностных систем, что затрудняет рассуждения с использованием инструментов, общих для групп по науке о данных, таких как различные распределения вероятностей или метрики.
Конечно, может помочь отход от жаргона: сравните точность 80% с когда делаются предсказания о том, что что-то мошенническое, это верно в 80% случаев [12]. Однако, что более важно, интернализация различных вероятностных распределений является сложной задачей, и информационный дизайн может способствовать развитию дистрибутивного мышления. Например, пчелиный рой сайта FiveThirtyEight в их вероятностном среднесрочном прогнозе на 2022 год побуждает читателей думать о прогнозах выборов как о наборе возможных результатов, а не об одном ответе. , демонстрируя индивидуальные возможности: 1) намекнуть пользователю, что его прогноз на самом деле является распределением, и 2) раскрыть форму этой совокупности расходящихся результатов [13][14]. Один из моих недавних проектов с открытым исходным кодом (StartupOptionsBot) отображает параметры запуска аналогичным образом [15].
Как и предвыборные прогнозы, ряд сложных событий может изменить исход опционов сотрудников стартапа, часть их вознаграждения, которая позволяет им покупать акции своей компании (отказ от ответственности, а не финансовый совет) [16]. Сотрудники могут заработать или потерять деньги, и, опять же, форма совокупности результатов для этих инвестиций часто оказывается более информативной, чем общий средний ответ. Поэтому StartupOptionsBot показывает каждое из своих испытаний методом Монте-Карло на диаграмме рассеяния, чтобы набросать общую совокупность потенциальных результатов. Короче говоря, отображение результатов отдельных симуляций подталкивает пользователей к распределенному мышлению.
Задание 2. Механическая непрозрачность
Помимо устранения неопределенности, обратите внимание, что сложный механизм машинного обучения/вероятностной модели часто становится трудно описать в краткой и понятной человеку форме. Поэтому откройте доступ к таким инструментам, как LIME, которые могут оценить важность различных атрибутов для объяснения отдельного прогноза [17]. Кроме того, эта информация может отображаться с использованием шаблонов дизайна интерфейса для контекстных объяснений, предлагая понимание без нарушения пользовательского потока [18].
В качестве демонстрации рассмотрим, как StartupOptionsBot прикрепляет прослушиватель кликов к точкам, представляющим отдельные симуляции [15]. По-прежнему оставляя незагроможденное представление об общем распределении, пользователь может получить доступ к отдельным событиям, которые приводят к результату, предоставляя интуитивное представление о том, какие сценарии приводят к каким результатам. Действительно, Президентский прогноз FiveThirtyEight делает что-то аналогичное отдельным картам выборов на уровне симуляции [14]. Короче говоря, прозрачность механики помогает укрепить доверие к модели, а объяснения прогнозов могут способствовать пониманию проблемы.
Задание 3: Единое авторство
После устранения неопределенности и непрозрачности учтите, что такие методы, как совместное проектирование/совместное проектирование, направлены на вовлечение пользователей в процесс проектирования/разработки в качестве соавторов [19]. Как это может работать для проектов данных, когда реальным системам часто требуются навыки специалиста по данным или инженера для взаимодействия с моделью или конвейером? Такие решения, как моделирование изменения климата En-ROADS, позволяют пользователям играть с параметрами модели, чтобы увидеть, как различные варианты выбора изменяют результаты потепления, а такие продукты, как Grid или Observable, позволяют сделать части модели интерактивными [20]. [21][22]. Они создают безопасную среду для продуктивного исследования, сохраняя при этом базовую механику и гарантии модели.
В качестве примера рассмотрим интерактивный дизайн пользовательского интерфейса StartupOptionsBot для создания симуляций [15]. Во-первых, обратите внимание, что он использует прогрессивное раскрытие для группировки различных элементов управления за сворачиваемыми разделами, чтобы пользователь мог упростить сложность системы, начиная с доступного обзора структуры модели, прежде чем показывать детали [23]. Во-вторых, он заимствует концепцию основного цикла игрового дизайна, используя выделенные кнопки и цвет, чтобы направлять пользователя через цикл изменения параметра модели и просмотра результата [24]. В целом, эти варианты дизайна могут создавать повторяющиеся песочницы для экспериментов, которые предлагают среду для безопасного исследования.
Задача 4. Агентство с ограниченной ответственностью
Конечно, навигация по этим сложным интерфейсам требует усилий. В то время как эти методы позволяют пользователям манипулировать параметрами модели, сложность пользовательских интерфейсов, таких как En-ROADS и StartupOptionsBot, означает, что в какой-то момент эти инструменты становятся похожими на программирование для интенсивного использования: достижение такой же сложности, как программирование на основе кода, только в графический интерфейс [15][20][25]. Однако языковой дизайн может помочь!
Например, StartupOptionsBot предоставляет небольшой специфический для предметной области язык программирования. Узко ориентированные на конкретную среду или проект, эти DSL могут оказаться проще, чем язык общего назначения (например, Python) для решения задачи и обеспечить истинное соавторство сотрудников в системе [26][27 ]. Действительно, как часто бывает при сравнении визуального программирования с программированием на основе кода, компактность представления кода в StartupOptionsBot часто оказывается более работоспособной, чем эквивалент пользовательского интерфейса для больших симуляций [15][25]. Хотя переход от пользовательского интерфейса к коду для удобства использования нелогичен, подумайте, требуют ли ваши инструменты обработки данных своего рода визуальное программирование и какие методы обеспечивают более глубокое совместное авторство/агентство.
Приглашение сотрудников из сторонних групп данных может помочь заручиться поддержкой заинтересованных сторон и включить новый опыт в моделирование, способствуя внедрению и успеху. Проекты данных представляют собой уникальные проблемы, но эти методы могут проложить путь к сотрудничеству и соавторству. Все это я хочу закончить, признав, что для этого требуются ресурсы: визуализация данных, разработка программного обеспечения и инфраструктура. Тем не менее, если наличие этих навыков снижает риск неудачи, может ли ваша группа обработки данных позволить себе их не иметь?
Нравится это и хотите больше идей на стыке дизайна и данных? "Подписывайтесь на меня"! Также см. слайды из похожего выступления.
