Типовой процесс разработки решений на базе ИИ и типовые ошибки при их внедрении

Как выглядит типовое ИИ-решение

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

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

• —  Если не будет бизнеса – то разработчики и дата-сайнтисты могут придумать классную идею, сделать ей феерический интерфейс, обучить точнейшие модели… но ведь только за интерфейс с ИИ «под капотом» денег не дают. Так что такое решение явно может уйти в историю, не оставив следа.

• —  Если не будет разработчиков – то решение рискует получиться слишком «костыльным». Т.е. бизнес рискует не понять, а что за самородок принесла команда дата-сайнтистов, поскольку он будет выглядеть как обычный булыжник (уж простят мне геологи такое сравнение – автор статьи никогда не держал в руке золотой самородок)

• —  Если не будет ИИ … но простите – это тогда уже не решение на базе ИИ, а просто разработка ПО.

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

Как выглядит типовой процесс разработки ИИ-решений

Таким образом, когда такое решение еще только планируется, стоит держать в голове, что одними только дата-сайнтистами все не обойдется. Как следствие – и процесс разработки решения не обойдется одними только ML-ными задачами вроде «подготовка данных», «обучение модели» и т.п. штуками из CRISP-DM (при всем моем уважении к этой методологии). И если немного обобщить и упростить типовой процесс разработки решений на базе ИИ, то получится нечто подобное:

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

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

2. 2. После этого можно переходить к ML/ИИ – здесь все традиционно для этого типа задач. Все по CRISP-DM – работаем с данными, обучаем модели, тестируем, снова обучаем до тех пор, пока не получим хорошие метрики.

3. 3. Вот только после того, как модель готова, рано переходить к деплою. Для начала стоит оценить эффект и получить подтверждение – а решена ли бизнес-задача (см. шаг 1). Надо провести пилот или А/Б тестирование или еще что-то подобное, оценить результаты и только потом уже идти дальше.

4. 4. И если эффекты от прототипа показали нужную бизнес-эффективность, то дальше по-хорошему, надо идти 3-мя путями параллельно (на самом деле, что-то можно начинать делать раньше, что-то позже, но это нюансы):

• —  Детальная проработка встройки решения в бизнес-процесс. Это аналитика как она есть. В результате ТЗ на разработку и единое понимание, как бизнес будет решение использовать.

• —  Разработка и интеграция решения в бизнес-процесс и инфраструктуру. По-хорошему, конечно же, надо сначала согласовать ТЗ, а только потом интегрироваться и встраиваться, но, право слово, многое можно начать делать в параллель.

• —  Вывод обученной модели в прод – на самом деле, для многих этот шаг не очень очевиден. Ну действительно – модель же уже есть? Есть. Работает? Работает. Так чего же еще надо? Но я бы сказал, что нужна инфраструктура, отражающая критичность для бизнеса результата этой модели. Нужен нормальный процесс подготовки и поставки данных, а не «костыль», который части делают на пилот. Нужны логи, нужен мониторинг качества почти всего – от данных до работы модели – в общем, много того, что отличает прототип от работы в проде.

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

Типовые ошибки при внедрении ИИ-решений

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

1. 1. Если с бизнесом договорились не столь детально, как стоило.

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

2. 2. Если данные собрали какие-то, то и результат получится «какой-то».

   Классика жанра – «мусор на входе – мусор на выходе», что уж тут добавишь.

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

   С одной стороны – это хорошо. С другой – нужен баланс. Баланс между приростом точности с одной стороны и сложностью пайплайна обработки данных, быстродействием и требованиям к ресурсам, сложностью поддержки в конце концов. И как искать этот баланс? Мой выбор – переложить точность в деньги. Т.е. высчитать какой экономический эффект принесет каждый процентный пункт точности модели. И тогда будет четко понятно, где тот самый компромисс между стоимостью и прибылью.

4. 4.  Частенько бывает, что новую «классную» модель выкатывают на прод, не проведя полноценных тестов ее работы на реальных данных.

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

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

   Чаще всего такое бывает, когда разработкой и внедрением занимаются чисто разработчики без участия бизнес-аналитиков. В этом случае они долго потом удивляются – а почему результатами работы такой классной модели никто не пользуется (а зачастую никто и не знает)? Корни этой ошибки кроются буквально на первом шаге – чем меньше бизнеса вовлечено в разработку с самого начала, тем сложнее потом монетизировать полученные результаты.

6. 6. Мониторинг – вспоминаются слова классика «как много в этом звуке для сердца русского слилось!». И ровно также часто про этот компонент все забывают. А ведь мониторить, как я уже говорил, надо многое:

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

   b. Чуть менее очевидное – данные на входе и результаты модели на выходе. И стоит контролировать не только то, что данные есть, но и оценивать их качество, полноту и наличие дрифта в данных. Это полезно, чтобы быть уверенными, что модель получает корректные данные, схожие с тем, что было на обучении. А также, что модель выдает корректный прогноз (банальная оценка распределения даст хотя бы минимальную уверенность в этом).

   c. Ну и рекомендация – мониторьте и оценивайте экономический эффект модели. Это поможет «продавать» результаты и автоматически рисовать красивые презентации для руководства.

7. 7. Ну и последнее по списку, но не по важности – выстроить полноценный пайплайн обработки данных.

   Не махнуть рукой «а, и так сойдет», а взять дата-инженера, собрать полноценный пайплайн с контролями качества и мониторингом (да, люблю я это дело) и обязательно не забыть про сбор данных для дообучения модели. Просто чтобы не возвращаться к этому вопросу каждый раз. Ну и небольшой совет – не забывать про версионность датасетов. Для разбора полетов потом очень пригодится.
   
   

В заключение

Подозреваю, что кто-нибудь скажет «да ладно, ну и зачем вся эта морока? Работает же и так. И никаких ваших типовых ошибок у меня нет!» В общем и целом, соглашусь – действительно, частенько работает «и так».

Но это повод задуматься либо бизнесу – а насколько устойчив получаемый результат или даже можно спросить по-другому – а как бизнес узнает, что результат уже давно не соответствует изначальной точности? Либо стоит задуматься разработчику – а насколько ценен получаемый результат для бизнеса? Мало ли случаев, когда результаты ML/ИИ просто игнорируется бизнесом и все работает по старинке, а разработчик и не в курсе – ну действительно, чего расстраивать хорошего человека.

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

Также читайте на Хабре.