Как запустить MVP в проекте с машинным обучением

МЕНЮ


Искусственный интеллект
Поиск
Регистрация на сайте
Помощь проекту

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


2020-09-02 10:15

it новости

AI Community в рамках проекта AI Heroes регулярно проводит вебинары с ведущими экспертами в области Data Science.

На очередном вебинаре основатель Vision Systems Максим Савченко и руководитель группы анализа данных Роман Штейнберг рассказали, как запустить MVP в проекте с машинным обучением и каких ошибок можно избежать заранее.

Смотреть все материалы серии

Как запустить MVP в проекте с машинным обучением

MVP — продукт, обладающий минимальным необходимым набором возможностей. 

Главное, что нужно знать об MVP, — это цель, ради которой его запускают.

Цели могут быть следующими:

  1. Проверить технологическую гипотезу. Например, понять, получится ли распознавать определенный объект или действие с точностью выше или сравнимой с человеческой. 
  2. Побудить компанию к запуску ML-проекта и созданию для него инфраструктуры для анализа данных. Показать, что возможно переиспользование данных и создание на их основе дополнительной ценности.
  3. Проверить маркетинговую гипотезу. Например, будут ли клиенты пользоваться условным чат-ботом или нет.

От этих целей зависит, каким должно быть решение, чтобы считаться MVP. 

Базовая проблема MVP в машинном обучении в том, что в большом количестве случаев проверяется не маркетинговая гипотеза, а технологическая.

При проверке технологических гипотез бюджет выделить готовы, если заказчик будет уверен, что продукт сработает. Чтобы убедить заказчика, надо сделать работающую ML-модель. Чтобы сделать такую модель, нужно иметь бюджет той стадии, когда заказчик уже поверил, что это будет работать.

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

Упаковка MVP

Критерии приемки и дизайн метрики качества, или как совместить логику и психологию

Метрика качества — это некий компромисс между командой разработки и бизнес-заказчиком. От ее формулировки напрямую зависит сложность и трудоемкость проекта. 

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

Без соблюдения этих условий на старте переговоры могут затянуться на месяцы или провалиться, а срок разработки — вырасти в несколько раз.

Пример из одного из проектов 

Заказчик верит в качество MVP в 70%. При этом команда разработки считает, что без ограничений может вывести модель на качество в 60%. При этом при хороших «погодных условиях» модель будет показывать качество значительно выше 70%. Довести модель до общего качества в 70% — это плюс три месяца к разработке. 

В итоге в договоре появилась строчка про качество модели в 70% за исключением условия «плохой погоды». При этом первоначальное предложение про 60% качества в любых условиях было более трудоемко для команды и хуже интерпретируемо заказчиком. Это может казаться банальным, но в таких мелочах вся «соль».

Как выстроить взаимоотношения с заказчиком в R&D-проектах

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

На практике коллеги из Vision Systems показывали такие ценности, дополняющие основной проект:

  • Репутационная ценность

Например, банки и представители других отраслей крупного бизнеса регулярно проводят отраслевые конференции. Если показать на такой конференции прототип новой разработки, это будет иметь ценность для представителей организации и иногда может окупить весь бюджет на MVP.

Пример использования MVP на выставке. Стенд Сбербанка. MVP по созданию системы оценки удовлетворенности клиентов в офисах обслуживания на основании анализа их эмоций.

  • Внутренний консалтинг

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

Сделать MVP не равно запустить его

Это может не осознаваться на старте, но MVP не имеет ценности, если им будет слишком сложно воспользоваться. Формула такая: новый продукт на базе ML — это уже сложность, если его еще сложно протестировать, то велик риск, что топ-менеджмент не оценит его перспективы и отложит в бэклог. 

Например, когда Сбербанк запускал терминалы для самообслуживания, они бы не приносили никакой ценности без консультантов, которые первое время учили ими пользоваться (и даже сейчас помогают, но уже меньше). То есть MVP — это был не просто терминал, а терминал + консультант. 

Вывод: нужно всегда закладывать удобный интерфейс для MVP либо другую возможность легко и понятно «пощупать» ценность. 

Как ускорить запуск MVP в три раза

При запуске нового проекта до 90% времени занимает проработка инфраструктуры. Использование наработок может сократить время на запуск MVP до трех раз.

  1. Внутренний фреймворк по определенному направлению машинного обучения. У компании, которая специализируется в рамках одного из направлений ML, должны возникать собственные инфраструктурные наработки. Например, часть пайплайна обработки изображения при детекции «котика» может быть переиспользована при распознавании и фиксации событий в видеоконференцсвязи.
  2. Наработки в инсталляции системы. Часто ML для корпоративных клиентов связан с «железной» инфраструктурой, и можно иметь инструменты, позволяющие быстро его запускать на почти любом «железе». Коллеги привели в пример упаковка ML-сервисов в ISO-образы взамен docker. Решение позволило продвинуться в нескольких проектах.
  3. Один интерфейс. Приходится использовать разные библиотеки, которые по-разному используются в коде. Удобно написать единый интерфейс поверх часто используемых библиотек в компании. Это позволит унифицировать разработку и сэкономить на каждом проекте десятки часов. А если проект требует, например, больше пяти различных моделей, это уже сотни часов.

Как сэкономить время заказчика

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

Сэкономить время заказчика на сбор можно при помощи таких подходов:

  1. Синтетическая генерация с помощью элементарных составляющих. Допустим, у нас есть 100 картинок (товары на полках). Вам нужно сгенерировать визуальное изображение полки с товарами. Можно взять несколько полок и вставлять изображения, которые у вас есть. Такой подход может быть применим к разным историям. На выходе в одном из кейсов получили 60 тысяч изображений из 100 реальных картинок. При этом точность получившейся модели удовлетворила заказчика — и MVP ушло в развитие.
  2. 3D-моделирование. Например, аварии на дорогах. Проще использовать 3ds MAX, подготовить автомобили, применить скины и симулировать процесс столкновений. Получаем изображения с разных ракурсов и направлений камер.
  3. Размеченный открытый датасет. Например, готовый датасет, которым все пользуются. Но здесь следует быть внимательными и осторожными.

Чистка данных

При фильтрации 30% изображений можно увеличить качество модели на 15%. Эти же 15% качества можно было получить путем 2–4 месяцев разработки. Часто коллеги используют датасеты в их первоначальном виде.

Для чистки данных также есть платные сервисы. Можно взять неразмеченные данные и отдать сервису, а дальше учить свою модель.

Итого: на стадии MVP у заказчика зачастую нет нужных данных или они не в том формате. Сопровождайте и помогайте ему со сбором — это ускорит процесс запуска MVP. 

Open Source

Все компании поняли, что только на свои решения, разработанные с нуля, опираться нельзя. Поэтому в вашем проекте будет наследие open source.

Ребята ведут таблицу с колонками: статья, репозиторий на гитхабе, качество, год, комментарии, количество точек. По всем колонкам проверяют найденный слот и думают, работать дальше с этим материалом или нет. 

Далеко не все, что написано, работает. Максим и Роман делятся несколькими проектами на гитхабе от других разработчиков, которые считают качественными и применяли в продакшн-решениях:

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

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

Последовательность действий:

  1. Берете с рынка проект, который касается создания инфраструктуры сбора данных.
  2. Дальше в качестве внутреннего R&D и за счет прибыли от инфраструктурного проекта предлагаете заказчику эксперимент с какой-нибудь простой ML-задачей по уже собираемым данным.
  3. Сравниваете результат с open source. Разбираетесь в теме.
  4. В итоге получаете экспертизу, достаточную для создания собственных решений с «подмешиванием» к ним open source.

Зачем ML-команде нужен UX-дизайн и почему сделать библиотеку будет недостаточно

Для UX-дизайнера есть два важных направления в команде:

  • Подача данных. Заказчики предпочитают метрики в виде визуализации и графиков. Отчет непонятен, а наглядная визуализация снимает головную боль заказчика. Наймите дизайнера для интерпретации данных. История с графиками успешнее, чем сухие цифры. А визуальный интерфейс/конструктив в ряде проектов опережает графики.

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

  • MVP делается с компромиссами и ограничениями. Некоторые моменты можно решить через дизайн-эффект. Например, при размытии фона в видео для ВКС проблемным местом является точность границы среза между изображением человека и задним фоном. Но можно создать дизайн-эффект, который загримирует эту зону. Вместо задачи сроком около года вы получаете задачу нескольких недель. Либо новые функции, которые возникают на базе ML, диктуют и новый интерфейс, потому что привычным пользоваться уже не удобно
Но UX-дизайнер не знает, что делается долго и дорого, а что — быстро. Для этого нужна коммуникация между инженером и дизайнером.

Как достичь максимума

Если хотите сделать запуск MVP для ML-проекта максимально быстрым и предсказуемым, стоит использовать описанные выше практики и определиться, каким путем идти:

  1. Нанять сильного человека с рынка, и он соберет команду. Экономить на таком лидере проекта точно не стоит, если по какой-то причине аутсорс не подходит с самого начала. И так по каждому направлению.
  2. Нанять аутсорсера, который специализируется на тематике, максимально близкой к технологической гипотезе, и в процессе работы перенимать компетенции. В итоге, если проект «выстрелит», у вас будет человек, который в него погрузился и который может помочь сделать результат труда «отделимым» от компании-подрядчика. Вокруг этого человека уже будет оправдано выстроить новый отдел, который сможет дальше самостоятельно развивать продукт, если возникнет необходимость перенести все в in-house.

    Аутсорсинг на этом этапе роста будет полезен тем, что позволит гибко закрывать возрастающие объемы работ, под которые еще не наняты подходящие люди во внутреннюю команду. 

Фото на обложке: Zapp2Photo / Shutterstock 

Источник: rb.ru

Комментарии: