Ispravan JSON može biti pogrešna naredba AI agenta

Prije nego što strukturirani izlaz AI agenta postane poziv poslovnom sustavu, provjerite može li se JSON parsirati, odgovara li objekt shemi i predstavlja li radnju koju je korisnik doista zatražio. Zatim zasebno provjerite smije li taj korisnik izvršiti upravo tu radnju. Uredan format nije odobrenje za narudžbu, promjenu zapisa ili plaćanje.

Semantička provjera uspoređuje vrijednosti u objektu s korisnikovim uputama, aktualnim podacima i poslovnim pravilima. Ako nedostaje podatak potreban za odluku ili se korisnikova ograničenja sukobljavaju s predloženom radnjom, izvršenje treba zaustaviti te zatražiti pojašnjenje ili vratiti odbijanje, ovisno o pravilu sustava.

Što provjeravaju JSON, shema i poslovna pravila

Sintaktička provjera utvrđuje može li program pročitati izlaz kao JSON. Shematska provjera utvrđuje sadrži li objekt potrebna polja, odgovarajuće tipove i dopuštene vrijednosti. OpenAI-jeva dokumentacija razlikuje JSON mode, koji proizvodi valjan JSON uz iznimke koje aplikacija mora obraditi, od Structured Outputs, koji nameće usklađenost s podržanim dijelom JSON Schemas.

U aplikaciji najprije obradite nepotpun odgovor ili odbijanje modela, pa zaprimljeni objekt validirajte prema shemi koju očekuje izvršni poziv. Shema može zahtijevati da je količina cijeli broj, a status jedna od dopuštenih vrijednosti. Ne može iz samog oblika zaključiti je li količina ona koju je korisnik naveo, odnosi li se dodatak na pravu stavku ili je status „prihvaćeno” opravdan. To je granica između ugovora o podacima i odluke o radnji.

Provjerite vjernost zahtjevu prije prihvaćanja

Za semantičku provjeru razložite zahtjev na stavke, količine, izmjene, negacije i uvjete koji vrijede za cijelu radnju. Svaku predloženu vrijednost usporedite s tim zahtjevom i mjerodavnim podacima sustava. Provjerite i odnos među poljima: dodatak može biti dopušten, ali pridružen pogrešnoj stavci; proizvod može postojati u katalogu, ali biti nedostupan za konkretnu narudžbu.

Razlika ima izmjeren primjer. U istraživanju OrderBench s 2.400 poziva četirima otvorenim modelima, najuspješniji promatrani model imao je 100 % izlaza usklađenih sa shemom u oba ispitana načina rada, ali 81,3 % semantički uspješnih narudžbi u načinu s JSON shemom i 83,0 % uz uputu bez nametnute sheme. Semantički uspjeh ondje zahtijeva točan status i točnu narudžbu, uključujući korisnička ograničenja. Riječ je o sintetičkim zadacima s ograničenim jelovnikom, pa ti postoci nisu procjena uspješnosti nekog stvarnog restorana.

Provjera treba razlikovati netočan prijedlog od prijedloga koji se ne smije izvršiti. Pogrešna veličina ili dodatak pridružen pogrešnoj stavci čini objekt nevjernim zahtjevu. Prihvaćanje nedostupne stavke ili radnje koja krši izričito sigurnosno ograničenje zahtijeva zaustavljanje prije izvršnog API-ja. U oba slučaja valjana shema samo pokazuje da sustav može pročitati prijedlog, a ne da ga smije prihvatiti.

Negacija, nedostupna stavka i sukob ograničenja

Sljedeći su primjeri uvjetni; pretpostavimo da agent priprema restoransku narudžbu i da svaki njegov objekt prolazi provjeru sheme. Korisnik traži pizzu bez maslina, a u objektu su masline navedene kao dodatak. Naziv dodatka i tip polja mogu biti dopušteni, no predložena radnja preokreće korisnikovu negaciju. Provjera mora povezati riječi „bez maslina” s popisom dodataka i uklanjanja za tu pizzu.

U drugom primjeru agent navede stavku koja postoji u poznatom jelovniku, ali trenutačno nije dostupna. Shema s dopuštenim nazivima ne govori što je moguće naručiti u trenutku izvršenja. Dostupnost zato treba provjeriti prema aktualnom izvoru podataka; ako korisnik nije odobrio zamjenu, sličan proizvod nije prešutni nastavak iste narudžbe. Rezultat može biti zahtjev za novim odabirom, a ne status prihvaćene narudžbe.

Treći primjer polazi od sukoba u zahtjevu: korisnik navede prehrambeno ograničenje, a zatim zatraži dodatak koji ga krši. Objekt može vjerno prenijeti obje upute i ipak predstavljati nedopuštenu radnju. Pravilo domene mora odrediti treba li narudžbu odbiti ili zatražiti pojašnjenje; agent ne smije sam odlučiti koja je korisnikova uputa važnija. Isti pristup vrijedi kada se izmjena odnosi samo na jednu od više jednakih stavki: opseg izmjene mora ostati točan.

Ovlast provjerite izvan modelova izlaza

Nakon provjere značenja slijedi autorizacija konkretne radnje. Model može predložiti poziv, ali polje poput „odobreno” koje je sam napisao nije dokaz korisnikova pristanka. Izvršni sloj treba provjeriti identitet i ovlasti korisnika, dopuštenu vrstu radnje, ciljni zapis te primjenjiva ograničenja poput iznosa. Za radnju s velikim učinkom može biti potrebna zasebna potvrda osobe.

OWASP-ove smjernice o prevelikoj autonomiji preporučuju najmanje potrebne ovlasti, izvršavanje u korisnikovu kontekstu i provjeru autorizacije u nizvodnom sustavu za svaki zahtjev. Zato provjera pri sastavljanju prijedloga ne može zamijeniti provjeru pri izvršenju: u međuvremenu se mogu promijeniti dostupnost, stanje ciljnog zapisa ili korisnikove ovlasti. Ako provjera ne uspije, novi izlaz modela ponovno prolazi iste kontrole.

Kontrolni popis prije poziva API-ja

Potvrdite da je odgovor potpun, parsirajte JSON i obradite odbijanje modela.
Validirajte objekt prema stvarnoj shemi izvršnog poziva, uključujući neočekivana polja.
Usporedite stavke, količine, negacije i opseg izmjena s izvornim zahtjevom.
Provjerite aktualnu dostupnost, međusobni odnos polja i poslovna ograničenja; pri sukobu ili nejasnoći zaustavite izvršenje.
Autorizirajte točnu radnju u korisnikovu kontekstu, pa tek onda pozovite poslovni sustav.

Prije produkcije isti niz provjera uključite u testove ishoda AI agenta. Uspješan test treba pokazati da je sustav izvršio dopuštenu radnju ili ostao nepromijenjen kada je prijedlog trebalo zaustaviti.

Pročitajte i: