Demo radi savršeno. Pokažete upravi ChatGPT-style sučelje koje odgovara na pitanja o vašim podacima, i svi su oduševljeni. “Lansirajte to”, kažu.

Šest mjeseci kasnije, još nije lansirano. Ne zato što AI ne radi — nego zato što ga učiniti pouzdanim, sigurnim i isplativim u produkciji potpuno je drugi problem. Tim koji je izgradio demo još uvijek otklanja rubne slučajeve. Pravnici traže ugovor o obradi podataka za koji niste znali da vam treba. Financijaši pitaju zašto je mjesečni račun za API tri puta veći od projekcije. A negdje, netko čeka odgovor na ticket koji je bot odgovorio s potpunom samouvjerenošću i potpunom netočnošću.

Evo što se ne spominje u demou.

Procjep između demoa i produkcije

Demo je kontrolirano okruženje. Vi birate ulaze. Znate izlaze. Publika vidi točno ono što želite da vidi.

Produkcija je kaos. Stvarni korisnici postavljaju pitanja koja niste predvidjeli. Unose podatke u formatima koje niste planirali. Očekuju odgovore u milisekundama, ne sekundama. A kada nešto pođe po krivu, ne pišu pristojan bug report — gube povjerenje.

Procjep između demoa i produkcije mjesto je gdje umire većina AI projekata. Premostiti ga zahtijeva engineering, ne samo data science. Zahtijeva istu disciplinu koju biste primijenili na bilo koji kritični sustav: monitoring, alerting, planove povratka, kapacitetno planiranje, sigurnosne preglede. Novost tehnologije nije razlog da ovo preskočite — razlog je da to shvatite još ozbiljnije, jer su načini propadanja manje poznati i teže ih je razumjeti.

Izazov 1: Latencija

LLM-ovi su spori. Tipičan GPT-4 odgovor traje 2–8 sekundi. Korisnici očekuju da web aplikacije reagiraju u manje od 500 milisekundi. To je razlika od 10 do 20 puta. Još gore, latencija nije fiksni broj — varira ovisno o opterećenju providera, zagušenosti modela i duljini konteksta koji šaljete. Odgovor koji je jučer trajao dvije sekunde danas može trajati sedam, i nema upozorenja kada se to dogodi.

Što stvarno treba napraviti:

  • Streamajte odgovore tako da korisnici odmah vide napredak
  • Cachirajte česte upite — ako je 30% pitanja slično, ne zovite LLM za svako
  • Koristite manje, brže modele za jednostavne zadatke i preusmjeravajte složene upite na veće modele
  • Pre-kalkulirajte odgovore za poznate obrasce pitanja u off-peak terminima
  • Razmislite o vlastito hostiranim modelima (Llama, Mistral) za slučajeve osjetljive na latenciju

Streaming je najjeftinije i najučinkovitije poboljšanje. Percipirana brzina odgovora puno je važnija od stvarnog ukupnog vremena — korisnici će oprostiti šestosekundnom odgovoru ako vide riječi kako se pojavljuju nakon pola sekunde, ali neće oprostiti tri sekunde praznog ekrana.

Izazov 2: Trošak

API pozivi LLM-ovima nisu besplatni. U scaleu, nisu ni jeftini. Jedan GPT-4 Turbo poziv košta otprilike 0,01–0,03 dolara. To zvuči zanemarivo dok ne pomnožite s tisućama dnevnih korisnika koji rade više upita. A brojevi postaju gori kada uračunate retryje, duge kontekste i razgovorni tok koji agentski obrasci često zahtijevaju.

Što stvarno treba napraviti:

  • Implementirajte agresivno cachiranje — semantičko pretraživanje sličnosti prije API poziva
  • Koristite najjeftiniji model koji zadovoljava kvalitetu za svaki zadatak
  • Postavite limite tokena i skraćujte kontekst gdje je moguće
  • Pratite trošak po korisniku i po upitu — tretirajte to kao infrastrukturu
  • Računajte s 3–5 puta većim troškom u produkciji u odnosu na pilot

Klopka u koju većina timova upadne jest pretpostavka da pilotska upotreba linearno preslikava na produkciju. Ne preslikava. Korisnici u produkciji otkrivaju rubne slučajeve koje pilot nikad nije pokrio — uploadaju ogromne dokumente, kopiraju cijele transkripte u prompt ili u petlji ponavljaju isti upit jer prvi odgovor nije bio dovoljno specifičan. Svako od tih ponašanja množi vaš račun, a nijedno se ne vidi u sređenim pilotskim podacima.

Izazov 3: Halucinacije

LLM-ovi izmišljaju. Iznose netočne informacije s potpunom samouvjerenošću. U demou ovo možete zamahnuti rukom. U produkciji — posebno u reguliranim industrijama — halucinacija je odgovornost. Jedan izmišljeni odgovor na pitanje korisnika, ako stigne do krive osobe, može postati incident sukladnosti, povrat novca ili medijska priča.

Što stvarno treba napraviti:

  • Implementirajte RAG (Retrieval Augmented Generation) za uzemljivanje odgovora u stvarnim podacima
  • Tražite citate — model mora referencirati konkretne dokumente
  • Izgradite slojeve provjere koji uspoređuju odgovore s izvornim podacima
  • Postavite pragove pouzdanosti — ako model nije siguran, treba to reći
  • Uvedite ljudski pregled za odgovore visokog rizika (pravo, financije, medicina)

Naučite model da odbije. AI asistent produkcijske kvalitete mora moći reći “ne znam” ili “to je izvan mog opsega” bez da to korisnik shvati kao kvar. Dobro dizajnirano odbijanje vrjednije je od uvjerljivog krivog odgovora jer čuva povjerenje. Prvi put kada korisnik uhvati vašeg asistenta da nešto izmišlja, prestaje vjerovati svemu drugom što kaže — i ta erozija je trajna.

Izazov 4: Sigurnost i privatnost podataka

Kada šaljete prompt LLM API-ju, šaljete potencijalno osjetljive podatke trećoj strani. Podatke o korisnicima, interne dokumente, vlasničke informacije — sve to teče kroz tuđe servere. Ovo nije teorijska briga. Vaš sigurnosni tim će prije ili poslije saznati, i razgovor je puno lakši ako ste to rješavali unaprijed nego ako naknadno krpate stvari nakon lansiranja.

Što stvarno treba napraviti:

  • Koristite providere s enterprise sporazumima o podacima (Azure OpenAI, AWS Bedrock)
  • Implementirajte uklanjanje PII-ja prije nego što podaci dospiju do modela
  • Razmislite o vlastito hostiranim modelima za vrlo osjetljive podatke
  • Logirajte koji se podaci šalju i primaju — treba vam audit trag
  • Pregledajte politike retencije podataka kod vašeg providera

Odluka između hostanog i vlastito hostiranog rješenja obično se vodi klasifikacijom podataka, ne tehničkom preferencijom. Ako podaci koje šaljete modelu mogu biti obrađeni od strane treće strane prema ugovoru, hostani API-ji su gotovo uvijek bolji izbor — brže ih je deployati, sposobniji su, a netko drugi održava infrastrukturu. Ako podaci ne smiju izaći iz vašeg perimetra, vlastito hostirano rješenje je jedini iskren odgovor, a kompromis je značajno viši operativni trošak.

Izazov 5: Monitoring i opservabilnost

Tradicionalni softver ili radi ili javlja grešku. LLM-ovi tiho zakazuju. Odgovor može biti gramatički savršen i činjenično pogrešan. Nema error koda za “AI je to izmislio”.

Što stvarno treba napraviti:

  • Logirajte svaki par prompt-odgovor
  • Implementirajte ocjenjivanje kvalitete — automatske provjere relevantnosti i točnosti
  • Postavite petlje povratnih informacija od korisnika — palac gore/dolje na odgovore
  • Pratite vrijeme odgovora, korištenje tokena i stope grešaka
  • Izgradite dashboarde koji prate metrike kvalitete kroz vrijeme, ne samo uptime

Tradicionalni alati za opservabilnost nisu građeni za ovo. Morate ih proširiti. To može značiti dodavanje sloja evaluacije koji uzorkuje produkcijske odgovore i ocjenjuje ih u odnosu na referentni dataset, ili izgradnju regression suitea koji se pokreće na svaku promjenu prompta. Bez toga, kvaliteta polako i nevidljivo skreće — model počinje malo gore raditi, korisnici prestaju vjerovati, a nitko u timu ne može odrediti kada je pad počeo.

Izazov 6: Krhkost promptova

Isti prompt može proizvesti potpuno različite rezultate ovisno o sitnim promjenama u formulaciji, duljini konteksta ili verziji modela. Ono što danas radi može se slomiti kada se model nadogradi. To je izazov koji iznenađuje čak i iskusne engineering timove jer izgleda kao tradicionalni softverski problem, a ponaša se kao nešto drugo — ne možete samo napisati unit test i smatrati ga riješenim.

Što stvarno treba napraviti:

  • Tretirajte promptove kao kod — držite ih u verzionskoj kontroli
  • Izgradite test suiteove za promptove s očekivanim ispisima
  • Pinjate verzije modela u produkciji — ne nadograđujte automatski
  • Implementirajte rezervne promptove za slučajeve kada primarni promptovi podbace
  • A/B testirajte promjene promptova prije globalnog deploya

Vlasništvo nad promptovima pitanje je koje vrijedi razjasniti rano. Promptovi sjede na sjecištu engineeringa, proizvoda i sadržaja — to je kod, ali i copy, a osoba koja napiše najbolji prompt nije uvijek osoba u engineering timu. Postavite radni proces koji omogućuje netehničkim ljudima da predlažu i testiraju promjene promptova, pa filtrirajte produkcijske deployeve kroz isti review proces kao i bilo koji drugi kod.

Produkcijska lista provjere

Prije nego što vaš AI ode u produkciju:

  • [ ] Latencija odgovora ispod 3 sekunde (uz streaming)
  • [ ] Stopa halucinacija izmjerena i ispod prihvatljivog praga
  • [ ] Trošak po upitu izračunat i unutar budžeta
  • [ ] Pregled privatnosti podataka završen
  • [ ] Monitoring i logiranje na mjestu
  • [ ] Ponašanje kod kvara definirano za slučajeve kada AI ne može odgovoriti
  • [ ] Mehanizam povratnih informacija korisnika izgrađen
  • [ ] Verzionska kontrola promptova uspostavljena
  • [ ] Load testiranje napravljeno na 2–3 puta očekivanog vrhunca prometa
  • [ ] Plan reagiranja na incident za AI-specifične kvarove

Suština

Izgraditi AI demo vikend je projekt. Izgraditi AI za produkciju engineering je disciplina. Tvrtke koje uspješno deployaju AI u produkciji tretiraju ga kao i bilo koji drugi kritični sustav — s monitoringom, testiranjem, sigurnošću i operativnom izvrsnošću. Također ga ekipiraju u skladu s tim. Prototip može voditi jedan inženjer sa strane. AI značajka u produkciji treba vlasnika, on-call rotaciju i jasnu eskalacijsku liniju za slučaj kada odgovori krenu nakrivo u 2 ujutro.

AI nije teški dio. Produkcijski engineering jest. A timovi koji to rano shvate — koji rezerviraju budžet za pravi posao prije euforije oko demoa — oni su ti čije AI značajke godinu dana nakon lansiranja i dalje rade i dalje su korisne.