Чему ИИ-стратеги могут научиться из истории разработки программного обеспечения?
За последние несколько лет проникновение ИИ и машинного обучения значительно продвинулось вперед. С ростом внедрения ИИ умножились и проблемы, связанные с администрированием моделей ИИ. Большинство крупных организаций, не рожденных цифровыми, разрешили множество экспериментов с ИИ по всей организации. Из моих бесед с лидерами отрасли и коллегами-профессионалами я вижу много общих проблем, таких как модели, построенные на различных платформах/инструментах, которые оказываются сложными в обслуживании; Несмотря на то, что некоторые модели/функции могут использоваться в разных процессах, их использование ограничено создателями; Многие модели в производстве оказываются избыточными, поскольку они не соответствуют первоначальной цели.
«Модели перерастают создателей!»
«Больше навредить, чем помочь»
На этом фоне давайте немного вернемся к истории разработки программного обеспечения. Важными вехами, которые сыграли ключевую роль в определении сегодняшней зрелости разработки программного обеспечения, были: а) установление общих стандартов кодирования — укрепление доверия к коду; б) создание независимой группы обеспечения качества для тестирования стандартов и самого тестирования; в) определение гибких методологий для масштабирования; d) Объединение разработки и ИТ-операций для эксплуатации и обслуживания с помощью DevOps. Учитывая, что мир действительно впервые переживал беспрецедентную трансформацию технологий, потребовалось почти 30 лет, чтобы достичь такого уровня зрелости.
Для некоторых из нас, кто прошел через эту историю, сходство с путешествием к зрелости AI/ML ощутимо. Однако у нас не так много времени, как на этапе бума разработки программного обеспечения. Рост ИИ был быстрым, и текущая ситуация с COVID потребовала молниеносных темпов для его зрелости и масштабирования.
Давайте попробуем рассмотреть некоторые ключевые вопросы, с которыми сегодня сталкиваются директора по данным, и почерпнуть ответы из истории SDLC. Как упоминалось ранее, индустрия ИИ совершила скачок. Так что проблема не в том, чтобы установить необходимость в нем или доказать его ценность. Вопрос в том, чтобы из «суммы частей» создать «целое»!
а) Укрепление доверия к Кодексу:
Имея доступ ко многим библиотекам с открытым исходным кодом для создания алгоритмов, разработка прогностических моделей, помогающих упростить бизнес-решения, в наши дни относительно проста. Что еще сложнее, так это построить долгосрочное доверие к этим моделям среди пользователей, руководства, клиентов и регулирующих органов. Есть несколько кандидатов, участвующих в моделях ML, чтобы вызвать необходимое доверие. Модель сложнее, чем просто программный код, в том смысле, что это код + данные + алгоритм. Чаще всего при построении моделей основное внимание уделяется данным и алгоритму, в то время как самому коду не придается такого большого значения, поскольку необходимо доказать, что модель более интересна, чем лежащий в ее основе код. Чтобы вернуться к нашему сравнению с опытом разработки программного обеспечения, на начальных этапах основное внимание и здесь уделялось доказательству того, что программное обеспечение может хорошо соответствовать требованиям функциональности, а не обеспечению соблюдения дисциплины для создания кода с высокими стандартами.
Урок 1. Не игнорируйте код в моделях машинного обучения. Это делается для того, чтобы код по своей сути не допускал компромиссов, таких как угрозы безопасности или проблемы совместимости. Обеспечьте документирование каждого этапа жизненного цикла модели.
b) Обеспечение качества ИИ:
Тестирование систем на основе AI/ML может быть сложным. Традиционные методы тестирования не работают в системах на основе AI/ML. Существует несколько уровней тестирования, которые необходимо запланировать. Тестирование базовой модели, которое называется валидацией, — это то, что специалист по данным обучен делать хорошо. Однако дьявол может скрываться в данных или может возникнуть при применении вывода модели к действию. Начиная с данных, понимание и создание соответствующих стратегий тестирования для данных является ключевым. Вещи, которые необходимо извлечь из данных, могут быть предвзятостью или выбросами. Соответствующие методы их обнаружения и обработки перед построением моделей будут иметь решающее значение. Может быть хорошей идеей иметь системы искусственного интеллекта с помощью человека для проверки человеком параллельно с критически важными системами на основе машинного обучения, чтобы избежать любого неблагоприятного воздействия.
Вывод №2. Тестирование систем на основе AI/ML намного сложнее, чем программных систем на основе правил. Стратегия тестирования должна быть как можно более сложной с учетом данных, кода и лежащего в основе алгоритма.
c) Методологии гибкой разработки моделей
Agile — это включение обратной связи из реального мира в итеративную разработку. Модели машинного обучения уже построены на реальных данных. Поэтому мы часто слышим, как специалисты по данным упоминают, что проекты AI/ML отличаются друг от друга и не могут навязывать им такие концепции, как Agile. Что ж, модели машинного обучения действительно построены на реальных данных. Однако вопрос о том, были ли включены правильные данные (признаки) или были ли обработаны несоответствия данных (предварительная обработка), может быть не очевиден сразу. Особенно, если точность модели высокая — это может ввести в заблуждение. Таким образом, чем раньше система будет передана в руки пользователю для тестирования, тем лучше для создания заслуживающих доверия систем ИИ. Кроме того, несмотря на то, что модель лежит в основе систем искусственного интеллекта, остальные этапы процесса все равно необходимо проверить на угловые условия. Итак, вовлекайте пользователей в проекты ИИ на ранней стадии и внедряйте гибкие методологии, чтобы принести пользу проекту.
Урок № 3. Agile подходит не только для разработки программного обеспечения, но и для систем искусственного интеллекта, в основе которых лежат модели машинного обучения. Это поможет определить любые необходимые дополнительные этапы предварительной обработки или определить состояние углов на ранней стадии.
d) MLOps для масштабирования:
Управление несколькими моделями, созданными разными командами, — непростая задача. Традиционно сбором всех данных из разных источников занимались ИТ-специалисты. В то время как специалисты по данным больше ориентируются на бизнес-функции, понимают области воздействия и строят прогностические модели для улучшения процесса. В то время как в идеальном мире рукопожатие между специалистами по данным и ИТ-командами было бы безупречным, реальность такова, что специалисты по данным, имеющие исследовательский опыт, мало понимают в огромном мире технологий, и наоборот.
В результате модели, показавшие большую ценность в соответствующих процессах, не могут создать ценность для организации. Классический пример несостоявшегося правила: целое больше, чем сумма частей! Чтобы построить корпоративную стратегию ИИ, важно внедрить MLOps. Необходима интеграция конвейеров данных от ИТ к внедрению CI/CD с помощью группы ИТ-операций — уроки, извлеченные из внедрения DevOps.
Урок № 4. Внедряйте MLOps, чтобы собрать воедино все части и извлечь большую пользу для всей организации из проектов ИИ.
Хотя ИИ, безусловно, развивается очень быстрыми темпами, сам этот темп может создавать множество различных проблем. Некоторые из этих проблем могут быть более сложными, чем те, с которыми мы сталкивались в прошлом, но я верю, что многие из них можно активно решать с опытом. Хотелось бы узнать, действительно ли из истории разработки программного обеспечения можно извлечь больше уроков, которые можно применить для надежного масштабирования ИИ.
