Od PoC do produkcie: prečo väčšina AI projektov nikdy nedobehne

Demo trvalo tri týždne a vyzeralo skvele. Odvtedy prešlo osem mesiacov a stále to nie je v produkcii. Ak vám to je povedomé, nie ste v tom sami — a nie je to vaša chyba. Cesta z prototypu do prevádzky je iná disciplína než postavenie prototypu a väčšinou sa na ňu zabudne pri plánovaní rozpočtu.

Tu je, čo v tom priestore skutočne treba urobiť.

Prečo je demo klamlivé

Prototyp sa robí na dátach, ktoré niekto vybral. Väčšinou nevedomky vyberie tie, ktoré dávajú zmysel — čitateľné, kompletné, typické. V produkcii príde e-mail bez predmetu, faktúra odfotená pod uhlom a objednávka s poznámkou, ktorá popiera zvyšok správy.

Prototyp tiež testuje jeden človek, ktorý vie, čo od systému čakať, a nevedome sa pýta tak, aby to fungovalo. Sto používateľov sa pýta inak.

A do tretice: prototyp nemá cenovku za prevádzku. Kým ho používate vy, náklady sú zanedbateľné. Pri tisícke požiadaviek denne je to iný rozhovor.

Krok 1: evaluácie, skôr než čokoľvek iné

Toto je najdôležitejšia veta celého článku: kým nemáte spôsob, ako zmerať kvalitu, nemá zmysel nič optimalizovať.

Evaluácia je sada vstupov s očakávanými výstupmi, ktorá sa spustí automaticky pri každej zmene. Znie to ako testy v bežnom softvéri, lebo to testy sú — len s tým rozdielom, že výstup nie je deterministický, takže sa hodnotí presnosť, nie zhoda.

Bez nej vyzerá vývoj takto: zmeníte prompt, dve veci sa zlepšia, jedna sa nenápadne pokazí a zistíte to o tri týždne od zákazníka. S ňou: zmeníte prompt, uvidíte číslo, rozhodnete sa.

Praktické minimum je 30–50 reálnych prípadov so správnym výsledkom. Nie vymyslených — reálnych, vrátane tých škaredých. Práve tie škaredé sú dôvod, prečo evaluácie robíme.

Krok 2: čo sa stane, keď to zlyhá

Prototyp nemá stavy zlyhania. Produkčný systém ich musí mať pre každý z týchto prípadov:

• Poskytovateľ modelu má výpadok. Máte záložného? Alebo aspoň zmysluplnú chybovú hlášku namiesto nekonečného točenia?
• Odpoveď príde v zlom formáte. Opakujete pokus? Koľkokrát? Čo potom?
• Model si nie je istý. Existuje fronta na človeka, alebo sa tvárime, že si istý je?
• Požiadavka trvá príliš dlho. Máte timeout a vie o ňom používateľ?

Väčšina týchto vecí sa v prototype rieši tak, že sa nerieši. V produkcii sú to práve ony, čo rozhoduje o dôvere používateľov.

Krok 3: náklady, kým vás prekvapia

Účet za tokeny má nepríjemnú vlastnosť: rastie s používaním, teda s úspechom. Čím lepšie to funguje, tým viac to stojí.

Čo s tým robíme v praxi:

• Cachovanie. Opakujúce sa časti kontextu (systémový prompt, dokumentácia) sa nemusia posielať zakaždým celé.
• Kratší kontext. Posielať dvadsať nájdených dokumentov, keď stačí päť, je zbytočne drahé aj menej presné.
• Smerovanie na menší model. Jednoduché požiadavky nepotrebujú najväčší model. Klasifikácia zložitosti na začiatku býva veľmi návratná.
• Limity a alerty. Denný strop a upozornenie pri prekročení. Toto je päť minút práce a raz za čas ušetrí nepríjemné prekvapenie.

Krok 4: verzionovanie, aby sa dalo vrátiť

Prompt je kód. Model je závislosť. Oboje sa mení a oboje musí byť verzionované.

Konkrétne to znamená, že pri každej odpovedi v produkcii viete povedať, ktorá verzia promptu a ktorý model ju vygenerovali. Bez toho sa hlásenie „minulý týždeň to fungovalo lepšie" nedá overiť ani opraviť.

Zároveň: keď poskytovateľ modelu vydá novú verziu, nespoliehajte sa, že bude lepšia vo vašom prípade. Preevaluujte. Videli sme prípady, keď novšia verzia bola celkovo silnejšia, ale na konkrétnej úzkej úlohe horšia.

Krok 5: kto to bude prevádzkovať

Najtichšia príčina neúspechu. Riešenie sa nasadí, dodávateľ odíde a vo firme nie je nikto, kto by vedel zmeniť prompt alebo pozrieť logy. Po pol roku sa systém vypne, lebo „nefunguje" — pričom nikto nezistil prečo.

Do odovzdania preto patrí runbook: čo robiť pri výpadku, kde sú logy, ako sa nasadí zmena, koho volať. A zaškolenie človeka, ktorý to má na starosti.

Ako spoznať, že ste pripravení na produkciu

Kontrolný zoznam, ktorý používame:

• Vieme zmerať kvalitu na sade reálnych prípadov.
• Vieme, čo sa stane pri každom type zlyhania.
• Vieme, koľko stojí jedna požiadavka a máme nastavený strop.
• Vieme, ktorá verzia promptu a modelu je nasadená.
• Máme monitoring latencie, chybovosti a nákladov.
• Existuje človek vo firme, ktorý systém vlastní.

Ak zaškrtnete všetkých šesť, ste ďalej než väčšina.

Zhrnutie

Cesta z prototypu do produkcie nie je „už len nasadiť". Je to samostatná fáza, ktorá býva porovnateľne dlhá ako samotný vývoj — a práve jej vynechanie stojí za väčšinou AI projektov, ktoré sa po roku ticho vypnú.

Ak máte prototyp, ktorý sa bojíte pustiť do sveta, nasadenie a prevádzka AI je presne tá chýbajúca časť. Prevezmeme aj riešenie, ktoré staval niekto iný.