Struktūruotos DI pokalbių botų išvestys: JSON schema, validavimas ir saugūs atsarginiai scenarijai

DI pokalbių botas gali suformuluoti įtikimą atsakymą ir vis tiek pakenkti tolesniam procesui. Trūkstamo lauko, sugalvotos kategorijos arba nepatikrintos nuorodos pakanka, kad CRM, užklausų sistema ar svetainės sąsaja apdorotų neteisingus duomenis. Struktūruotos DI pokalbių botų išvestys sumažina šią riziką, privalomai apibrėždamos formą ir duomenų tipus. Tačiau jos tampa patikimos tik tada, kai schema, dalykinė reikšmė, leidimai ir klaidų atvejai tikrinami atskirai.

Šis gidas skirtas svetainių, produktų ir operacijų komandoms, kurios automatiškai apdoroja modelio išvestis. Jame parodyta, ką gali atlikti JSON schema, kur yra jos ribos ir kaip sukurti saugų kelią nuo modelio atsakymo iki faktinio veiksmo.

Galiojantis JSON dar nėra patikima sutartis

Senesnis daugelio modelių API JSON režimas daugiausia užtikrina tik tai, kad atsakymą būtų galima išanalizuoti kaip JSON. Jis negarantuoja, kad tikimasi laukai egzistuoja arba kad laikomasi sutartų tipų. Oficiali OpenAI dokumentacija apie Structured Outputs todėl aiškiai skiria galiojantį JSON nuo atitikties schemai. Taip pat ir Microsoft Foundry aprašo Structured Outputs kaip atsakymo susiejimą su kartu pateikiama JSON schema.

Tai yra svarbi pažanga: užuot vėliau spėliojus kintančius laukų pavadinimus, programa gauna nuspėjamą struktūrą. Nepaisant to, teikėjai dažnai palaiko tik dalį visos specifikacijos. Gemini dokumentacija struktūruotoms išvestims nurodo palaikomus tipus ir savybes, tačiau kartu atkreipia dėmesį į poaibius ir sudėtingumo ribas. Todėl schema turi būti išbandyta su konkrečiu naudojamu modeliu ir konkrečiu API keliu.

Schema aprašo formą, o ne tiesą

JSON schema yra deklaratyvi kalba, skirta JSON duomenų struktūrai ir apribojimams aprašyti. Pavyzdžiui, laukas gali būti apibrėžtas kaip privalomas, skaičius, išvardijimas (enum) arba masyvas. Tačiau iš to neseka, kad reikšmė yra teisinga dalykine prasme. Simbolių eilutė 2026-02-31 formaliai gali tikti kaip tekstas, nors tokia data neegzistuoja. Leidžiamas produkto ID gali būti sintaksiškai teisingas, bet nežinomas esamoje kliento aplinkoje.

Todėl gamybiniams pokalbių botams reikalingi keli patikrinimo sluoksniai:

Patikrinimo sluoksnis	Tipinis klausimas	Pavyzdys
Transportavimas	Ar atsakymas yra pilnas ir išanalizuojamas?	nėra nutrūkimo JSON viduryje
Schema	Ar sutampa laukai, tipai ir leidžiamos reikšmės?	priority yra tik low, medium arba high
Semantika	Ar turinys yra logiškas ir viduje nuoseklus?	pabaigos data nėra ankstesnė už pradžios datą
Taisyklės ir prieiga	Ar šiam vartotojui leidžiama matyti ar naudoti šią reikšmę?	užklausa priklauso autentifikuoto kliento paskyrai
Išvesties kontekstas	Ar reikšmė vaizduojama arba perduodama saugiai?	tekstas koduojamas HTML formatu, o ne interpretuojamas kaip skriptas

Šis atskyrimas neleidžia supainioti atitikties schemai su dalykiniu patvirtinimu. Matavimui ir regresiniam testavimui jį galima susieti su Golden Set sk skirtu DI pokalbių boto atsakymų kokybei matuoti.

Mobilių, konkrečioms užduotims skirtų schemų kūrimas

Vienas universalus atsakymo objektas greitai tampa giliai įdėtiniu, sunkiai suprantamu ir brangiai prižiūrimu. Geriau kurti mažą schemą kiekvienai aiškiai užduočiai, pavyzdžiui, atsiliepimams klasifikuoti, palaikymo užklausai iš anksto sugrupuoti arba trūkstamiems duomenims papildomam klausimui pažymėti. Kiekvieno lauko pavadinimas ir aprašymas turėtų paaiškinti jo dalykinę reikšmę.

• Privalomus laukus rinkitės apgalvotai: Reikalaukite tik tų reikšmių, kurių procesui tikrai reikia. Nežinomas reikšmes aiškiai atvaizduokite kaip null arba atskirą būseną, užuot leidę jas išgalvoti.
• Naudokite išvardijimus, o ne laisvą tekstą: Trumpas, versijuotas sąrašas apsaugo nuo rašybos variantų atveju, kai nustatoma būsena, kategorija ar kitas žingsnis.
• Atmeskite papildomus laukus: Jei teikėjas tai palaiko, additionalProperties: false apsaugo nuo netikėtų raktų.
• Pakartokite apribojimus programos kode: Užtikrinkite, kad ilgiai, reikšmių rėžiai, URL adresai ir tarpusavio ryšiai nebūtų palikti tik modelio ar konkretaus teikėjo schemos poaibio atsakomybei.
• Versijuokite schemą: Stabilus identifikatorius ir maiša (hash) parodo, kuri sutartis sugeneravo ir patikrino atsakymą.

„Nežinoma“ yra atskira būsena

Tuščias laukas, trūkstamas laukas ir aiškiai nežinoma reikšmė nereiškia to paties. Jei šaltinyje trūksta informacijos, schema turėtų numatyti tam leidžiamą būseną. Priešingu atveju sutartis netiesiogiai apdovanoja modelį už tai, kad jis įrašo tikėtiną simbolių eilutę. Kritinėms reikšmėms kombinacija iš value, status ir neprivalomo reason dažnai yra patikimesnė nei vienas laisvo teksto laukas.

Pateikite versiją ir maišą kartu

Prie atsakymo priskiriama ne tik modelio ir užklausos (prompt) versija, bet ir schemos bei validatoriaus versija. Faktiškai išsiųstos schemos maiša apsaugo nuo tylaus nuokrypio dėl kūrimo ar konfigūracijos pakeitimų. Migracijos metu ta pati modelio išvestis iš pradžių gali būti patikrinta pagal abiejų sutarčių versijas. Rašymas ir toliau vykdomi tik aktyviu keliu; skirtumai įrašomi kaip palyginimo duomenys kokybės užtikrinimo (QA) sistemoje.

Užklausose neturėtų būti slaptos informacijos ar vidinių leidimų sprendimų, perkeliamų į schemą. Pavyzdžiui, modeliui leidžiama klasifikuoti pageidaujamą kitą žingsnį. Ar šis žingsnis yra leidžiamas, vėliau nusprendžia serveris, remdamasis esama tapatybe ir taisyklėmis.

Nutraukimą ir atmetimą traktuokite kaip atskiras būsenas

Griežtai suformatuotas atsakymas gali ir nepasirodyti. Išvesties limitai, laiko limitai (timeouts), turinio filtrai, teikėjo klaidos arba sąmoningas modelio atsisakymas yra normalios veiklos būsenos. OpenAI struktūrizuotoms išvestims dokumentuoja tiek nevisus atsakymus, tiek atskirą atmetimo kelią, kuris nebūtinai atitinka prašomą schemą. Todėl programos neturi aklai kreiptis į pirmąjį tikėtiną lauką.

Atskiriamas vidinis apvalkalas, nepriklausomas nuo teikėjo, atskiria bent success, refused, incomplete, provider_error ir validation_failed. Tik esant success, struktūrizuotas turinys perduodamas kitam patikrinimo sluoksniui. Esant kitoms būsenoms, vartotojai mato trumpą, sąžiningą pranešimą arba saugų perdavimą, bet ne išgalvotus pakaitinius duomenis.

Tikrinkite semantines taisykles serverio pusėje

Atlikus schemos patikrinimą, prasideda dalykinis validavimas. Jis turėtų būti deterministinis ir kuo labiau nepriklausomas nuo modelio. Produktų identifikatoriai tikrinami pagal esamą duomenų šaltinį, URL adresai – pagal leidžiamus protokolus ir domenus, kalbų kodai – pagal faktiškai palaikomas kalbas. Sumoms, laikotarpiams ir būsenų pokyčiams reikalingi kryžminiai patikrinimai. RAG atsakymų atveju nurodytas šaltinis turi faktiškai egzistuoti patvirtintuose paieškos rezultatuose.

Tai galioja ir iš pažiūros nekenksmingiems teksto laukams. OWASP GenAI saugumo projektas įspėja apie nepakankamai patikrintas modelio išvestis, kai jos perduodamos naršyklei, duomenų bazei, failų sistemai ar kitiems įrankiams. HTML tekstas koduojamas pagal kontekstą, prieiga prie duomenų bazės išlieka parametrizuota, o sisteminės komandos jokiu būdu nesudaromos iš laisvai sugeneruoto teksto. Struktūrizuota išvestis yra įvestis iš nepatikimo šaltinio, o ne privilegijuotas vidinis objektas.

Saugus atsarginis scenarijus netaiso bet kokia kaina

Klaidingo atsakymo atveju greitas, identiškas pakartotinis bandymas retai būna geriausia standartinė reakcija. Tai gali padidinti išlaidas ir pakartoti tą pačią klaidą. Apribotas atsarginis kelias atskiria priežastį:

1. Techninis nutrūkimas: Esant aiškiai laikinai teikėjo klaidai, pakartokite tiksliai apribotą skaičių kartų, naudodami tą patį idempotentiškumo ID.
2. Per daug sudėtinga schema: Padalinkite užduotį į mažesnius, atskirai patikrinamus žingsnius. Tai yra suplanuotas produkto pakeitimas, o ne spontaniškas privalomų laukų atsisakymas.
3. Semantinė klaida: Neinicijuokite jokio automatinio veiksmo. Tikslingai pasiteiraukite trūkstamų duomenų arba perduokite atvejį žmogaus patikrinimui.
4. Atmetimas arba taisyklių riba: Gerbkite atmetimą ir pasiūlykite leidžiamą informacijos arba perdavimo kelią.
5. Neaiški būsena po įrašymo: Prieš pradėdami antrąjį bandymą įrašyti, pirmiausia perskaitykite tikslinės sistemos duomenis naudodami idempotentiškumo ID.

Didesniems pakeitimams rekomenduojamas šešėlinio režimo (shadow mode) testas prieš svetainės paleidimą. Jo metu naujas struktūrizuotas kelias jau generuoja rezultatus, tačiau dar nevaldymo vartotojo veiksmų.

Sutarčių testai apima daugiau nei pavyzdinius dialogus

Geras testavimo rinkinys apima ne tik idealias užklausas. Tuščios įvestys, labai ilgi tekstai, prieštaringi duomenys, nežinomos kategorijos, kelios kalbos, užklausų įterpimo (prompt injection) bandymai, teikėjo atmetimai ir tyčia sumažinti žetonų (token) limitai taip pat yra jo dalis. Kiekvienam atvejui tikėtina veiklos būsena, schemos rezultatas ir dalykinis sprendimas fiksuojami atskirai.

Keičiant schemą, komanda turėtų patikrinti senus išsaugotus pavyzdžius pagal naująją versiją. Migracijos metu programa laikinai gali tikrinti pagal senąją ir naująją versiją, neatlikdama dviejų veiksmų. Tik tada, kai sėkmės rodiklis, semantiniai atmetimai ir vėlavimas yra stabilūs, naujoji sutartis tampa įrašymo keliu. Klaidos gali būti priskirtos naudojamo modelio, užklausos ir schemos versijai naudojant visapusišką DI pokalbių boto stebėjimą (observability), nesaugant visų konfidencialių atsakymų.

Rodikliai kasdienei veiklai

Svarbiausias rodiklis nėra vien tik sintaksiškai galiojančių atsakymų dalis. Naudingi rodikliai yra pirmojo bandymo schemos rodiklis, semantinio atmetimo dažnumas, nevisų atsakymų dalis, atmetimai, apriboti taisymo bandymai, perdavimai žmogui bei vėlavimas ir kaina, tenkanti vienam sėkmingai patikrintam rezultatui. Reikšmės vertinamos atskirai pagal modelio, užklausos, schemos versiją, naudojimo atvejį ir kalbos nustatymą (locale).

Staigus semantinių klaidų padidėjimas, kai schemos rodiklis išlieka nepakitęs, yra ypač informatyvus: forma vis dar teisinga, tačiau turinys arba duomenų sąsaja nukrypsta. Tokiu atveju procesas turėtų pereiti į saugų režimą. Esamas gidas apie degraduotą režimą ir atstatymą (rollback) DI pokalbių botuose parodo, kaip paruošti tokį atsarginį kelią.

Kontrolinis sąrašas prieš pirmąjį automatinį veiksmą

• Ar konkretus API ir modelio kelias išbandytas būtent su šia schema?
• Ar nevisi atsakymai, atmetimai ir teikėjo klaidos atpažįstami prieš atliekant analizę (parsing)?
• Ar serveris tikrina schemą ir dalykines taisykles nepriklausomai nuo modelio?
• Ar tapatybė, kliento aplinka ir teisės vėl patikrinamos prieš pat kiekvieną veiksmą?
• Ar HTML, URL adresai, duomenų bazės reikšmės ir įrankių parametrai yra saugūs atitinkamame kontekste?
• Ar idempotentiškumas ir nuskaitymas atgal apsaugo nuo dvigubo įrašymo veiksmų?
• Ar yra „Golden Set“, atakų, kalbų palaikymo ir migracijos testai?
• Ar schemos versija, klaidos klasė ir kokybės rodikliai yra stebimi?
• Ar komanda gali be duomenų praradimo perjungti į saugų informavimo arba perdavimo žmogui režimą?

Struktūrizuotos išvestys padaro DI pokalbių botus lengviau integruojamus, tačiau jos nesuteikia modeliui autoriteto. Tie, kurie formą, semantiką, prieigą ir išvesties kontekstą vertina kaip atskirus vartus, gauna suprantamą sutartį, o ne tik tariamai saugų JSON fasadą. Naujam svetainės procesui verta pradėti nuo vieno apriboto naudojimo atvejo, mažos versijuotos schemos ir matuojamo šešėlinio testo.