JSON valid nu înseamnă date corecte: două validări pentru ieșirea unui LLM

Pentru a folosi ieșirea JSON a unui LLM, verificați mai întâi structura față de o schemă și apoi valorile față de datele și regulile aplicației. Un obiect se poate parsa fără eroare, poate avea toate câmpurile cerute și totuși poate indica un produs inexistent sau o operație pe care utilizatorul nu are dreptul să o execute.

Prima etapă stabilește ce câmpuri, tipuri și valori declarate poate livra modelul; a doua stabilește dacă acele valori sunt corecte și utilizabile în contextul curent. Granița contează mai ales când răspunsul alimentează o comandă, actualizează o înregistrare sau devine argument pentru o funcție: forma acceptată nu acordă automat încredere conținutului.

Constrângeți forma, apoi validați rezultatul primit

Porniți de la un contract explicit. Într-un exemplu ipotetic de linie de comandă, schema cere product_id ca șir, cantitate ca număr întreg și moneda dintr-o listă închisă. Dacă furnizorul permite decodare constrânsă la schemă, activați-o: simpla instrucțiune din prompt de a scrie JSON nu impune tipurile și câmpurile cerute.

Într-un flux cu două validări, ghidul OpenAI pentru Structured Outputs delimitează prima etapă: modul JSON urmărește un rezultat JSON valid, iar ieșirea structurată respectă schema acceptată; ghidul avertizează și că un rezultat structurat poate conține greșeli. În modul strict descris acolo, toate proprietățile trebuie declarate obligatorii, obiectele trebuie să interzică proprietăți suplimentare, iar construcții precum if, then și else nu sunt acceptate. Verificați schema în condițiile furnizorului folosit, chiar dacă validatorul local o acceptă.

La recepție, separați refuzul modelului și răspunsul întrerupt de un obiect complet. Decodați rezultatul complet și rulați validatorul aplicației înainte de a-l transforma în date de lucru. Validatorul local face contractul explicit la granița sistemului și prinde abateri dacă folosiți un mod fără constrângere, schimbați furnizorul sau modificați schema.

Verificați identificatorii în sistemul care îi deține

Schema poate cere un șir cu o anumită formă; catalogul stabilește dacă identificatorul desemnează un produs real. Într-un exemplu ipotetic, modelul întoarce product_id „A123”, acceptat de schemă. Aplicația caută acel cod în catalogul actual, verifică dacă produsul este activ și dacă este disponibil pentru comanda respectivă. Dacă lipsește sau aparține altei entități, păstrarea obiectului doar pentru că este JSON valid ar introduce o eroare în flux.

Aceeași regulă se aplică identificatorilor de client, factură sau rezervare. Nu cereți modelului să decidă existența lor din memorie și nici să inventeze un cod plauzibil când nu găsește o potrivire. O listă de opțiuni obținută din sistemul sursă poate restrânge alegerea, însă verificarea finală trebuie să citească starea actuală a înregistrării, deoarece opțiunile se pot schimba între generare și folosire.

Recalculați relațiile și aplicați permisiunile

Câmpurile valide separat pot forma împreună o afirmație falsă. Dacă răspunsul conține cantitate, preț unitar, total și monedă, recalculați suma cu prețul autorizat de sistem, apoi aplicați regulile de rotunjire și de monedă ale produsului. Un total calculat corect dintr-un preț inventat rămâne inutilizabil. Pentru valori extrase dintr-un document, comparați câmpurile care declanșează acțiunea cu documentul sau cu evidența autoritativă, în loc să tratați tipul numeric drept dovadă.

Verificați și relațiile logice: o dată de încheiere nu poate preceda data de început a aceleiași rezervări, iar produsul și moneda trebuie să aparțină aceleiași oferte. Unele relații pot fi exprimate într-o schemă completă, dar suportul efectiv al decodării constrânse diferă; regulile dependente de catalog, prețuri sau stare aparțin oricum aplicației. Este mai sigur să calculați valorile derivate în cod decât să cereți modelului să le furnizeze ca autoritate.

Un customer_id existent nu înseamnă că utilizatorul autentificat îl poate vedea sau modifica. Controlul accesului trebuie să folosească identitatea utilizatorului, resursa găsită și permisiunile curente, inclusiv apartenența la organizația potrivită. Pentru o acțiune care schimbă date ori bani, reevaluați autorizarea imediat înainte de execuție: între generarea răspunsului și apelul efectiv drepturile pot fi retrase.

Tratați diferit erorile de formă și cele de sens

Un răspuns incomplet ori care nu trece schema poate fi respins sau regenerat într-un număr limitat de încercări, dacă intrarea permite un răspuns. În schimb, un identificator inexistent cere o alegere din date verificate sau o clarificare; un acces interzis oprește operația. Regenerarea oarbă nu transformă modelul în catalog, motor de prețuri sau serviciu de autorizare.

Pentru apelurile de funcții, referința OpenAI pentru Chat API avertizează că argumentele generate pot fi JSON invalid sau pot include parametri inventați și cere validarea lor în cod înainte de apel. Tratați rezultatul modelului ca pe o propunere de argumente: aplicația parsează, verifică schema, controlează sensul și abia apoi decide dacă invocă funcția. Un refuz sau lipsa datelor necesare trebuie să rămână un rezultat explicit, nu să fie convertit într-o operație aproximativă.

Testați separat conformitatea și utilizabilitatea

Înainte de producție, construiți un set de cazuri acceptate și respinse care traversează ambele etape. Includeți în mod deliberat răspunsuri corecte ca formă, dar greșite prin valoare:

• JSON incomplet, tip greșit, câmp lipsă, proprietate suplimentară și valoare în afara listei permise;
• identificator bine format, dar inexistent, inactiv sau asociat altei organizații;
• câmpuri valide separat, dar cu total greșit, monedă nepotrivită sau interval de date imposibil;
• utilizator fără dreptul necesar și permisiune retrasă între generare și executare;
• intrare ambiguă ori incompletă, pentru care aplicația trebuie să ceară lămuriri sau să oprească acțiunea.

Lucrarea JSONSchemaBench prezintă un benchmark cu 10.000 de scheme reale și evaluează șase cadre de decodare constrânsă după eficiență, acoperirea constrângerilor și calitatea ieșirii. Pentru produsul propriu, măsurați separat proporția de răspunsuri conforme cu schema și proporția care trec verificările semantice. Păstrați și cauza respingerii: o eroare de tip cere alt remediu decât un produs inexistent, un total neconcordant sau o permisiune lipsă.

Citește și:

• IMM-urile primesc 75% pentru audit CRA, dar nu pot aplica singure
• ChatGPT sau Perplexity pentru documentare: mai multe surse nu înseamnă adevăr
• Coursera sau Udemy: aceeași companie, două moduri de a plăti învățarea