Выявление потенциального вреда

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

1. Определение потенциального вреда
2. Приоритеты выявленных причинений вреда
3. Тестирование и проверка приоритетных причин вреда
4. Документируйте и делитесь проверенным вредом

1. Определение потенциального вреда

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

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

Чтобы полностью понять известные ограничения и поведение служб и моделей в решении, ознакомьтесь с доступной документацией. Например, служба Azure OpenAI включает заметку о прозрачности; которые можно использовать для понимания конкретных аспектов, связанных с службой и моделями, которые он включает. Кроме того, разработчики отдельных моделей могут предоставлять документацию, например, карточку системы OpenAI для модели GPT-4.

Рассмотрите возможность изучения руководства Microsoft Responsible AI Impact Assessment Guide и использования соответствующего шаблона Responsible AI Impact Assessment template для документирования потенциальных угроз.

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

2. Приоритет вреда

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

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

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

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

3. Тестирование и проверка наличия вреда

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

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

4. Документируйте и делитесь сведениями о вреде

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