OpenAI ar Claude Structured Outputs: tinkamas JSON dar negarantuoja tiesos

Jei integracijai reikia griežtai apibrėžtų laukų ir palaikomų skaitinių ribų, verta rinktis „OpenAI“ Structured Outputs; jei svarbūs iš tiesų pasirenkami laukai, lankstesnė gali būti „Claude“ schema. „OpenAI“ dokumentacija nurodo, kad griežtajame režime visi laukai turi būti privalomi, objektuose būtina uždrausti papildomus laukus, o nepalaikoma schema sukelia užklausos klaidą. Šios taisyklės padeda valdyti atsakymo formą, bet nepatvirtina jame įrašytų faktų.

„Claude“ JSON atsakymui naudoja output_config.format su json_schema tipu ir leidžia schemoje turėti pasirenkamų laukų. „Claude“ dokumentacija taip pat aprašo nepalaikomus skaitinius apribojimus ir SDK pagalbinių funkcijų atliekamą schemos supaprastinimą. Taigi nė vieno API negalima vadinti patikimesniu visiems atvejams: reikia atskirai vertinti, ar jis priima reikiamą schemą ir ar grąžintos reikšmės atitinka pirminius duomenis.

Kur baigiasi schemos patikra

JSON sintaksės patikra parodo, ar atsakymą galima išparsinti. JSON Schema papildomai apibrėžia laukų tipus, privalomumą, leistinas enum reikšmes ir kitus apribojimus. Tačiau laukas, kurio tipas string, gali turėti visiškai taisyklingą, bet iš šaltinio neteisingai ištrauktą tekstą. Net datos format taisyklė, kaip aiškina JSON Schema aprašas, pagal numatytąją sampratą yra anotacija; jos tikrinimas priklauso nuo validatoriaus. Taisyklingas datos užrašas vis tiek neįrodo, kad dokumente buvo būtent ta data.

Abu teikėjai riboja generuojamą struktūrą, todėl mažėja trūkstamų ar netikėto tipo laukų rizika. Prasmės klaida lieka įmanoma net tuomet, kai JSON parseris ir schemos validatorius atsakymą priima. Šis skirtumas ypač svarbus, kai iš teksto ištrauktas laukas vėliau sukelia veiksmą: pakeičia užsakymo būseną, įrašo sumą ar nukreipia kliento užklausą.

Ta pati schema abiejuose API

Prieš keičiant teikėją reikia palyginti ne vien laukų pavadinimus. Toliau pateiktos taisyklių poros rodo, kur ta pati JSON Schema idėja skirtinguose API virsta kitokiu kontraktu; tai dokumentuotų galimybių palyginimas, o ne vienodas visų modelių bandymas.

• Privalomi ir pasirenkami laukai. „OpenAI“ reikalauja visus aprašytus laukus įtraukti į required. Jei reikšmės gali nebūti, lauką galima palikti privalomą, bet leisti null. „Claude“ leidžia lauko visai negrąžinti, jeigu jis nėra privalomas, tačiau pasirenkamų laukų skaičių riboja schemos sudėtingumo taisyklės. Šie variantai programai reiškia skirtingus duomenis: lauko nebuvimas nėra tas pats, kas aiškiai grąžintas null.
• Papildomi raktai. Abiejų teikėjų struktūrizuotuose JSON atsakymuose objektams reikia additionalProperties: false. Tai neleidžia modeliui pridėti nenumatyto rakto. Taisyklė nieko nepasako apie tai, ar numatytame rakte esanti reikšmė paimta iš tinkamo šaltinio.
• Skaitinės ir masyvų ribos. „OpenAI“ aprašo minimum, maximum, minItems ir maxItems palaikymą, bet nurodo papildomas išimtis pagal užsakymą mokytiems modeliams. „Claude“ JSON atsakymo schemoje skaitinių ribų nepalaiko, o minItems leidžia tik nulį arba vienetą. Jeigu tokia riba būtina verslo taisyklei, ją reikia tikrinti programoje net tada, kai generavimo schema buvo priimta.
• Schemų jungimas. „OpenAI“ leidžia anyOf schemos viduje, tačiau šakninė schema turi būti objektas ir negali būti anyOf; allOf nepalaikomas. „Claude“ leidžia anyOf ir ribotą allOf, bet nepalaiko rekursinių schemų. Todėl sudėtingą tipų sąjungą perkeliant tarp API gali tekti keisti pačią schemos sandarą.
• SDK pagalbinės funkcijos. „Claude“ pagalbinė funkcija gali pašalinti nepalaikomą minimum iš API siunčiamos schemos ir įrašyti apribojimą į lauko aprašą. Jei pasirinkta funkcija validuoja atsakymą pagal pradinę schemą, riba tikrinama jau programos pusėje. Tiesioginė API užklausa tokio papildomo tikrinimo automatiškai nesuteikia.

Klaida, kurios schema nepastebi

„BenchLM“ klientų užklausų bandyme per „OpenRouter“ GPT-5.6 Terra atitiko schemą visose 87 užbaigtose užklausose, bet 10 atsakymų turėjo pagal užduotį klaidingas reikšmes; Claude Sonnet 5 schemą atitiko 86 iš 87 užbaigtų užklausų, o dvi tinkamos formos reikšmės buvo klaidingos. Tai konkrečių modelių, tarpinio maršruto, užklausos ir atsakymo ilgio ribos rezultatas, o ne tiesioginių teikėjų API patikimumo reitingas.

Viename bandymo įraše klientas pirmiausia paprašė atšaukti prenumeratą, paskui aiškiai persigalvojo. Modelio grąžintas atšaukimo veiksmas tilpo į requested_action laukui leistiną tekstinį tipą, tačiau prieštaravo galutiniam prašymui. Schema negali nustatyti, kuri iš dviejų to paties pranešimo frazių išreiškia galiojančią kliento valią. Tam reikia taisyklės, vertinančios pirminį tekstą ir jo kontekstą.

Platesniame struktūrizuotų atsakymų tyrime modeliai beveik visada laikėsi schemos, tačiau geriausias tikslus atskirų reikšmių atitikimas pirminiam turiniui siekė 83,0 % teksto užduotyse. Tyrimo matas yra ištrauktų reikšmių tikslumas, o ne „OpenAI“ ir „Claude“ tiesioginių API palyginimas. Jis parodo, kodėl formato sėkmės rodiklis neturėtų būti naudojamas kaip duomenų teisingumo rodiklis.

Validavimo grandinė: forma ir prasmė

Naudinga atskirti dvi patikros pakopas. Pirmoji atsako, ar programai perduotas objektas atitinka techninį kontraktą; antroji – ar jo reikšmės pagrįstos pirminiu įrašu ir leidžia atlikti numatytą veiksmą. Toks skirstymas taip pat leidžia atskirai matuoti, kur integracija suklydo.

1. Forma. Pirmiausia nustatykite, ar atsakymas užbaigtas ir ar modelis neatsisakė atsakyti: nutrūkęs atsakymas nėra klaidinga lauko reikšmė. Tada išparsinkite JSON ir patikrinkite jį pagal programos pradinę schemą, įskaitant apribojimus, kuriuos SDK galėjo pašalinti iš teikėjui siųstos versijos. Atskirai registruokite sintaksės klaidą, schemos pažeidimą ir užklausos atmetimą dėl nepalaikomos schemos.
2. Prasmė. Tik techninę patikrą praėjusį objektą lyginkite su verslo taisyklėmis ir pirminiais duomenimis. Užsakymo identifikatorius turi sutapti su įrašu, suma – su sistemoje apskaičiuotomis eilutėmis, o iš kliento pranešimo ištrauktas veiksmas – su galutiniu, neatšauktu prašymu. Kai šaltinyje reikšmės nėra, kontrakte numatykite null arba aiškią „nežinoma“ būseną, kad tikėtinas spėjimas nevirstų tariamu faktu.

Renkantis API prasminga tikrinti tą pačią užduotį su kiekvienam teikėjui pritaikyta, bet vienodą verslo reikšmę išsaugančia schema. Atskirai skaičiuokite atmestas schemas, netaisyklingus arba neužbaigtus atsakymus ir teisingos formos, bet klaidingo turinio laukus. Tik taip matyti, ar pasirinkimą lemia schemos suderinamumas, modelio ištraukimo tikslumas, ar jūsų programai būtinas papildomas tikrinimas.

Taip pat skaitykite:

• „Microsoft Fabric“ agentams atveria duomenis, bet svarbios dalys dar bandomos
• Kalifornija pareikalavo „OpenAI“ atsakymų dėl DI kibernetinių incidentų
• „DeepL“ ar „Google Translate“: taisyklinga lietuvių kalba dar nėra tiksli