Когда я общаюсь с клиентами в роли консультанта по ИИ, я сталкиваюсь с некоторыми стандартными мифами. Надлежащее прояснение этих мифов - первый шаг на пути клиента к ИИ. Большинство проблем возникает из-за общей неграмотности ИИ. Многие компании, начиная свой путь к ИИ, просят своих самых опытных менеджеров (или тех, у кого есть лишняя пропускная способность) заняться преобразованием ИИ. Проблема в том, что эти менеджеры являются экспертами в традиционной парадигме разработки программного обеспечения. Без официального знакомства с искусственным интеллектом они пытаются взглянуть на проект искусственного интеллекта с точки зрения классической разработки программного обеспечения. С высоты птичьего полета подход SDLC выглядит очень применимым и к проектам AI. Но на этом сходство заканчивается, и черт в деталях. В проектах искусственного интеллекта есть некоторые существенные различия, которые требуют особого подхода и понимания. Честно говоря, я сам получил классическое образование в области разработки программного обеспечения, а позже перешел в науку о данных через формальное образование. Я страдал от некоторых из тех же неправильных представлений в первые дни моей карьеры в области науки о данных. Крайне необходимо разубедить ваших клиентов в этих мифах, чтобы вам было удобнее работать над проектом.
Не говоря уже о тактичности и навыках, необходимых для передачи знаний, вот список проблем, с которыми я часто сталкивался с такими клиентами. Приведенный ниже список не является ни полным, ни исчерпывающим. Но я хотел бы составить список мифов, с которыми я часто сталкиваюсь.
Предполагая, что данных достаточно для решения любой проблемы
Миф: это происходит, когда менеджеры чрезмерно полагаются на маркетинговую шумиху в отношении ИИ. Они предполагают, что после того, как все генерируемые данные будут сброшены на сервер ИИ, любую проблему можно решить с помощью алгоритмов ИИ.
Реальность: такое бывает редко. Я хотел бы привести классический пример из сферы здравоохранения. Допустим, у нас есть данные о каждой больнице в городе относительно количества их ежемесячных пациентов, количества отпусков персонала, отпусков, количества использованных сиренгов, количества рожденных здоровых детей, количества кесаревых сечений, сделанных в месяц и т. Д. Это отличные данные . Но этого недостаточно, чтобы предсказать, будут ли у конкретной женщины нормальные роды или кесарево сечение. Для этого нам нужны данные на уровне отдельного пациента. Если у вас нет данных такого уровня, тогда ни один алгоритм не сможет дать ожидаемых чудес ИИ.
Подход, который я выбрал, заключается в том, чтобы попросить менеджеров ответить на этот вопрос. Если доступно бесконечное количество времени, можно ли выполнить задачу с помощью карандаша и бумаги, используя имеющиеся данные? Если ответ положительный, то проблема и данные могут быть решены с помощью искусственного интеллекта. Следующим шагом будет оценка сложности и окупаемость инвестиций.
Предполагая, что модели ИИ являются моделями общего назначения, которые собираются раз и навсегда.
Миф: модель, созданную для варианта использования A, можно развернуть для прогнозирования результатов в сценарии B.
Реальность: менеджеры нередко используют такие термины, как «эволюционный прототип» и т. Д., Когда имеют дело с проектами ИИ. PoC AI не обязательно должны быть «одноразовыми» прототипами. Но вполне возможно, что модель, построенная с использованием подмножества данных, не будет просто масштабироваться до полного набора данных (то есть большего количества столбцов). Если данные, используемые для PoC, недостаточно репрезентативны для полного набора данных, результаты PoC могут вводить в заблуждение.
Этот миф часто встречается в конце PoC. Я могу привести пример: допустим, у вас есть PoC для выполнения анализа временных рядов данных журнала сервера. Код, который вы разработали для изменения данных, выполнения анализа временных рядов и прогнозирования KPI, нельзя повторно использовать как есть, например, для данных фондового рынка. Правда, оба они используют одни и те же концепции, такие как стационарность, сезонность, дифференциация и т. Д. Но модель, построенная для анализа журнала сервера, не может работать на фондовых рынках. В классических алгоритмах программирования есть такие концепции, как разветвление, разветвление и т. Д., Которые могут справиться с некоторыми из этих сложностей, но не многие решения ИИ достигли этого уровня.
Приведенный выше пример может быть крайним и очевидным. Но есть один непростой вопрос: вы подошли к концу успешного PoC для анализа журнала сервера Windows. Менеджер подходит к вам и говорит: «Загрузите данные журнала сервера Unix в ту же модель и получите столь же выдающиеся результаты». По правде говоря, нет никакой гарантии, что модель масштабируется как есть. Аргумент: «Почему мы не можем настроить данные Unix, чтобы они имели одинаковые имена столбцов и использовали существующую модель?» Это просто так не работает. По мере изменения данных модель должна меняться. Параметры, которые были очень важны для журнала сервера Windows, могли не иметь никакого отношения к серверу Unix. Простое изменение имен столбцов и типов данных не даст таких же результатов.
Использование смоделированных данных для PoC
Миф: для демонстрации концепции продукта потенциальному покупателю можно использовать смоделированные данные.
Реальность: это самая большая проблема, с которой я сталкиваюсь, и использование этой команды - мой самый большой страх. Причина в том, что смоделированные данные генерируются с использованием некоторого варианта генерации случайных чисел. Однако случайные числа, генерируемые в компьютерах (могут быть на любом языке), не являются на самом деле случайными. Это псевдослучайные числа. т.е. они следуют математической функции. Какой бы сложной ни была функция, в нее заложены закономерность и предсказуемость. Теперь алгоритмы машинного обучения очень хорошо понимают предсказуемость. Таким образом, любые смоделированные данные можно относительно легко понять и спрогнозировать. Нередко бывает очень высокая точность классификации или регрессия r2. Это дает ложное представление о мире и рассматриваемом PoC. Более того, используемое решение не должно масштабироваться до реального мира. Стохастичность - это определяющая характеристика реальных данных. Шум - вот что делает данные реальными. ML - это понимание этой стохастичности. Предсказуемость псевдослучайных чисел противоречит самой цели машинного обучения.
Проблема в том, что объяснить это неграмотному ИИ чрезвычайно сложно. В классическом мире разработки программного обеспечения смоделированные данные почти всегда были надежным вариантом для запуска PoC. Просить менеджера не полагаться на его самый надежный инструмент - серьезное изменение, и эти разговоры никогда не заканчивались для меня удовлетворительно.
Непонимание r2, точность / отзыв с коэффициентом успешных / неудачных тестов SDLC, непонимание компромиссов
Миф: у нас есть r2 (r-квадрат), равный 0,6. Это означает, что модель машинного обучения успешна только в 60% случаев и неверна в 40% случаев. Любой код должен соответствовать 99% точности тестового сценария. Иначе бесполезно.
Реальность: Хорошо, это классика. Это второй по величине из моих страхов при общении с менеджерами. В классической разработке программного обеспечения кодирование основано на правилах. Эти правила сформулированы людьми. Тестовые примеры предназначены для проверки граничных условий. Следовательно, очень разумно ожидать 99% успеха тестовых случаев.
Однако сфера ИИ выходит за рамки ручного определения правил. Грубо говоря, мы кидаем данные в движок ИИ и просим его выплюнуть правила. А стохастичность, присущая данным, затрудняет достижение 99% -ного коэффициента успеха. На данный момент ИИ не достиг уровня 99% успеха, будь то регрессия, классификация или что-то еще. В настоящее время ИИ используется для сокращения человеческих усилий. Не заменять полностью.
Это источник всех бед. Если клиент не знаком с этим фундаментальным различием, то, вероятно, он приравняет ваш отчет о r2 или точности / точности / отзыве и т. Д. С отчетом об успешности тестовых сценариев традиционного программного обеспечения. Я всегда считал, что отказ от этого понятия является вторым по сложности делом. Часто в результате для меня менеджер по работе с клиентами говорил: «Вы ничего не знаете. Вы должны реализовывать проекты шести сигм »и т. Д. И в конечном итоге вы чувствуете, что хотите убить его или себя.
Изучение Python / R достаточно для запуска проекта AI
Миф: предложение не требует пояснений
Реальность: кодирование на Python / R / Julia / gobbledy-gook не означает, что вы используете ИИ. Особенно Python. Я слышал, как кто-то сравнивал Python со швейцарским клинком, и обнаружил, что согласен с этим. Python можно использовать в различных областях, таких как веб-разработка, графический интерфейс, приложение для Android и HMI. Хотя Python / R / Julia отлично поддерживает алгоритмы ИИ, совокупность знаний ИИ не имеет ничего общего с этими языками. AI может быть реализован на чистом C, C ++ или даже FORTRAN. Сказать, что использование Python реализует кодирование, сродни утверждению, что использование Java необходимо и достаточно для реализации многопоточных или многозадачных программ.
Невозможно понять проблемы контроля версий
Миф: Нам нужен только код контроля версий в проекте AI.
Реальность: Не совсем так. Контроль версий в AI требует гораздо большего. Мы должны контролировать версии наборов данных, кода, обучающих и тестовых подмножеств, вносить технические изменения как по отдельности, так и вместе.
Тем не менее, этот миф относительно легко развенчать. Ни один менеджер не возражает, когда мы говорим, что для проектов ИИ нужен более чем обычный контроль версий. Обычно достаточно тщательного объяснения причины. Во многих случаях менеджерам становится легче, когда они легко усвоили некоторые особенности проектов искусственного интеллекта. Итак, этот миф должно быть легко развенчать.
Не заострять внимание на требованиях к объяснимости ИИ-решения
Миф: у меня есть отличное решение для искусственного интеллекта с прекрасными показателями r2 или точности / отзыва / точности. Я все готов. Это все, что мне нужно.
Реальность: вы также должны учитывать объяснимость. Если просто сказать, что «ИИ дал это решение с большой точностью», это никуда не годится. Например, допустим, вы утверждаете или отклоняете заявку на получение кредита с помощью ИИ. Если вы не можете объяснить, почему алгоритм отклонил конкретный запрос, вы не сможете развернуть его в реальном мире, где юридические последствия являются серьезной проблемой. Объяснение необъяснимости алгоритмов искусственного интеллекта, особенно алгоритмов глубокого обучения, - это аспект, который требует предварительного рассмотрения.
Этот список ни в коем случае не является исчерпывающим. Это даже не авторитетно. Это некоторые из повторяющихся мифов, с которыми я столкнулся как консультант по ИИ. С чем еще вы столкнулись?
