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

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

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

Зачем нужен алгоритмический обзор?

Алгоритмический обзор преследует двоякую цель.

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

Кто причастен?

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

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

Когда это делать?

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

Что при этом задействовано?

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

1. Заполните контрольный список

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

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

Для элементов, которые не отмечены флажком, действия должны быть согласованы с руководителем по вопросам справедливости и определены приоритетом для выполнения у менеджера по продукту.

2. Обсуждение вопросов

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

  • C.1 Отсутствующие точки зрения. Стремились ли мы устранить слепые пятна в анализе путем взаимодействия с соответствующими заинтересованными сторонами (например, путем проверки предположений и обсуждения последствий с затронутыми сообществами и профильными экспертами)?
  • C.2 Систематическая ошибка набора данных. Изучили ли мы данные на предмет возможных источников систематической ошибки и предприняли ли шаги для смягчения или устранения этих предубеждений (например, сохранение стереотипов, предвзятость подтверждения, несбалансированные классы или пропущенные смешивающие переменные)?
  • D.1 Прокси-дискриминация. Удостоверились ли мы, что модель не полагается на переменные или заместители для переменных, которые являются несправедливо дискриминационными?
  • D.2 Справедливость по группам. Проверяли ли мы результаты модели на предмет справедливости по отношению к различным затронутым группам (например, проверяли на несопоставимые коэффициенты ошибок)?
  • D.3 Выбор метрики. Учли ли мы влияние оптимизации по нашим определенным метрикам и учли дополнительные метрики?
  • D.5 Сообщать о предвзятости. Сообщили ли мы о недостатках, ограничениях и предвзятостях модели соответствующим заинтересованным сторонам в понятной для всех форме?

3. Обзор справедливости

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

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

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

4. Завершение предметов

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

Итоги шагов

  1. Заполните контрольный список DEON https://deon.drivendata.org
  2. Честно обсудите и приведите пункты контрольного списка к взаимному соглашению о том, какие пункты следует и не следует проверять. Убедитесь, что C1, C2 и D1, D2, D3, D5 не проверяются, если они не обсуждаются с защитниками этики и справедливости и менеджером по продукту.
  3. Согласуйте и расставьте приоритеты в действиях, таких как выполнение проверки справедливости, для непроверенных элементов с опережением справедливости.
  4. Запустить обзор, например создать запрос на вытягивание Github, чтобы включить контрольный список и действия в репозиторий кода проекта.
  5. Менеджер по продукту должен расставить приоритеты и назначить задачи, связанные с действиями.
  6. Чтобы убедиться, что действие завершено, вам необходимо провести обсуждение и отказаться от руководства по вопросам справедливости, этики и менеджера по продукту.
  7. Когда действие завершено, измените контрольный список, предоставив для этого обоснование или анализ. Изменение должно быть рассмотрено и одобрено таким же образом, например: запрос на вытягивание, проводимый лидерами по вопросам этики и справедливости.

Заключительные слова

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