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

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

Следует ли Acme Solutions приступить к проекту чат-бота с искусственным интеллектом?

Если этот проект будет завершен по всем стандартам, решит ли он проблемы Acme?

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

Что здесь не так?

Самая первая проблема здесь — «модифицировать мышление». Acme Solutions начинает с решения, а затем пытается соответствовать своей растущей клиентской базе и отчетам об инцидентах. Они сформировали свою гипотезу при выборе решения, что является фундаментальной ошибкой в ​​построении гипотезы.

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

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

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

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

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

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

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

1. Устраняете ли вы правильную основную причину?

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

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

y = f (x)

Y — это проблема, а x — причина или движущая сила (или несколько причин или движущих сил) этой проблемы, а f представляет собой процесс или формулу, благодаря которой x приводит к y.

Если мы продолжим наш предыдущий пример Acme Solutions, он может выглядеть примерно так:

Отчеты об инцидентах = f (плохое руководство по продукту, низкокачественный продукт и т. д.)

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

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

Что, если благодаря внедрению расшифровщика на основе ИИ качество руководства по продукту улучшится, что позволит автоматически написать руководство по продукту и проверить его на предмет качества контента?

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

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

2. Правильно ли обучено решение?

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

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

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

Если данные, переданные во время обучения решения, недостаточно хороши, это может привести к нескольким проблемам позже, и риск будет проявляться в разных формах.

Например, в решение может просочиться алгоритмическая предвзятость, которая повлияет на все результаты. Алгоритмы машинного обучения выявляют шаблоны в данных, а затем строят прогностическую модель на основе этого шаблона. Любое созданное правило или решение, принятое решением ИИ, зависит от этого. Если в этих паттернах есть какая-то предвзятость, то решение усилит эту предвзятость и может привести к результатам, которые могут еще больше усилить предвзятость.

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

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

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

3. Учтены ли в решении все сценарии?

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

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

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

Возьмем пример беспилотного автомобиля. Если вы попросите машину доставить вас к месту назначения как можно быстрее, она может доставить вас туда. Более того, вы, возможно, нарушили несколько правил дорожного движения, когда добрались туда, и поставили под угрозу жизнь попутчика. Ничего из этого не приемлемо. Однако такое может случиться, если ваш ИИ слишком узок и не видит леса за деревьями.

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

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

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

4. Есть ли возможность изящно остановиться?

Система, которая правильно спроектирована, всегда будет иметь встроенную избыточность. Решения искусственного интеллекта нового века могут быть очень эффективными и могут привести к масштабируемому ущербу, когда что-то пойдет не так.

Итак, спросите свою команду разработчиков или поставщиков ИИ об аварийном выключателе. Уточните у них возможность корректной остановки системы при необходимости.

Система без возможности изящной остановки является очень рискованной системой.

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

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

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

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

5. Является ли решение объяснимым и поддающимся проверке?

Программное решение, каким бы сложным оно ни было, всегда можно проверить, понять и объяснить. Только если бы он был неправильно разработан, он бы пропустил это.

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

Для многих отраслей объяснимость ИИ является нормативным требованием. Например, с действующими законами об Общем регламенте защиты данных (GDPR) компании должны будут предоставлять потребителям объяснение решений, основанных на ИИ. [1]

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

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

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

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

6. Подходит ли решение для вашего варианта использования?

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

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

Если вы ожидаете, что ваше решение будет расшифровывать записи врачей и делать прогнозы или решения на их основе, ваше решение должно понимать местный диалект, сленг и другие языковые нюансы. Например, мусорное ведро (США) и мусорное ведро (AU) или тротуар (US) и пешеходная дорожка (AU) означают одно и то же, но имеют разные слова. Приведенные здесь примеры довольно примитивны; однако языковые различия будут иметь большое значение для сложного приложения.

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

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

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

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

7. Предусмотрено ли решение для борьбы с дрейфом?

Проблема изменения данных с течением времени и, следовательно, влияние на статически запрограммированные (или предполагаемые) отношения — обычное явление для нескольких других реальных сценариев машинного обучения. В машинном обучении этот сценарий называется концептуальным дрейфом.[2]»

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

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

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

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

Проверьте, учитывало ли ваше решение дрейф концепции, и если да, то в какой степени. Ответ на этот чек скажет вам уровень риска.

Тщательная оценка является ключевым

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

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

Суть дела в том, что вы не можете предоставить разработчикам ИИ, внутренним или внешним, самим следить за продуманным дизайном и разработкой.

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

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

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

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

Тактически важно «делать все правильно», в то время как стратегически важно «делать правильные вещи». Но при наличии такой мощной технологии, как ИИ, важно и то, и другое.

[1] https://www.fico.com/blogs/gdpr-and-other-regulations-demand-explainable-ai

[2] https://medium.com/tomorrow-plus-plus/handling-concept-drift-at-the-edge-of-sensor-network-37c2e9e9e508

Примечание. Эта статья является частью 10 из 12 статей об искусственном интеллекте. Эта серия была впервые опубликована журналом EFY в прошлом году и теперь также доступна на моем веб-сайте по адресу https://www.anandtamboli.com/insights.