Инвестирайте минути, за да спестите евентуално милиони на вашата компания

Въведение

Хиляди лидери на компании са се влюбили в данните – отчасти защото има толкова много от тях, отчасти поради потенциала на науката за данни и машинното обучение (ML), за които се пише в бизнес пресата, и отчасти защото знаят, че има стойност в данните но те не са сигурни какво да правят с всичко това или как да го извлекат и то просто продължава да расте експоненциално (Redman, Знае ли вашата компания какво да прави с всичките си данни?, 2017 г.). И все пак, според скорошно проучване на Gartner, 85% от проектите за наука за данни се провалят. Защо? По-конкретно, как вашата компания може да бъде в 15% (Walker, 2017)? Индустриалната литература е пълна с някои причини от типа на здравия разум: неадекватни данни (Asay, 2017), технология за самата себе си вместо двигатели на печалбите и ключови показатели за ефективност (KPI) (Taylor, 2017), лоша комуникация (Taylor, 2017) , недостатъчна изпълнителна подкрепа (Taylor, 2017), прекалено усложняване (Veeramachaneni, 2016) и твърде тесен фокус на проблема (Veeramachaneni, 2016).

Въпреки това, като учен по данни и организационен лидер, възниква въпросът дали това са само симптоми, а не това, което разболява проектите за наука за данни. Какви са техните първопричини? Има ли метапроблеми нагоре от тези последствия надолу по веригата, така че ако тези източници на „болест“ бъдат идентифицирани и адресирани, симптомите са предотвратени и проектът за наука за данни/ML остава здрав?

Основените причини за успехите и неуспехите в науката за данните

1. Разнообразие на екипи — Екипи с различни функции —В средата на 90-те години на миналия век първата ми работа след университета беше работа за първата в света глобална телекомуникационна компания от край до край точно когато интернет — и следователно трафикът на данни — беше преживява метеоритен растеж. Тъй като бяха подписали договори за 700 милиона долара с 2000 клиенти в 40 държави въз основа на минимални споразумения за ниво на обслужване (SLA) за качество на данните, беше изключително важно да се предвидят пропуски в качеството на данните, които договорно биха предизвикали финансови санкции достатъчно рано, за да се направи нещо, което да ги предотврати. За да направят това, те трябваше да създадат многоизмерни потоци от данни с качество на предаване, да ги съхраняват в хранилище за данни, след което да разработят персонализирани инструменти за автоматично анализиране, прогнозиране и предупреждение, когато тип услуга и област ще ударят SLA с достатъчно предупреждение, за да го предотвратят , като по този начин гарантират удовлетворението на своите многонационални клиенти и собствената си доходност чрез избягване на санкции.

Този успешен многогодишен проект почти избухна на стартовата площадка поради една от същите причини, поради които проектите за наука за данни се провалят – те погрешно предположиха, че програмист, който владее няколко езика и инструменти, може: (а) да направи всичко с тези няколко инструмента; и (б) да разберете всички други елементи — успешно идентифициране на изисквания, технически стратегии, статистика, потребителско изживяване, осигуряване на качество, обучение и доставка.

Има аналогии. Представете си да наемете талантлив готвач на сладкиши, който да развие ресторанта ви - би могло да се справи много добре с участието на звезден готвач на сладкиши, но който ще създаде други видове храни, ще разработи менюта, ще създаде и увеличи максимално изживяването при хранене, ще обслужва посетителите, ще популяризира и рекламира ресторанта, управлявайте финансите и т.н. Или си представете, че искате да построите имение с опитен дърворезбар. Докато дърворезбите може да са превъзходни, кой ще развие мястото и ще ориентира сградата най-добре, ще я архитектира, ще получи одобрение за разрешителни, ще разработи системите, ще направи зидарията, покрива, остъкляването, озеленяването и ще я украси?

Така формулиран, отговорът изглежда очевиден: дори изключително талантливи програмисти, работещи сами, вероятно няма да успеят да предложат голяма инициатива в областта на науката за данните, защото изисква по-голямо разнообразие от междуфункционални умения и таланти. Цитирайки водеща консултантска компания за машинно обучение, „един специалист по данни трябва да има бизнес прозрения, да разбира математиката зад данните и да работи в тандем с опитен разработчик“ (Tereschenko, 2017). Въпреки че теоретично е възможно да се предвиди специалист по данни с баланс на знанията между много функции и инструменти, в реалния живот те са като еднорози – много трудни за намиране. И така, какъв е идеалният екип за наука за данни или ML? Е, това е интересен и оживен индустриален дебат; обаче, точно както идеалният екип за разработка на софтуер е многофункционален, така е и науката за данни и машинното обучение – това е по същество специфичен случай за определен тип екип за разработка на софтуер. Въпреки че има квазитрадиционни функции за всеки член на екипа, по-важно е да се съсредоточите върху представянето на функциите, отколкото върху заглавията:

(A) Ръководство на проекта – Това се предлага в две форми: (i) ръководител на проекти, който има опит в създаването на пътни карти и знае потенциалните клопки, управление на персонала и бюджетите и резултатите и осигуряване на висококачествени резултати, на - време и бюджет, които надхвърлят очакванията; и (ii) технически ръководител, който обикновено има окончателна препоръка, ако не и одобрение, относно техническите елементи за това как функционалните и бизнес изисквания се изпълняват най-добре. И двете страни често имат роля в изграждането на екип; рядко обаче те са едни и същи хора.

(B) Стратег — Това вероятно е някой с богат опит със статистика, биостатистика, прогнозен анализ, AI и подходи за машинно обучение. Като цяло те имат способността да поставят бизнес проблеми или изследователски въпроси в най-подходящия модел(и) за наука за данни, да интерпретират резултатите, да оценяват моделите сравнително, да знаят кога да използват кои статистически инструменти, алгоритми за контролирано обучение и алгоритми за неконтролирано обучение и кои типове (напр. „случайни гори“ за пропорционална причинно-следствена връзка – особено с големи данни, кои модели са над или недостатъчно подходящи и как да се подобрят, „усилване на градиента“ за функциите на търсачката, кога и как да се използват табла за управление като „Tableau“ за демократизиране данни в реално време за потребители на компанията на първа линия, в търговията на дребно за използване на K-средства или самоорганизиращи се карти за сегментиране на клиенти или групиране, кога и как да се използва колективен прогнозен анализ „мъдростта на тълпата“ в електронната търговия на дребно и т.н.) и разбиране на високо ниво за това как да използват типове данни, да почистват, да обучават и т.н. Накратко, стратезите са специализирани в това какво да правят, когато, те вероятно са в състояние да създадат нови иновативни подходи към решения от различни области и на високо ниво, знаят как да го направят.

(C) Комуникация/Превод— „Най-добрите специалисти по данни излизат и говорят с хората“, казва Томас Редман в „Harvard Business Review“ (Redman, 2017). Най-добрите изисквания се откриват с много разговори с крайни потребители, документират се, преглеждат се, редактират се и след това се приоритизират. Тези сесии с въпроси и отговори изискват умение за съдебномедицински разпит и лесен диалог с всеки - от квалифицирана работна ръка до ръководство и ръководители. В идеалния случай те също имат широк обхват от бизнес познания, за да разберат как работят процесите, кои са ключовите проблеми, които помагат на бизнеса да расте и да бъде печеливш. И те трябва да бъдат експертни преводачи - способни да преодолеят пропастта между нуждата, функционалното решение и технологията, която го адресира. Те са отчасти анализатори, отчасти запознати, отчасти писатели и почти винаги са автори на подробни документи за функционални и технически изисквания, на които разработчиците и програмистите разчитат. [1] Понякога тези анализатори-комуникатори-писатели са също перфектният човек за водене на документация и обучение — това е какво прави, как работи и защо — защото те вече познават бизнес проблемите и решенията напълно и са напълно способни да ги формулират и обяснят на хората, с които вече са изградили взаимоотношения.

(D) Разработване/Програмиране — В началото на повечето технологични цикли всичко е персонализирано кодирано, тъй като все още не съществуват пакети с графичен потребителски интерфейс. Това беше вярно за статистиката; сега обаче MATLAB, Minitab, SAS и SPSS са лидери в графично базирани пакети, които позволяват на специалистите по данни да получават много по-бързи и точни резултати с много по-малко необходимост от инвестиране на ценно и скъпо време за програмиране или отстраняване на грешки в кода. Според мен тези, които използват графични инструменти за разработка на софтуер, са „разработчици“, а тези, които кодират на езици, са „програмисти“. В науката за данните преходът от персонализирано кодиране към графична програма-инструмент е може би по средата. Със сигурност има графични решения, включително споменатите по-горе тук, които вършат отлична работа бързо и могат да бъдат персонализирани с код, но често няма нужда от това; въпреки това, за персонализирани приложения все още има сравнително добър аргумент за персонализиран код с програмисти - обикновено в Python или R в зависимост от това дали е общо приложение, при което са необходими други функции или съответно чисто наука за данни и статистика. Днес вероятно все още е необходимо да правите и да имате и двата набора умения в екипа си. Дори ако някой използва автоматизирани ML инструменти от следващо поколение — като Data Robot, който може да съпостави десетки популярни ML модели и алгоритми паралелно, спестявайки месеци на догадки и трудоемко изграждане на модели — най-добрият алгоритъм все още трябва да бъде изграден в персонализиран производствена среда. Разработчиците и програмистите са хората с подробно „как“.

(E) Инженеринг на данни— „Само 3% от данните на компаниите отговарят на основните стандарти за качество“ установиха трима изследователи през 2017 г. (Nagle, 2017). Този проблем с достоверността на данните приема много форми — „мръсни данни“, които могат да бъдат неправилно категоризирани, погрешно идентифицирани или просто грешни — липсващи данни или може би най-обезпокоителното — данни, които изглеждат верни; обаче се определя по много начини. Той създава защитна врата за осигуряване на качеството в предния край, която изисква данните да са възможно най-точни, преди да бъдат въведени в анализ на науката за данни или инженерни процеси. Въпреки че има стратегии за справяне с липсващи данни - изтриване на записи, вмъкване на средна стойност или медиана за останалите данни, премахване на отклонения, които имат 2,5 пъти средната стойност на липсващите елементи от данни, отнема много време със сигурност - изключително важно е да знаете как и кога да използвайте всяка. В идеалния случай този човек вероятно е някой с много опит в извличането, трансформирането и зареждането (ETL) на данни в системите и също така трябва да има добро разбиране на речника на данните и дефинициите, които са били и се използват във всяка среда. Този проблем се умножава, когато компаниите комбинират себе си или системи, тъй като всеки субект често има своя собствена система от данни и дефиниции и тяхното привеждане в съответствие е предпоставка за холистични и обхващащи цялото предприятие проекти за наука за данни. Инженерите по данни са безценни партньори за подробното „как“, върху което разработчиците и програмистите се фокусират.

(F) Осигуряване/тестване на качеството— Това може да е най-пренебрегваната функция в екип за наука за данни; обаче е критично. В традиционния жизнен цикъл на разработка на софтуер, тестерите разглеждат функционалните изисквания и гарантират, че решението прави това, за което е предназначено. След това те се опитват да го разбият, като правят странни неща, които правят потребителите, или го зареждат с твърде много данни, за да го тестват под стрес. В разработките на науката за данните, това придобива допълнително значение поради статистиката и математиката, които трябва да са правилни, за да получите ценни отговори и прогнози. В противен случай компанията буквално инвестира стотици хиляди или милиони долари в супер ефективна машина за генериране на грешни отговори, която ще дезинформира и ще заблуди повече, отколкото ще информира и ще даде възможност. Направете това веднъж и недоверието, което създава, може да не бъде преодоляно за едно поколение корпоративни лидери. От тактически подход за осигуряване на качеството, те отговарят критично на неща като работят ли инструментите за наука за данни, тествани срещу множество поколения данни (често задържани от обучение), дали корелациите или асоциациите са били неправилно обединени с причинно-следствената връзка, използван ли е статистически инструмент, който предполагаеми нормализирани разпределения на данни върху ненормализирани данни, дали данните са дисбалансирани, причинявайки дясно или ляво наклонени разпределения, дали типовете данни са неправилно смесени в рамките на методи (напр. непрекъснати, срещу категорични и т.н.). Ако екип ми каже, че е похарчил 33% от продължителността на проекта за анализ и дизайн, 33% за разработка и 33% за QA/тестване, това ми се струва разумно и здравословно разпределение на изразходваното време и ресурси.

2. Разнообразие и широчина на данните – откъде се започва – „Don Wedding“, един от моите брилянтни професори по прогнозен анализ в „Northwestern University“ и бивш технически ръководител в „SAS Institute“, има аналогия, за да предаде импортирайте ефикасността на машинното обучение до голяма степен в зависимост от началната точка. Ако попитате алгоритъм за машинно обучение коя е най-високата точка на Земята и той започне с груба сила, проба-грешка в Аляска, той може да каже връх Маккинли. Ако започва в Азия, може да каже връх Еверест. Ако започва в Долината на смъртта, може да каже ръб на дупка за местни прерийни кучета. Резултатите са съответно много добри, перфектни и много лоши (Сватба, 2017).

Подобен проблем възниква при приложенията на науката за данни към геномиката. Повечето геномни бази данни или биобанки, използвани днес, са проби от кавказци от западноевропейски произход. Точно както откриването на измами в търговията на дребно търси отклонения в поведението, в геномните ML приложения, вариантите са името на играта. Какъв е нормалният геномен отпечатък и кога, къде и защо нещо се различава от този нормален отпечатък? Следователно, освен ако данните не са от разнообразна популация, като извадката съответства на популацията, когато ML алгоритъм идентифицира „различието“ на варианта от нормата, за да покаже заболяване, резистентност и т.н., много добре може просто да е, че вариантът е от недостатъчно представено малцинство в набора от данни, което го прави погрешно предположение. Всичко това означава, че широчината и разнообразието от данни в инженерната страна на данни на проект за наука за данни са ключови, в противен случай технологията просто ви дава подвеждащ отговор по-ефективно и фалшива увереност.

3. Разберете контекстуалния основен(ни) проблем(и) – Също така на Дон Уединг се приписва концепцията за „аналитичния върколак“, онези неща, които са по-дълбоки основни проблеми, които карат компаниите да възприемат, че трябва да се занимават с наука за данни или машинно обучение за „убийте върколака“ (Сватба, 2017). Проф. Уединг, който е и водещ учен по данни в компания от Fortune 500, изрази мнение и научи от значителния си опит, че: (а) интересът към машинното обучение често може да предполага липса на аналитични или статистически данни талант, ограничени умения със SAS или остарели инструменти, недостатъчна изчислителна мощност или модели или проблеми с качеството на данните; и (б) клиентите често използват инициатива за наука за данни или машинно обучение като „сребърен куршум“, за да си осигурят професионален консултантски ангажимент за преодоляване на техните аналитични пропуски, увеличаване на инструментите и/или обучението, надграждане на софтуера, повече изчислителна мощност (напр. преход към облака или по-мощни процесори или по-голяма памет, преход към разпределена изчислителна архитектура, по-бърза пропускателна способност на бази данни и т.н.), реорганизиране на архитектури на бази данни или всякаква комбинация. Тези основни нужди, мотиви и решения изобщо не са непременно лоши; Въпреки това, когато се формира инициатива за наука за данни или ML, е важно да се контекстуализира кръговата диаграма на мотивите и причините, поради които науката за данни се препоръчва или желае. Не можете да предоставите ефикасни решения, без да познавате проблемите.

4. Работи ли? — Ние, учените по данни, сме много маниаци. Търговските списания, да не говорим за академичните рецензирани списания, са пълни със статии, разчитащи на тайнствен жаргон относно настройването на този алгоритъм на процеса или онази формула, за да се предскажат .01 по-добре или в прекалено или недостатъчно подходящи корекции за постигане на постепенно по-добри резултати. Със сигурност тези чисто изследователски статии са важни за напредъка в областта. Например, ако някой работи в процъфтяващата област на изкуствения интелект, приложен към медицинските науки, което може да е причината в крайна сметка да живеем много по-дълго от нашите предци (или не), постепенното подобряване на точността на разчитане на изображения или предсказване на заболявания може да удължи очакваната продължителност на живота за хиляди хора; в бизнеса обаче по-голямата част от възвръщаемостта на инвестицията в науката за данни (ROI) е по-проста. Ако едно научно решение за данни увеличава рентабилността с повече от разходите си, прекалено опростено, това е успех. По-конкретно, ако едно научно решение за данни може да подобри рентабилността на клиентите, сегментирането, придобиването, прогнозирането на поведението, задържането или предпочитанията с повече от 10%, това вероятно е голям успех. Ако може да го направи с повече от 10% многократно във всяка област, вероятно ще ви направи лидер на вашите конкурентни пространства.

5. Ще го използват ли? — Отговорът на този въпрос може до голяма степен да зависи от неговата обяснимост за широката аудитория и нивото на доверие (Gray, 2017). Има малко мръсна тайна около AI-ML страната на науката за данни (за разлика от статистическата страна), за която е „писано повече от веднъж в техническата преса“ (Knight, 2017). А именно, когато машинното обучение включва неконтролирано обучение, може да бъде трудно да се установи как даден модел е получил отговора си и поради тази необяснимост общото ръководство и непрофесионалните потребители може да не му се доверяват. Представете си, ако неконтролиран алгоритъм за ML прогнозира, че новото ви дете ще развие заболяване след 20 години, което може драстично да съкрати продължителността на живота му. Следователно техните гени трябва да бъдат редактирани незабавно след раждането, за да се опита да се предотврати болестта; обаче, може да има и непредвидени последици надолу по веригата на такова редактиране на гени, което може да причини други проблеми. Бихте ли го направили? Отговорът вероятно до голяма степен зависи от това дали сте разбрали защо алгоритъмът е предвидил това. При отсъствието на това доверие в резултата/прогнозата, вземащите решения са алергични към действия в съответствие с него. Със статистиката и дори контролираното обучение, страните на науката за данните, можем да образоваме вземащите решения защо машината е направила такава прогноза или констатация; с неконтролиран ML, където той се учи сам, при липса на обратна връзка, която обяснява какво е направил на хората, често не знаем как е стигнал до заключението си. Да вярваш или да не вярваш.

Ансамблите са ключови

И накрая, бъдещето на науката за данни и машинното обучение вероятно е в комбинирането на модели и подходи в ансамбли, които превъзхождат отделните приложения. Такъв е и случаят с успешните проекти за наука за данни. Най-успешният подход може да не максимизира нито една от горните пет първопричини или двигатели, но да доведе до най-високата средна или средна стойност за всичките пет. Например, клиентите могат да се доверят — и следователно да използват — „многоизмерен куб за онлайн аналитична обработка (OLAP), който сегментира клиентите графично по начин, който те могат да разберат повече от k-средства или самоорганизираща се карта, въпреки че последната подходите са по-сложни, прецизни и автоматизирани. По същия начин, най-добрият подход за машинно обучение за определяне на причинно-следствени елементи и изграждането им в предсказуем модел може да бъде дърво на решенията, последвано от автоматизирано сравнение на предсказуем модел от Data Robot; ако обаче екипът не разполага с тези инструменти и вместо това разполага с експерти по Python програмисти в TensorFlow или инстанция на Minitab, която може да изведе логистична регресия (често почти толкова добра, колкото ML), това е балансът, който може да спечели деня.

По същия начин, в един идеален свят, няколко от буквите междуфункционални екипни способности, изброени тук, ще бъдат намерени в едно и също лице. Собственик на проект, ако търси и има малко късмет, ще намери многофункционални членове на екипа. Например ръководител на проекти, който също е умел и опитен комуникатор и стратег, или технически ръководител, който може да бъде разработчик/програмист и тестер. Колкото по-малко са възлите за хора в екипа, толкова по-лесно, ефективно и ефикасно могат да работят заедно – и обикновено толкова по-добра е стойността (може да бъде и по-изгодно за доставчиците на услуги, тъй като някои функции се таксуват на по-високи ставки от други, докато цената на ресурсите остава същата). Въпреки че един многофункционален член на екипа може да струва повече за единица време, той може да спести на клиента или да проектира двама души, които почти биха работили с една и съща скорост.

На Стив Джобс се приписва това, което може да бъде най-добрият ключ към успеха в прилагането на тези интердисциплинарни и специализирани области, които стават повсеместни през 21-ви век - може би по ирония на съдбата, защото той имаше ограничено формално образование - в обяснението на огромния дългосрочен иновационен двигател на Apple Computers: „повечето компании наемат умни хора, след което им казват какво да правят, ние наемаме умни хора и ги оставяме да ни казват какво да правим.“

Eric Luellen ръководи проекти за разработка на софтуер в предсказуем анализ в световен мащаб от 1997 г. насам, притежава магистърска степен по информатика от Северозападния университет, където дисертацията му проектира нови подходи за групово машинно обучение за прогнозиране, базирано на изображения с висока размерност, и беше глобален финалист за 2016 Stanford MedX C3 prize и 2017 World Technology Award.

Цитирани творби

Asay, M. (2017, 12 юли). 3 начина за масов провал с машинното обучение (и един ключ към успеха). Tech Republic, стр. https://www.techrepublic.com/article/3-ways-to-massively-fail-with-machine-learning-and-one-key-to-success /.

Грей, К. (2017 г., 20 юли). AI може да бъде неприятен съотборник. Harvard Business Review, стр. https://hbr.org/2017/07/ai-can-be-a-troublesome-teammate.

Knight, W. (2017, 11 април). Тъмната тайна в сърцето на AI. MIT Technology Review, стр. https://www.technologyreview.com/s/604087/the-dark-secret-at-the-heart-of-ai/.

Нагъл, Т., Редман, Т., Самън, Д. (2017 г., 11 септември). Само 3% от данните на компаниите отговарят на основните стандарти за качество. Harvard Business Review, стр. https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards.

Редман, Т. (2017, 15 юни). Вашата компания знае ли какво да прави с всичките си данни? Harvard Business Review, стр. https://hbr.org/2017/06/does-your-company-know-what-to-do-with-all-its-data.

Редман, Т. (2017 г., 26 януари). Най-добрите учени по данни излизат и говорят с хората. Harvard Business Review, стр. https://hbr.org/2017/01/the-best-data-scientists-get-out-and-talk-to-people.

Редман, Т. (2018 г., 25 януари). Настройвате ли вашите специалисти по данни да се провалят? Harvard Business Review, стр. https://hbr.org/2018/01/are-you-setting-your-data-scientists-up-to-fail.

Тейлър, Б. (2017 г., 16 октомври). Защо повечето AI проекти се провалят. Блог на Data Robot, стр. https://blog.datarobot.com/why-most-ai-projects-fail.

Терещенко, М. (2017, 9 декември). Изграждане на междуфункционален екип, когато ML-as-a-Service няма да работи. Извлечено от DZone: https://dzone.com/articles/building-a-cross-functional-team -when-ml-as-a-serv

Veeramachaneni, K. (2016, 7 декември). Защо не получавате стойност от вашата наука за данни. Harvard Business Review, стр. https://hbr.org/2016/12/why-youre-not-getting-value-from-your-data-science.

Уокър, Дж. (2017 г., 23 ноември). Стратегиите за големи данни разочароват с 85 процента неуспех. Извлечено от Digital Journal: http://www.digitaljournal.com/tech-and-science/technology/big-data-strategies-disappoint-with-85-percent-failure-rate/article/508325#ixzz5JvGk3AV0

Сватба, Д. (2017). Прогнозно моделиране. (D. Wedding, Изпълнител) Северозападен университет, Еванстън, Илинойс, САЩ.

[1] Въпреки че е често срещана идея да се пропуснат тези времеемки стъпки, екипите го правят на собствена отговорност, защото те поставят основата на очакванията, функциите и целта на проекта. В идеалния случай, по мнението на този автор, те са напълно завършени, след което започва процес на „бърза разработка на приложения (RAD)“, при който екипът си отива и се връща след 30 дни и пита „това ли имахте предвид?“ и проекторешението се редактира за нов 30-дневен цикъл на преглед. Продуктът, в рамките на 2-3 кратки цикъла, често е експоненциално по-добър от една дълга разработка.