Валидният JSON пак може да греши: проверете смисъла след схемата

За да не задейства грешен резултат следващата операция, проверявайте структурирания отговор на два етапа: първо формата и типовете, после фактите и бизнес правилата. Преди това установете дали отговорът е завършен и дали моделът не е отказал задачата. Ръководството на OpenAI обяснява, че Structured Outputs налага съответствие със схема, но съдържанието пак може да е погрешно, а отказът и непълният отговор изискват отделна обработка.

Валиден обект с поле за обща сума може да съдържа число от правилния тип, което не съвпада с цената и количеството. Следователно машинно четимият резултат е предложение за данни, а не разрешение за плащане, промяна в база данни или извикване на инструмент. Решението дали стойностите са допустими принадлежи на приложението.

Определете договора за формата

Започнете от данните, които следващата операция действително използва. За всяко поле посочете тип, дали е задължително, допустимите стойности при фиксиран набор и поведението при непознати свойства. Имена като „статус“ и „сума“ не са достатъчни сами по себе си: статусът трябва да има ясни стойности, а сумата — определено значение и мерна единица.

Използвайте режим за извеждане по схема, когато избраният API го поддържа. Обикновеният JSON режим може да осигури синтактично валиден JSON, без да гарантира исканите полета и типове. Схемата трябва да съвпада с типовете, които приложението очаква; иначе генерирането може да завърши успешно, а следващият компонент да тълкува обекта по друг договор.

Практичен начин да избегнете разминаването е да извеждате схемата от типовете в кода или обратно. Ако ги поддържате отделно, проверявайте при всяка промяна дали задължителните полета, допустимите стойности и версиите още съвпадат. Не приемайте, че строгият режим на даден доставчик поддържа всяко правило от пълния стандарт JSON Schema; проверете поддържаното подмножество, преди да разчитате на конкретно ограничение.

Отделете отказа и прекъсването от готовия резултат

Преди парсване разгледайте статуса на заявката и причината за приключване. Отказът, достигнатият лимит за изход и прекъснатият поток не са готов структуриран отговор. Частичният JSON не бива да се допълва по предположение, а текстът на отказ не бива да се подава към валидатора като данни за поръчка или клиент.

Документацията на Claude различава структурирания JSON изход от строгото извикване на инструменти и описва случаи, при които отказ, достигнат лимит или разлика в главните и малките букви на enum стойност нарушават очакваното съответствие. Затова приложението трябва да отчита както състоянието на отговора, така и точната стойност на критичните полета.

Върнете различими вътрешни резултати за отказ, непълен отговор, невалидна структура и нарушено бизнес правило. Те водят до различни решения: спиране, искане на допълнителен вход, ограничен нов опит или преглед от човек. Ако всички случаи се превърнат в празен обект, следващата стъпка губи причината за неуспеха и може да обработи липсата на данни като нормална стойност.

Проверете формата и типовете в приложението

След като отговорът е завършен, парснете целия JSON и го валидирайте локално спрямо договорената схема. Това е независима граница пред следващия компонент, особено когато процесът приема резултати от различни модели или версии на API. Не превръщайте мълчаливо низ в число и не приемайте част от поток за окончателен обект: и двете действия скриват несъответствие.

Локалната проверка трябва да завърши преди извличане на полета за действие. Така непознат статус, липсващ идентификатор или неправилен тип получава ясна грешка, вместо да стигне до база данни чрез стойност по подразбиране. За диагностика запазвайте версията на схемата, вида на грешката и идентификатора на заявката; при чувствителни данни няма нужда целият вход и отговор да се записват в оперативните логове.

Схемата установява как е представена стойността, но не дали тя е вярна за конкретната операция. Тя може да изисква поле за клиентски идентификатор и пак да получи идентификатор на друг клиент. Може да допуска положителна цена, която вече не е актуална. За тези въпроси е нужен достъп до данните, на които приложението има основание да се доверява.

Сверете стойностите с факти и бизнес правила

След структурната проверка изпълнете детерминистични правила, без да питате модела дали собственият му отговор е правилен. В условен пример за поръчка количество 2, единична цена 10 и обща сума 25 са валидни числа, но сумата не съвпада с произведението. Пресметнете я в приложението по правилата за съответната валута и закръгляне, вместо да използвате числото от модела като окончателно.

• Сверете кодове и идентификатори с допустимите стойности в системата. Синтактично правилен идентификатор не доказва, че записът съществува или че текущият потребител има право да работи с него.
• Проверете зависимости между полета и състоянието на външните системи. Ако резултатът твърди, че поръчката е платена, основанието за този статус трябва да дойде от платежната система, а не от текст, генериран от модела.
• При извличане от подаден текст сравнете критичните факти с този текст или с предварително определен надежден източник. Когато основание липсва, върнете изрично състояние за липсващи данни, вместо правдоподобно попълнено поле.

Неподходящият вход също трябва да има предвиден изход в договора. Ако задачата изисква данни за поръчка, а подаденият текст не съдържа поръчка, задължителните полета могат да подтикнат модела да попълни измислени стойности. Предвидете допустимо състояние за невъзможно извличане или насочете случая към преглед, преди да бъде разрешено действие.

Повтаряйте заявка само когато причината позволява

Нов опит е уместен при техническо прекъсване или поправима грешка във формата, с предварително определен лимит. Ако входът не съдържа търсения факт, повторението не създава доказателство. При нарушено бизнес правило първо установете дали проблемът е в източника, инструкциите към модела или текущите данни на системата; автоматичното повторение на същата заявка може само да предложи друга недоказана стойност.

Разрешавайте запис или извикване на инструмент едва след проверката на завършването, локалната валидация и сверяването с доверените данни. За операция с външен ефект използвайте механизъм за еднократно изпълнение, така че повторена заявка да не задейства второ плащане или втори запис. Отбелязвайте коя проверка е спряла резултата: това позволява да се поправи точно схемата, входът или бизнес правилото, без грешните стойности да преминат напред.

Прочетете също:

• Docker мести coding агентите в microVM — задачата продължава след лаптопа
• „Безопасен“ резултат не оправдава подозрителен линк — проверете без кликване
• Turnstile Spin инсталира защитата, но сървърната проверка остава решаваща