Строг JSON од AI: точната структура сè уште може да содржи погрешни вредности

За предвидлив JSON од AI API, испратете поддржана JSON Schema преку Structured Outputs, па проверете го добиениот објект во сопствената апликација пред внесување во база. Режимот го контролира обликот на одговорот, но не утврдува дали идентификаторот, валутата или износот се точни за конкретниот запис.

Ако моделот врати поле total со погрешен број, одговорот може да биде и синтаксички исправен и целосно усогласен со шемата. Затоа раздвојте ги проверките за завршен API одговор, валиден JSON, соодветна шема и вредности според доверлив извор; запишувањето нека следи дури по последната проверка.

Кој режим го обезбедува бараниот облик

Водичот на OpenAI за Structured Outputs разликува JSON mode, кој дава валиден JSON без гаранција за конкретна шема, од Structured Outputs, кој го усогласува одговорот со поддржаната шема; наведува и дека неподдржана шема во строг режим предизвикува грешка. Обичен prompt со зборовите „врати JSON“ не ја заменува поставката за структуриран излез во API барањето.

Кај строгата поставка сите декларирани полиња мора да бидат во required, а секој објект мора да има additionalProperties: false. Ако некое поле логички може да недостига, моделирајте го како задолжително поле со дозволена вредност null, таму каде што избраниот API ја поддржува таа форма. Локалната проверка на шемата е особено важна кога користите само JSON mode: успешно парсирање не кажува ништо за пропуштено поле или погрешен тип.

Мала шема што лесно се пренесува

Документацијата на Gemini за структурирани одговори опишува подмножество од JSON Schema, вклучувајќи properties, required, additionalProperties и enum, и препорачува проверка на вредностите во апликацијата. За заедничка основа меѓу API-ја, почнете со object, едноставни типови и затворени списоци само таму каде што навистина постојат. Обвивката со која шемата се испраќа се разликува според провајдерот, дури и кога внатрешниот опис на полињата е ист.

За условен запис на нарачка, мала шема е: {"type":"object","properties":{"order_id":{"type":"string"},"currency":{"type":"string","enum":["MKD","EUR"]},"total":{"type":"number"}},"required":["order_id","currency","total"],"additionalProperties":false}. Ова е условен пример, а не подготвено целосно API барање. Тој бара присуство на сите наведени полиња, дозволува само две ознаки за валута и исклучува непознати клучеви.

Не пренесувајте автоматски сложени правила од целосната JSON Schema спецификација во барањето до моделот. Ако API пријави неподдржан keyword, изменете ја шемата или спроведете го правилото во локалниот валидатор; повторување на истото барање не ја менува поддршката. Чувајте ја верзијата на шемата заедно со кодот што го толкува одговорот, за секоја промена на поле да биде видлива и контролирана.

Каде шемата запира, а почнува проверката на фактите

Во условен пример, изворната нарачка има вкупно 1.200 MKD, а моделот враќа 12.000 MKD. Полето total и понатаму содржи број, а currency може да биде дозволениот текст MKD. Шемата успешно ја ограничила формата, но нема пристап до вистинскиот вкупен износ во системот што ја води нарачката.

Локалната семантичка проверка за овој случај може да се запише како кратка низа услови:

1. Најдете ја нарачката според order_id во доверливата база и потврдете дека тековниот процес смее да ја обработи.
2. Споредете го currency со валутата на пронајдената нарачка, иако ознаката веќе поминала низ enum.
3. Споредете го total со потврдениот износ или пресметајте го од доверливите ставки според правилата на системот.

Овие проверки фаќаат различни грешки. Enum отфрла непозната ознака, но не може да знае дали токму оваа нарачка е во MKD или EUR; типот number прифаќа и точен и погрешен износ. Ако немате доверлив податок за споредба, не означувајте ја генерираната вредност како потврдена: задржете го записот за рачна или друга дозволена проверка.

Посебни гранки за одбивање, прекин и шема

Проверете го исходот на API повикот пред да ја читате содржината. Одбивање е посебен статус и неговата порака не треба да се толкува како JSON за нарачка. Зачувајте дека нема употреблив резултат и насочете го случајот според правилата на апликацијата; автоматско повторување на исто одбиено барање може само да создаде циклус без напредок.

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

Неподдржан schema-keyword бара поправка на конфигурацијата, не повторно генерирање на истиот запис. Ако одговорот е целосен и локално ја поминува шемата, но паѓа на споредбата со изворната нарачка, зачувајте го како семантичка грешка. Одделните статуси кажуваат дали треба да се поправи барањето, да се побара нов одговор или да се проверат самите деловни податоци.

Запишување по проверката

Редоследот за автоматизиран внес е: проверка на исходот од API, парсирање на JSON, локална проверка на шемата, споредба со доверливиот запис и дури потоа запишување. При неуспех вратете јасен статус до повикувачот и не префрлајте го сомнителниот износ меѓу потврдени нарачки. Така промената на модел или провајдер не ја менува границата на доверба во вашата апликација.

Поврзете го уписот со постојниот идентификатор на нарачката и проверете дали таа веќе е обработена. Тоа е важно кога успешен одговор треба повторно да се испрати по мрежен прекин: истата нарачка не треба да произведе два потврдени записи. Со ваква завршна контрола добивате употреблив JSON за автоматизација, а одлуката кои вредности се прифатливи останува во системот што ги познава нарачките.