Обновить

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

Время на прочтение8 мин
Охват и читатели3.8K
Всего голосов 3: ↑2 и ↓1+1
Комментарии7

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

Являюсь research lead и впринципе согласен практически со всем что написано. Но есть у меня личные наработки:
1) дважды в неделю команда рассказывает подробно свои успехи за период. На этой мини конфе мы фактически заполняем квадрат, только это делает команда целиком
2) исследования в ширину — на каждую задачу формируется список научных работ и проверяются все методы описанные в работах. Потом к первому пункту обращаемся и делаем вполне себе точный прогноз на решение задачи
3) приоритет на алгоритмы, а не на нейронки. Всё-таки нейронки пока являются жутким черным ящиком и предсказать их результат можно только по верхней границе( не лучше чем разметка). Плюс если решение на алгоритмах то есть техники которые позволяют делать очень тонкие настройки.

НЛО прилетело и опубликовало эту надпись здесь

Вы правы, но тут имеется ввиду оценка прогресса бизнесом, а не инженерами. Условно, сравривать гамбургер с калориями.

Проблема в том что люди недооценивают скучную но очень сложную часть приведения потокового видео к инпуту сети, обязательно помимо чистого ML иста надо нанимать в командну на полную катушку видеопрограммиста.

В целом, я согласен, что такой инженер даст большой профит, однако ценность его не в том, как мне кажется. Ровно как и специалиста по камерам и оптике...

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

Для меня любой программист = инженер. Вы же используете инженер = низкоквалифивированный специалист, техник. В моем лексиконе это не имеет таких оттенков.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации