AI nie podejmuje złych decyzji. Robią to źle zdefiniowane problemy.

Przez długi czas myślałem, że problemy z systemami AI wynikają z modeli. Za słabe, za drogie, za mało „inteligentne”. Dopiero budując realny system AI w B2B – nie demo, nie prezentację – zrozumiałem coś prostszego: większość błędów AI to błędy w specyfikacji problemu, nie w algorytmach.

To jak z każdym projektem inżynieryjnym – jeśli źle zdefiniujesz wymagania, najlepszy wykonawca zbuduje ci coś nie tego.

Gdzie naprawdę psują się projekty AI –Widziałem to u siebie wielokrotnie:

Problem z danymi. Wyobraź sobie, że projektujesz most bazując tylko na pomiarach z lata, bez uwzględnienia warunków zimowych. Model AI uczy się na danych, które masz – ale jeśli te dane nie pokrywają wszystkich sytuacji, w których system będzie działał, model będzie sobie wymyślał zachowanie w nieznanych przypadkach.

Przykład: uczysz system do oceny jakości leadów sprzedażowych tylko na danych z firm, które ostatecznie kupiły. Model nauczy się rozpoznawać „dobrych klientów”, ale nie będzie umiał odróżnić przypadków, gdzie firma była zainteresowana, ale nie kupię z powodów budżetowych, od przypadków, gdzie firma w ogóle nie była w target group.

Problem ze specyfikacją.
Definiujesz cel biznesowy („zwiększ sprzedaż”), ale nie tłumaczysz go na konkretne, mierzalne kryterium decyzyjne. To tak jakby powiedzieć budowlańcom „zbudujcie coś ładnego” zamiast dać im projekt z wymiarami.

Model AI optymalizuje konkretną miarę – ale jeśli ta miera słabo odpowiada twoim rzeczywistym celom, dostaniesz system, który technicznie działa, ale biznesowo jest bezużyteczny.

Klasyczny przykład: optymalizujesz system rekomendacyjny pod „kliknięcia”. Dostajesz nagłówki clickbaitowe, które ludzie klikają, ale potem są rozczarowani treścią. Technicznie: wysoka skuteczność. Biznesowo: katastrofa.

Problem z granicami pewności.
System AI nie wie, kiedy powinien powiedzieć „nie wiem”. Będzie działał równie pewnie na typowych przypadkach i na kompletnie nietypowych sytuacjach, których nigdy nie widział.

To jak GPS, który nawiguje cię z taką samą pewnością siebie przez znane miasto i przez teren, którego nie ma w mapach – tylko że w tym drugim przypadku wymyśla sobie trasę.

Jeśli chcesz zobaczyć, jak buduje BIZPULL – możesz dołączyć do beta testerów – wejdź na: https://beta.bizpull.ai

Dlaczego „lepszy model” nie rozwiązuje problemu

W pewnym momencie każdy zespół myśli: „Może potrzebujemy lepszego modelu.” Większego, droższego, nowszej generacji.

Problem: lepszy model nie naprawia złego zadania.

Co więcej – lepsze modele językowe są bardziej przekonujące w swoich błędach. Nowszy model napisze ci dłuższe, bardziej spójne, lepiej sformułowane uzasadnienie błędnej odpowiedzi. Ma lepszą „gramatykę myślenia”, więcej kontekstu, gładszą narrację.

Ale jeśli podstawowy problem jest źle zdefiniowany, lepszy model tylko skuteczniej przekona cię do złego rozwiązania.

Analogia: to jak zatrudnić bardziej elokwentnego projektanta, który dalej źle zrozumiał twoje wymagania. Projekt będzie pięknie narysowany i profesjonalnie zaprezentowany – ale dalej będzie nie tym, czego potrzebujesz.

Co zmieniło moje myślenie

Budując Bizpull.ai, pracuję z zespołem systemów AI (Claude, GPT, Lovable) jak z wykonawcami w procesie inżynieryjnym.

Moja praca to nie „robienie AI”. To: Definiowanie problemu decyzyjnego.

Zanim zapytam system AI, muszę wiedzieć:
– Jaka konkretnie decyzja ma zostać podjęta?
– Jakie są możliwe opcje do wyboru?
– Według jakiego kryterium wybieramy?
– Przy jakim poziomie pewności ta decyzja jest wystarczająco dobra?

To jak pisanie specyfikacji technicznej – im precyzyjniej określisz wymagania, tym lepszy będzie wynik.

Projektowanie struktury informacji.
Nie chodzi o to, jak zapytać system AI (tzw. „prompt”). Chodzi o to, jak uporządkować wiedzę, którą system ma przetworzyć.

Wyobraź sobie bibliotekę: możesz mieć najlepszego bibliotekarza na świecie, ale jeśli książki są chaotycznie rozrzucone bez systemu katalogowego, nie znajdzie tego, czego szukasz. System AI potrzebuje struktury – kategoryzacji, hierarchii, powiązań.

Ustalanie granic pewności.
Systemy AI nie mają wbudowanego mechanizmu „nie wiem”. Musisz to zaprojektować: kiedy system powinien podać odpowiedź, a kiedy powinien przekazać decyzję człowiekowi. To musi być zaprojektowane.

To wymaga wielokrotnego testowania tego samego przypadku, sprawdzania spójności odpowiedzi, definiowania progów akceptowalnej pewności. Bez tego system będzie równie pewny prawidłowej odpowiedzi i całkowitej pomyłki.

Weryfikacja na kartce.
Zanim uruchomię proces zautomatyzowany, robię go ręcznie. Na kartce, na tablicy. Jeśli nie potrafię zdefiniować procesu myślenia na papierze krok po kroku, to system AI też tego nie zrobi.

To podstawowa zasada inżynierii: najpierw zrozum problem, potem automatyzuj rozwiązanie.

Prawdziwe pytanie

Nie „Jakiego modelu użyć?”, tylko „Czy potrafię zdefiniować problem jako sekwencję konkretnych decyzji z mierzalnymi efektami?”

Bo jeśli nie:
– System zoptymalizuje coś innego niż potrzebujesz (coś, co łatwiej zmierzyć, ale niekoniecznie ważniejsze)
– Błędy będą wyglądały jak prawidłowe odpowiedzi (bo system nie ma pojęcia, że jest w sytuacji, której nie zna)
– Skalowanie tylko zwiększy skalę błędu (więcej błędnych decyzji szybciej)

Co z tego wynika dla produktów AI

Większość problemów z „AI nie działa w produkcji” to nie problemy z technologią. To problemy z:

Zmianą warunków.
Dane, na których system się uczył, różnią się od danych, które dostaje w rzeczywistej pracy. To jak zaprojektować system chłodzenia na podstawie pomiarów z zimy i włączyć go latem.

Przykład: uczysz system rozpoznawania leadów na podstawie firm z 2023. W 2024 zmienia się gospodarka, zmieniają się budżety, zmieniają się priorytety zakupowe. System dalej działa według starych wzorców.

Przepaścią między testem a rzeczywistością.
W laboratorium mierzysz „dokładność rozpoznawania” (ile procent przypadków system klasyfikuje poprawnie). Ale w biznesie liczy się coś innego – ile to przynosi przychodu, ile oszczędza czasu, ile redukuje kosztów.

System może mieć 95% dokładności i jednocześnie być biznesowo bezużyteczny, bo te 5% błędów dotyczy najważniejszych klientów.

Nadmierną pewnością siebie.
System jest równie pewny na typowych przypadkach (które widział tysiące razy) i na skrajnych sytuacjach (których nigdy nie widział). To wymaga osobnego projektowania – musisz nauczyć system rozpoznawać „to jest poza moim zakresem kompetencji”.

Błędem w definicji celu.
Optymalizujesz zaangażowanie użytkowników – dostajesz system, który generuje kontrowersje, bo kontrowersje angażują. Optymalizujesz czas odpowiedzi – dostajesz system, który daje najkrótsze możliwe odpowiedzi, często bezużyteczne.

To fundamentalny problem inżynieryjny: łatwo zmierzyć nie to, co naprawdę ważne. I jeśli mierzysz nie to, system zoptymalizuje nie to.

Dlaczego to piszę

Rozmowa o AI skupia się na możliwościach technologii. Mało kto mówi o tym, że wdrożenie AI to przede wszystkim inżynieria problemu, nie dobór modelu.

Jeśli AI dziś „podejmuje złe decyzje” w twoim systemie, najprawdopodobniej:
1. System optymalizuje metrykę zastępczą, która słabo koreluje z rzeczywistym celem biznesowym (Cel techniczny rozjechał się z celem biznesowym – system optymalizuje coś innego niż potrzebujesz)
2. Dane uczące nie pokrywają wszystkich sytuacji produkcyjnych (uczysz na próbce, testujesz na całym zakresie) – Tzn. czysz system na pogodzie z lata, a potem włączasz go zimą i dziwisz się, że nie działa
3. System nie ma mechanizmu oceny własnej pewności (nie wie, kiedy powiedzieć „nie wiem”)- generuje odpowiedź niezależnie od tego, czy jest (lub nie jest) w swoim zakresie kompetencji.
4. Metryki testowe są oderwane od rzeczywistego zastosowania (laboratorium ≠ produkcja)

Chętnie poznam perspektywę ludzi, którzy wdrażają AI w produkcji – nie proof-of-concept, tylko systemy z realną odpowiedzialnością biznesową.