Od POC do produkcji

Prototyp działa. Demonstracja przechodzi bez potknięcia, na sali padają dobre pytania, ktoś rzuca, że to zmieni sposób pracy całego działu. Trzy miesiące później nikt nie pamięta, gdzie był ten link. Scenariusz powtarza się na tyle regularnie, że przestaje być pechem pojedynczego zespołu i staje się właściwością sposobu, w jaki prowadzone są prototypy.

Skala zjawiska

W lipcu 2024 Gartner prognozował, że do końca 2025 co najmniej 30% projektów generatywnej AI zostanie porzuconych po fazie POC (proof of concept), czyli prototypu, który ma wyłącznie pokazać, że pomysł da się zrealizować.¹ Jako przyczyny wskazano słabą jakość danych, niewystarczające mechanizmy kontroli ryzyka, rosnące koszty oraz niejasną wartość biznesową. Prognoza nie dostała publicznego rozliczenia, więc traktujemy ją jako opis mechanizmu, nie jako pomiar rynku.

Kierunek zgadza się z tym, co widać w projektach: bariera rzadko stoi po stronie modelu. Stoi w miejscach, które w prototypie świadomie pominięto, żeby było szybciej.

Definicja sukcesu spisana przed startem

Najtańsza rzecz, jaką można zrobić dla losu prototypu, zajmuje pół strony i powstaje przed pierwszą linijką kodu. Jedna metryka, próg liczbowy, sposób pomiaru i nazwisko osoby, która ten wynik akceptuje.

Zamiast „sprawdzimy, czy AI poradzi sobie z weryfikacją dokumentów”, zapis brzmi:

Na 100 sprawach wylosowanych z ostatniego kwartału ekstrakcja kluczowych pól ma być poprawna w ponad 90%, a średni czas weryfikacji ma spaść z 14 minut do poniżej 5.

Bez tego prototyp kończy się dyskusją, czy wynik jest „wystarczająco dobry”, a takiej dyskusji nie da się wygrać, bo każdy uczestnik ma w głowie inny próg.

Kompromis jest realny: na starcie często nie wiadomo, jaki próg jest w ogóle osiągalny. W takiej sytuacji warto wpisać próg wstępny razem z datą jego rewizji. Liczba do poprawienia działa lepiej niż brak liczby.

Dane produkcyjne, nie testowe

Prototypy testuje się zwykle na próbce, którą ktoś wcześniej uporządkował: czyste skany, komplet pól, przypadki typowe. Produkcja wygląda inaczej. Skan obrócony o 90 stopni, dwa dokumenty w jednym PDF, dopisek odręczny na marginesie, plik z 2019 roku w nieaktualnym szablonie, pole wypełnione w sposób, którego nie przewidywał żaden formularz.

Praktyczna zasada: próbka losowana z realnego strumienia, z zachowaniem ogona dziwnych przypadków. Zestaw wybrany ręcznie przez osobę, która chce pokazać działający wynik, mówi wyłącznie o tym zestawie. Jeżeli dane nie mogą opuścić organizacji, prototyp powstaje w środowisku organizacji. Anonimizacja i uzgodnienie podstawy przetwarzania zajmują tygodnie, więc ten wątek warto uruchomić w pierwszym tygodniu prac.

Bywa, że na starcie dostępne są wyłącznie dane syntetyczne. Wtedy pierwszy wynik traktujemy jako sygnał o wykonalności technicznej, a rozmowę o jakości odkładamy do momentu, w którym pojawi się próbka z produkcji.

Właściciel biznesowy z własnym interesem

Sponsor, który „popiera temat”, nie wystarczy. Potrzebny jest właściciel, czyli osoba, której wskaźniki zmienią się, jeśli rozwiązanie zadziała, która przydzieli czas swoich ludzi na testy akceptacyjne i która ma mandat do zmiany procesu.

Test jest prosty: czyje liczby w raporcie kwartalnym będą wyglądać inaczej. Jeśli odpowiedź nie pada w ciągu kilku sekund, prototyp nie ma adresata. Dział IT zbuduje rozwiązanie i utrzyma je, natomiast nie odbierze wyniku biznesowego za kogoś, kto tego wyniku nie potrzebuje.

Ten punkt tłumaczy sporą część porzuconych prototypów. Powstały z ciekawości technologicznej, w oderwaniu od konkretnego problemu, który ktoś naprawdę chciał rozwiązać.

Bezpieczeństwo od pierwszego dnia

Trzy pytania warto zadać już na starcie prototypu, zamiast odkładać je do momentu przekazania na produkcję. Gdzie trafiają dane i na jakiej umowie. Kto ma dostęp do logów, promptów i wyników. Kto utrzyma to rozwiązanie za 18 miesięcy i z jakiego budżetu.

Trzydziestominutowa rozmowa z bezpieczeństwem i działem prawnym w pierwszym tygodniu kosztuje mniej niż odkrycie w ósmym tygodniu, że wybrany dostawca modelu nie przejdzie oceny ryzyka. W organizacjach objętych regulacjami dochodzi do tego klasyfikacja systemu, ocena skutków dla ochrony danych i dokumentacja, która ma przetrwać audyt. Konkretne obowiązki warto potwierdzić z właściwym doradcą.

Utrzymanie bywa pomijane jeszcze częściej niż bezpieczeństwo. Wersje modeli się zmieniają, jakość promptów degraduje się przy zmianie danych wejściowych, integracje się psują. Rozsądnie jest założyć stałą roczną pozycję budżetową na utrzymanie, zamiast traktować wdrożenie jako koszt jednorazowy.

Data decyzji: skalować czy zamknąć

Data decyzji powinna być ustalona razem z zakresem prototypu. W praktyce sprawdza się okno sześciu do ośmiu tygodni i trzy możliwe rozstrzygnięcia: skalujemy, poprawiamy jeden konkretny element i powtarzamy pomiar raz, albo zamykamy.

Zamknięcie jest normalnym rozstrzygnięciem i warto raportować je jako wynik pomiaru, bez etykiety porażki zespołu. Najgorszy scenariusz to prototyp, który dryfuje przez pół roku, aż wszyscy przestaną o nim mówić. Nikt wtedy niczego się nie uczy, a organizacja zapamiętuje jedynie, że „AI u nas nie działa”.

Przy zamknięciu przydaje się jednostronicowa notatka: co sprawdzano, jaki był wynik wobec progu, co zrobilibyśmy inaczej. Trzy takie notatki po roku są warte więcej niż jeden prototyp, który nigdy nie dostał werdyktu.

Co z tego wynika

Wszystkie pięć punktów kosztuje niewiele: kilka rozmów, jedna strona zapisu, jedna próbka danych i wpisana w kalendarz data decyzji. Pominięcie ich skraca start o tydzień i regularnie odbiera wartość trzem kolejnym miesiącom pracy.

Warto też zacząć od problemu, zanim wybierze się narzędzie. Jeżeli sukces prototypu nie zmieni żadnej liczby, na której komuś zależy, wynik techniczny pozostanie ciekawostką.

Footnotes

1. Gartner, prognoza z 29 lipca 2024 o porzucaniu projektów generatywnej AI po fazie proof of concept: https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025. ↩