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

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

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

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

Процесс и дрейф

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

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

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

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

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

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

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

Простой процесс

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

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

Но что, если вместо того, чтобы смотреть на влияние ошибок, мы посмотрим на дрейф в процессе?

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

Также…. как точно определяется «релевантный» объект? Процесс не проясняет это. Возможно, есть какой-то авторитетный источник объектов, на которые стоит обратить внимание. Или можно было предположить, что релевантность очевидна. Если есть список соответствующих объектов, как должен вести себя человек-оператор, когда он сталкивается с чем-то, не включенным в список, но похожим на другие соответствующие объекты? Например, если наш список «подходящих объектов» состоит из таких предметов, как ручки, карандаши и маркеры, считается ли мел для прогулки по сторонам? Есть ли кисть для каллиграфии?

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

Если мы попытаемся изобразить эти отклонения на нашей карте процесса, мы можем получить что-то вроде этого:

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

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

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

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

Мышление Типа 1 и Типа 2

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

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

По этой причине было бы очень интересно проследить мышление Типа 1 и Типа 2 через существующий процесс.

Если бы мы автоматизировали этот процесс, мы бы, вероятно, удалили эти проверки. Распознавание лиц идентифицирует лица, а обнаружение объектов - объекты, затем компьютер производит подсчет. Там есть немалый запас на неудачу. Если этот процесс не требует высокой степени точности, это, вероятно, нормально, но если это так, кажется очевидным, что человек не в курсе.

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

Поиск решений

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

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