POC do produkcji - Dolina Śmierci

Świat dema vs świat produkcji

Twój pilotaż AI działa. Demo jest imponujące. Wszyscy są podekscytowani. Zarząd widział. CEO pokochał. Twój CTO powiedział „wdróżmy to”.

Potem próbujesz wdrożyć do produkcji i wszystko się psuje.

To dolina śmierci - tam umiera 80% projektów AI. Nie w pilotażu, gdzie wszyscy świętują. W luce między pilotażem a produkcją.

Świat dema: Czyste dane. Kontrolowane wejścia. Brak konsekwencji. Brak skali. Brak użytkowników. Brak presji kosztów. Brak zgodności. Brak zagrożeń bezpieczeństwa. Brak przypadków brzegowych.

Świat produkcji: Bałagan danych. Nieprzewidywalni użytkownicy. Wymogi skali. Realne koszty. Obowiązki zgodności. Zagrożenia bezpieczeństwa. Przypadki brzegowe, których nie przewidziałeś.

Luka między tymi dwoma światami to miejsce, gdzie projekty umierają. Oto 7 rzeczy, które się psują - i jak zapobiec każdej.

Pęknięcie 1: Jakość danych

W pilotażu użyłeś czystego CSV. Ktoś go wyeksportował, przefiltrował, sformatował. Był perfekcyjny.

W produkcji dane przychodzą z systemów live. Brakujące pola. Błędy kodowania. Duplikaty. Niespójne formaty. Pola opcjonalne w pilotażu, ale wymagane w produkcji. Pola istniejące w pilotażu, ale wycofane w produkcji.

Twój model był 95% dokładny na czystym CSV. Jest 70% dokładny na prawdziwych danych. To nie problem modelu - to problem danych.

Poprawka: Buduj potok danych przed modelem. Testuj na prawdziwych danych od pierwszego dnia. Nie czekaj na produkcję, by odkryć, że twoje „czyste” dane treningowe nie pasują do bałaganu produkcyjnego.

Pęknięcie 2: Opóźnienie (latency)

W demo odpowiedź wróciła w 2 sekundy. Wszyscy byli pod wrażeniem.

W produkcji, pod obciążeniem, z 50 jednoczesnymi użytkownikami, odpowiedź zajmuje 15 sekund. Użytkownicy rezygnują. Wracają do procesu ręcznego. AI jest „za wolne”.

Nikt nie zaprojektował pod skalę. Pilotaż działał na laptopie. Produkcja na serwerze za małym. API ma limity, których nikt nie uwzględnił. Baza wektorowa zwalnia wraz ze wzrostem.

Poprawka: Zdefiniuj SLA opóźnienia przed budową. „Odpowiedzi muszą być poniżej 3 sekund przy szczycie obciążenia”. Test obciążeniowy przed wdrożeniem. Jeśli nie spełniasz SLA, napraw architekturę, zanim użytkownicy ją zobaczą.

Pęknięcie 3: Obsługa błędów

W pilotażu, gdy model się mylił, data scientist uruchamiał go ponownie z innymi parametrami. Ręczna poprawka. Bez problemu.

W produkcji, gdy model się myli, widzi to użytkownik. Przepływ pracy się psuje. Brak fallbacku. Brak zjazdu z godnością. System albo działa perfekcyjnie, albo zawodzi całkowicie.

Poprawka: Zaprojektuj ścieżkę awaryjną przed ścieżką sukcesu. Co się dzieje, gdy AI się myli? Co się dzieje, gdy AI jest niedostępne? Co się dzieje, gdy API przekroczy limit czasu? Każdy tryb awarii potrzebuje reakcji, którą nie jest „pokaż użytkownikowi ekran błędu”.

Pęknięcie 4: Koszt

W pilotażu API kosztowało 50 €/miesiąc. Pomijalne. Nikt się nie martwił.

W produkcji, na skalę, API kosztuje 4500 €/miesiąc. Nikt nie modelował kosztu produkcji. Uzasadnienie biznesowe wyglądające świetnie na skali pilotażu wygląda fatalnie na skali produkcyjnej.

Dzieje się tak, bo użycie pilotażu jest niskie (kilku użytkowników, kilka zapytań), a produkcji wysokie (wszyscy użytkownicy, cały czas). Cennik API jest za token, a tokeny szybko się sumują.

Poprawka: Modeluj koszt przy 10-krotności oczekiwanego wolumenu przed budową. Jeśli matematyka nie działa przy 10x, nie zadziała przy 1x, gdy uwzględnisz wzrost. Rozważ cache’owanie, batchowanie i dobór modelu, by kontrolować koszty.

Pęknięcie 5: Monitoring i dryf

W pilotażu data scientist sprawdzał model ręcznie. Wszystko wyglądało dobrze.

W produkcji nikt nie patrzy. Model dryfuje po cichu. Dystrybucje danych się zmieniają. Dokładność spada. Nikt nie zauważa, aż klient zgłosi skargę albo miara spadnie.

Dryf modelu to cichy zabójca systemów AI. Model był poprawny przy starcie. Staje się błędny z czasem. Nie nagle - stopniowo. Zanim ktokolwiek zauważy, szkody są dokonane.

Poprawka: Monitoring od pierwszego dnia. Śledź dystrybucje wejść, dystrybucje wyjść, metryki dokładności i feedback użytkowników. Ustaw alerty dryfu. Zaplanuj regularne retrenowanie. Nie czekaj na problemy - wykrywaj je, zanim staną się widoczne.

Pęknięcie 6: Bezpieczeństwo

W pilotażu model działał na laptopie za firmowym firewallem. Bezpieczeństwo nie było problemem.

W produkcji system jest wystawiony na użytkowników, potencjalnie na internet. Ataki prompt injection. Wyciek danych przez model. Adwersarialne wejścia zaprojektowane, by manipulować wyjściami. PII w promptach wysyłanych do zewnętrznych API.

Systemy AI mają unikalne ryzyka bezpieczeństwa, których tradycyjne aplikacje webowe nie mają. Prompt injection może sprawić, że model ujawni systemowe prompty lub ominie zabezpieczenia. Dane wysłane do zewnętrznych API mogą naruszać GDPR lub umowy przetwarzania danych.

Poprawka: Przegląd bezpieczeństwa przed wdrożeniem. Test na prompt injection. Upewnij się, że PII jest filtrowane przed wysłaniem do zewnętrznych API. Wprowadź rate limiting i walidację wejść. Traktuj system AI jak każdą inną aplikację wystawioną na internet - bo nią jest.

Pęknięcie 7: Zaufanie użytkowników

Budujący ufają systemowi. Go zbudowali. Znają jego ograniczenia.

Użytkownicy nie. Nigdy go nie widzieli. Nie wiedzą, kiedy mu ufać, a kiedy być sceptycznym. Nie wiedzą, do czego jest dobry, a do czego zły. Więc albo ufają mu za bardzo (i palą się, gdy się myli), albo wcale (i nadpisują każdą decyzję).

Oba wyniki zabijają adopcję. Jeśli użytkownicy nadpisują każdą decyzję AI, zbudowałeś drogi system, który nic nie robi. Jeśli ufają ślepo, stworzyłeś pasywo.

Poprawka: Angażuj użytkowników od startu. Pokazuj poziomy pewności. Wbuduj przejrzystość w UI - „znalazłem to w 3 dokumentach, oto źródła”. Pozwól użytkownikom dawać feedback. Buduj zaufanie przez szczerość, nie przez ukrywanie ograniczeń.

Przekraczanie doliny

Dolina śmierci nie dotyczy lepszych modeli. Dotyczy budowania systemów produkcyjnych, które zawierają AI.

System produkcyjny ma:

• Potoki danych obsługujące realne, bałaganiaste dane
• Infrastrukturę skalującą się
• Obsługę błędów i ścieżki awaryjne
• Zarządzanie kosztami
• Monitoring i detekcję dryfu
• Kontrole bezpieczeństwa
• Strategie zaufania użytkowników i adopcji

Jeśli twój pilotaż nie zawiera tego, to nie pilotaż. To demo. A dema nie przekraczają doliny.

Firmy, które wdrażają, traktują pilotaż jako pierwszy sprint systemu produkcyjnego, nie jako samodzielny eksperyment. Projektują pod produkcję od pierwszego dnia. Budują instalację obok modelu. Angażują użytkowników wcześnie. Planują porażkę.

FAQ

Jak długo zajmuje przejście doliny? 2-4 miesiące dla dobrze zaprojektowanego pilotażu. 6-12 miesięcy, jeśli pilotaż nie był zaprojektowany pod produkcję. Jeśli jesteś po 12 miesiącach, nie przekraczasz doliny - utknąłeś w niej.

Czy możemy pominąć POC i iść prosto do produkcji? Tylko jeśli masz wysoką pewność - czyli zrobiłeś audyt, twoje dane są gotowe i przypadek użycia jest dobrze zrozumiany. W przeciwnym razie POC to miejsce, gdzie odkrywasz to, czego nie wiesz.

Utkęliśmy w dolinie. Co robić? Zaudytuj projekt względem 7 punktów pęknięcia. Jeśli masz 3 lub więcej awarii, prawdopodobnie nie warto ratować. Zacznij od nowa z podejściem produkcja-najpierw. Jeśli masz 1-2 awarie, są naprawialne - ale napraw je przed skalowaniem.