Руководство для нетехнических клиентов и менеджеров, заказывающих проект ИИ, от человека, который с любовью был и техническим разработчиком, и менеджером.
Искусственный интеллект (ИИ) — относительно новая и быстро меняющаяся отрасль. Общеизвестно, что ИИ может изменить то, как мы живем и работаем, но подробности того, как он может это сделать, гораздо более неуловимы. Широко распространенная шумиха вокруг ИИ и машинного обучения (МО) увеличивает как интерес, так и путаницу в отношении проектов ИИ[1]. Не помогает и то, что большинство менеджеров вынуждены знать о передовых технологиях, не задавая вопросов.
Сочетание завышенных ожиданий и плохого понимания создает в проектах искусственного интеллекта порочные стимулы для того, чтобы отдавать приоритет быстрому созданию моделей с блестящими результатами и выделять минимальные ресурсы на скучную, но важную работу по обеспечению того, чтобы система продолжала хорошо работать после окончания первоначального контракта. В результате разработчики (разработчики) могут столкнуться с необходимостью урезать свои собственные системы, если это будет быстрее или удобнее с самого начала. Ярлыки, такие как использование неверных обучающих данных, могут привести к снижению производительности модели, чего не хотят ни разработчики, ни их менеджеры, ни их клиенты. Однако таких результатов трудно избежать в тех случаях, когда люди, заказывающие систему, не понимают последствий того, о чем они просят.
Хорошие новости: человеку, заказывающему систему ИИ (будь то внутренний менеджер или внешний клиент), не обязательно быть экспертом в области машинного обучения, чтобы спроектировать и реализовать отличный проект ИИ. В конце концов, их работа не в том, чтобы разбираться в AI/ML, как и в том, чтобы разбираться в практических деталях операции по удалению аппендицита — разные специалисты специализируются в разных областях, и эта специализация позволяет каждому из нас углубить свои знания в конкретной области. поле. Вместо этого, чтобы разработать отличный проект ИИ и управлять им, менеджер должен понимать основные входные данные, необходимые для функционирования ИИ, и какие результаты он может реально ожидать с учетом этих входных данных.
К сожалению, учитывая относительно ранние этапы внедрения ИИ в большинстве отраслей и плохое понимание ИИ широкой публикой, менеджеры все еще подвержены ряду ошибок при разработке и реализации проектов ИИ и машинного обучения. Следующие ошибки могут быть абсолютно фатальными для успеха проекта, но их легко избежать, просто помня о них — курсы машинного обучения не требуются.
- Неспособность четко определить проблему
Чего вы хотите достичь с помощью ИИ? Слишком часто я видел, как менеджеры сосредотачиваются на идее использования ИИ, не задумываясь о том, как результаты будут использоваться на практике. Четко определите проблему, прежде чем пытаться ее решить, и помните, что более яркие решения не всегда самые лучшие! Вместо того, чтобы говорить: «Я слышал об этой замечательной технике, что она может мне сделать?», можно добиться гораздо большего, если определить существующую проблему и спросить: «Какие техники могут помочь мне в этом?» Вам не нужно точно определите, как проблема должна быть решена, но вы должны быть в состоянии сформулировать, в чем проблема. Хороший архитектор или разработчик ИИ должен рассказать вам, как потенциальные решения ИИ решат вашу проблему, и помочь выбрать наиболее подходящее. - Сосредоточение внимания на задачах, а не на результатах
Сосредоточение внимания менеджера или клиента на конкретных задачах может снизить функциональность системы, вызвать путаницу среди разработчиков и задержать успешную разработку. Задачи взаимозаменяемы и должны быть понятны только разработчикам, которые будут их выполнять; результаты гораздо более конкретны в течение срока действия проекта и должны быть согласованы всеми соответствующими заинтересованными сторонами. Менеджеру, который измеряет прогресс выполнением конкретных задач, будет трудно адаптироваться, когда будет определен лучший способ достижения того же результата. Менеджер, который измеряет прогресс достижением результатов, нуждается только в подтверждении того, что результат был достигнут, предоставляя разработчикам свободу оптимизировать детали своей работы по своему усмотрению. - Не задавать вопросов, потому что не хотите выглядеть глупо
Это нормальный, но чрезвычайно контрпродуктивный человеческий инстинкт, особенно в некоторых отраслях, где престиж является основной валютой. Если вы боитесь показаться глупым, вы можете попробовать поискать вопрос в Google, прежде чем задавать его, но, пожалуйста, не стесняйтесь спрашивать своих разработчиков и архитекторов о технических вещах, с которыми вы не знакомы. Часть их работы состоит в том, чтобы убедиться, что вы понимаете, что они вам продают, но они не смогут этого сделать, если вы притворитесь, что знаете, чтобы сохранить лицо. Если вы не понимаете, на что соглашаетесь, в дальнейшем могут возникнуть всевозможные неприятные проблемы. Нет ничего постыдного в том, чтобы не понимать что-то техническое — помогите своим разработчикам помочь вам принять правильное решение! - Отказ от приоритезации обучающих данных
Вы, наверное, слышали, что обучающие данные можно использовать для обучения моделей машинного обучения. Но вы можете не знать, что без обучающих данных создать модель машинного обучения буквально невозможно. Определяющим фактором машинного обучения является то, что модели необходимо изучать данные, чтобы научиться выполнять свою задачу. Кроме того, плохие обучающие данные означают, что модель будет изучать неправильные вещи и давать неверные результаты. Это означает, что вам нужны не только обучающие данные, но и набор обучающих данных, который должен быть надежным, точным и непротиворечивым. Данные обучения должны содержать множество записей о том, как ваша проблема решается так, как вы хотите, чтобы она решалась — если вы пытаетесь автоматизировать задачу, это могут быть примеры правильного выполнения задачи, или если вы пытаетесь определить конкретные условия, примеры тех условий, которые уже были идентифицированы. [2]
Поскольку адекватные обучающие данные являются таким важным требованием для моделей ML — но часто труднодоступным — были разработаны такие ярлыки, как перенос обучения, чтобы облегчить бремя защиты обучающих данных. Они облегчают нагрузку, но не устраняют ее. Ни одна модель машинного обучения не нуждается в обучающих данных.
(В ИИ есть исключение из этого правила: модели, основанные на правилах, которые не являются машинным обучением, но все же являются разновидностью ИИ, не требуют обучающих данных. Для моделей, основанных на правилах, вы не полностью крючок — разработка этих моделей по-прежнему потребует четкого обсуждения с экспертами в предметной области, чтобы определить правила, которые будет использовать модель, но это может быть полезным методом, если невозможно получить данные для обучения. решается с помощью моделей на основе правил, так что это не панацея от нехватки обучающих данных.Дополнительную информацию о моделях классификации на основе правил и ML см. в этой статье, а информацию о гибридных моделях см. в этом докладе. ) - Использование искаженных или вводящих в заблуждение данных для получения достаточного количества обучающих данных
К сожалению, одного количества наблюдений недостаточно для обеспечения хорошей обучающей выборки. Иногда обучающие данные можно быстро собрать, собрав множество легкодоступных записей, которые встречаются в природе, т. е. уже доступны в системе, без тщательного анализа. Такой набор данных — даже если он включает миллионы строк — может привести к множеству проблем. Возможно, вы слышали об искусственном интеллекте, который отдает предпочтение мужчинам в алгоритмах найма, или о том, что технология распознавания лиц лучше всего распознает светлокожие лица. Наиболее доступные наблюдения могут быть не лучшими для обучения вашей модели и могут включать в себя существующие социальные предубеждения, которые вы (надеюсь) не хотите увековечивать. Относительная распространенность типа наблюдения в обучающей выборке оказывает большое влияние на веса, которые модель будет присваивать различным функциям. Это может иметь как этические, так и деловые последствия для вашей системы искусственного интеллекта. Чтобы начать исследовать верхушку айсберга, то есть сложную проблему статистической погрешности в ИИ, ознакомьтесь с этой статьей. - Создание мертвых моделей для живых систем
Представьте, что вы обучаете алгоритм рекомендаций по покупкам на основе предпочтений пользователей, собранных за период в 6 месяцев. Но предполагается, что алгоритм будет использоваться годами. Тенденции меняются, пользователи взрослеют, и вскоре молодому специалисту рекомендуют не стильную детскую одежду, а стильную офисную одежду, которая соответствовала бы его нынешнему образу жизни. Этот алгоритм, очевидно, никогда не выживет в реальном мире быстрой моды — настоящие рекламные алгоритмы постоянно адаптируются к меняющимся предпочтениям пользователей, непрерывно поглощая новые данные. Петли обратной связи сохраняют актуальность моделей даже при изменении пользователей и окружающих условий.[3] Для получения дополнительной информации об реагирующих и адаптивных системах искусственного интеллекта ознакомьтесь с этими, блогами или этой статьей. - Создание зависимых моделей
Ничто не является постоянным. Это включает в себя ваших сотрудников, контракты на поставку и жесткие диски. Модели, которые полагаются на людей или системы, которые в конечном итоге исчезнут, станут непригодными для использования, и было бы неплохо проектировать свои системы ИИ с учетом этого. Важность воспроизводимого кода и документации хорошо понимается в сообществах программистов, но они могут занимать много времени, и многие клиенты не заинтересованы в том, чтобы заранее платить за дополнительные усилия, чтобы обеспечить эффективное выполнение кода. годы спустя. Не поддавайтесь этому недальновидному инстинкту! Даже сама ваша кодовая база может исчезнуть, если она хранится в неустойчивом месте (например, на одном компьютере разработчика). Ваши технические разработчики должны быть хорошо знакомы с такими инструментами, как GitHub и BitBucket, которые позволяют им отслеживать изменения в процессе работы, сотрудничать с коллегами по команде, управлять развертыванием, а также сохранять и обновлять документацию. Дополнительное время и усилия, потраченные на обеспечение устойчивости системы сейчас, будут стоить того, чтобы обеспечить долговечность проекта. - Забыть о пользовательском опыте
Если система сложна или запутана в использовании, если доступ к ней слишком сложен, она никогда не будет широко принята пользователями. В дополнение к понятному и интуитивно понятному интерфейсу вы также должны убедиться, что система, которую вы разрабатываете, удобна для доступа и позволяет легко получать результаты. Это не должно быть запоздалой мыслью. Чтобы внедрить модель или систему ИИ в общую деятельность организации, требуется время, планирование и ресурсы. Существует целая профессия, посвященная UX/UI (пользовательский опыт и пользовательский интерфейс), в которой ваши разработчики AI и ML могут иметь или не иметь вторичной специализации. Стоит инвестировать в пользовательский опыт — и понимать, что это пересекающаяся, но отдельная карьера от разработки ИИ — чтобы гарантировать, что ваша система ИИ может принести обещанные преимущества вашей организации.
ИИ и машинное обучение штурмом захватили многие отрасли, и, как и любая другая технология, они могут быть полезными, пустой тратой ресурсов или вредными, в зависимости от того, как они используются. При заказе системы ИИ (либо у собственных сотрудников, либо у подрядчика) вам действительно не нужно знать мельчайшие детали того, как работает ИИ, но вам необходимо понимать некоторые общие концепции и опасности, связанные с ИИ. Ключ к раскрытию преимуществ ИИ для вашей организации заключается в правильном его использовании и предотвращении фатальных ошибок.
[1] Во-первых, уточнение: машинное обучение — это разновидность искусственного интеллекта. Таким образом, все машинное обучение — это ИИ, но не все ИИ — это машинное обучение. Смотрите полезные посты в блогах здесь и здесь.
[2] Тот факт, что этот абзац, вероятно, станет неожиданностью для многих читателей, является источником путаницы и разочарования во многих проектах ИИ и МО и часто побуждает меня задуматься о написании блога или статьи под названием Машинное обучение — это не Магия. К сожалению, нет, машинное обучение не может создавать результаты из ничего.
[3] Обратите внимание, что неконтролируемые циклы обратной связи могут в конечном итоге слепо принимать проблемные данные (см. Фатальная ошибка № 5). Для получения более подробной информации см. этот пост или этот знаменитый прецедент о социальных сетях.
