AI od pilotażu do produkcji: dlaczego większość pilotaży grzęźnie i jak to naprawić

Demo było łatwą częścią

Większość firmowych inicjatyw AI przebiega według tego samego schematu: pilotaż robi wrażenie na demo, zarząd zatwierdza kolejny etap, a potem projekt spędza miesiące w stanie ani martwym, ani wdrożonym. Według większości szacunków znacznie ponad połowa pilotaży nigdy nie trafia na produkcję; nasze doświadczenie projektowe to potwierdza. Przyczyną zastoju rzadko jest model. Jest nią wszystko to, czego demo nigdy nie musiało przetrwać — nieuporządkowane dane produkcyjne, złośliwe dane wejściowe, limity kosztów, wymagania audytowe i użytkownicy, których nie było na spotkaniu otwierającym.

Korekta zaczyna się od zmiany perspektywy. Pilotaż dowodzi, że dana zdolność istnieje. Produkcja wymaga dowodu, że system zachowuje się akceptowalnie pod realnym obciążeniem, na realnych danych i przy realnych trybach awarii — a to problem inżynierii systemów, nie data science.

Dobór przypadków użycia według kosztu błędu

Najbardziej brzemienna w skutki decyzja zapada, zanim powstanie choćby linijka kodu. Pilotaże budowane wokół najefektowniejszego demo zwykle grzęzną; te budowane wokół akceptowalnego trybu awarii zwykle trafiają na produkcję. Cztery filtry wykonują większość pracy:

• Istnieje mierzalny punkt odniesienia — minuty na sprawę, koszt na zgłoszenie, wielkość zaległości — dzięki czemu poprawa jest liczbą, a nie opinią.
• Błędy są odwracalne: błędny szkic trafia do weryfikacji, błędna klasyfikacja jest korygowana na dalszym etapie, a żaden pojedynczy wynik nie uruchamia nieodwracalnego działania.
• Punkt kontroli przez człowieka naturalnie wpisuje się w przepływ pracy, zamiast być doklejanym po fakcie ze względów zgodności.
• Wolumen jest na tyle duży, że wzrost efektywności o 30–50% uzasadnia inwestycję inżynierską.

Proszę zwrócić uwagę, czego tu brakuje: nowości. Najlepszy pierwszy produkcyjny przypadek użycia jest zwykle tym najmniej efektownym.

Fundamenty danych wyznaczają sufit

Niezależnie od architektury — retrieval-augmented generation, fine-tuning czy ekstrakcja strukturalna — sufit jakości wyznaczają dane, nie wybór modelu. Najwięcej ważą trzy fundamenty. Po pierwsze, kontrola dostępu musi być egzekwowana w momencie wyszukiwania: jeśli użytkownik nie może otworzyć dokumentu, system nie może mieć możliwości zacytowania go w odpowiedzi, a żadna instrukcja na poziomie promptu nie zastąpi weryfikacji uprawnień w warstwie wyszukiwania. Po drugie, aktualność i pochodzenie danych: system musi wiedzieć, którą wersję polityki czy cennika czyta, inaczej będzie z pełnym przekonaniem odpowiadał na podstawie nieaktualnych danych. Po trzecie, obsługa danych wrażliwych — maskowanie danych osobowych, zasady retencji, wymogi dotyczące miejsca przechowywania danych — musi być zaprojektowana przed pierwszą integracją, bo dokładanie jej później oznacza przebudowę pipeline'ów.

Ewaluacja oddziela dema od systemów

Najsilniejszym predyktorem tego, czy pilotaż trafi na produkcję, jest w naszym doświadczeniu istnienie środowiska ewaluacyjnego. Zespoły, które oceniają jakość, przewijając wyniki, nie potrafią odpowiedzieć na jedyne pytanie, które liczy się przy przeglądzie: czy ta zmiana uczyniła system lepszym, czy gorszym?

• Zanim zaczną Państwo cokolwiek stroić, należy zbudować golden dataset z prawdziwych przypadków — kilkaset danych wejściowych ze zweryfikowanymi, oczekiwanymi wynikami.
• Ewaluacje uruchamia się przy każdej zmianie promptu, modelu lub wyszukiwania, w CI — dokładnie tak jak zestaw testów regresyjnych.
• Ocenę warto automatyzować tam, gdzie to możliwe, ale automatycznych sędziów trzeba kalibrować okresowym przeglądem przez człowieka, aby wyniki wciąż coś znaczyły.
• Jakość należy śledzić także na produkcji, nie tylko przed wdrożeniem: wyrywkowy przegląd przez człowieka i opinie użytkowników są częścią systemu, a nie dodatkiem.

Zabezpieczenia i wzorce integracji

W architekturze produkcyjnej model jest zawodną zależnością zewnętrzną i tak też należy go integrować: timeouty, ograniczone ponawianie na operacjach idempotentnych oraz deterministyczna ścieżka awaryjna na wypadek, gdy model zawiedzie lub obniży jakość. Interfejs warto ograniczyć z obu stron — walidować i oczyszczać dane wejściowe, wymagać wyników zgodnych ze schematem i walidowanych przed użyciem, zamiast wolnego tekstu parsowanego na wiarę, oraz przyznawać modelowi najwęższy dostęp do narzędzi, na jaki pozwala przypadek użycia. Wyniki, które uruchamiają działania — zapisy, e-maile, transakcje — przechodzą przez warstwę autoryzacji traktującą wynik modelu jak niezaufane dane wejściowe od użytkownika, bo dokładnie tym one są.

Model operacyjny, nie projekt

Pilotaże są projektami; systemy produkcyjne są produktami. Ktoś musi po starcie odpowiadać za jakość, koszty i incydenty: wersje modeli i promptów są przypięte i zmieniane wyłącznie w drodze przeglądu, koszt pojedynczego żądania jest budżetowany i monitorowany, a na noc, w której dostawca zawiedzie, istnieje dyżur. Zespoły, które przydzielają tę odpowiedzialność przed uruchomieniem, zachowują swoje systemy; te, które tego nie robią, patrzą, jak jakość dryfuje, aż ktoś po cichu wyłączy funkcję.

Tym, co odblokowuje ugrzęźnięty pilotaż, rzadko jest lepszy model. Jest nim węższy przypadek użycia, prawdziwe środowisko ewaluacyjne, zabezpieczenia zakładające awarię i imiennie wskazany właściciel. Nic z tego nie jest efektowne — ale właśnie to zamienia demo w infrastrukturę.