Фреймворк управления с открытым исходным кодом для создания ответственного ИИ

Недавно мы приняли участие в конкурсе Global Veritas Challenge, проводимом валютно-кредитным управлением Сингапура (MAS).

… Стремится ускорить разработку решений, которые проверяют решения искусственного интеллекта и анализа данных (AIDA) на соответствие принципам справедливости, этики, подотчетности и прозрачности (FEAT), чтобы укрепить доверие и способствовать более широкому внедрению решений ИИ в финансовом секторе.

В этом посте описывается наше решение проблемы: VerifyML.

Примечание 1. В этом посте термин «предвзятость» относится к понятию несправедливости / несправедливости, а не к предвзятости в статистическом смысле. Там, где это относится к последнему, будет прямо указано.

Примечание 2. Несмотря на то, что FEAT относится к 4 различным концепциям, основное внимание в этой задаче уделяется справедливости.

Задний план

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

  1. Справедливость через незнание: защищенные атрибуты (например, раса, пол, возраст и т. д.) в наборе данных исключаются из разработки модели. Идея состоит в том, что если модель не обучена по этим атрибутам, менее вероятно, будет предвзято относиться к какой-либо конкретной подгруппе атрибутов или против нее. Это ясный и простой подход, который относительно легко реализовать.
  2. Справедливость через равенство показателей. Оцените модель по сравнению с набором показателей равенства (например, различия в прогнозируемых положительных показателях / ложноотрицательных показателях / показателях ложного обнаружения в подгруппах и т. д.) - модель считается справедливой (или нет несправедливо), если его производительность попадает в заданный пользователем порог равенства метрик. Грубо говоря, это равносильно добавлению дополнительных математических ограничений для оптимизации модели.

У обоих подходов есть свои достоинства, но есть и ограничения, которые следует учитывать:

  1. Справедливость через неосведомленность не мешает модели аппроксимировать защищенные атрибуты через прокси-переменные (например, расу кого-то можно определить по стране происхождения). Прокси-серверы могут быть удалены по мере их обнаружения, но это превращает усилия по обеспечению справедливости в бесконечную игру в кошки-мышки. Даже с самыми лучшими кошками более тонкие отношения между особенностями могут остаться незамеченными! Кроме того, защищенные атрибуты иногда имеют решающее значение для более широкой бизнес-проблемы - например, в области медицины знание возраста / пола человека может быть важной информацией при назначении подходящего лечения и лекарств.
  2. Использование только метрических мер равенства недостаточно, так как оно лишено человеческого контекста. Справедливость, в конце концов, по существу оспариваемая концепция - сведение ее к математическим формулам не будет справедливо по отношению к присущей ей субъективности. Вместо того, чтобы использовать их как панацею, соответствующие меры и пороговые значения следует тщательно выбирать только после тщательного обсуждения собственных определений справедливости в организации.

Следовательно, мы стремились создать структуру, обеспечивающую целостный подход к построению моделей машинного обучения - такую, которая учитывает социальный / деловой контекст, операции и производительность модели в совокупности. Мы чувствовали, что такое решение объединит описанные выше преимущества и будет более полно соответствовать духу принципов MAS’ FEAT .

Решение

Так родился VerifyML - среда управления с открытым исходным кодом для построения надежных и справедливых моделей машинного обучения. Он состоит из трех частей:

1. Форма опроса

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

2. Модель карты

Заимствованный из Инструментария Google Model Card Toolkit, это источник правды для всей информации, относящейся к конкретной модели. Используя нашу библиотеку Python, модельную карту можно загрузить с помощью ответа на анкету, полученного по электронной почте, или создать с нуля.

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

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

Затем можно добавить модельные тесты, чтобы оценить, соответствует ли модель различным критериям производительности, объяснимости и справедливости. В настоящее время VerifyML предоставляет 5 типов тестов:

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

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

После создания модельной карты информация сохраняется в файле protobuf, который можно экспортировать в файл HTML / Markdown как бизнес-отчет.

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

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

3. Типовой отчет

Отчет по модели содержит автоматизированную документацию и предупреждения по результатам тестирования модели, сгенерированным с помощью Github Actions. Подобно обычному рабочему процессу CI / CD модульного тестирования, его можно настроить на проверку Model Card при каждой фиксации Github, сообщая сводку результатов теста всем пользователям в репозитории. Это обеспечивает основу для хорошего рабочего процесса разработки, поскольку каждый может легко определить, когда модель готова к производству, а когда нет.

Примеры

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

Зрение

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

Вывод

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

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

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

РЕДАКТИРОВАТЬ - Если вы хотите начать работу с VerifyML, прочтите наши краткие руководства здесь: