Иронии автоматизации
Вероятно, один из главных в мире текстов об автоматизации — статья «Ironies of Automation» когнитивного психолога Лизанны Бейнбридж, опубликованная в 1983 году в журнале Automatica. На неё ссылаются более 1800 других академических работ, про неё есть страница в Википедии, её продолжают вспоминать спустя сорок лет после публикации. Думаю, что сейчас, когда ChatGPT и беспилотные автомобили порождают новый виток замены людей машинами, этот текст по-прежнему очень актуален.
Но вот на Хабре об этой статье вроде бы никогда не писали. Я и сам узнал о ней почти случайно: мы проводим Java-конференции, где её упомянул один из спикеров. И ощутил, что она была бы полезна здесь на русском. Но поскольку исходная публикация академическая, она не вполне в стилистике Хабра. Поэтому я решил не переводить её дословно, а пересказать ряд тезисов оттуда своими словами и добавить немного от себя. Для тех, кому хочется полной точности, даю ссылку на оригинал.
В заголовке «Ironies of Automation» под словом «ирония» понимается «сочетание обстоятельств, результат которых прямо противоположен тому, что можно было бы ожидать».
От автоматизации многие ожидают, что благодаря устранению человеческого фактора получится избежать ошибок. Однако «иронии автоматизации» заключаются в том, что порой результат оказывается противоположным, лишь усугубляя ситуацию. Статья сосредоточена на таких ситуациях.
Как эти ситуации могут выглядеть, в чём заключаются «иронии»?
Проектировщики тоже люди!
Иронично, что проектировщики автоматизированных систем пытаются исключить человека из системы, однако проблемы могут возникнуть из-за ошибок, допущенных самими проектировщиками. Такое порой называют «design-induced error».
А отдельная сложность в том, что эти скрытые ошибки могут проявляться только при определённом стечении обстоятельств. И тогда они могут в течение многих лет «ожидать своего часа», оставаясь незамеченными, пока система будет казаться людям надёжной и безопасной.
Людям остаётся случайный неоптимальный набор задач
Автоматизация стремится исключить людей из процесса, но на деле обычно лишь минимизирует их роль. Человек-оператор всё же остаётся с определёнными задачами. И эти задачи получаются не целенаправленно продуманным набором, соответствующим определённой компетенции. Это произвольный винегрет из тех задач, которые проектировщик не смог исключить. И совершенно не факт, что человек справится с ними лучше, чем с исходным набором.
В этих оставшихся задачах выделяются две больших категории: следить, хорошо ли справляется машина, и перехватить управление при сбое. И в обеих возникают свои проблемы:
Человек утрачивает физические навыки при редком использовании
Физические навыки ухудшаются, когда они не используются, и поэтому, когда человек берет на себя управление автоматизированной системой или автопилотом, его действия могут быть не такими отточенными, как раньше при ручном управлении.
Если на каком-то устройстве надо «подкрутить ручку до определённого уровня», то человек, делающий это постоянно, может сделать это одним уверенным движением. А неопытный человек будет промахиваться. При этом, поскольку физические навыки ухудшаются без практики, в результате автоматизации даже опытный оператор может снова стать «неопытным».
А если после автоматизации понадобилось ручное вмешательство — значит, что-то пошло не по плану. И в такой внештатной ситуации от человека может особенно сильно требоваться быть компетентным.
Когнитивные навыки тоже зависят от использования
Эффективность хранения знаний в долгосрочной памяти зависит от частоты их использования (много ли мы помним вещей из школьной программы, по которым когда-то успешно писали контрольные, но к которым со школы не возвращались?)
Когда система оказывается автоматизированной, многие знания о ней больше не требуются её оператору на постоянной основе. И это означает, что когда они внезапно понадобятся-таки, могут оказаться «недоступными».
Кроме того, сам уровень знаний во многом зависит от их практического применения. Когда постоянно взаимодействуешь с системой, теоретические знания превращаются в реальный опыт, когда получаешь от системы фидбек и усваиваешь его. А без такого взаимодействия знания остаются абстрактными лекционными рассуждениями.
Когда человеку приходится вмешиваться, скорее всего, возникла внештатная ситуация, и может требоваться взять на себя управление автоматизированной системой в кратчайшие сроки — без достаточного времени, чтобы получить полный контекст.
Если персонал, контролирующий систему, не имел практического опыта работы с системой или данным конкретным сценарием до автоматизации, у него может не быть понимания, необходимого для успешного взятия управления.
Люди неэффективны в фоновом мониторинге
Когда по умолчанию задачу выполняет машина, человеку зачастую остаётся следить, чтобы она делала всё правильно. Но по многочисленным исследованиям внимательности известно, что люди не способны сосредотачиваться более чем на полчаса на источнике информации, в котором почти ничего не меняется. Это значит, что выявление отклонений физически невыполнимо лишь человеческими силами.
Следовательно, требуются автоматические системы тревоги, которые подают сигнал при каком-то значимом изменении. Но тогда возникает вопрос:, а кто проверит, что сами эти автоматические системы тревоги работают как надо?
«А тут есть лампочка «Проверьте лампочку «Проверьте двигатель»?»
От людей требуют быть эффективнее того, что их и заменило
Возникает некоторый парадокс. Сначала мы поручили какую-то задачу машине вместо человека, потому что она справляется лучше. Затем мы поручили машине при внештатной ситуации подавать сигнал тревоги, потому что она следит за этим лучше. Но дальше мы ждём от человека, что он примет правильное решение о системах, которые справляются лучше него и умеют считать быстрее него.
Может ли он в принципе точно определять, что компьютер повёл себя неправильно, если человек не способен быстро обработать весь тот объём информации, на основании которого компьютер принял решение? Человеку поручена задача, которая изначально невыполнима полностью.
И что с этим делать — непонятно
Ярко перечислив проблемы, статья дальше пробует рассмотреть подходы к их решению, однако там всё куда менее однозначно.
Приводятся некоторые конкретные тезисы: «при необходимости полезны даже алармы на алармы», «интересна замена красных лампочек более информативными мониторами, где оператор может сам настроить информацию под себя». Однако в первую очередь в статье делается оговорка, что многое зависит от конкретного случая и его специфики. И в целом эта часть для меня выглядит больше приглашением к дискуссии, чем готовым ответом. Ну, можем подискутировать в комментариях.
От меня: иронии автоматизации в 2023-м
Как выглядит эта статья сейчас, спустя сорок лет? По-моему, хотя какая-то конкретика могла устареть, главные мысли остаются более чем актуальны. И они особенно хорошо применимы к новому витку развития AI-технологий, который мы сейчас проживаем.
Компании работают над беспилотными автомобилями, но оговариваются «пока что водитель обязан следить за дорогой и в случае чего перехватить управление». У Tesla Autopilot это уже в продакшне, на реальных дорогах. Это та самая «автоматизация-но-не-совсем», о которой речь в статье, и тут встают во весь рост все обозначенные проблемы.
Способен ли водитель физически непрерывно быть настороже и не отвлекаться, если автомобиль три часа подряд сам едет без каких-либо проблем? Сможет ли человек в аварийной ситуации уверенно отреагировать, если до этого ему долго не приходилось вмешиваться в работу автопилота и он отвык от ручного управления? Может ли водитель вообще быть уверен, что машина ведёт себя неправильно, если у него нет 360-градусного зрения, а у машины есть?
Даже если отвлечься от пока что экзотического автопилота, мы уже каждый день пользуемся в автомобилях другой автоматизацией: GPS-навигацией и автоматической прокладкой маршрута. Это тоже пример того, как машина в целом справляется лучше (человек не может за секунду проложить сложный оптимальный маршрут по незнакомым дорогам), однако временами может давать сбой (вести маршрут хоть в пропасть).
И ответственность человека — вовремя заметить этот сбой и взять всё на себя. А он, привыкший к автоматике, не всегда справляется и порой слепо следует GPS-указаниям, даже когда это ухудшает его положение. Это привело к возникновению понятия «Death by GPS»: смерть от следования таким указаниям. Иронии автоматизации в худших случаях способны приводить к летальному исходу.
А теперь тренд сезона — ChatGPT, Stable Diffusion и схожие нейросети. И по-моему, они тоже в эту степь. Они могут генерировать убедительно выглядящие тексты и компилирующийся код, но везде, где есть цена ошибки, нельзя просто отправлять их в продакшн: кто-то живой должен проверять, что не получилась внешне убедительная опасная ерунда. И эта работа по проверке порой может требовать столько компетенций и времени, а слепое доверие к системе порой может быть настолько опасным, что становится неочевидно, насколько овчинка стоит выделки. Неудивительно, что на Stack Overflow использование ChatGPT для ответов просто запретили.
Я совершенно не хочу быть луддитом, который становится на пути у прогресса. Автопилот, GPS, ChatGPT — это всё полезные штуки. Предполагаю, что GPS спас куда больше жизней, чем загубил.
Мне просто хотелось бы, чтобы люди осознавали не только их преимущества, но и их опасности. Чтобы здраво взвешивали, принимали меры предосторожности и не ждали от технологий больше, чем они могут дать.
Напоследок — минутка рекламы: мы проводим IT-конференции, и некоторые из них перекликаются с темой этого текста. Например, бесплатный IT-фестиваль TechTrain (1 апреля, онлайн) будет посвящён как раз AI, там тема машинного обучения будет рассмотрена с самых разных сторон. А на конференции по тестированию Heisenbug (апрель, онлайн + Москва) можно очень часто услышать слово «автоматизация» — так что понимание «ироний автоматизации» там тоже важно. Все мероприятия весеннего сезона — на сайте jugru.org.
