JSON-skemavalidering uden LLM

Determinisme er produktet

Når jeg designer en validerer, fokuserer jeg på gennemgangen af instancetræet. Hver trin producerer et fejlobjekt, der bærer en JSON Pointer-sti, det fejlende nøgleord og en kort besked. Fordi gennemgangen følger den samme algoritme for de samme data, er fejllisten identisk på hver kørsel. Denne gentagelighed giver holdene mulighed for at behandle validering som en port, der aldrig ændrer sin dom uden en reel ændring i skemaet eller input.

JSON Pointer-stier mapper direkte til formularfelter eller API-svarnøgler. En front-end kan tage pegeren /items/2/name og højligte det tredje elements navnefelt uden nogen ekstra oversættelsesskikt. Denne mapping er deterministisk, så den samme peger peger altid på det samme sted i det samme dokumentform.

I CI kører jeg validereren mod testssuiten og mod eventuelt genererede fixtures. Hvis validereren returnerer en tom fejlarray, fortsætter bygningen; enhver ikke-tom array mislykkes bygningen, og fejllasten publiceres som en artifact. Fordi outputtet er maskinlæsbart, kan downstream-trin tælle fejl, gruppere dem efter peger eller poste en kommentar på pull-forespørgslen, der viser de præcise fejlende stier.

Hvor et LLM tjener sin plads

Jeg bruger kun en sprogmodel til opgaver, der ikke kræver en sand/falsk afgørelse. Modellen afgør aldrig om en vurdering er bestået eller ikke-bestået; den producerer kun forslag, som en menneskelig eller et værktøj kan gennemgå.

Givet en håndfuld eksempel-JSON-dokumenter beder jeg modellen om at udgive et Draft 2020-12-skema, der fanger de observerede typer, påkrævede felter og grundlæggende mønstre. Outputtet er et udgangspunkt; jeg kører det gennem valideringsværktøjet for at se, om det accepterer eksemplerne, og derefter justerer jeg manuelt begrænsningerne.

Når valideringsværktøjet returnerer en liste af fejl, føder jeg hver fejlobjekt til modellen med en anmodning om at omskrive meddelelsen på almindeligt sprog. Modellen kan omdanne „failed keyword “required” at pointer /user/profile/age” til „Brugerprofilen mangler en aldersfelt, som din tjeneste forventer at være et helt tal.” Dette hjælper API-forbrugere, der ikke er bekendt med JSON-skema-nøgleord.

Ved at vise modellen en liste af hyppige valideringsfejl kan jeg bede den om at foreslå yderligere begrænsninger, såsom en minimumstekstlængde eller et mønster for en identifikator. Jeg gennemgår hver forslag, tilføjer dem, der giver mening, og kører valideringsværktøjet igen for at bekræfte, at det nye skema stadig passerer de kendte gode eksempler.

Til sikkerhed holder jeg modellen bag en intern API og logger hver anmodning og svar. Loggen giver mig mulighed for at gennemgå, om modellen nogensinde har forsøgt at påvirke afgørelsesgrænsen, hvilket den ikke kan, fordi jeg aldrig sender dens output til valideringsværktøjet som en regel.

Kør validering i CI og på kanten

Den samme skema skal beskytte kodebiblioteket og den live-tjeneste. Jeg kører valideringsværktøjet på to steder:

Kørsel af validering kun på en gateway efterlader den interne tjeneste åben for drift; hvis gateway-skemaet opdateres, men en downstream-tjeneste glemmer at trække ændringen, kan dårlige data slippe igennem. Ved at integrere valideringsværktøjet i tjenesten garanterer jeg, at kontrakten gennemtvinges, uanset hvor koden befinder sig.

Når valideringen fejler, returnerer jeg HTTP 400 med en JSON-tekst, der indeholder et array af fejlobjekter. Hvert fejlobjekt indeholder:

Klienter kan parse dette array og vise inline-form-fejl, hvilket accelererer integrationsarbejdet i forhold til en generisk „validering fejlet“-streng.

Fordi valideringsværktøjet er stateless og deterministisk, kan jeg bruge samme binær- eller bibliotek på begge steder uden at bekymre mig om skjult tilstand, der kunne forårsage divergens.

Udkastgenerering versus styring

SchemaSafe adskiller sig klart fra andre:

Denne opdeling sikrer, at kontrakten er gennemskuelig. Jeg kan pege på en specifik skemafil i repository, notere valideringsversionen og vise, at den samme input altid giver det samme resultat. Modellens bidrag lever i separate logfiler eller i kommentarer vedhæftet pull-anmodningen; det bliver aldrig en del af den uændrede beslutningsrekord.

Når jeg skal opdatere skemaet, følger jeg disse trin:

Gennem hele denne arbejdsgang er validereren portvagten; modellen får aldrig det endelige ord.

Hvad dette ikke er

Denne tilgang er ikke en garanti for, at hver enkelt ugyldig dokument bliver fanget, før det når en bruger. Hvis en udvikler bevidst omgår middleware eller hvis en fejl i valideringsværktøjet lader en fejl slippe igennem, kan dårlige data stadig optræde. Jeg hævder ikke 100 % dækning; jeg hævder kun, at kontrollen er deterministisk og gentagelig.

Det er ikke en erstatning for omhyggelig API-design. En skema kan beskrive form og grundlæggende begrænsninger, men det kan ikke udtrykke forretningsregler, der afhænger af eksternt tilstand eller kompleks tværfeltlogik. Disse regler kræver stadig enhedstests eller runtime-beskyttelse.

Det er ikke en garanti for, at LLM altid producerer nyttige forklaringer. Modellen kan lejlighedsvis overse nuancer eller producere en misvisende omskrivning. Jeg behandler dens output som en forslag, som en menneskelig kan acceptere, redigere eller forkaste.

Endelig er det ikke en mirakelkur mod sikkerhed. Selvom validering af input reducerer mange injektionsrisici, følger jeg stadig vejledningen fra OWASP om promptinjektion ( https://genai.owasp.org/llmrisk/llm01-prompt-injection ) og om legitimationshygiejne i CI/CD ( https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene ) for at holde den omgivende pipeline sikker.

Referencer

https://genai.owasp.org/llmrisk/llm01-prompt-injection

https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene

https://ajv.js.org/json-schema.html

https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

Ofte stillede spørgsmål

Validering skal være reproducerbar: samme input, samme resultat. En models vurdering kan variere mellem kørsler, hvilket er uacceptabelt for en kontrakt, der kontrollerer en installation. Valideringsværktøjet afgør; modellen forklarer.

Opstilling af et schema fra et eksempel, omskrivning af en valideringsfejl til et menneske eller foreslå, hvorfor et felt blev udeladt. Disse er hjælpemidler oven på en rigtig valideringsværktøj, ikke en erstatning for en.

Nej. Valider indgående anmodninger i den tjeneste, du kontrollerer, så fejlmeddelelserne indeholder domænekontekst. Kør det samme schema i CI mod faste data, og behandle schemas ændringer som potentielle brud på ændringer.

Udkast 2020-12 er den stabile version, der understøttes af moderne valideringsværktøjer som Ajv v8 og er i tråd med OpenAPI 3.1. Fastgør $schema-URL'en i hver fil, så adfærden ikke glider.

Prøv produktet: SchemaSafe

2026-09-16 · kun primære kilder · ingen fabrikerede trafikmålinger

Relaterede artikler

Almindelige fejl ved skabelse af JSON-skemaer

Udforsk det fulde AI mikro-SaaS emne-matrix →