Strukturirani izlazi AI chatbota: JSON Schema, validacija i sigurni alternativni scenariji

AI chatbot može formulirati uvjerljiv odgovor i svejedno oštetiti nizvodni proces. Polje koje nedostaje, izmišljena kategorija ili neprovjerena poveznica dovoljni su da CRM, sustav za tikete ili frontend web stranice obrade pogrešne podatke. Strukturirani izlazi AI chatbota smanjuju taj rizik tako što obvezujuće opisuju oblik i tipove podataka. Međutim, oni postaju pouzdani tek kada se shema, stručno značenje, ovlasti i slučajevi pogrešaka provjeravaju odvojeno.

Ovaj je vodič namijenjen timovima za web stranice, proizvode i operative koji strojno dalje obrađuju izlaze modela. On pokazuje što JSON Schema može pružiti, gdje su joj granice i kako izgraditi siguran put od odgovora modela do stvarne akcije.

Valjani JSON još uvijek nije pouzdan ugovor

Stariji JSON način rada mnogih API-ja modela uglavnom osigurava da se odgovor može parsirati kao JSON. On ne jamči da su očekivana polja prisutna ili da se poštuju dogovoreni tipovi. Službena OpenAI dokumentacija o Structured Outputs stoga izričito razlikuje valjani JSON od usklađenosti sa shemom. I Microsoft Foundry opisuje Structured Outputs kao vezanje odgovora uz poslanu JSON Schemu.

To je važan korak naprijed: umjesto da naknadno nagađa promjenjiva imena polja, aplikacija dobiva predvidljivu strukturu. Unatoč tome, pružatelji usluga često podržavaju samo dio pune specifikacije. Gemini dokumentacija za strukturirane izlaze navodi podržane tipove i svojstva, ali istovremeno ukazuje na podskupove i granice složenosti. Stoga se shema mora testirati za stvarno korišteni model i konkretni API put.

Shema opisuje oblik, a ne istinu

JSON Schema je deklarativni jezik za opisivanje strukture i ograničenja JSON podataka. Polje se, na primjer, može definirati kao obvezno polje, broj, nabrajanje (enum) ili niz (array). Međutim, iz toga ne slijedi da je vrijednost stručno točna. Niz znakova 2026-02-31 može formalno odgovarati kao tekst, iako taj datum ne postoji. Dopušteni ID proizvoda može biti sintaktički ispravan, a svejedno nepoznat u trenutnom klijentu (tenantu).

Za produkcijske chatbotove stoga je potrebno više slojeva provjere:

Sloj provjere	Tipično pitanje	Primjer
Transport	Je li odgovor potpun i može li se parsirati?	nema prekida usred JSON-a
Shema	Odgovaraju li polja, tipovi i dopuštene vrijednosti?	priority je samo low, medium ili high
Semantika	Je li sadržaj stručno logičan i interno konzistentan?	Datum završetka nije prije datuma početka
Pravila i pristup	Smije li ovaj korisnik vidjeti ili koristiti ovu vrijednost?	Tiket pripada autentificiranom računu klijenta
Kontekst izlaza	Prikazuje li se ili prosljeđuje vrijednost na siguran način?	Tekst se kodira za HTML, ne interpretira se kao skripta

Ova podjela sprečava zamjenu usklađenosti sa shemom sa stručnim odobrenjem. Za mjerenje i regresijsko testiranje, ona se može povezati s Zlatnim skupom (Golden Set) za kvalitetu odgovora AI chatbota.

Dizajniranje malih shema specifičnih za zadatak

Jedinstveni univerzalni objekt odgovora brzo postaje duboko ugniježđen, teško razumljiv i skup za održavanje. Bolja je mala shema po jasnom zadatku, kao što je klasifikacija povratnih informacija, predstrukturiranje upita podršci ili označavanje podataka koji nedostaju za dodatno pitanje. Ime i opis svakog polja trebali bi objasniti njegovo stručno značenje.

• Pažljivo birajte obvezna polja: Zahtijevajte samo vrijednosti koje proces stvarno treba. Nepoznate vrijednosti eksplicitno prikažite kao null ili vlastiti status, umjesto da dopustite njihovo izmišljanje.
• Koristite nabrajanja umjesto slobodnog teksta: Kratka, verzionirana lista sprečava varijacije u pisanju statusa, kategorije ili sljedećeg koraka.
• Odbijte dodatna polja: Tamo gdje pružatelj to podržava, additionalProperties: false sprečava neočekivane ključeve.
• Ponovite ograničenja u kodu aplikacije: Duljine, raspone vrijednosti, URL poslužitelje (hostove) i međuodnose nemojte prepustiti samo modelu ili podskupu sheme specifičnom za pružatelja.
• Verzionirajte shemu: Stabilna oznaka i sažetak (hash) čine vidljivim koji je ugovor generirao i provjerio odgovor.

Nepoznato je zasebno stanje

Prazno polje, polje koje nedostaje i izričito nepoznata vrijednost ne znače isto. Ako informacija nedostaje u izvoru, shema bi za to trebala predvidjeti dopušteno stanje. U suprotnom ugovor posredno nagrađuje model za umetanje uvjerljivog niza znakova. Za kritične vrijednosti, kombinacija value, status i opcionalnog reason često je pouzdanija od pojedinačnog polja sa slobodnim tekstom.

Zajedničko dokazivanje verzije i sažetka (hasha)

Uz odgovor stoga ne idu samo verzija modela i prompta, već i verzija sheme i verzija validatora. Sažetak (hash) stvarno poslane sheme štiti od tihog odstupanja uzrokovanog promjenama u buildu ili konfiguraciji. Prilikom migracije, isti izlaz modela može se najprije provjeriti prema obje verzije ugovora. Pisanje se i dalje odvija samo putem aktivnog puta; razlike završavaju ako usporedni podaci u QA-u.

Promptovi ne bi trebali prebacivati tajne ili interne odluke o ovlastima u shemu. Model može, na primjer, klasificirati željeni sljedeći korak. Je li taj korak dopušten, naknadno odlučuje poslužitelj na temelju trenutnog identiteta i pravila.

Tretiranje prekida i odbijanja kao zasebnih stanja

Strogo formatirani odgovor može izostati. Ograničenja izlaza, istek vremena (timeouts), filtri sadržaja, pogreške pružatelja ili namjerno odbijanje modela normalna su pogonska stanja. OpenAI za Structured Outputs dokumentira kako nepotpune odgovore, tako i zasebni put odbijanja koji ne mora nužno slijediti zatraženu shemu. Aplikacije stoga ne smiju slijepo pristupati prvom očekivanom polju.

Interna omotnica (envelope) neovisna o pružatelju razdvaja najmanje success, refused, incomplete, provider_error i validation_failed. Tek pri success strukturirani se sadržaj predaje sljedećem sloju provjere. Korisnici kod ostalih stanja vide kratku, iskrenu povratnu informaciju ili siguran prijenos, ali ne i izmišljene zamjenske podatke.

Provjera semantičkih pravila na strani poslužitelja

Nakon provjere sheme započinje stručna validacija. Ona bi trebala biti deterministička i što je više moguće neovisna o modelu. Oznake proizvoda provjeravaju se prema trenutnom izvoru podataka, URL-ovi prema dopuštenim protokolima i hostovima, a kodovi lokalizacije (locale) prema stvarno podržanim jezicima. Zbrojevi, vremenski periodi i promjene stanja zahtijevaju unakrsne provjere. Kod RAG odgovora, navedeni izvor mora se stvarno pojaviti u odobrenom rezultatu dohvaćanja (retrievala).

To vrijedi i za naizgled bezopasna tekstualna polja. OWASP GenAI Security Project upozorava na nedovoljno provjerene izlaze modela kada se oni prosljeđuju preglednicima, bazama podataka, datotečnom sustavu ili drugim alatiima. Za HTML se primjenjuje odgovarajuće kodiranje ovisno o kontekstu, pristup bazi podataka ostaje parametriziran, a sistemske naredbe se nikada ne sastavljaju od slobodno generiranog teksta. Strukturirani izlaz je ulaz iz nepouzdanog izvora, a ne privilegirani interni objekt.

Siguran alternativni scenarij (fallback) ne popravlja pod svaku cijenu

U slučaju pogrešnog odgovora, trenutni identični ponovni pokušaj (retry) rijetko je najbolja standardna reakcija. On može povećati troškove i ponoviti istu pogrešku. Ograničeni zamjenski put razlikuje uzrok:

1. Tehnički prekid: Kod jasno privremene pogreške pružatelja, ponovite strogo ograničen broj puta koristeći isti idempotencijski ID.
2. Previše složena shema: Podijelite zadatak na manje korake koji se mogu pojedinačno validirati. To je planirana promjena proizvoda, a ne spontano izostavljanje obveznih polja.
3. Semantička pogreška: Nemojte pokretati automatsku akciju. Ciljano zatražite podatke koji nedostaju ili preusmjerite slučaj na ljudsku provjeru.
4. Odbijanje ili granica pravila (policy): Poštujte odbijanje i ponudite dopušteni put informacija ili preusmjeravanja.
5. Nejasno stanje nakon pisanja: Najprije pročitajte ciljni sustav pomoću idempotencijskog ID-a prije pokretanja drugog pokušaja pisanja.

Za veće promjene preporučuje se testiranje u sjenovitom načinu rada (Shadow Mode) prije pokretanja web stranice. Pritom novi strukturirani put već generira rezultate, ali još ne upravlja akcijama korisnika.

Testovi ugovora pokrivaju više od primjera dijaloga

Dobar skup testova ne sadrži samo idealne upite. Prazni unos, vrlo dugi tekstovi, proturječni podaci, nepoznate kategorije, više jezika, pokušaji ubacivanja prompta (prompt injection), odbijanja pružatelja i namjerno tesna ograničenja tokena također pripadaju ugovorima. Za svaki se slučaj očekivani pogonski status, rezultat sheme i stručna odluka bilježe odvojeno.

Prilikom promjena sheme, tim bi trebao validirati stare spremljene primjere prema novoj verziji. Tijekom migracije, aplikacija može privremeno provjeravati prema staroj i novoj verziji bez izvršavanja dviju akcija. Tek kada su stopa uspješnosti, semantička odbijanja i latencija stabilni, novi ugovor postaje aktivni put pisanja. Pogreške se pomoću potpune opservabilnosti AI chatbota mogu dodijeliti korištenoj verziji modela, prompta i sheme, bez bilježenja kompletnih povjerljivih odgovora.

Kključni pokazatelji (KPI) za redovni rad

Najvažniji ključni pokazatelj nije samo udio sintaktički valjanih odgovora. Korisni su stopa usklađenosti sa shemom iz prvog pokušaja, stopa semantičkog odbijanja, udio nepotpunih odgovora, odbijanja, ograničeni pokušaji popravka, preusmjeravanja čovjeku te latencija i trošak po uspješno validiranom rezultatu. Vrijednosti se promatraju odvojeno prema verziji modela, prompta, sheme, slučaju upotrebe i lokalizaciji (locale).

Nagli porast semantičkih pogrešaka uz nepromijenjenu stopu usklađenosti sa shemom posebno je poučan: oblik je i dalje točan, ali sadržaji ili povezanost podataka odstupaju. Tada bi proces trebao prijeći u siguran način rada. Postojeći vodič o degradiranom načinu rada i povratku na prethodno stanje (rollback) kod AI chatbotova pokazuje kako pripremiti takav zamjenski put.

Kontrolni popis prije prve automatske akcije

• Je li konkretni API i put modela testiran s točno ovom shemom?
• Prepoznaju li se nepotpuni odgovori, odbijanja i pogreške pružatelja prije parsiranja?
• Validira li poslužitelj shemu i stručna pravila neovisno o modelu?
• Provjeravaju li se identitet, klijent i ovlasti ponovno neposredno prije svake akcije?
• Jesu li HTML, URL-ovi, vrijednosti baze podataka i parametri alata osigurani ovisno o kontekstu?
• Spriječavaju li idempotencija i ponovno čitanje dvostruke postupke pisanja?
• Postoje li testovi zlatnog skupa, napada, lokalizacije i migracije?
• Jesu li verzija sheme, klasa pogreške i pokazatelji kvalitete opservabilni?
• Može li tim bez gubitka podataka prijeći na siguran način informiranja ili preusmjeravanja?

Strukturirani izlazi čine AI chatbotove jednostavnijima za integraciju, ali ne prenose autoritet na model. Tko oblik, semantiku, pristup i kontekst izlaza tretira kao odvojena vrata (gates), dobiva razumljiv ugovor umjesto naizgled sigurne JSON fasade. Za novi radni tijek na web stranici isplati se započeti s točno jednim ograničenim slučajem upotrebe, malom verzioniranom shemom i mjerljivim testom u sjeni.