Dlaczego tworzenie produktów AI potrzebuje nowego modelu opartego na człowieku

Większość projektów AI kończy się niepowodzeniem z prostego powodu. Osoby, które je tworzą, tracą z oczu ludzi, dla których je budują. 

Prognozy dotyczące tego, ile projektów generatywnej AI zostanie porzuconych po etapie proof of concept, okazały się zbyt optymistyczne. 

Ta sytuacja wymaga modelu, który utrzymuje człowieka w centrum na każdym etapie, od pierwszego wywiadu z użytkownikiem aż po kod, na którym działa model.

Co decyduje o sukcesie projektów GenAI?

Produkty AI dominują dziś w nagłówkach. Niezależnie od tego, czy chodzi o chatboty, silniki rekomendacji, czy inteligentnych asystentów programowania, wszystkie obiecują zmienić sposób działania biznesu. Za tym szumem kryje się jednak trudniejsza prawda. 

Większość projektów GenAI kończy się niepowodzeniem, bo w tym procesie brakuje ludzi.

Szeroko cytowana prognoza Gartnera z 2024 roku wskazywała niską jakość danych, słabą kontrolę ryzyka, rosnące koszty i niejasną wartość biznesową jako główne przyczyny porzucania projektów GenAI, szacując wskaźnik niepowodzeń na 30% (Gartner). Nowsze badania sugerują, że rzeczywista skala jest większa. 

Badanie RAND z 2024 roku, oparte na wywiadach z 65 data scientistami i inżynierami, pokazało, że za większością niepowodzeń projektów AI stoją decyzje liderów i jakość danych, a ograniczenia modeli odgrywają znacznie mniejszą rolę. 

Osobne badanie S&P Global wykazało, że organizacje porzucają 46% proof of conceptów AI, zanim trafią one na produkcję. 

IBM Watson for Oncology to studium przypadku, na które ludzie wciąż powołują się po latach. Inicjatywa warta 4 mld USD potrafiła analizować ogromne ilości danych. Nie uwzględniała jednak lokalnego, ludzkiego osądu, którym onkolodzy posługują się na co dzień. Jej rekomendacje często stały w sprzeczności z opiniami ekspertów, opierały się bardziej na wyselekcjonowanych danych niż na rzeczywistej dokumentacji klinicznej i słabo wpisywały się w aktualne przepływy pracy. W efekcie projekt po cichu anulowano.

To ostrzeżenia przed brakiem dopasowania. Ludzkie potrzeby, projektowanie produktu i inteligencja maszyn muszą ze sobą współgrać. Sukces produktu AI zaczyna się od empatii i jasnego zrozumienia problemu. Baza kodu jest dopiero na drugim miejscu.

Design thinking wnosi podejście skoncentrowane na człowieku. Lean wnosi efektywność. Agile wnosi zdolność adaptacji. MLOps wnosi rygor. Razem tworzą jedną praktyczną metodologię.

Jak design thinking ewoluuje w erze AI?

Design thinking powstało na długo przed tym, jak przejęły je firmy technologiczne. To podejście do rozwiązywania problemów skoncentrowane na człowieku, stosowane w architekturze, projektowaniu produktów i edukacji. Opiera się na znanych etapach: zespoły poznają perspektywę użytkowników, precyzyjnie definiują problem, szeroko generują pomysły, szybko prototypują, testują z udziałem szczerego feedbacku i wdrażają rozwiązania, dalej je iterując.

Machine learning wzmacnia dziś każdy z tych etapów. Przetwarzanie języka naturalnego wydobywa problemy ukryte w tysiącach komentarzy użytkowników, które umknęłyby przy kilku wywiadach. Grupowanie oparte na danych pokazuje, które problemy naprawdę mają największe znaczenie. Generatywna AI poszerza zakres pomysłów, które zespół bierze pod uwagę.

Prototypy, które kiedyś powstawały tygodniami, dziś można przygotować w kilka minut. Eksperymenty na dużą skalę w dużej mierze zastąpiły małe testy z użytkownikami. Pipeline'y MLOps utrzymują powstałe modele w aktualności po wdrożeniu. Ta sama siła niesie jednak nowe ryzyka:

• Tradycyjny produkt po wdrożeniu pozostaje stabilny. 

• Produkt AI cały czas się zmienia w rękach użytkowników. 

• Silnik rekomendacji dostosowuje się do sposobu przeglądania treści. 

• Chatbot zmienia się z każdą rozmową. 

• Model wykrywania oszustw ewoluuje tak samo jak przestępcy.

Bez nadzoru te systemy zaczynają dryfować. Mogą po cichu wzmacniać uprzedzenia wpisane w stare dane treningowe albo zacząć optymalizować się pod własne wcześniejsze wyniki zamiast pod ludzi, którzy z nich korzystają. Podejście skoncentrowane na człowieku staje się tym ważniejsze, im większą część procesu przejmuje AI, właśnie dlatego, że system nadal się zmienia długo po wdrożeniu.

Czym jest MLOps i dlaczego zwinne tworzenie rozwiązań AI go potrzebuje?

Design thinking sprawia, że produkty AI zaczynają się od właściwie zdefiniowanego problemu. MLOps sprawia, że nie zatrzymują się, zanim dotrą do użytkowników. MLOps wnosi dyscyplinę DevOps do całego cyklu życia machine learningu przez ciągłą integrację, wdrażanie i monitoring, dzięki czemu rozwój modeli staje się powtarzalny.

Data scientiści skupiają się na dokładności modeli. Data engineerowie budują pipeline'y zasilające te modele. Projektanci i product managerowie dbają o to, czy efekt da się wygodnie wykorzystywać na co dzień. Bez wspólnego sposobu pracy modele zostają w notatnikach, pipeline'y nie skalują się, a potrzeby użytkowników giną przy przekazywaniu pracy między zespołami.

Agile wnosi elastyczność. Lean wnosi dyscyplinę w ocenie tego, co w ogóle warto budować. MLOps staje się kręgosłupem, który zamienia eksperymenty w systemy produkcyjne, na których ludzie mogą polegać. Razem te podejścia tworzą Design-Driven MLOps.

Cztery filary Design-Driven MLOps

Design-Driven MLOps opiera się na elementach, które wzajemnie się wzmacniają. Celem są produkty AI, które się skalują i pozostają użyteczne długoterminowo, zamiast być tylko sprytnymi demonstracjami, które nigdy nie wychodzą z laboratorium.

1. Zrozumienie człowieka

Wszystko zaczyna się od ludzi: od wejścia w realny kontekst użytkowników, obserwowania ich rzeczywistych zachowań i sprawdzania, czy pomysły z nimi rezonują, zanim zostaną skalowane z użyciem machine learningu. W praktyce wspierają to analityka bezpieczna dla prywatności i zautomatyzowane śledzenie ścieżek użytkownika. Pętle feedbacku mogą tu uruchomić albo aktualizację projektu, albo ponowne trenowanie modelu, zależnie od tego, co pokażą dane.

2. Trafny priorytet

To tutaj myślenie Lean utrzymuje pracę nad AI przy ziemi: pozwala szybko testować, uczyć się na podstawie danych i odrzucać wszystko, co nie przynosi efektu. Największą pracę wykonują dashboardy kosztowe, metryki efektywności modeli i automatyczne skalowanie. Razem nie pozwalają, by eksperymentowanie zamieniło się w wymykający się spod kontroli rachunek za infrastrukturę.

3. Zwinny przepływ pracy

Projektowanie i dostarczanie przebiegają tu równolegle, w krótkich sprintach i przy współpracy międzyfunkcyjnej. Pipeline'y CI/CD sprawdzają regresje UX równolegle z wydajnością modeli w miarę postępu prac. Wspólne dashboardy pokazują w jednym miejscu metryki projektowe, modelowe i infrastrukturalne.

4. Skalowalny kręgosłup

Warstwa MLOps leży pod wszystkim pozostałym: to zautomatyzowane pipeline'y, wersjonowanie modeli, monitoring i governance, które pozwalają wynieść eksperymenty do środowiska produkcyjnego. Metryki techniczne i te dotyczące doświadczeń użytkownika działają obok siebie w tym samym systemie alertów. Nikt nie musi sprawdzać dwóch osobnych dashboardów, żeby zobaczyć pełny obraz.

Te filary działają razem jako jeden system. Pominięcie Zrozumienia człowieka i Trafnego priorytetu grozi zbudowaniem czegoś, czego nikt nie potrzebował. Pominięcie Skalowalnego kręgosłupa sprawia, że nawet najlepiej zaprojektowany produkt zostaje w notatniku i nie da się go skalować. 

Pięć faz Design-Driven MLOps

Produkty AI działają inaczej niż tradycyjne oprogramowanie. Wdrożona funkcja zwykle zachowuje się przewidywalnie, podczas gdy wdrożony model nadal się uczy, dryfuje i zużywa infrastrukturę w sposób, który wymusza biznesowe kompromisy. Ten model obejmuje pięć faz zaprojektowanych właśnie z myślą o tej różnicy.

1. Odkrywanie i empatia

Badania użytkowników, uzgodnienie z interesariuszami i audyt danych tworzą tu fundament, sprawdzając, czy dostępne dane rzeczywiście pozwalają zbudować rozwiązanie oparte na machine learningu. Ta faza wcześnie wychwytuje zły kierunek. Dzięki temu nie przepalasz miesięcy pracy inżynierskiej na coś, co od początku nie miało sensu.

2. Ideacja i prototypowanie

Projektanci szkicują tu koncepcje, a inżynierowie ML prowadzą małe eksperymenty, testując architektury i wstępne relacje kosztów do korzyści. Wszystko dzieje się szybko i celowo. Celem jest tanie potwierdzenie założeń, zanim ruszy budowa gotowego systemu. 

3. Rozwój i budowa

Zwinne sprinty integrują tu modele z rzeczywistymi funkcjami, obejmując zarządzanie data pipeline'ami oraz strojenie pod kątem dokładności, opóźnień i kosztów. Pipeline'y CI/CD, automatyczne testy i wersjonowanie modeli sprawiają, że tę fazę da się powtarzać. Taka dyscyplina ma dziś jeszcze większe znaczenie, skoro tak duża część tego kodu od początku jest generowana przez AI.

4. Walidacja i iteracja

Modele dryfują, bo zmieniają się zachowania i dane, na których działają, dlatego ta faza tak naprawdę nigdy się nie kończy. Testy A/B, monitoring dryfu, audyty stronniczości i przegląd z udziałem człowieka utrzymują system w ryzach. Koszt jest też stale zestawiany z wydajnością, bo niewielki wzrost dokładności rzadko uzasadnia nieproporcjonalny skok kosztów obliczeniowych.

5. Skalowanie i governance

Śledzalność, bezpieczeństwo i kontrola zgodności z przepisami towarzyszą tu skalowaniu infrastruktury. Wzrost nigdy nie wyprzedza zdolności organizacji do wyjaśnienia, co robi system. To właśnie zamienia działający model w model, któremu naprawdę można zaufać.

W praktyce te fazy rzadko układają się w prostą linię. Zespoły często wracają do etapu Odkrywanie i empatia w środku projektu, szczególnie gdy model odchyli się na tyle, że pojawią się nowe pytania o pierwotne założenia dotyczące danych. Ten powrót jest dokładnie tym, do czego ten model został stworzony. 

Czym jest vibe coding i zasada ograniczonego zaufania?

Faza „Rozwój i budowa” opiera się na przeglądzie wyników AI przed wdrożeniem. Tymczasem coraz częściej mówi się o zjawisku „vibe coding”, czyli przyjmowaniu kodu wygenerowanego przez AI bez przeglądu. To odpowiednik tego samego błędu, na który Design-Driven MLOps odpowiada na poziomie produktu, tylko że tutaj widać go w kodzie.

Ten schemat brzmi znajomo. Model bez nadzoru człowieka oddala się od tego, czego użytkownicy naprawdę potrzebują. Kod bez ludzkiego przeglądu niesie podobne ryzyko. Narzędzia AI halucynują logikę, która nigdy nie istniała, i pomijają obsługę błędów dla nieprzewidzianych przypadków. Mogą też wprowadzać luki bezpieczeństwa, które przejdą każdy automatyczny test, aż ktoś je wykorzysta.

Większość profesjonalnych programistów już intuicyjnie to rozumie. Najnowsze dane z badania Stack Overflow pokazują, że deweloperzy nadal ostrożnie podchodzą do czystego „vibe codingu” w pracy zawodowej, co odzwierciedla obawy przed poleganiem na nieprzejrzanym kodzie generowanym przez AI i jego wpływem na jakość kodu w dłuższej perspektywie. 

Tak w praktyce działa zasada ograniczonego zaufania. Wyniki AI zdobywają zaufanie dzięki weryfikacji, tak samo jak prognozy modelu zdobywają zaufanie dzięki walidacji. Zespół pracujący zgodnie z Design-Driven MLOps stosuje tę zasadę na każdej warstwie.

Wnioski z badań użytkowników weryfikuje się z udziałem prawdziwych użytkowników, a prognozy modeli sprawdza się względem ground truth. Kod wygenerowany przez AI trafia do scalenia dopiero wtedy, gdy ktoś naprawdę go przejrzy i zrozumie. Zmienia się warstwa. Podstawowa dyscyplina pozostaje dokładnie taka sama.

Praktyczne przykłady połączenia design thinking i machine learningu

Same modele mają mniejsze znaczenie niż to, do czego prowadzą. Kilka przykładów pokazuje, jak to wygląda poza tablicą i warsztatami.

IBM

IBM wykorzystał design thinking na dużą skalę, aby zmienić globalne wsparcie IT. Zespoły wsparcia bezpośrednio wskazały frustracje agentów i klientów. Firma wykorzystała też machine learning na milionach wcześniejszych zgłoszeń, by odkryć wzorce przyczyn źródłowych, których człowiek nie byłby w stanie przeanalizować ręcznie. Ten proces doprowadził do stworzenia konwersacyjnej AI opartej na realnych potrzebach użytkowników.

Ford

Inicjatywa Smart Mobility Forda połączyła dane telemetryczne, zbierane przez niewielki adapter montowany w samochodzie, z pracą nad projektowaniem skoncentrowanym na człowieku prowadzoną przez IDEO. Dane ujawniły wzorce pokazujące, jak ludzie rzeczywiście jeżdżą. Design thinking przełożyło te wzorce na koncepcję ubezpieczenia pay-as-you-go, opartą na rzeczywistym stylu jazdy.

PillPack

Zanim przejął go Amazon, PillPack zbudował cały swój biznes na empatii wobec pacjentów, którzy muszą godzić wiele recept naraz. Mapowanie ścieżki użytkownika ujawniło codzienne punkty tarcia. Machine learning przewidywał potem terminy kolejnych uzupełnień leków i automatyzował dostawy. Pacjenci mieli dzięki temu zauważalnie mniej złożoności do ogarnięcia.

Architech

Architech zaczął od wywiadów z użytkownikami, aby zidentyfikować niejasności związane z utrzymaniem najmu. Następnie wykorzystał machine learning do analizy historycznych danych leasingowych i wskazania głównych czynników wpływających na utrzymanie klientów. Powstały dashboard odniósł sukces głównie dlatego, że menedżerowie bez technicznego zaplecza mogli z niego łatwo korzystać na co dzień.

Design-Driven MLOps z partnerem outsourcingowym

Outsourcing może przyspieszyć tworzenie rozwiązań AI, o ile stoi za nim prawdziwa dyscyplina. Produkty AI wymagają ścisłej, ciągłej współpracy projektantów, programistów, data scientistów i data engineerów. Wymagają też dyscypliny potrzebnej do monitorowania i ponownego trenowania modeli jeszcze długo po wdrożeniu.

Cztery rzeczy odróżniają partnera, który to zapewnia, od takiego, który tego nie robi:

• Transparentny proces oznacza jasne sprinty, widoczne mapy drogowe i współdzielone narzędzia, dzięki którym postęp jest stale widoczny dla obu stron.

• Sprawczość zespołu oznacza, że klienci uczestniczą w warsztatach projektowych i przeglądach modeli, obserwując pracę na żywo zamiast czekać na comiesięczne podsumowanie.

• Narzędzia governance oznaczają pipeline'y CI/CD, wersjonowanie danych i modeli oraz monitoring stronniczości wbudowane od pierwszego dnia, a także ciągłe testowanie modeli przez cały okres ich działania.

• Warsztaty uzgadniające na starcie łączą wizję, potrzeby użytkowników, wykonalność techniczną i tolerancję ryzyka, zanim ktokolwiek zacznie budować, dzięki czemu presja biznesowa nie prowadzi do powstania kosztownego modelu, którego nikt nie potrzebował.

Właściwy partner traktuje te cztery praktyki jako punkt wyjścia i wpisuje je we współpracę od pierwszej rozmowy. To właśnie ta dyscyplina odróżnia dostawcę kodu od partnera, który buduje coś trwałego. Outsourcing działa wtedy, gdy przejmuje te same nawyki weryfikacji, od których zależy cały ten model. 

Jak działa design thinking w erze AI?

Design-Driven MLOps zamienia AI z medialnego szumu w trwały wpływ, osadzając złożoność w klarowności, innowację w empatii, a skalę w trwałości.

Prawdziwa siła AI nigdy nie będzie wynikać wyłącznie z samych algorytmów. Bierze się z tego, jak dobrze organizacje potrafią ukierunkować tę moc na realne ludzkie potrzeby. AI spełnia swoją obietnicę wtedy, gdy rozwiązuje rzeczywisty problem i wpisuje się w istniejące przepływy pracy. Zdobywa zaufanie osób, które z niej korzystają, jeden zweryfikowany wynik po drugim.

Organizacje, które wygrają tę dekadę, nie będą tymi z najbardziej zaawansowanymi modelami AI. Będą nimi te, które wbudowały weryfikację w każdą warstwę procesu, od pierwszego wywiadu z użytkownikiem po ostatnią linijkę kodu wygenerowanego przez AI.

Jeśli tworzysz produkt AI i szukasz partnera, dla którego ludzki nadzór jest elementem podstawowej infrastruktury, zespół AI Monterail pomoże ci dobrze to zaplanować.