Strukturirani izhodi AI klepetalnikov: JSON Schema, validacija in varni rezervni scenariji

AI klepetalnik lahko oblikuje prepričljiv odgovor, a kljub temu poškoduje nadaljnji proces. Enostavno manjkajoče polje, izmišljena kategorija ali nepreverjena povezava zadoščajo, da CRM, sistem za podporo ali spletna stran obdelajo napačne podatke. Strukturirani izhodi AI klepetalnikov zmanjšujejo to tveganje tako, da obvezujoče opredelijo obliko in podatkovne tipe. Zanesljivi pa postanejo šele, ko ločeno preverimo shemo, strokovni pomen, pravice dostopa in primerne ukrepe ob napakah.

Ta vodnik je namenjen ekipam za spletne strani, izdelke in operativno delovanje, ki strojno obdelujejo izhode modelov. Prikazuje, kaj lahko doseže JSON Schema, kje so njene meje in kako zgraditi varno pot od odgovora modela do dejanskega dejanja.

Veljaven JSON še ni zanesljiva pogodba

Starejši način JSON pri številnih API-jih modelov predvsem zagotavlja, da je odgovor mogoče razčleniti kot JSON. Ne zagotavlja pa, da so prisotna pričakovana polja ali da se upoštevajo dogovorjeni tipi. Uradna dokumentacija OpenAI o strukturiranih izhodih zato izrecno razlikuje med veljavnim JSON-om in skladnostjo s shemo. Tudi Microsoft Foundry opisuje strukturirane izhode kot vezavo odgovora na priloženo JSON Schema.

To je pomemben napredek: namesto naknadnega ugibanja spreminjajočih se imen polj aplikacija prejme predvidljivo strukturo. Kljub temu ponudniki pogosto podpirajo le del celotne specifikacije. Dokumentacija Gemini za strukturirane izhode navaja podprte tipe in lastnosti, hkrati pa opozarja na podmnožice in meje kompleksnosti. Shemo je zato treba preizkusiti za dejansko uporabljen model in konkretno pot API-ja.

Shema opisuje obliko, ne pa resnice

JSON Schema je deklarativni jezik za opisovanje strukture in omejitev podatkov JSON. Polje je mogoče na primer opredeliti kot obvezno polje, število, naštevanje ali polje vrednosti (array). Iz tega pa ne sledi, da je vrednost vsebinsko pravilna. Niz znakov 2026-02-31 lahko formalno ustreza besedilu, čeprav ta datum ne obstaja. Dovoljena ID številka izdelka je lahko sintaktično pravilna, a v trenutnem sistemu stranke vseeno neznana.

Za produkcijske klepetalnike je zato potrebnih več ravni preverjanja:

Raven preverjanja	Tipično vprašanje	Primer
Transport	Ali je odgovor popoln in ga je mogoče razčleniti?	Brez prekinitve na sredini strukture JSON
Shema	Ali se polja, tipi in dovoljene vrednosti ujemajo?	priority je lahko le low, medium ali high
Semantika	Ali je vsebina strokovno smiselna in interno dosledna?	Končni datum ni pred začetnim datumom
Pravila in dostop	Ali sme ta uporabnik videti ali uporabiti to vrednost?	Zahtevek pripada avtenticiranemu računu stranke
Kontekst izpisa	Ali se vrednost varno upodobi ali posreduje naprej?	Besedilo je kodirano za HTML, ne interpretirano kot skripta

Ta ločitev preprečuje, da bi zamenjali skladnost s shemo s poslovno odobritvijo. Za meritve in teste regresije jo je mogoče povezati z zlato zbirko za kakovost odgovorov AI klepetalnika (Golden Set).

Oblikovanje malih, opravilu prilagojenih shem

Enoten univerzalni objekt odgovora hitro postane globoko vgnezden, težko razumljiv in drag za vzdrževanje. Boljša izbira je majhna shema za vsako jasno opravilo, na primer za razvrščanje povratnih informacij, predstrukturiranje zahtevka za podporo ali označevanje manjkajočih podatkov za dodatno vprašanje. Ime in opis vsakega polja morata pojasnjevati njegov strokovni pomen.

• Premišljeno izberite obvezna polja: Zahtevajte le vrednosti, ki jih proces resnično potrebuje. Neznane vrednosti izrecno prikažite kot null ali kot poseben status, namesto da pustite modelu, da si jih izmišljuje.
• Uporabite naštevanja namesto prostega besedila: Kratek, verzioniran seznam preprečuje variante zapisov pri statusu, kategoriji ali naslednjem koraku.
• Zavrnite dodatna polja: Kjer ponudnik to podpira, additionalProperties: false preprečuje presenečenja v obliki nepričakovanih ključev.
• Ponovite omejitve v kodi aplikacije: Dolžin, razponov vrednosti, gostiteljev URL in medsebojnih povezav ne prepuščajte le modelu ali specifični podmnožici sheme ponudnika.
• Verzionirajte shemo: Stabilna oznaka in zgostitvena vrednost (hash) jasno pokažeta, katera pogodba je ustvarila in preverila odgovor.

Neznano je samostojno stanje

Prazno polje, manjkajoče polje in izrecno neznana vrednost ne pomenijo iste stvari. Če informacija v viru manjka, mora shema za to predvideti dopustno stanje. Sicer pogodba model posredno nagrajuje za to, da vstavi verjeten niz znakov. Za kritične vrednosti je kombinacija vrednosti (value), statusa (status) in neobveznega razloga (reason) pogosto zanesljivejša od posameznega polja s prostim besedilom.

Skupno dokazovanje verzije in zgoščene vrednosti

K odgovoru zato ne sodita le verzija modela in poziva (prompta), temveč tudi verzija sheme in verzija validatorja. Zgostitvena vrednost (hash) dejansko poslane sheme ščiti pred tihim odstopanjem zaradi sprememb v gradnji ali konfiguraciji. Pri migraciji se lahko isti izhod modela najprej preveri glede na obe verziji pogodbe. Zapisi se še naprej izvajajo le preko aktivne poti; razlike se kot primerjalni podatki shranijo v sistemu za zagotavljanje kakovosti (QA).

Pozivi ne bi smeli prenašati skrivnosti ali internih odločitev o pravicah dostopa v shemo. Model lahko na primer razvrsti željeni naslednji korak. Ali je ta korak dovoljen, nato odloči strežnik na podlagi trenutne identitete in pravilnika.

Obravnava prekinitve in zavrnitve kot samostojnih stanj

Strogo formatiran odgovor lahko včasih izostane. Omejitve izpisa, časovne prekoravitve (timeouts), filtri vsebine, napake ponudnika ali namerna zavrnitev modela so običajna delovna stanja. OpenAI za strukturirane izhode dokumentira tako nepopolne odgovore kot tudi lastno pot zavrnitve, ki ne sledi nujno zahtevani shemi. Aplikacije zato ne smejo slepo dostopati do prvega pričakovanega polja.

Interni ovoj, neodvisen od ponudnika, ločuje najmanj stanja success, refused, incomplete, provider_error in validation_failed. Šele pri stanju success se strukturirana vsebina predajo naslednji ravni preverjanja. Uporabniki pri ostalih stanjih vidijo kratko, iskreno sporočilo ali varen prenos, ne pa izmišljenih nadomestnih podatkov.

Preverjanje semantičnih pravil na strani strežnika

Po preverjanju sheme se začne strokovna validacija. Ta mora biti deterministična in čim bolj neodvisna od modela. Oznake izdelkov se preverijo glede na trenutni vir podatkov, URL-ji glede na dovoljene protokole in gostitelje, kode jezikov pa glede na dejansko podprte jezike. Vsote, časovna obdobja in spremembe stanj potrebujejo navzkrižno preverjanje. Pri odgovornih RAG mora navedeni vir dejansko obstajati v odobrenem rezultatu iskanja (retrieval).

To velja tudi za na videz nenevarna besedilna polja. Projekt OWASP GenAI Security Project opozarja pred nezadostno preverjenimi izhodi modelov, ko se ti posredujejo brskalniku, podatkovni zbirki, datotečnemu sistemu ali drugim orodjem. Za HTML se izvede ustrezno kodiranje glede na kontekst, dostop do podatkovne zbirke ostaja parametriziran, sistemski ukazi pa se nikoli ne sestavljajo iz prosto ustvarjenega besedila. Strukturirani izhod je vnos iz nezanesljivega vira, ne pa privilegiran interni objekt.

Varen rezervni scenarij ne popravlja za vsako ceno

Pri napačnem odgovoru takojšen identičen ponovni poskus (retry) redko predstavlja najboljšo standardno reakcijo. Lahko poveča stroške in ponovi isto napako. Omejena rezervna pot razlikuje med vzroki:

1. Tehnična prekinitev: Pri jasno začasni napaki ponudnika izvedite natančno omejen ponovni poskus z uporabo iste identifikacije za idempotenco (idempotency ID).
2. Preveč kompleksna shema: Razdelite opravilo na manjše korake, ki jih je mogoče validirati posamično. To je načrtovana sprememba izdelka, ne pa spontano izpuščanje obveznih polj.
3. Semantična napaka: Ne sprožajte samodejnega dejanja. Ciljno povprašajte po manjkajočih podatkih ali predajte primer v ročno preverjanje.
4. Zavrnitev ali meja pravilnika: Spoštujte zavrnitev in ponudite dovoljeno pot do informacij ali predajo operaterju.
5. Negotovo stanje po zapisu: Najprej preberite ciljni sistem na podlagi identifikacije za idempotenco, preden začnete drugi poskus zapisa.

Za večje spremembe se priporoča testiranje v senčnem načinu (shadow mode) pred zagonom spletnega mesta. Pri tem nova strukturirana pot že ustvarja rezultate, vendar še ne upravlja dejanj uporabnikov.

Testi pogodbe pokrivajo več kot le primerjalne pogovore

Dobra testna zbirka ne vsebuje le idealnih zahtevkov. Prazni vnosi, zelo dolga besedila, protislovni podatki, neznane kategorije, več jezikov, poskusi vbrizgavanja pozivov (prompt injection), zavrnitve ponudnika in namerno tesne omejitve žetonov prav tako sodijo zraven. Za vsak primer se ločeno zabeležijo pričakovani status delovanja, rezultat sheme in strokovna odločitev.

Ob spremembah sheme mora ekipa preveriti stare shranjene primere glede na novo verzijo. Med migracijo lahko aplikacija začasno preverja glede na staro in novo različico, ne da bi izvedla dve dejanji. Šele ko so stopnja uspešnosti, semantične zavrnitve in zakasnitev (latenca) stabilni, nova pogodba postane aktivna pot zapisa. Napake je mogoče z celovito sledljivostjo AI klepetalnika (observability) dodeliti uporabljeni verziji modela, poziva in sheme, ne da bi bilo treba beležiti celotne zaupne odgovore.

Kazalniki za redno delovanje

Najpomembnejši kazalnik ni le delež sintaktično veljavnih odgovorov. Koristni so delež uspešnih shem v prvem poskusu, stopnja semantičnih zavrnitev, delež nepopolnih odgovorov, zavrnitve, omejeni poskusi popravkov, predaje človeškemu operaterju ter zakasnitev in stroški na uspešno validiran rezultat. Vrednosti se opazujejo ločeno po verziji modela, poziva, sheme, primeru uporabe in lokaciji (locale).

Naden skok semantičnih napak pri nespremenjeni stopnji skladnosti s shemo je še posebej opozorilen: oblika še vedno ustreza, vendar se vsebina ali povezava do podatkov odmikata. V tem primeru mora proces preklopiti v varen način. Obstoječi vodnik o omejenem delovanju (degraded mode) in povratni spremembi (rollback) pri AI klepetalnikih prikazuje, kako pripraviti takšno rezervno pot.

Kontrolni seznam pred prvim samodejnim dejanjem

• Ali je konkretna pot API-ja in modela preizkušena s točno to shemo?
• Ali se nepopolni odgovori, zavrnitve in napake ponudnika prepoznajo pred razčlenjevanjem?
• Ali strežnik validira shemo in strokovna pravila neodvisno od modela?
• Ali se identiteta, sistem stranke in pravice dostopa ponovno preverijo neposredno pred vsakim dejanjem?
• Ali so HTML, URL-ji, vrednosti podatkovnih zbirk in parametri orodij ustrezno zavarovani glede na kontekst?
• Ali idempotenca in ponovno branje preprečujeta dvojne poskuse zapisa?
• Ali obstajajo testi z zlato zbirko, testi napadov, lokalizacijski testi in migracijski testi?
• Ali so verzija sheme, razred napake in kazalniki kakovosti sledljivi?
• Ali lahko ekipa brez izgube podatkov preklopi na varen informativni način ali način predaje operaterju?

Strukturirani izhodi omogočajo boljšo integracijo AI klepetalnikov, vendar modelu ne predajajo avtoritete. Kdor obravnava obliko, semantiko, dostop in kontekst izpisa kot ločena vrata, prejme sledljivo pogodbo namesto le navidezno varne fasade JSON. Za nov spletni potek dela se splača začeti s točno enim omejenim primerom uporabe, majhno verzionirano shemo in merljivim testom v senčnem načinu.