Վավեր JSON-ը դեռ ճիշտ տվյալ չէ․ Structured Outputs-ի թաքնված սահմանը

3 հոկտեմբերի, 2026 թ., 22:00|Հեղինակ: QUASA-ի խմբագրական թիմ|5 րոպե ընթերցանություն| 1

OpenAI-ի Structured Outputs ուղեցույցը տարբերակում է վավեր JSON-ը սխեմային համապատասխան պատասխանից․ JSON mode-ն ապահովում է առաջինը, իսկ Structured Outputs-ը՝ նաև տրված սխեմայի պահպանումը։ Նույն ուղեցույցում նկարագրված խիստ ռեժիմը պահանջում է բոլոր դաշտերը նշել որպես պարտադիր, չթույլատրել չսահմանված լրացուցիչ դաշտեր և օգտագործել JSON Schema-ի աջակցվող հնարավորությունները։ Այդ պայմանները կարգավորում են պատասխանի ձևը, սակայն չեն հաստատում, որ հաշիվ-ապրանքագրից վերցված գումարը կամ վաճառողի տվյալը ճիշտ է։

Ծրագրով անվտանգ մշակման համար պատասխանը անցկացրեք երեք հաջորդական ստուգմամբ։ Նախ վավերացրեք JSON-ը ձեր սխեմայով, հետո դաշտերի արժեքները համեմատեք սկզբնական փաստաթղթի, հաշվարկների և վստահելի ներքին տվյալների հետ։ Միայն երկու ստուգումն էլ անցած պատասխանը կարող է հասնել տվյալների բազայի գրանցմանը կամ գործարքային API-ին. մերժված, կիսատ կամ չստուգված արդյունքի դեպքում այդ գործողությունը չի կատարվում։

Սխեմայում ամրագրեք այն, ինչ ծրագիրն ընդունում է

Հաշիվ-ապրանքագրի համար սկսեք այն դաշտերից, որոնք հետագա գործողության մեջ իրական նշանակություն ունեն՝ փաստաթղթի համար, վաճառողի նույնականացուցիչ, արժույթ, ապրանքային տողեր և ընդհանուր գումար։ Սահմանեք յուրաքանչյուր դաշտի տեսակը, պարտադիր լինելը և, որտեղ տեղին է, թույլատրելի արժեքները։ Եթե տվյալ հոսքն ընդունում է միայն դրամով հաշիվներ, արժույթի դաշտում կարելի է թույլատրել միայն AMD արժեքը։ Այդ սահմանափակումը կանխում է անսպասելի արժույթի փոխանցումը ծրագրի հաջորդ շերտին։

Սխեման պետք է արտացոլի նաև բացակայող տվյալների վիճակը։ Եթե վաճառողի նույնականացուցիչը երբեմն հնարավոր չէ կարդալ, դաշտը կարելի է նկարագրել այնպես, որ այն ընդունի նաև null, իսկ կիրառական կոդում null-ի համար սահմանել մերժում կամ ձեռքով վերանայում։ Դա ավելի հստակ է, քան մոդելին թույլ տալ դատարկ տեղը լրացնել հավանական թվով։ Նույն ձևով ապրանքային տողի քանակը և գինը պետք է ունենան կանխորոշված տեսակներ, որպեսզի հետագա հաշվարկը կախված չլինի կամայական տեքստից։

Պատասխանը ստանալուց հետո սերվերում կրկին կատարեք սխեմայի վավերացում՝ նախքան դաշտերը կիրառական կոդին փոխանցելը։ Այս քայլը ձեր համակարգի ընդունման կանոնն է և առանձին արձանագրում է կառուցվածքային խափանումը։ Եթե մոդելին տրվող սխեման ծառայության աջակցվող ենթաբազմության համար պարզեցված է, սերվերային ստուգման մեջ պահեք նաև ձեր կիրառությանը անհրաժեշտ լրացուցիչ սահմանափակումները։

Նույն կառուցվածքը կարող է տարբեր արդյունք տալ

Պայմանական օրինակում հաշիվ-ապրանքագիրը պարունակում է ապրանքի երկու միավոր՝ յուրաքանչյուրը 6000 դրամով, և 12000 դրամ ընդհանուր գումարով։ Պատասխանը կարող է ունենալ բոլոր պահանջվող դաշտերը, ճիշտ տեսակները և AMD արժույթը, բայց ընդհանուր գումարի տեղում նշել 13000 դրամ։ Այդ JSON-ը կարող է անցնել կառուցվածքային ստուգումը, քանի որ սխեման չի համեմատել թիվը փաստաթղթի տողերի հետ։ Գործարքի համար այդ տարբերությունը որոշիչ է՝ անկախ պատասխանի ձևական վավերությունից։

JSON Schema-ի բացատրությունը կառուցվածքային վավերացումից առանձնացնում է իմաստային վավերացումը. դաշտերի որոշ փոխադարձ կապեր պահանջում են կիրառական կոդով ստուգում։ Հաշիվ-ապրանքագրի դեպքում այդ կապերից մեկն ընդհանուր գումարի և ապրանքային տողերի համապատասխանությունն է։ Մյուսը փաստաթղթում նշված վաճառողի և այն գրառման համապատասխանությունն է, որի անունով համակարգը պատրաստվում է պարտավորություն ստեղծել։

2026 թվականի Structured Output Benchmark-ում սխեմային համապատասխանությունը գրեթե կատարյալ էր, մինչդեռ դաշտերի արժեքների ճշգրիտ համընկնման լավագույն արդյունքները կազմել էին 83.0% տեքստային, 67.2% պատկերներից և 23.7% ձայնային նյութերից ստացված տվյալների համար։ Փորձարկման բոլոր մոդելները ստացել էին տեքստի վերածված համատեքստ։ Հետևաբար այս տոկոսները վերաբերում են կառուցվածքային պատասխանում արժեքների համընկնմանը, ոչ թե առանձին պատկերի կամ խոսքի ճանաչման որակին։

Արժեքները ստուգեք անկախ հիմքով

Յուրաքանչյուր դաշտի համար սահմանեք ոչ միայն ձևը, այլև ընդունման հիմքը։ Ընդհանուր գումարը հաշվեք ապրանքային տողերի քանակներից և գներից՝ գումարների համար ճշգրիտ թվային ներկայացմամբ, ապա համեմատեք վերադարձված արժեքի հետ։ Եթե տվյալ փաստաթուղթը ներառում է զեղչ կամ հարկ, հաշվարկի կանոնը պետք է բացահայտ հաշվի առնի դրանք։ Մոդելի վերադարձած ընդհանուր գումարը մի օգտագործեք որպես նույն գումարի ճշտությունը հաստատող հիմք։

Վաճառողի նույնականացուցիչը համեմատեք սկզբնական փաստաթղթի համապատասխան հատվածի և հաստատված մատակարարների գրանցամատյանի հետ։ Ճիշտ վերահաշվարկված գումարը բավարար չէ, եթե այն վերագրվել է այլ վաճառողի։ Փաստաթղթի համարը համեմատեք արդեն ընդունված գրառումների հետ, որպեսզի նույն հաշիվը կրկին չգրանցվի որպես նոր պարտավորություն։ Այս կանոնները ստուգում են տարբեր հարաբերություններ, ուստի մեկի հաջողությունը չի փոխարինում մյուսներին։

Սկզբնական տվյալն այստեղ նույնքան կարևոր է, որքան JSON պատասխանը։ Պահպանեք, թե որ մուտքից է ստացվել գրառումը և որ դաշտի ստուգումն ինչ պատճառով է ձախողվել։ Եթե փաստաթղթի մի հատվածը բացակայում է կամ ընթեռնելի չէ, այդ դաշտը պահեք որպես չլուծված վիճակ։ Վերանայողը կարող է ուղղել հենց այդ արժեքը՝ տեսնելով մերժման պատճառը, իսկ մոդելի ենթադրությունը չի դառնա հաստատված հաշվապահական տվյալ։

Նույն կիրառական կանոնները գործադրեք նաև այն դեպքում, երբ կառուցվածքային պատասխանը գալիս է գործիքի կանչի փաստարկներով։ Դաշտերի ճշտությունը կախված է ստուգվող սկզբնաղբյուրից և ձեր ընդունման պայմաններից, ոչ թե նրանից, թե API-ի որ ձևով է վերադարձվել JSON-ը։

Մերժումը կանգնեցրեք մինչև գրանցումը

Գրանցման կամ վճարման կանչի իրավունքը տվեք միայն ամբողջ ստուգումն անցած գրառմանը։ Նախ ստուգեք՝ API պատասխանը ավարտվա՞ծ է և մերժում չի՞ պարունակում, ապա վերլուծեք JSON-ը, վավերացրեք սխեման և գործադրեք իմաստային կանոնները։ Եթե այս փուլերից որևէ մեկը ձախողվում է, վերադարձրեք հստակ մերժման վիճակ՝ առանց տվյալների բազան փոխելու կամ գործարքային API կանչելու։ Կիսատ պատասխանից ստացված դաշտերը մի ընդունեք միայն այն պատճառով, որ դրանց մի մասը ճիշտ է թվում։

Մերժված հաշիվը կարելի է փոխանցել վերանայման հերթ՝ սկզբնական մուտքի հղումով և կոնկրետ պատճառներով, օրինակ՝ անհամապատասխան ընդհանուր գումար կամ չհաստատված վաճառող։ Վերանայման գրառումն առանձնացրեք հաստատված հաշիվներից, որպեսզի հաջորդ ավտոմատ քայլը այն պատահմամբ չմշակի։ Եթե որոշում եք նորից դիմել մոդելին, նոր պատասխանը նույնպես պետք է անցնի ամբողջ ստուգումը։ Կրկնակի հարցումը ինքնին չի հաստատում նախկինում սխալ եղած արժեքը։

Ստուգման և գրանցման սահմանը պահեք նաև ծրագրի ներսում։ Գործարքային գործողություն կատարող կոդը պետք է ստանա միայն ընդունված գրառում, իսկ կրկնության ստուգումը կատարվի այն պահին, երբ գրառումն իրականում ստեղծվում է։ Այսպես նույն փաստաթղթի վերաբերյալ զուգահեռ հարցումներն էլ չեն կարող շրջանցել ընդունման կանոնը։ Սխալի դեպքում պահպանվում է մերժման պատճառը, բայց կասկածելի հաշիվը չի դառնում վճարման կամ հաշվառման հիմք։

Կարդացեք նաև:

Կիսվել: