Strukturiran izhod še ni pravilna vsebina: JSON potrebuje dodatno kontrolo

Preden izhod jezikovnega modela sproži dejanje, mora aplikacija ločeno preveriti, ali je odgovor dokončan in berljiv kot JSON, ali ustreza shemi ter ali so njegove vrednosti pravilne glede na zaupanja vredne podatke in trenutno stanje. Če katera od teh kontrol odpove, izvršitveni klic ne sme steči.

Veljaven JSON potrjuje zapis, skladnost s shemo pa pričakovane tipe, polja in dovoljene vrednosti. Nobena od teh lastnosti ne potrdi, da je model izbral pravi zahtevek ali upravičeno predlagal njegovo zaprtje. OpenAI-jeva dokumentacija loči način JSON od strukturiranega izhoda, opozarja na možne vsebinske napake tudi pri slednjem ter opisuje zavrnitve in nepopolne odgovore kot posebna stanja.

Shema omeji obliko predloga

Shemo zasnujte okoli podatkov, ki jih izvršitveni del dejansko potrebuje. V ponazorilnem procesu podpore bi predlog lahko vseboval identifikator zahtevka, predlagani status in razlog. Zahtevana polja označite kot obvezna, status omejite na dovoljene vrednosti, nepričakovana polja pa zavrnite. Tako je mogoče ugotoviti, ali je odgovor sploh primeren za nadaljnjo obdelavo.

Za vhod, iz katerega ni mogoče zanesljivo določiti statusa, predvidite izrecno vrednost, na primer »ni mogoče določiti«. Ta vrednost je veljaven rezultat razvrščanja, vendar v poslovnem pravilu pomeni pot brez spremembe. Če takšnega stanja ne predvidite, lahko model zaradi zahteve po zapolnitvi obveznega polja vrne na videz prepričljivo izbiro, čeprav vhod zanjo ne daje podlage.

Preverite tudi, katere omejitve izhodne sheme ponudnik podpira. Po navodilih Amazon Bedrock storitev ob nepodprtih elementih sheme vrne napako 400; rekurzivne sheme in zunanji sklici niso podprti, prav tako ne nekatere številčne in nizovne omejitve. Zato pravila, ki ga ponudnikov način strukturiranega izhoda ne more uveljaviti, ne smete šteti za opravljeno kontrolo: izvedite ga v aplikaciji.

Podobno previdnost zahteva posebno oblikovanje nizov. Razlaga JSON Schema navaja, da je ključna beseda format privzeto oznaka, preverjanje kot omejitev pa je odvisno od validatorja in njegove nastavitve. Tudi pravilno oblikovan datum še ni nujno datum, ki je smiseln za konkretni zahtevek; to je ločeno poslovno vprašanje.

Poslovno pravilo odloča o dejanju

Po validaciji sheme primerjajte predlog modela s podatki, ki jih hrani aplikacija. Identifikator mora označevati obstoječi zahtevek v pravem kontekstu, predlagani prehod mora biti dovoljen iz njegovega trenutnega stanja, pobudnik pa mora imeti ustrezno pooblastilo. Besedilo razloga v JSON-u lahko pojasni predlog, ne more pa samo dokazati, da so pogoji za spremembo izpolnjeni.

V ponazorilnem primeru je vrednost »rešeno« lahko povsem pravilna po shemi, čeprav stranka še čaka na odgovor. Pravilo za zaprtje mora zato preveriti podatke, ki v vašem procesu pomenijo zaključeno obravnavo, in ob njihovem neujemanja vrniti odločitev brez spremembe. Enako velja za zneske, naslove ali prejemnike v drugih procesih: pravilna vrsta vrednosti ne pomeni, da se ujema z zapisom, na podlagi katerega sme sistem ukrepati.

Kontrolo opravite tik pred izvršitvijo. Zahtevek se lahko spremeni med nastankom modelovega odgovora in poskusom posodobitve. Ponovno preberite trenutno stanje ter, če sistem to omogoča, uporabite preverjanje različice zapisa ali pogojno posodobitev. Tako lahko aplikacija zavrne predlog, ki je bil ob nastanku morda smiseln, ob izvršitvi pa temelji na zastarelih podatkih.

Zavrnitve in nejasnosti potrebujejo pot brez dejanja

Stanje odgovora ponudnika preverite pred razčlenjevanjem vsebine. Izrecna zavrnitev, prekinjen odgovor ali prazen rezultat niso predlogi za poslovno odločitev. Zavrnitev zato ne sme postati status zahtevka »zavrnjeno«, nepopolnega odgovora pa ne dopolnjujte s privzetimi vrednostmi, ki bi omogočile izvršitev.

Ločite tudi napake po vzroku. Neveljaven JSON in manjkajoče obvezno polje ustavita obdelavo pred poslovnimi pravili. Predlog z veljavno obliko, a napačnim identifikatorjem, nedovoljenim prehodom ali nezadostno podlago za odločitev ustavite pri vsebinskem preverjanju. Ta razlika pomaga pri beleženju in odpravljanju težav, medtem ko je posledica za izvršitveni del enaka: dejanje se ne izvede.

Varno privzeto ravnanje določite za vsako vrsto opravila. Pri zapiranju zahtevka je to lahko ohranitev obstoječega stanja in predaja v ročni pregled; pri informativni razvrstitvi označitev rezultata kot nepotrjenega. Ponovni poziv modelu je mogoč, kadar pričakujete odpravljivo napako, vendar mora tudi ponovljeni odgovor skozi iste kontrole. Število ponovitev omejite, da nejasen vhod ne povzroča neskončne zanke.

Preizkusite navidezno pravilne rezultate

Preizkusni nabor naj poleg pokvarjenega JSON-a vsebuje odgovore, ki prestanejo shemo, vendar bi brez vsebinske kontrole povzročili napačno dejanje. Za ponazorilni proces zapiranja zahtevkov so posebej koristni naslednji primeri:

• Identifikator je pravilne oblike, vendar pripada drugemu zahtevku: zaprtje se ne izvede.
• Status »rešeno« je dovoljen, zadnje sporočilo stranke pa še zahteva odgovor: poslovno pravilo zadrži spremembo.
• Predlog se nanaša na starejšo različico zahtevka: preverjanje trenutnega stanja prepreči posodobitev.
• Vhod ne vsebuje podatka, potrebnega za odločitev: stanje »ni mogoče določiti« vodi v pot brez samodejnega dejanja.
• Odgovor ponudnika je zavrnjen, prazen ali prekinjen: izvršitveni del ne prejme predloga.

Pri vsakem primeru preverite rezultat posamezne kontrole in dejansko stanje sistema po poskusu obdelave. Samo pričakovano sporočilo o napaki ni dovolj, če je bil stranski učinek že izveden. Zabeležite razlog za ustavitev in identifikator poskusa, da lahko razlikujete med napako sheme, neustreznim vhodom, kršitvijo poslovnega pravila in zastarelim stanjem.

Končno zaporedje je preprosto: preverite stanje odgovora, razčlenite JSON, validirajte shemo, primerjajte ključne vrednosti z zaupanja vrednimi podatki in trenutnim stanjem ter šele nato dovolite izvršitev. Vsaka zavrnitev ali dvoumnost mora imeti določeno pot brez samodejne spremembe.