Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 2
Очень правильный пост! Поспорить можно разве что с
Еще несколько заметок из практики (часть выводов из них вполне может принадлежать КЭПу, но тем не менее, пропускаются они в 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% Чурова, и отвечать за невыполнение бизнес-функции, или, как минимум, приставлять к системе постоянно «подкручивающего» инженера придется вам
… Либо же можно назвать метрики, но с обязательной оговоркой, что вы не можете гарантировать, что в других условиях качество останется таким же. Оно может как улучшиться, так и ухудшиться— никогда качество работы 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% Чурова, и отвечать за невыполнение бизнес-функции, или, как минимум, приставлять к системе постоянно «подкручивающего» инженера придется вам
Некоторые хотят использовать в бизнесе нейросети уже только потому, что это популярно.
Проблема в том, что люди хотят использовать нейросети только потому что «популярно», или потому что «начальство требует». Видел это в десятках проявлений. «Цифровизация бизнеса», «развитие продукта», и.т.д.
Я бы не советовал брать такие проекты вообще. Проект можно брать только когда он идёт от реальной проблемы или хотя бы от гипотезы и её проверки. Тогда будет реальная работа и проект. Остальное — это раскрутка заказчика на деньги. Мерзко и некрасиво.
«Нам нужна нейросеть для решения такой-то задачи»
Если клиент может чётко обозначить проблему — это уже хорошо. Но я такое видел достаточно редко. Приходит и говорит «нам нужно распознавание того-то с такой точностью». И 99% проблемы в том чтобы объяснить заказчику что такая постановка задачи может вообще не существовать. Потому что даже человеческая разметка по тому датасету даст 70%) Я как то даже на эту тему тут статью писал.
«Мы хотим нейронную сеть которая будет по медицинским снимкам ставить человеку диагноз заболевания. Сколько времени это займет?»
Вот это хороший пример, кстати. В большинстве случаев проблема не в точности. А в том что врачи одинаковый диагноз поставить не могут обычно. По КТ, Мамографии, Флюрке, и.т.д, и.т.п. Вот и появляются на рынке 100-500-800 стартапов которые распознают мамографию на 91%. Но только внедрить это никуда нельзя, так как существующие инфраструктуры/методы работы врачей/техника — для этого не предназначена. Опять же, писал про это.
С серверами проблем не будет
Знаете. У нас в год 7-8 проектов по ML. И ни разу не было проблем в этой части. Там все риски очень хорошо считаются и расписываются. Обычно все риски лежат в плоскости «удастся ли портировать с приемлемой точностью оставаясь в рамках допустимой скорости или нет». И это просто реализуется как отдельное исследование.
Нигде никогда не видел подходов где бы нельзя было заранее всё оценить.
И, если честно, сложно представить выход на 5 миллионов классов, где бы нельзя было сделать эмбединг и искать уже в пространстве эмбедингов на инференсе. Но может чего-то не знаю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подводные камни в управлении Machine Learning проектом