Buduj lub kupuj: Ramka decyzyjna dla projektów uczenia maszynowego

Dlaczego ta decyzja bierze tak często nieprawidłowy kurs

Jednorazowo zidentyfikowawszy problem, który chce rozwiązać za pomocą uczenia maszynowego i zdobytym budżetem, kolejnym pytaniem rzadko jest związane z algorytmami — decyzja polega głównie na sposobie zakupu systemu. Istnieje trzy główne ścieżki: tworzenie niestandardowego rozwiązania wewnątrz firmy lub przez kontrahenta, kupowanie subskrypcyjnego produktu SaaS lub zastosowanie hybridowej strategii polegającej na połączeniu systemu otwartego źródła lub platformy z niestandardowymi rozwiązaniami na górze.

W praktyce duża część pierwszych projektów ML wybiera nieprawidłową ścieżkę. Zespół tworzy niestandardowe systemy dla problemów, które już są rozwiązane za pomocą narzędzia SaaS o koszcie 300 dolarów miesięcznie, płacąc trzy do pięciokrotnie więcej niż konieczne i zaczerpniętego w czasie wydania. Tak samo często zespoły kupują generyczny produkt SaaS dla problemu rzeczywiście niezwykłego — specyficznych formatów danych, ścisłych zasad lokalizacji danych lub głębokiej integracji z starymi systemami — a narzędzie nigdy nie dostarcza oczekiwanej wartości, ponieważ nie można go dostosować do potrzeb.

Poprawa nie polega na intuicji, doświadczeniu ani entuzjazmie producenta. To powtarzalny proces oceny, który przekształca niejasne debaty w liczby.

Trzy opcje w jednym odstępie tekstowym

Tworzenie oznacza zlecenie rozbudowy pod pełną kontrolą kodu, danych i architektury, albo z wewnętrznym zespołem, albo zewnętrznym kontraktantem. Działa najlepiej w przypadkach rzadko występujących problemów, danych o ścisłej tajemnicy lub wymagających określonego formatu, a także w sytuacjach, gdzie nie można uniknąć głębokiej integracji z systemami starszymi — detekcja fałszywych transakcji dostosowana do konkretnego zestawu transakcji, lub prognozowanie popytu wymagającego przetworzenia specyficznej kombinacji sygnałów, o których żaden dostawca dotąd nie modele razem.

Kupowanie oznacza subskrypcję chmrową produkcyjną, gdzie dostawca ma pełną kontrolę nad rozbudową, hostingu i wsparciem. Działa najlepiej w standardowych problemach, których rozwiązanie jest dobrze zrozumiane, gdzie szybkość wydania jest kluczowa, budżet jest ograniczony, a nie ma wewnętrznej umiejętności w zakresie uczenia maszynowego i brak planu na jego rozbudowę. Chatboty wsparcia klienta, personalizacja wiadomości e-mail i ocena potencjalnych klientów zintegrowana z CRM są typowymi kandydatami do kupowania, ponieważ już setki dostawców konkurencji na tym samym problemie.

Hybrydowe rozwiązanie polega na połączeniu gotowego komponentu — framework otwartego źródła, zarządzanego platformy ML chmrowej lub SaaS z dostępem do wdrożenia dostosowanego — z niestandardowym kodem nałożonym na górę. Działa najlepiej w przypadkach, które częściowo są standardowe i częściowo unikalne, w zespołach mających już pewną umiejętność ML wewnętrznie, a także w budżetach średnich. Model przewidywania odchyleń oparty na frameworkie gradientowego boostingu otwartego źródła z niestandardową inżynierią cech, lub framework chatbotu dostosowany do własnych zgłoszeń wsparcia firmy, są typowymi wzorcami hybrydowych rozwiązań.

11-kryteriowy system oceniania

Najbardziej wiarygodny sposób na podjęcie decyzji polega na ocenie projektu według 11 kryteriów, przydzielaniu wag dla każdego kryterium w zależności od tego, jak istotne jest ono dla biznesu, a następnie sumowaniu wyników. Każdy kryterium jest oceniany z zakresu 1 (silnie przeważa budowa) do 5 (silnie przeważy kupno):

Mnożenie każdego punktu przez jego wagę i sumowanie wyników. Całkowita suma poniżej około 200 punktów w stosunku do możliwego maksimum przeważy budowę; 200–350 przeważy podejście hybridowe; powyżej 350 przeważy kupno. Wartości dokładne próg mają mniej znaczenia niż dyscyplina w tym, aby ocenić każde kryterium jasno, zamiast domyślnie wybierać opcję, którą najgłośniejsza osoba w pomieszczeniu preferuje.

Koszt całkowity posiadania przewyższa cenę etykietową

Najczęstsze błędy polegają na porównywaniu miesięcznych opłat za subskrypcję SaaS z jednorazowym kosztem rozwoju bez przekształcenia żadnego z nich w dalszą perspektywę. Porównanie kosztu całkowitego posiadania (KCP) na trzy lata opisuje bardzo inny scenariusz niż porównanie na pierwsze lata.

Załóżmy, że mówimy o rekomendatorze do biznesu e-komercyjnego. Subskrypcja SaaS może kosztować 10 000 dolarów w pierwszym roku (w tym montaż), wzrastając do 12 000 i 15 000 w kolejnych latach – KCP na trzy lata wynosi około 42 000 dolarów. Zestawienie na mocy zlecenia może kosztować 60 000 dolarów na rozwój plus 3 000 dolarów za hosting w pierwszym roku, a następnie 19 000 i 22 000 dolarów na kolejne lata za hosting, wsparcie i regularne re-instrukcje – KCP wynosi blisko 104 000 dolarów. Hybrydowy podejście z użyciem ramy open-source z dostosowaniem niestandardowym może kosztować około 58 000 dolarów w trzech latach – tańsze niż pełny zestaw, ale bardziej elastyczne niż pures SaaS.

Skala zmienia rachunek. W przypadku bardzo wysokich volumes transakcji, ceny SaaS, które skali liniowo z użyciem, mogą odwrócić porównanie: platforma do rekomendacji wypłacająca 80 000 dolarów rocznie dla 100 000 użytkowników miesięcznych kosztuje około 400 000 dolarów w pięciu latach, podczas gdy niestandardowy system z 60 000 dolarów na rozwój i 27 000 dolarów rocznie na kontynuowane koszty wynosi blisko 180 000 dolarów – punkt równowagi zwykle dojmuje w drugim lub trzecim roku. Reguła zasadnicza: poniżej około 10 000 użytkowników dziennych, SaaS obwieszcza zwycięstwo; powyżej 100 000 użytkowników dziennych, niestandardowy zestaw obwieszcza zwycięstwo; między nimi, liczący explicitnie.

Pięć hibridowych wzorców, które warto znać

Hibrydowe nie jest jednym samym podejściem, ale rodziną pięciu rozpoznawalnych wzorcow, naorderzonych w przybliżeniu od najbardziej elastycznych do najprzytłaczających:

Proces pięciostepowy decydujący o akcji

W praktycedecyzja może być zredukowana do krótkiej przepisanej procedury. Pierwsze, przejdź przez filtr dwuminutowy: jeśli budżet jest poniżej około 15 000 dolarów, termin realizacji wynosi mniej niż dwa miesiące, pięć lub więcej dostawców SaaS już obsługują problem, a nie ma zespołu ML ani planu jego utworzenia, odpowiedź prawie zawsze brzmi na zakup — dalsza analiza jest niepotrzebna. Drugie, jeśli żaden z tych szybkich filtrów nie dotyczy, uzupełnij tabelę oceny poziomu wyróżniającego się na dwunastu kryteriach powyżej. Trzecie, stwórz model kosztów całkowitych (TCO) trzech do pięciu lat dla każdej dostępnej opcji, ponieważ ceny pierwszego roku są systemicznie fałszywe. Czwarte, jeśli pozostaje niepewność, przeprowadź trial: próbny okres dostaw SaaS lub projekt dowodowy obejmujący około 10% danych dla kandydata na budowę przed przydzielaniem pełnego budżetu. Piąte, dokumentuj decyzję — wybrany podejście, powody, budżet i termin realizacji, kluczowe ryzyka oraz jasna strategia wyjściowa do migracji w przypadku, gdy dostawca podniesie ceny znacznie lub system niestandardowy okazuje się nieefektywny.

To ostatnie punkt wymaga podkreślenia. Blokada dostawcy jest często niedostatecznie oceniana w trakcie początkowej decyzji i ponownie odkrywana bolesnymi dwiema latami później, gdy dostawca SaaS podnosi ceny o 50% lub całkowicie zamyka działalność. Przed podpisaniem umowy powinien istnieć pracowity plan wyjściowy — jak dane zostaną eksportowane, jak zostanie wybrany zastępczy system, oraz ile czasu rzeczywistego zajmie migracja — nie po tym, gdy się ona stała konieczna.

Pięć błęd powtarzających się w różnych branżach

Te same błędy pojawiają się w decyzjach dotyczących budowy czy zakupu systemów w bardzo różnorodnych firmach. Equipozy budują wewnętrznie, ponieważ founder lub lider inżynieryjny chce doświadczyć zarządzania zespołem ML, nie zauważając, że kompetentna drużyna kosztuje ponad 100–200 tys. dolarów rocznie za pełnowartościowe wynagrodzenie i zaczyna zyskiwać tylko wtedy, gdy jest już trzy lub więcej projektów ML w kolejce. Zespół porównuje ceny listowe zamiast kosztów całkowitych (TCO), niezauważając, że cena listowa usługi SaaS wzrasta rocznie, podczas gdy koszty utrzymania systemu niestandardowego są często przekraczane. Zespół traktuje ramy open-source jako bezpłatne, zapominając o tym, że rozwoj, hosting i wsparcie nadal kosztują — open-source obniża zwykle całkowite koszty o 20–30%, a nie do zera. Zespół ignoruje związanie się z dostawcą aż do chwili kryzysu. A zespół planuje wydanie szybkie za pomocą narzędzia SaaS i „przygotowanie właściwe później”, plan, który w praktyce rzadko przetrwa kontakt z priorytetami kolejnego kwartalu, pozostawiając dług techniczny, który kosztuje więcej do odłożenia niż budowa niestandardowego systemu od początku.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz Build vs Buy: A Decision Framework for Machine Learning Projects i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.