Мнение
X по дизайну
От конфиденциальности к объяснимости, доверию и надежности
В процессе разработки любой системы конфиденциальность по умолчанию означает, что конфиденциальность — это то, что вы принимаете во внимание с самого начала, а не в последнюю очередь. Это означает, что производительность системы в отношении конфиденциальности считается компонентом общих критериев производительности. Какую часть данных пользователей вы можете предоставить посторонним, поставщику услуг и другим заинтересованным сторонам без ущерба для желаемого сервиса? В рамках конфиденциальности этот подход не вызывает затруднений. После небольшого размышления становится совершенно очевидным, что дизайн системы, обеспечивающей хорошую конфиденциальность, требует конфиденциальности по умолчанию в такой степени, как это требуется европейскими законами о конфиденциальности, известными как GDPR.
Недавно я понял, что мы должны применять аналогичные подходы и к таким вещам, как объяснимость, доверие и надежность, или объяснимость по дизайну, доверие по дизайну и надежность по дизайну.
Объяснимость по замыслу
Во-первых, объяснимость относится к прозрачности причинно-следственных связей в модели. То есть предположим, что ИИ решает включить отопление в доме, тогда система объяснима, если пользователь может узнать, что является триггером для включения отопления. Например, система может решить, что если температура ниже порога, то включается обогрев.
Таким образом, в таком игрушечном примере объяснимость тривиальна. Правило существует и оно должно быть прозрачно для пользователя. Однако реальный ИИ намного сложнее. Существует много переменных, и отношения между входными переменными и выходными могут быть очень нелинейными. Фактически, вся цель систем ИИ состоит в том, чтобы найти причинно-следственные связи из данных, которые настолько сложны, что простые правила недоступны. Таким образом, мы не можем требовать, чтобы правила были прозрачными. Вместо этого для каждой из входных переменных мы можем пометить их соответствующий вес или важность при выборе конкретного результата. Например, «из-за ваших хороших оценок за последний год в университете я решил взять вас на работу». То есть, даже при наличии большого количества критериев для выбора, кого нанять, в качестве триггера были обозначены «классы». Таким образом, это апостериорный подход, при котором мы делаем обратный вывод, чтобы определить, какие характеристики входных данных были важными/решающими для вывода.
Объяснимость по дизайну будет тогда относиться к процессу проектирования, где мы думаем о том, как обеспечить объяснимость с самого начала. Например, если мы разрабатываем сквозную систему машинного обучения, которая принимает необработанные данные в качестве входных данных, может быть сложно присвоить значимые метки важности. Скажем, если у нас есть голосовой пользовательский интерфейс, который принимает сигнал микрофона в качестве входных данных, нет смысла присваивать важность отдельным образцам сигнала микрофона. Они бессмысленны для пользователя. Вместо этого нам потребуются какие-то другие представления признаков, либо параллельные источники данных, либо промежуточные уровни системы, которые дадут эвристически понятные объяснения причинно-следственных связей. Например, «у вас хриплый голос, поэтому я предполагаю, что у вас грипп». Таким образом, объяснимый дизайн требует, чтобы вы могли извлекать квалификаторы, описывающие эвристически значимые признаки, для установления причинно-следственных связей.
Таким образом, процесс проектирования, учитывающий объяснимость, обязательно включает изучение квалификаторов, то есть того, как они выбираются или генерируются. Если у нас есть источник для таких квалификаторов, я ожидаю, что можно будет извлечь их причинную важность. Например, мы можем использовать обратное распространение для изучения чувствительности квалификаторов по отношению к входным данным. Однако часто такие квалификаторы недоступны, и их создание потребует структурных изменений в системе ИИ. Таким образом, на практике нам пришлось бы переобучать модули машинного обучения, что является трудоемким и вычислительно-емким процессом. Следовательно, лучше использовать подход «объяснимость за счет дизайна», когда квалификаторы и методы обратного вывода включаются в проект с самого начала.
Доверие по дизайну
Здесь я бы определил доверие как чувство того, что можно предсказать исход событий вне прямого контроля. Таким образом, мы должны разделить доверие на две части: надежность и чувство доверия, где первое относится к последовательному поведению (предсказуемость), а второе — к ощущению (вере), которое мы можем предсказать, независимо от фактического уровня предсказуемости. . Оба, очевидно, важны. Летая на самолете, мы оба хотим чувствовать себя в безопасности (чувство доверия), но также хотим, чтобы мы действительно были в безопасности (заслуживаем доверия). То же самое относится и к системам ИИ.
Требование последовательного поведения — это задача, с которой разработчики ИИ, вероятно, уже знакомы. Это относится к обеспечению того, чтобы весь диапазон ожидаемых входных данных давал достаточно точные результаты. Это относится к используемой методологии обучения, тестирования и проверки, которая позволяет получить доказательства стабильной работы.
Возможно, более интересной частью является уровень доверия, которое пользователи чувствуют при использовании системы ИИ. Очевидно, что это задача дизайна пользовательского интерфейса и опыта (UIX). Опять же, дизайнеры UIX должны быть вовлечены в процесс проектирования с самого начала. Например, при выборе квалификаторов объяснимости нам необходимо проконсультироваться с разработчиками UIX. Как бы себя чувствовали пользователи, если бы выбор найма основывался на степени хрипоты в голосе? Ясно, что такой выбор является (может быть) также этическим и моральным выбором. Несомненно, доверие по замыслу поэтому хорошо мотивировано и важно.
Прочность по дизайну
Классический подход к оценке систем ИИ заключается в проверке их производительности на невидимых (никогда не виденных) данных, которые не использовались для обучения системы. Это критерий надежности в том смысле, что достаточно похожие наборы данных должны давать аналогичные результаты (как интерполяции, так и экстраполяции). Вопрос, однако, в том, может ли надежность быть спроектирована сверх этого?
Более фундаментальный вопрос состоит в том, чтобы определить, что означает надежность. Эвристическое определение заключалось бы в том, что результат вывода не должен быть чрезмерно чувствительным к небольшим изменениям любого из входных данных. С математической точки зрения было бы полезно, если бы несколько независимых измерений данных указывали на один и тот же результат. То есть при приеме на работу нехорошо, если решение основывается исключительно на оценках университетских курсов, но и другие источники, такие как история занятости, должны поддерживать тот же результат. Это означает, что небольшие изменения в оценках не повлияют на решение. Очевидная проблема заключается в том, что обычно всегда будут пограничные случаи, когда небольшие изменения изменят решения.
Таким образом, с помощью тестирования мы можем оценить надежность системы, а с помощью методов отсева мы можем обучить систему так, чтобы она меньше зависела от конкретных измерений. Я также недавно видел некоторые работы по обеспечению соблюдения критериев непрерывности и гладкости результатов, которые явно повышают надежность. Тем не менее, я чувствую, что я что-то упускаю здесь. Я чувствую, что должен быть какой-то другой, лучший способ убедиться, что решения являются надежными, например, основанный на большинстве голосов независимых индикаторов. Здесь я вижу самую большую практическую проблему в определении независимости, поскольку классические определения основаны на линейных операциях, а системы ИИ нелинейны. В любом случае, мое ненаучное чутье подсказывает, что эти вопросы должны быть снова включены в процесс проектирования с самого начала.
Резюме и выводы
Я чувствую, что пришел к круговому аргументу. Ясно, что если мы хотим иметь надежные и объяснимые системы, которым мы можем доверять, мы должны проектировать их так, чтобы они были таковыми с самого начала. В более широком смысле, мы могли бы фактически применить дух этичности по замыслу, который включал бы надежность, объяснимость, доверие, конфиденциальность и т. д. Проще говоря, мы могли бы просто сказать, что мы разрабатываем хорошие системы. Чем же тогда это отличается от того, что мы уже делаем?
Во-первых, я думаю, что представление дизайна систем ИИ как целостных проблем дизайна было бы значительным улучшением. Дело не только в том, насколько точен ИИ-найм по отношению к обучающему набору данных. Дело не только в том, сколько клиентов нажимают на баннер, выбранный системой ИИ. Системы ИИ не являются изолированными системами, они взаимодействуют с обществом в целом. В рамках найма ИИ нам необходимо также оценить реакцию общества на систему и системы рекомендаций по рекламе, нам необходимо оценить их влияние на уязвимые группы населения, на демократию, на социальную и экономическую справедливость и разнообразие и так далее. Могучая задача.
Ответственность за хороший дизайн лежит на дизайнере (sic). Хотя вышеописанная задача трудна, ответственность лежит на нас, проектировщиках. Всегда, когда мы проектируем, но особенно когда публикуем результаты, мы должны оценивать качество системы с точки зрения ее целостной производительности. Точно так же, читая об ИИ, мы должны задавать вопросы и требовать ответов о целостной производительности. Не уверен, что вообще смогу придумать вариант, последствия могут быть мрачными, надо сделать хороший дизайн.
