Исправан JSON може да лаже — шема проверава облик, не чињенице

LLM одговор може у базу или други систем тек пошто прође три провере: да је JSON потпун и читљив, да одговара очекиваној шеми и да су његове вредности исправне према пословним правилима и меродавним подацима. Успешна провера облика сама по себи не доказује да је модел навео праву поруџбину, износ или статус уплате.

Те провере решавају различите проблеме. OpenAI документација разликује JSON режим, који у завршеном одговору обезбеђује исправан JSON, од Structured Outputs, који одговор усклађује са подржаном шемом; упозорава и да структурисан одговор може садржати грешке. Зато објекат који парсер и шема прихвате још није аутоматски поуздан запис.

Шта шема заиста проверава

Шема је уговор о подацима које систем очекује. Може да захтева поља, одреди да износ буде цео број, ограничи валуту на RSD или EUR и забрани непозната својства. Ако модел врати текст уместо броја или валуту ван дозвољеног скупа, таква грешка може бити откривена пре него што податак стигне до пословне логике.

Дозвољена вредност ипак није нужно тачна вредност. Ознака RSD може бити исправна по шеми, а износ погрешан за конкретну поруџбину. Идентификатор може бити текст очекиваног облика, али не мора постојати у бази. Шема без приступа меродавном запису не може да утврди ни да ли је уплата заиста потврђена.

Потребно је знати и која ограничења изабрани алати стварно примењују. Водич JSON Schema наводи да је format подразумевано напомена, а да га валидатор може засебно укључити као услов за прихватање вредности. Чак и када валидатор провери запис датума, однос тог датума према одређеној поруџбини остаје посебно пословно правило.

Gemini документација наводи да структурисани одговори подржавају подскуп JSON Schema и препоручује проверу вредности у апликацији, укључујући одговоре који су у складу са шемом, али су семантички погрешни. При преносу интеграције на други API зато треба проверити које делове исте шеме он прихвата и како их тумачи.

Три провере пре уписа

1. Синтакса и потпуност. Утврдите да ли је генерисање завршено и да ли је враћен садржај намењен обради. Одбијање захтева и прекинут одговор обрадите као посебне исходе. Тек затим парсирајте JSON; грешка парсирања зауставља поступак пре било каквог уписа или позива алата.
2. Усклађеност са шемом. Парсирани објекат проверите према верзији шеме коју очекује систем прималац. Проверите типове, обавезна поља, дозвољене вредности и додатна својства. Локална провера на граници апликације чини услов пријема јасним и када се начин генерисања или добављач касније промени.
3. Пословна и чињенична исправност. Идентификатор упоредите са меродавним записом, износ и валуту са подацима о поруџбини, а тврдњу о уплати са стањем система који уплате евидентира. Проверите и да ли је радња дозвољена за тренутно стање и права корисника. Тврдња у одговору модела није доказ за саму себе.

Редослед спречава да неисправан улаз покрене скупље или ризичније кораке. Ако парсер не може да прочита одговор, нема разлога тражити поруџбину; ако шема одбије поље, објекат не испуњава уговор између система. Тек структурно прихватљив објекат постаје кандидат за поређење са стварним стањем.

Исправни објекти који ипак морају бити одбијени

Условни пример је интеграција која мења податке о већ постојећим поруџбинама. Њена шема захтева текстуални order_id, ненегативан цео број amount, валуту RSD или EUR и логичко поље paid. Сва поља су обавезна, а додатна нису дозвољена. Следећа три одговора имају исправну JSON синтаксу и пролазе тако описану шему; одлука о упису зависи од меродавних података:

• Ако је за поруџбину A-17 забележено 1900 RSD, одговор {"order_id":"A-17","amount":9000,"currency":"RSD","paid":false} има погрешан износ. Број 9000 је исправног типа и у дозвољеном опсегу, али поређење са записом открива неслагање.
• Ако за исту поруџбину нема потврђене уплате, одговор {"order_id":"A-17","amount":1900,"currency":"RSD","paid":true} мора бити одбијен. Вредност true је исправан логички тип; потврду да је новац примљен даје систем који прати уплате.
• Ако поруџбина A-18 не постоји, одговор {"order_id":"A-18","amount":1900,"currency":"RSD","paid":false} не може служити за измену постојеће поруџбине. Шема види текстуални идентификатор, док апликација мора да утврди да тај идентификатор припада стварном запису.

Ово су условни примери, а не резултати теста модела. Исти механизам грешке може се јавити код адресе, шифре производа или датума: вредност може имати дозвољен облик, а односити се на погрешан запис или на стање које више не важи. Тачност зато зависи и од тога који систем апликација сматра меродавним за свако поље.

Када покренути упис или позив алата

Радњу покрените тек када исти кандидат за податке прође све три провере. Ако правило зависи од стања које се у међувремену може променити, проверу тог стања и измену повежите трансакцијом или другим механизмом који спречава да између њих буде прихваћена застарела одлука. То је нарочито важно када више захтева може истовремено да мења исту поруџбину.

Неуспехе обрадите према узроку. Оштећен или непотпун одговор може оправдати контролисан поновни захтев, док неслагање са меродавним записом захтева исправан контекст, проверу тог записа или одлуку овлашћене особе. Понављање истог упита без нових података не може утврдити да ли је спорни износ или статус тачан.

Прочитајте и:

• Pre-money и post-money вредност: исти број може сакрити веће разводњавање
• Bun или Node.js: 81% бржи JSON не значи бржи цео API
• Grammarly или LanguageTool: више језика не значи и бољу исправку