Ошибки, которых следует избегать в качестве специалиста по искусственному интеллекту в промышленности

Автор Заррин Реза

Женщины, которые кодируют разговоры о технологиях 10 | Spotify — iTunes — Google — YouTube — Текст
Заррин Реза Ученый-исследователь искусственного интеллекта в Volta Charging и руководитель организации Women Who Code делится «Ошибками, которых следует избегать в качестве специалиста по искусственному интеллекту в индустрия". Она обсуждает важность знания того, когда ИИ действительно является подходящим решением, ценность знаний в предметной области для проекта и другие ключевые факторы успешного применения ИИ.

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

Я выделю двенадцать ошибок, которых очень важно избегать, если вы хотите успешно внедрить решение на основе ИИ. Первая ошибка заключается в том, что любая проблема с данными требует решения AI ML. На современном рынке ИИ — это модное слово. Все хотят попробовать новые алгоритмы и попытаться решить все проблемы. Распространенная поговорка в мире ИИ состоит в том, что когда у вас есть молоток, все выглядит как гвоздь. Когда у вас есть навыки ИИ, у вас есть ресурсы в вашей команде, вы чувствуете, что вам нужно решать все проблемы только с помощью алгоритма ИИ. Это не всегда так. Цель должна состоять в том, чтобы найти практичное и эффективное решение, которое вы найдете для своего бизнес-варианта. Алгоритмы ИИ не всегда очень практичны для использования в реальных сценариях использования.

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

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

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

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

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

Ошибка номер четыре — думать, что сложные модели лучше, чем простые. Так что это не всегда верно по нескольким причинам. У Уильяма Оккама есть известная гипотеза, известная как бритва Оккама, которая предполагает, что более простые модели с меньшим количеством коэффициентов предпочтительнее сложных моделей, таких как выборки. Это в полной мере относится к сегодняшнему развитию машинного обучения, когда современные модели не всегда применимы для практических случаев. Если вы хотите создать продукт, который должен запускать эту большую модель поезда на любом из устройств меньшего размера, это непрактичное решение. Более простые модели также легче отлаживать и быстрее проводить эксперименты. Когда у вас есть очень большая сложная модель, где для завершения одной тренировки требуется от пяти до шести дней, вам действительно сложно опробовать множество комбинаций. Вы теряете время. Кроме того, более простые модели намного дешевле развертывать и масштабировать. Сложные модели требуют больше вычислительных ресурсов и больше затрат.

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

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

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

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

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

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

Ошибка номер восемь — не применять разработку через тестирование в науке о данных, когда это необходимо. Наука о данных, управляемая тестированием, — это концепция, которая становится довольно популярной в наши дни. Система TDD состоит из трех этапов: красный, зеленый и рефакторинг. Красным вы пишете тестовый пример, который не работает. Зеленым вы пишете код, который проходит этот тест. Рефакторинг, вы пытаетесь избавиться от всех избыточностей. Модулируйте, очистите свой код и сделайте его пригодным для использования. Написание этих тестовых случаев на самом деле заставляет вас думать о том, какие сценарии пользователи могут создать позже, и какие типы вариаций мы можем ожидать во входных данных. Это также помогает разделить кодовую базу на модули для использования функций и для будущего расширения. Если в будущем существует вероятность того, что вашу модель потребуется расширить для определенного типа функций или наборов данных, такая система на основе TDD поможет вам в этом. Напишите тестовые примеры для модулей, охватывающих изменение данных, обработку исключений и обнаружение аномалий. Попросите ваших коллег проверить ваши коды. Поощряйте совместное кодирование и обмен идеями между ними. Это помогает специалистам по данным мыслить нестандартно, а также мыслить более ясно.

Мы уже рассмотрели восемь ошибок, осталось еще четыре. Я не буду вдаваться в подробности. Ошибка номер девять может состоять в том, чтобы пропустить этап проверки концепции и MVP, чтобы сразу перейти к производству. Ошибка номер 10 — не определить требования к инфраструктуре до и во время разработки модели. Номер 11 переходит в производство до опытно-промышленной эксплуатации и экспертизы. Номер 12 — это не план систематического мониторинга моделей. Это очень важно, потому что, если вы не отслеживаете свою модель, данные будут дрейфовать, пока модель находится в производстве. Если нет механизма постоянного мониторинга вашей модели, вы не будете знать, когда модель начала отклоняться от своих первоначальных характеристик.