Структурирани изходни данни от AI чатбот: JSON Schema, валидация и сигурни fallback механизми

Един AI чатбот може да формулира убедителен отговор и въпреки това да повреди последващ процес. Липсващо поле, свободно измислена категория или непроверена връзка са достатъчни, за да може CRM, тикет система или уебсайт фронтенд да обработят грешни данни. Структурираните изходни данни от AI чатбот намаляват този риск, като описват задължително формата и типовете данни. Но те стават наистина надеждни едва когато схемата, бизнес значението, правата за достъп и случаите на грешка се проверяват отделно.

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

Валидният JSON все още не е надежден договор

По-старият JSON режим на много API на модели основно гарантира, че даден отговор може да бъде парсиран като JSON. Той не гарантира, че очакваните полета присъстват или че договорените типове се спазват. Официалната документация на OpenAI за Structured Outputs затова изрично прави разлика между валиден JSON и съответствие със схемата. Microsoft Foundry също описва Structured Outputs като обвързване на отговора с изпратена JSON Schema.

Това е важен напредък: вместо последващо да се отгатват променящи се имена на полета, приложението получава предвидима структура. Въпреки това доставчиците често поддържат само част от пълната спецификация. Документацията за структурирани изходни данни на Gemini посочва поддържаните типове и свойства, но същевременно обръща внимание на подмножествата и ограниченията в сложността. Поради това дадена схема трябва да бъде тествана за действително използвания модел и конкретния API път.

Схемата описва формата, а не истината

JSON Schema е декларативен език за описване на структурата и ограниченията на JSON данни. Дадено поле може например да бъде дефинирано като задължително, число, изброяване (enum) или масив. От това обаче не следва, че дадена стойност е бизнес коректна. Символният низ 2026-02-31 може формално да пасне като текст, въпреки че датата не съществува. Позволен продукт ID може да бъде синтактично коректен и все пак неизвестен в текущия профил/клиент.

Ето защо за продуктивни чатботове са необходими няколко слоя за проверка:

n

Слой за проверка	Типичен въпрос	Пример
Транспорт	Пълен и парсируем ли е отговорът?	без прекъсване по средата на JSON
Схема	Съвпадат ли полетата, типовете и позволените стойности?	priority е само low, medium или high
Семантика	Бизнес правдоподобно и вътрешно съвместимо ли е съдържанието?	крайната дата не е преди началната дата
Политика и достъп	Има ли право този потребител да вижда или използва тази стойност?	тикетът принадлежи на автентикирания клиентски акаунт
Контекст на изхода	Стойността рендира ли се или предава ли се безопасно?	текстът се кодира за HTML, а не се интерпретира като скрипт

Това разделение предотвратява объркването на съответствието със схемата с бизнес одобрението. За измерване и регресионни тестове то може да се комбинира с Golden Set за качество на отговорите на AI чатбот.

Проектиране на малки, специфични за дадена задача схеми

Един-единствен универсален обект за отговор бързо става дълбоко влаган, труден за разбиране и скъп за поддръжка. По-добре е да има малка схема за всяка ясна задача, като например класифициране на обратна връзка, предварително структуриране на запитване за поддръжка или маркиране на липсващи данни за последващ въпрос. Името и описанието на всяко поле трябва да обясняват неговото бизнес значение.

• Избирайте задължителните полета съзнателно: Изисквайте само стойности, от които процесът наистина се нуждае. Изобразявайте неизвестните стойности изрично като null или със собствен статус, вместо да оставяте модела да ги измисля.
• Използвайте изброявания (enums) вместо свободен текст: Кратък, версиониран списък предотвратява правописни вариации при статус, категория или следваща стъпка.
• Отхвърляйте допълнителни полета: Когато доставчикът го поддържа, additionalProperties: false предотвратява изненадващи ключове.
• Повтаряйте ограниченията в кода на приложението: Не оставяйте дължините, диапазоните от стойности, URL хостовете и междуструктурните връзки единствено на модела или на специфично за доставчика подмножество от схеми.
• Версионирайте схемата: Стабилен идентификатор и хеш показват кой договор е генерирал и проверил даден отговор.

„Неизвестно“ е отделно състояние

Празно поле, липсващо поле и изрично неизвестна стойност не означават едно и също нещо. Ако дадена информация липсва в източника, схемата трябва да предвиди допустимо състояние за това. В противен случай договорът индиректно възнаграждава модела за това, че поставя правдоподобен символен низ. За критични стойности комбинацията от value, status и незадължителен reason често е по-надеждна от едно поле със свободен текст.

Доказване на версията и хеша заедно

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

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

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

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

Вътрешна обвивка (envelope), независима от доставчика, разделя най-малко success, refused, incomplete, provider_error и validation_failed. Едва при success структурираното съдържание се предава на следващия слой за проверка. При останалите състояния потребителите виждат кратка, честна обратна връзка или сигурно предаване, но не и измислени заместителни данни.

Проверка на семантичните правила от страна на сървъра

След проверката на схемата започва бизнес валидацията. Тя трябва да бъде детерминирана и възможно най-независима от модела. Идентификаторите на продуктите се проверяват спрямо актуалния източник на данни, URL адресите — спрямо позволените протоколи и хостове, а кодовете за локал (locale) — спрямо действително поддържаните езици. Сумите, времевите периоди и промените в състоянието се нуждаят от кръстосани проверки. При RAG отговори даден посочен източник трябва действително да се съдържа в одобрения резултат от извличането (retrieval).

Това важи и за изглеждащи безобидно текстови полета. Проектът за сигурност OWASP GenAI Security Project предупреждава за недостатъчно проверени изходни данни от модела, когато те се предават на браузъра, базата данни, файловата система или други инструменти. За HTML се кодира съобразно контекста, достъпът до базата данни остава параметризиран, а системните команди никога не се сглобяват от свободно генериран текст. Структурираните изходни данни са вход от ненадежден източник, а не привилегирован вътрешен обект.

Сигурният fallback механизъм не поправя на всяка цена

При погрешен отговор незабавният идентичен retry рядко е най-добрата стандартна реакция. Той може да увеличи разходите и да повтори същата грешка. Ограниченият fallback път прави разлика в причината:

1. Техническо прекъсване: При ясно временна грешка от доставчика повторете строго ограничено и използвайте същия идемпотентен ID.
2. Твърде сложна схема: Разделете задачата на по-малки, индивидуално валидируеми стъпки. Това е планирана промяна в продукта, а не спонтанно пропускане на задължителни полета.
3. Семантична грешка: Не задействайте автоматично действие. Попитайте целево за липсващите данни или предайте случая за човешка проверка.
4. Отказ или граница на политиката: Уважавайте отказа и предложете допустим път за информация или прехвърляне (handoff).
5. Неясна ситуация след запис (write): Първо прочетете целевата система с помощта на идемпотентния ID, преди да започнете втори опит за запис.

За по-големи промени се препоръчва тест в сянка (shadow mode) преди пускането на уебсайта. При това новият структуриран път вече генерира резултати, но все още не управлява действия на потребителя.

Тестовете на договора покриват повече от примерни диалози

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

При промени в схемата екипът трябва да валидира старите запазени примери спрямо новата версия. По време на миграция приложението може временно да проверява спрямо старата и новата версия, без да изпълнява две действия. Едва когато процентът на успех, семантичните откази и латентността са стабилни, новият договор се превръща в път за запис. Грешките могат да бъдат свързани с използваната версия на модела, промпта и схемата чрез цялостна AI чатбот наблюдаемост (observability), без да се логват пълни поверителни отговори.

Метрики за текущата работа

Най-важната метрика не е само делът на синтактично валидните отговори. Полезни са процентът на схемата от първия опит, процентът на семантичните откази, делът на непълните отговори, отказите, ограничените опити за ремонт, предаванията на човек, както и латентността и разходите за успешно валидиран резултат. Стойностите се разглеждат отделно според версията на модела, промпта, схемата, случая на употреба и локала (locale).

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

Чеклист преди първото автоматично действие

• Тестван ли е конкретният API и път на модела с точно тази схема?
• Разпознават ли се непълните отговори, отказите и грешките на доставчика преди парсирането?
• Валидира ли сървърът схемата и бизнес правилата независимо от модела?
• Проверяват ли се отново идентичността, профилът/клиентът и правата за достъп непосредствено преди всяко действие?
• Защитени ли са HTML, URL адресите, стойностите в базата данни и параметрите на инструментите съобразно контекста?
• Предотвратяват ли идемпотентността и обратното четене двойни записи?
• Има ли тестове с Golden Set, тестове за атаки, за локали и за миграция?
• Наблюдаеми ли са версията на схемата, класът на грешката и метриките за качество?
• Може ли екипът да превключи обратно към безопасен информационен режим или режим на предаване (handoff) без загуба на данни?

Структурираните изходни данни правят AI чатботовете по-лесни за интегриране, но те не прехвърлят авторитет на модела. Всеки, който третира формата, семантиката, достъпа и контекста на изхода как отделни бариери (gates), получава проследим договор вместо привидно сигурна JSON фасада. За нов уебсайт работен поток си струва да се започне с точно един ограничен случай на употреба, малка версионирана схема и измерим тест в сянка.