Wiele rozczarowujących projektów machine learning nie zawodzi na modelu. Zawodzi, zanim zacznie się trening: nikt nie potrafi powiedzieć, jak dobrze działa obecny proces, decyzja, którą miałby podejmować model, jest warta kilkaset dolarów miesięcznie, albo wynik ląduje w dashboardzie, którego nikt nie otwiera. Ankiety mówią to samo w ujęciu zbiorczym. Gartner spodziewa się, że ponad 40% projektów agentowej AI zostanie anulowanych do końca 2027 roku, wskazując rosnące koszty, niejasną wartość biznesową albo niewystarczającą kontrolę ryzyka. W ankiecie McKinsey z 2025 roku 39% respondentów zgłosiło jakikolwiek wpływ AI na EBIT na poziomie całego przedsiębiorstwa, a większość z nich szacowała go poniżej 5%. Badanie BCG z września 2025 roku wykazało, że 5% firm uzyskuje wartość z AI na dużą skalę, a 60% raportuje minimalne zyski w przychodach i kosztach mimo znacznych inwestycji.
Budowanie systemów ML to nasza praca, a mimo to odradzimy zakup, gdy reguła albo raport będą tańsze. Ta notatka wymienia pięć sygnałów, które sprawdzamy, co każdy z nich oznacza dla biznesu i co zbudować zamiast modelu.
Wersja skrócona dla osoby, która podpisuje budżet
Co. Pięć pytań o proces, dane i zespół. Jeśli którakolwiek odpowiedź brzmi „nie”, model prawdopodobnie nie jest następnym krokiem.
Kiedy. Zadać je przed fazą discovery, a nie po proof of concept. Odpowiedź zajmuje jedno popołudnie.
Koszt pominięcia. Faza discovery z zewnętrznym zespołem kosztuje zwykle 6k–14k € w ciągu 2–3 tygodni, proof of concept 14k–38k € w ciągu 4–7 tygodni, a system produkcyjny 45k–120k € w ciągu 10–20 tygodni. To nasze opublikowane przedziały; inni wykonawcy będą się różnić, ale rząd wielkości się zgadza. Reguła albo raport powstają zwykle w kilka dni.
Ryzyko. Drogim wynikiem nie jest model, który zawodzi. Jest nim model, który działa mniej więcej tak dobrze jak reguła, którą można było napisać, a teraz trzeba go co miesiąc ponownie trenować, monitorować i za niego płacić.
Wytyczne inżynierskie samego Google zaczynają się od tego samego. Reguła nr 1 z Rules of Machine Learning brzmi: „nie bój się wypuścić produktu bez machine learning”, bo proste heurystyki często dają większość efektu przy znacznie mniejszej złożoności.
Sygnał 1: nie da się powiedzieć, jak dobrze działa obecny proces
Co to oznacza. Jeśli nikt nie potrafi podać obecnego odsetka braków towaru, obecnego udziału oszukańczych zamówień ani obecnego czasu odpowiedzi na zgłoszenie do wsparcia, nikt nie będzie w stanie powiedzieć, czy model to poprawił. Projekt kończy się demem i sporem.
Typowy objaw. Cel jest sformułowany jako kierunek („zmniejszyć braki towaru”, „spersonalizować stronę”), a nie jako liczba z metodą pomiaru i oknem czasowym.
Co zrobić zamiast tego. Najpierw zbudować pomiar. Cotygodniowy raport tej jednej liczby, którą miałby przesunąć model, liczony co tydzień w ten sam sposób, przez cztery do ośmiu tygodni. Ten raport to punkt odniesienia, który każdy późniejszy model musi pobić, i jest przydatny sam w sobie: gdy liczba staje się widoczna, może się okazać, że warto rozwiązać zupełnie inny problem. Reguła nr 2 w przewodniku Google mówi to samo innymi słowami: zaprojektuj i wdroż metryki przed wszystkim innym.
Sygnał 2: decyzja jest rzadka albo wolumen jest mały
Co to oznacza. Model zarabia na swój koszt, podejmując wiele małych decyzji odrobinę lepiej. Jeśli decyzja zapada pięćdziesiąt razy w miesiącu, poprawa ma bardzo mało do pomnożenia.
Arytmetyka poglądowa. Załóżmy, że model poprawia każdą decyzję o 2% stawki, o którą chodzi.
| Decyzje miesięcznie | Wartość na decyzję | Miesięczny zysk przy 2% | Miesiące do zwrotu proof of concept za 14k € |
|---|---|---|---|
| 50 | 200 € | 200 € | 70 |
| 200 000 | 1 € | 4 000 € | 3,5 |
Liczby są poglądowe, a nie zmierzone. Chodzi o kształt: pierwszy wiersz nigdy się nie zwraca, nawet przed doliczeniem monitoringu i ponownego trenowania; drugi zwraca się w ciągu kwartału.
Co zrobić zamiast tego. Przy rzadkich decyzjach o wysokiej wartości lepiej dać osobie, która je podejmuje, lepszy arkusz: pięć czy sześć danych wejściowych, z których naprawdę korzysta, obok siebie, z zeszłorocznym wynikiem przy każdym przypadku. Checklista plus człowiek wygrywa z modelem wytrenowanym na pięćdziesięciu przykładach.
Sygnał 3: prosta reguła już daje większość wartości
Co to oznacza. Wiele problemów ma regułę, która obsługuje większość przypadków. Wstrzymać zamówienia powyżej progu wartości wysyłane na nowy adres z nową kartą. Pokazywać bestsellery kategorii odwiedzającym bez historii. Zamawiać ponownie, gdy zapas pokrywa mniej niż N dni sprzedaży z ostatniego miesiąca. Model musi pobić regułę na tyle, żeby pokryć koszt swojej budowy i działania, a często mu się to nie udaje.
Typowy objaw. Nikt nie wypróbował reguły, więc nikt nie wie, ile zostało do wygrania dla modelu.
Co zrobić zamiast tego. Wdrożyć regułę, zmierzyć ją raportem z sygnału 1 i prowadzić listę przypadków, w których się myli. Ta lista ma dwie funkcje: mówi, ile wartości model mógłby jeszcze dodać, i staje się pierwszymi oznaczonymi danymi oraz zbiorem testowym, jeśli model powstanie później.
Kiedy reguła przestaje wystarczać. Reguła nr 3 Google stanowi przeciwwagę: wybierz machine learning zamiast złożonej heurystyki. Gdy reguła rozrosła się do dziesiątek wyjątków, które rozumie tylko jedna osoba, a każdy nowy wyjątek psuje któryś stary, model jest łatwiejszy w utrzymaniu niż zbiór reguł. Wtedy ML zaczyna mieć sens.
Sygnał 4: dane nie zapisują wyniku, który chce się przewidywać
Co to oznacza. Model uczy się na przykładach, w których odpowiedź jest znana. Jeśli odpowiedzi nigdy nie zapisano, nie ma się z czego uczyć.
Typowe objawy.
- Prognozowanie popytu na historii sprzedaży, która nie zapisuje braków towaru. Gdy półka była pusta, sprzedaż wynosiła zero, ale popyt nie, i model uczy się, że produkt jest niepopularny dokładnie w te dni, w które był najbardziej poszukiwany.
- Przewidywanie odejść klientów, gdy nikt nie zapisał, kiedy klient odszedł, a jedynie to, że przestał się pojawiać.
- Scoring nadużyć, gdy chargebacki są w portalu operatora płatności i nigdy nie zostały połączone z zamówieniami.
Co zrobić zamiast tego. Zacząć logować wynik już teraz, w tym samym systemie co dane wejściowe, ze znacznikiem czasu. Większość wyników potrzebuje trzech do sześciu miesięcy historii, zanim model będzie można wytrenować, a potem przetestować na późniejszym okresie, którego nie widział. W międzyczasie warto korzystać z raportu albo reguły. Jeśli wynik przychodzi z opóźnieniem (chargebacki mogą trwać tygodniami), należy uwzględnić to opóźnienie w projekcie, a nie odkrywać go na produkcji.
Sygnał 5: nikt nie odpowiada za działanie na podstawie wyniku
Co to oznacza. Prognoza niczego nie zmienia, dopóki ktoś z jej powodu nie zamówi mniej towaru. Ocena ryzyka nadużycia niczego nie zmienia, dopóki zamówienie nie zostanie wstrzymane. Jeśli nie ma wskazanej osoby, systemu, w którym pojawia się wynik, ani uzgodnionego działania dla każdej wartości, model jest kosztem bez zwrotu.
Typowy objaw. Odpowiedzią na pytanie „kto będzie tego używał i co w poniedziałek zrobi inaczej” jest nazwa działu, a nie osoba i decyzja.
Co zrobić zamiast tego. Przez miesiąc podejmować decyzję ręcznie na podstawie raportu. Umieścić raport tam, gdzie zapada decyzja, i obserwować, czy ktoś z niego korzysta. Jeśli nikt nie działa na podstawie raportu, nikt nie będzie działał na podstawie modelu, a naprawić trzeba proces, a nie predykcję.
Szybki autotest
Na każde pytanie należy odpowiedzieć dla procesu, który ma zostać usprawniony.
| Pytanie | Jeśli odpowiedź brzmi „nie” | Zbudować zamiast tego | Typowy nakład |
|---|---|---|---|
| Czy da się podać dzisiejszą wartość metryki i sposób jej pomiaru? | Brak punktu odniesienia, brak dowodu poprawy | Cotygodniowy raport tej jednej metryki | Dni |
| Czy decyzja zapada co najmniej tysiące razy w miesiącu albo czy każda z nich jest dużo warta? | Za mały wolumen, by model się zwrócił | Arkusz albo checklista dla osoby podejmującej decyzję | Dni |
| Czy oczywista reguła została wypróbowana i zmierzona? | Nie wiadomo, co model mógłby dodać | Reguła plus log przypadków, w których się myli | Od kilku dni do dwóch tygodni |
| Czy wynik, który chce się przewidywać, jest zapisywany z datą od kilku miesięcy? | Nie ma się z czego uczyć | Logowanie wyniku, potem raport | Trzy do sześciu miesięcy logowania |
| Czy jest wskazany właściciel i określone działanie dla każdego wyniku? | Wynik niczego nie zmieni | Ręczny proces oparty na raporcie przez miesiąc | Jeden miesiąc |
Pięć odpowiedzi „tak” nie gwarantuje, że model się opłaci. Jedno „nie” zwykle wystarczy, by powiedzieć, że jeszcze się nie opłaci.
Kiedy ML zaczyna być wart zachodu
Ta sama lista czytana w drugą stronę opisuje dobry projekt ML:
- Metryka jest mierzona w ten sam sposób od tygodni i istnieje punkt odniesienia do pobicia.
- Decyzja zapada często albo każda niesie na tyle dużą wartość, że niewielka poprawa ma znaczenie.
- Reguła istnieje, została zmierzona i stała się zbyt złożona, by ją utrzymywać.
- Wynik jest zapisywany na tyle długo, by trenować na jednym okresie i testować na późniejszym.
- Wskazana osoba będzie działać na podstawie wyniku, w systemie, którego już używa.
Nawet wtedy pierwszy krok jest mały: prosty model porównany z regułą na tej samej metryce, najpierw na danych historycznych, a potem na części żywego ruchu. Jeśli model nie pobija reguły o więcej, niż kosztuje jego działanie, zostaje reguła. To wynik, a nie porażka.
Jak sprawdzić własny przypadek
Prowadzimy bezpłatny teardown z sześcioma pytaniami pod adresem /teardown. Pyta o proces, dane i właściciela, a jedną z możliwych odpowiedzi jest „jeszcze nie róbcie ML”, razem z tym, co zbudować zamiast tego. Jeśli odpowiedź brzmi, że model ma sens, opublikowane przedziały na /pricing pokazują, ile kosztuje następny krok, zanim ktokolwiek umówi się na rozmowę.
Źródła
- Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, czerwiec 2025 — https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
- McKinsey & Company, The state of AI in 2025: Agents, innovation, and transformation, listopad 2025 — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Boston Consulting Group, The Widening AI Value Gap: Build for the Future 2025 (informacja prasowa), wrzesień 2025 — https://www.bcg.com/press/30september2025-ai-leaders-outpace-laggards-revenue-growth-cost-savings
- Google for Developers, Rules of Machine Learning: Best Practices for ML Engineering (Martin Zinkevich), strona ostatnio aktualizowana w sierpniu 2025 — https://developers.google.com/machine-learning/guides/rules-of-ml