Моделите са на мода в момента, а защо да не бъдат? Техните приложения и възможности изглежда се удвояват всяка година, кутиите с инструменти продължават да растат и не можете да хвърлите камък, без да ударите 10 статии, написани за техните случаи на употреба всяка седмица. Тогава е неизбежно клиентите да започнат да искат все повече и повече модели, тъй като чуват всичко за тях. Заедно с това идва тенденцията първо да се пита за модела и по-задълбочено изследване на бизнес въпроса, на който се опитват да отговорят по-късно, когато трябва да е обратното. Разбирането на въпроса, на който клиентът се опитва да отговори, е предпоставка за избор на правилния модел за проблема, но често пъти има недооценен подход за отговор на техния бизнес въпрос: изобщо да не се изгражда модел.
Примерен случай: преди известно време бях завършил доказателство за концепцията с клъстерни модели на k-средства, за да помогна на клиента да разбере по-добре своите клиенти. Имахме последващ проект, при който те искаха да знаят повече информация за различен набор от клиенти, така че естествено поискаха друг модел k-средства. Можех да ги построя точно това, което поискаха, използвайки размерите на клиента, които вече предоставиха, и щеше да е точно това, което поискаха, което обикновено е еталонът за успех на всеки продукт. Въпреки това, след като изследвах малко повече, за да разбера повече за въпроса, на който се опитваха да отговорят, разбрах, че отговорът, който търсеха, може да бъде ефективно осигурен с проста SQL заявка и визуализация на данни, за което настоявах като по-добро решение. Не винаги е препоръчително да казвате на клиент, че това, което изрично е поискал, всъщност не е това, което наистина иска, но в случая с моделите се оказва, че по-често гледам да не им давам модел, ако не трябва да имат един.
Моделите са страхотни, но също така са невероятно тромави за поддръжка. Те изискват някой, който разбира науката за данните, за да ги поддържа, вътрешните им процеси на приспособяване не са интуитивни и ако някой попита за тяхната методология, след като си тръгнете, те не се поддават на лесни обяснения. Понякога, когато техните приложения имат много ясна цел, като предвиждане на количество, те могат да си струват неприятностите, особено ако са сравнени с точността на друг съществуващ процес и/или изисква труд. Но за по-абстрактни приложения, като групиране и сегментиране на клиенти, не е веднага ясно, че тяхното прозрение ще надмине по-простите статистики и методи. При равни други условия защо не изберете по-простото решение?
Разбирам, да имаш модел може да се почувства авангарден. Клиентът е щастлив, че прави футуристични неща, вие сте щастливи да използвате това обучение и способности за наука за данни и всеки може да се учуди колко умни се чувстват. Но да правиш това, което е правилно за всички, не означава да накараш хората да се чувстват умни, а да свършиш нещата с най-малко краткосрочни и дългосрочни разходи. Няма недостиг на легитимни случаи на употреба за по-напреднали техники за наука за данни и моделиране, но по-лошата тенденция е да се превърнеш в чука и да гледаш на всеки проблем като на пирон. Да правиш винаги това, което е правилно за клиента, приема много форми и понякога това включва разпознаването на най-добрия модел за работата е този, който не изграждаш.
