Уже полтора года я занимаю у себя в компании позицию основного ML-разработчика. Полгода управляю небольшой командой. Я накопил опыт, которым хочу поделиться. Делать это буду в формате топа заблуждений и потенциальных трудностей.
Хотим нейросеть!
Очень многие сейчас слышали хоть что-нибудь об искусственном интеллекте и достижениях нейронных сетей. Некоторые хотят использовать в бизнесе нейросети уже только потому, что это популярно. Вот вы решили какую-нибудь небольшую задачу по анализу текста и уже смело можете заявлять всем подряд, что в вашем бизнесе используются самые современные технологии искусственного интеллекта.
При этом практически никто не понимает сильных и слабых сторон нейронных сетей. Ведь из-за высокого ресурсопотребления они далеко не всегда являются оптимальной моделью.
Довольно часто алгоритмы вроде бустинга, k-ближайщих соседей или svm могут показывать более высокие показатели качества в решении бизнес-задач (если речь идет о классическом сценарии фичи -> значение), чем нейронные сети. Это при том, что они гораздо более легковесные.
Если клиент говорит вам: «Нам нужна нейросеть для решения такой-то задачи», то скорее всего он просто не знает, какими именно инструментами эту задачу лучше решать. Но ему кажется, что тут нужны какие-то сложные алгоритмы и единственное, что приходит ему на ум — это нейронная сеть.
Так что вы можете решить задачу и через какую-то более лайтовую модель.
Звучит очевидно, но на деле после такого запроса от клиента вы можете потратить время на перебор различных архитектур нейронных сетей прежде чем поймете, что задачу можно было решить гораздо проще.
Утром данные, вечером эстимейты
Довольно часто вас будут просить дать сроки по выполнению экспериментов/выкатыванию решения в прод. Причем в качестве основы для таких эстимейтов могут предоставить лишь абстрактное описание задачи. Например: «Мы хотим нейронную сеть которая будет по медицинским снимкам ставить человеку диагноз заболевания. Сколько времени это займет?». Люди не работавшие с МЛ(а иногда и работавшие) слабо понимают концепцию экспериментов. Многие подходят к разработке МЛ решения как к разработке стандартного ПО. Но это все ошибки. ML-разработка ближе к науке чем к разработке (особенно на начальных этапах). Большую часть времени требуется на анализ данных и эксперименты. И люди редко это понимают.
Если вам повезет и у вас будет например опытный менеджер проекта, то вам не придется иметь дело с такими проблемами. Он сам объяснит всё заказчику. Но бывает и наоборот — когда менеджер сам слабо понимает специфику ML, прогибается под клиента и на пару с ним начинает вас пинать требуя сроки через пару дней или неделю после получения запроса от клиента. Иногда даже до получения данных. Тогда, вам скорее всего придется назвать какие-то сроки(ну или поменять место работы, что тоже неплохой вариант в такой ситуации). Но будьте осторожны если всё же решите делать оценку сроков без достаточного количества информации. Выделите время на эксперименты с запасом.
Точность модели в предварительном эксперименте 99.99999%
Даже если на предварительных экспериментах или при испытании прототипа вы получили высокие значения метрик, это не повод сразу сообщать их клиенту. Но все, что вы скажете, может быть использовано против вас.
Если вы получили высокие значения оценок качества модели на предварительных экспериментах, можно сказать клиенту, что задача однозначно решаема, но заранее радовать его цифрами, которые могут оказаться не такими хорошими на новых порциях данных, не стоит. Либо же можно назвать метрики, но с обязательной оговоркой, что вы не можете гарантировать, что в других условиях качество останется таким же. Оно может как улучшиться, так и ухудшиться. Всегда остается вариант что вы банально ошиблись при выполнении экспериментов (неправильно написали генератор например и часть данных утекла из обучения в тест).
Как вариант, вы можете фиксировать разную оплату в контракте для разного финального качества вашей модели.
Вообще говоря, люди обычно доверяют конкретным примерам больше, чем абстрактным цифрам. Небольшая демонстрация работы вашей модели придаст клиенту больше уверенности, чем заявления о 99% точности.
Если вы решаете задачу, например, детекции/классификации средствами сверточной нейрости и настало время писать репорт о успехах команды за условный период, потратьте лишние 30 минут и сделайте пару красивых картинок: поиграйтесь с визуализацией сверточных фильтров на высоких уровнях абстракции или скрытых полносвязанных слоёв, сделайте тепловые карты классов и т.д.
С серверами проблем не будет
В какой-то момент начинал замечать, что работа модели часто упирается в её размеры. Например, когда тебе нужно сделать классификатор на 5 миллионов классов, даже самые простые модели могут оказаться слишком ресурсозатратными. Тогда естественным образом встает вопрос спецификации сервера, на что клиент может отмахнуться чем-то вроде: «С серверами проблем не будет — выберем что-нибудь на облачных сервисах».
Проблема в том, что он может совсем не представлять масштабов модели. Например, датасет будет весить 2 терабайта, а матрица весов обученной модели еще 500гб. Чтобы юзать такую модель, вам нужно 68-128 гб оперативной памяти. Снимать такую машину может стоить клиенту от нескольких тысяч, до нескольких десятков тысяч долларов в месяц (если ещё GPU будут нужны). И вот тут уже не многие согласятся оплачивать такие сервера.
Комментарии (2)
ZlodeiBaal
04.12.2019 03:46+2Некоторые хотят использовать в бизнесе нейросети уже только потому, что это популярно.
Проблема в том, что люди хотят использовать нейросети только потому что «популярно», или потому что «начальство требует». Видел это в десятках проявлений. «Цифровизация бизнеса», «развитие продукта», и.т.д.
Я бы не советовал брать такие проекты вообще. Проект можно брать только когда он идёт от реальной проблемы или хотя бы от гипотезы и её проверки. Тогда будет реальная работа и проект. Остальное — это раскрутка заказчика на деньги. Мерзко и некрасиво.
«Нам нужна нейросеть для решения такой-то задачи»
Если клиент может чётко обозначить проблему — это уже хорошо. Но я такое видел достаточно редко. Приходит и говорит «нам нужно распознавание того-то с такой точностью». И 99% проблемы в том чтобы объяснить заказчику что такая постановка задачи может вообще не существовать. Потому что даже человеческая разметка по тому датасету даст 70%) Я как то даже на эту тему тут статью писал.
«Мы хотим нейронную сеть которая будет по медицинским снимкам ставить человеку диагноз заболевания. Сколько времени это займет?»
Вот это хороший пример, кстати. В большинстве случаев проблема не в точности. А в том что врачи одинаковый диагноз поставить не могут обычно. По КТ, Мамографии, Флюрке, и.т.д, и.т.п. Вот и появляются на рынке 100-500-800 стартапов которые распознают мамографию на 91%. Но только внедрить это никуда нельзя, так как существующие инфраструктуры/методы работы врачей/техника — для этого не предназначена. Опять же, писал про это.
С серверами проблем не будет
Знаете. У нас в год 7-8 проектов по ML. И ни разу не было проблем в этой части. Там все риски очень хорошо считаются и расписываются. Обычно все риски лежат в плоскости «удастся ли портировать с приемлемой точностью оставаясь в рамках допустимой скорости или нет». И это просто реализуется как отдельное исследование.
Нигде никогда не видел подходов где бы нельзя было заранее всё оценить.
И, если честно, сложно представить выход на 5 миллионов классов, где бы нельзя было сделать эмбединг и искать уже в пространстве эмбедингов на инференсе. Но может чего-то не знаю.
gleb_l
Очень правильный пост! Поспорить можно разве что с
— никогда качество работы fuzzy-logic систем in vivo не будет лучше, чем in vitro — это фундаментальное неравенство, связанное с отношением многообразия бесконечного множества и его конечного приближения.Еще несколько заметок из практики (часть выводов из них вполне может принадлежать КЭПу, но тем не менее, пропускаются они в acceptance документах все равно часто)
1. Если хотя бы в одном из звеньев разрабатывамой системы есть ML/AI-компонент, то детерминированность поведения всей системы нужно тщательно отследить и вымарать из всех приемочных документов, а вместо нее постулировать:
a). качество выполнения бизнес-функции не хуже X при условии Y в не меньшем, чем Z проценте случаев
b). параметры X и Y сопроводить эталонным корпусом данных, кросс-валидация наборов которых дает соблюдение условия a).
c). обязательно указать, что в полевых условиях показатели могут быть меньше, задав статистическую (не жесткую) нижнюю границу X для типичного полевого набора Y.
d). обязательно описать внешние условия, влияющие на п.4 (например, замена ламп освещения помещения с накаливания на ртутные может привести к существенному снижению X для алгоритмов распознавания изображений, или необходимости их перетренировки)
2. (Это в основном относится к фазе ТЗ) Если в качестве ML/AI-движка используется внешний/закрытый/облачный/3rd-party engine, заявленные характеристики качества работы которого не лучше X, наивно полагать, что путем пред- и постобработки его результатов, или комбинации энджинов этого типа удастся получить результат, существенно больший X. Исключения здесь есть, но они происходят в основном за счет сужения общих условий к частным (например, сузив словарь распознавания voice-to-text, можно повысить его качество). Поэтому при составлении ТЗ нужно быть очень внимательным, и даже осмотрительно прописывать «насквозь» характеристики разрабатываемой системы из характеристик ее ML-энджина, а тем более, не завышая их, надеясь на воркэраунды, или специально подобранный корпус тестовых данных — на полевых испытаниях, а тем более, в продакшене, мать-природа положит вас на лопатки с вашими 146% Чурова, и отвечать за невыполнение бизнес-функции, или, как минимум, приставлять к системе постоянно «подкручивающего» инженера придется вам