Бих искал да твърдя, че определена работа или роля е по-важна, отколкото предполага днешният размер на нейните редици, и че нейната важност дори ще расте. Вече съществува объркващо множество работни места, свързани с данни и машинно обучение, така че първият въпрос е защо да имаме друга или каква е разликата тази?
Мотивацията зад моята мисъл е, че много компании изглежда се борят да се възползват от предимствата на данните с машинно обучение, въпреки че имат значителни отдели за тази цел и въпреки че има много напредък в техническите и научните области. Вероятно бих могъл да цитирам някаква Бяла книга за изследване на Magic Gartner Quadrant Harvard Business Review Thingy, наречена Business Not Reaping ML Benefits Enough, но ме мързи да го търся, вие ще бъдете твърде мързеливи да го прочетете и проучването вероятно ще бъде погрешно така или иначе . Искам да кажа, че всичко, наречено „Мегатенденции в Hype Cycle“ е някак си.
Така че нека просто останем на нивото на чистата мисъл и анекдотични доказателства.
Аспекти на ролите в машинното обучение
Типични изисквания за работа за списък с позиции в ML/Data умения с рамки за машинно обучение (Tensorflow, Keras) и обработка на данни (Pandas, Spark), университетска степен или самостоятелно придобито разбиране на теоретичната основа за машинно обучение и някакъв общ софтуер инженерни умения.
В различни случаи може да имате опит в академична публикация, да се фокусирате върху определена област (разпознаване на изображения, обучение за укрепване) или умения с някои облачни инструменти или рамки за внедряване.
По време на процеса на интервю кандидатът е помолен да реши някои проблеми с изкуствени данни и да демонстрира технически познания. Често това е придружено с шеговити забележки, че по-голямата част от работата е свързана със срещи и почистване на данни.
Нека сега поставим такава роля в контекста на бизнес цикъла. За опростяване считам, че жизненият цикъл на проектите (продуктите) се състои от:
- Идея - например разговор с потенциални клиенти, шпиониране на конкуренцията, мислене (извън кабината);
- Проучване — например правене на PoCs и макети, представяне на потенциални потребители, правене на пазарни проучвания;
- Внедряване — например разработване на действителен код;
- Поддръжка — например продажби, поддръжка на клиенти, наблюдение на облачна инфраструктура, коригиране на грешки.
Повечето от това, което разбираме като приложена ML работа, попада твърдо във фазата на внедряване — почистване на данни, обучение на модела, внедряване на модела. Има голяма част от дейността и в поддръжката (анализ на производителност/промяна на концепцията), обикновено означена като MLOps.
Понякога има дейност в Exploration (като разработване на PoC модел), но често в началото „няма достатъчно данни“. ML е много по-лесен за идея и внедряване, когато се подобрява над съществуващите евристични/човешки процеси.
Идеалната задача на практикуващ ML идва с пълна дефиниция на задачата (разпознаване на ръкописна цифра), критериите за приемане (граници на показателите за ефективност) — така че след това да могат да започнат да правят това, за което са били обучени, цялото инженерство на функции , избор на модел, настройка на хиперпараметър...
Ако по този начин ML трябва да донесе потенциал не само като постепенен подобрител на съществуващи добре дефинирани задачи (честота на кликване, отлив, …), но и разрушителна иновация, някой трябва да може да измисли проекти, които използват потенциала на ML и да ги формулира , или техните части, като проблеми с машинното обучение. И този човек трябва да е много запознат с бизнеса/клиентите. Понякога на отделите за машинно обучение се гледа като на черна кутия, в която се изсипват данни и иновациите изтичат навън – но това не се случва въз основа на моя ограничен опит.
Настоящото изследване на машинното обучение вероятно не се фокусира много върху дърветата на решенията или линейните регресии, тъй като те вече са „научно скучни“ — техният потенциал е разбран, най-добрите практики за тяхното използване са идентифицирани. Практикуващият може дори да избягва да ги използва и да прекарва време в фина настройка за конкретен проблем, вместо да използва някаква могъща генерична невронна мрежова архитектура, която обобщава много по-висок клас проблеми „сама по себе си“ или обещава публикация на хартия в допълнение.
И все пак вероятно остават много неизползвани бизнес възможности, които биха се задоволили само с основните методи. Наскоро реших две прости, но важни задачи, свързани с времеви редове и класификация/прогнози за потреблението на електроенергия, като просто наблюдавах на око какви характеристики и коефициенти може да използва линеен алгоритъм — и беше достатъчноза изискванията на бизнеса.
Еволюция на практикуващ машинно обучение
Абсолютно не твърдя, че чисто ML изследване не е необходимо или че всичко може да бъде решено с прости методи.
Но с подобренията в достъпността на ML или дори възхода на AutoML технологиите в предложения като Google Vertex, става по-малко важно за стартиращи компании или отдели за иновации да наемат експерти с дълбоки познания за различни методи за ML – ограничена интуиция на какво би могло/трябва да работи, разбирането как да се провери дали наистина работи, разбирането на ролята на етикетите, знанието кога да се обадите на истински ML експерт и т.н., може да е достатъчно.
Хората, които извършват фазата на идеята и предават изискванията на софтуерните инженери за изпълнение, обикновено се наричат продуктови мениджъри и UX дизайнери. Изискванията за техните работни места са значително различни от тези на ролите в машинното обучение - не много технически, а по-скоро за меки умения, представяне, съпричастност, стремеж, бизнес разбиране, …
Не звучи ли наивно, че очакваме по някакъв начин да се случи взаимно разбиране между ML Scientist и UX Designer? С традиционната разработка на софтуер някак си проработи – но ми се струва, че при най-ефективното сътрудничество всяка страна е познавала основите на занаята на другата.
И все пак, с машинното обучение ми се струва, че всички външни групи - разработчици на софтуер, продуктови мениджъри, ръководители - го третират като някаква тайнствена черна кутия. Също така, с разработването на софтуер — не се очаква често разработчиците на софтуер самите да донесат разрушителни идеи и иновации; вместо това те се разглеждат в най-добрия случай като партньори или конструктивни опоненти в процеса.
Различното третиране на машинното обучение е до известна степен оправдано — защото не винаги е лесно или просто. Следователно смисълът на моето мислене е, че специалната роля на продуктовия мениджър за машинно обучение ще придобие значение в близко бъдеще. Разбира се, не го измислям – Google Trends показва някои хитове още през 2014 г., с около трикратно увеличение през 2018 г. LinkedIn не предлага такава работа в моя район, но когато гледам Калифорния, виждам куп точно така наречени позиции от всички големи играчи (Meta, Amazon, Google, …). Други написаха статии с такова име, например „тук“ от август 2020 г. (и дори цитират изследване на PWC — не се колебайте да го прочетете).
Точното определение обаче не е важно – независимо дали първоначалният фон ще бъде управление на продукти или машинно обучение, необходимостта да се разбират и двете, както и желанието да се грижите и за двете, е това, което наистина има значение. Използвам ML Product Manager в тази статия — но ML Product Designer или ML Business Analyst също можеха да бъдат използвани, каквото и да е. А за специализирани области (здравеопазване, физика, …) експертът по домейн е по същество премиерът.
Заключение
Ако сте в компания, която очаква да се възползва от отдела за машинно обучение, попитайте - кой е човекът, който свързва световете? Кой може да формулира проблеми като ML, като в същото време може да прецени дали дадено решение е достатъчно/полезно изобщо за бизнеса?
Ако трябва да посочите комбинация от PM човек плюс ML човек — може да се окаже, че на вашата компания липсва връзка.
Разбира се, има и други подходи, като например да нямате изобщо отдел за машинно обучение и по-скоро да разпръснете практикуващите ML сред продуктовите екипи и да третирате ML просто като друг инструмент за решаване на проблеми в инструментариума за разработка на софтуер; и правете иновации с мислене без инструменти. Идентифицирането кой от тези двама е по-подходящ за вашия случай, не е лесно нещо.
Може би правилният начин за ML е да премести своя експерт от общите бизнес компании и да ги превърне в работещи на свободна практика или фокусирани върху ML компании за наемане, които също работят като изследователски лаборатории; и оставете само общи познания „каква е типичната сила на ML“ сред PM-овете и изпълнителните директори и общи знания „как да се обучава готовият модел“ сред обикновените SW инженери (изглежда доста амбициозно „пълно- stack dev” вече е измислен). В смисъл на теория на категориите това отразява случилото се с предложенията на PaaS или това, което тепърва може да се случи с No Code.
