Strukturerte KI-svar: gyldig JSON kan fortsatt inneholde feil

For å få pålitelig, maskinlesbar JSON fra en språkmodell bør du definere et skjema og validere svaret i egen applikasjon før andre systemer bruker verdiene. Et svar kan følge skjemaet og likevel inneholde feil dato, beløp eller kategori.

Legg et kontrollpunkt mellom modellen og mottakersystemet: Sjekk om svaret ble fullført, om JSON-en følger kontrakten, og om verdiene stemmer med kilden og reglene for oppgaven. OpenAIs beskrivelse av Structured Outputs skiller mellom JSON-modus og skjemastyrte svar, og omtaler avslag, avbrutte svar og feil som fortsatt kan oppstå i verdiene.

Definer feltene og betydningen deres

Start med feltene mottakersystemet faktisk trenger. Angi datatype, obligatoriske felt og tillatte verdier der utvalget er begrenset. Hvis en kategori bare kan være «godkjent», «avvist» eller «ukjent», bør disse alternativene stå i skjemaet i stedet for at feltet åpnes for fritekst.

Bestem også forskjellen mellom en ukjent verdi og et felt som mangler. Hvis en dato kan være ukjent, må kontrakten angi hvordan det uttrykkes, for eksempel med en tillatt nullverdi. Hvis datoen alltid kreves, må et manglende felt føre til avvisning eller gjennomgang. Modellen bør ikke presses til å fylle inn en tilsynelatende presis dato når grunnlaget ikke oppgir en.

Gi hvert felt en entydig oppgave. Beskriv hvilken opplysning som skal hentes fra inndataene, hvilken valuta eller enhet et tall skal ha, og om utledning er tillatt. Skillet mellom «beløpet på dokumentet» og «beløpet som skal betales» kan være avgjørende selv om begge passer i et tallfelt. Feltbeskrivelser hjelper modellen, mens applikasjonens kontroll avgjør om resultatet kan brukes.

Skill avslag og avbrudd fra fullførte svar

Ikke send ethvert API-svar rett til JSON-tolkeren. Kontroller først leverandørens signaler for avslag, avbrudd og andre feil. Et avslag kan komme utenfor skjemaet. Et svar som stoppet under generering, kan se lovende ut i starten, men mangle data som trengs for å behandle hele posten.

Bestem håndtering for hvert utfall. Et fullført svar går videre til validering. Et avbrutt svar kan forsøkes på nytt etter en fast regel, med en grense for antall forsøk. Et avslag må registreres som avslag, ikke oversettes til tomme eller antatt gyldige felt. Dermed kan mottakersystemet skille mellom «modellen svarte ikke» og «opplysningen finnes ikke i grunnlaget».

Når statusen er godkjent, tolker applikasjonen JSON-en og validerer den mot sin egen datakontrakt. Da fanges manglende obligatoriske felt, feil datatyper og verdier utenfor tillatte lister ved mottaket. Den samme kontrollen bør gjelde uansett om leverandøren allerede har styrt genereringen med et skjema: Det er mottakersystemets kontrakt som bestemmer hvilke data det kan ta imot.

Kontroller om verdiene er riktige

Skjemavalidering kan kontrollere at et beløp er et tall og at et datofelt har forventet form. Den kan ikke alene avgjøre om beløpet er hentet fra riktig linje, om datoen gjelder riktig hendelse, eller om en status er forenlig med resten av posten. Slike krav må uttrykkes som egne regler eller som sammenligninger med et autoritativt grunnlag.

I et tenkt eksempel skal modellen hente forfallsdato og totalsum fra et dokument. Svaret kan bestå skjemaet selv om dokumentdatoen havner i feltet for forfallsdato, eller en delsum havner i feltet for totalsum. Kontrollen må knytte hvert felt til riktig opplysning i grunnlaget. Hvis den koblingen ikke kan fastslås, er gjennomgang eller avvisning tryggere enn automatisk bruk.

Datofelt krever en ekstra presisering. JSON Schemas forklaring av format sier at nøkkelordet format som utgangspunkt er en merknad; om det faktisk avviser ugyldige datoer, avhenger av validatorens oppsett. Kontroller derfor både at datoen kan tolkes og at den er riktig for oppgaven. For beløp må valuta og enhet følge samme kontroll, ellers kan et teknisk gyldig tall få feil betydning i en beregning.

Behold en egen kontrakt på tvers av leverandører

Ikke anta at modellleverandører støtter eller håndhever de samme delene av JSON Schema. Geminis dokumentasjon for strukturerte svar beskriver støtte for et delsett av spesifikasjonen og anbefaler uttrykkelig at verdiene valideres i applikasjonen selv når JSON-syntaksen er korrekt.

Lag én intern datakontrakt som mottakersystemet validerer mot, og tilpass skjemaet som sendes til hver modell-API. Ved oppstart eller utrulling bør applikasjonen oppdage om leverandøren avviser skjemaet. Kontroller også at begrensningene dere er avhengige av, faktisk blir håndhevet. Regler som ikke kan uttrykkes i leverandørens støttede delsett, må fortsatt ligge i den interne valideringen.

Versjoner kontrakten når felter eller betydninger endres. Lagre hvilken versjon et svar ble produsert og vurdert mot, slik at eldre svar ikke senere tolkes etter nye regler. Ved bytte av modell eller leverandør kan de samme kontrollene brukes til å avdekke om håndteringen av manglende felt, nullverdier og avbrudd har endret seg.

Test plausible feil og logg utfallet

En nyttig testpakke inneholder mer enn ødelagt JSON. Bruk kontrollerte tilfeller der alle datatyper og obligatoriske felt er riktige, men en plausibel verdi er feil: en dato hentet fra feil sted, et beløp med feil valuta, en kategori som bryter en forretningsregel, eller et utfylt felt der grunnlaget ikke gir svar. Testen bør angi både forventet verdi og forventet behandling når riktig verdi ikke kan fastslås.

Ta også med avslag, avbrudd, tomme inndata og svar som tilhører en annen skjemaversjon. For hvert tilfelle bør forventet utfall være tydelig: godta, avvis, prøv igjen eller send til gjennomgang. Slik prøves beslutningen som beskytter mottakersystemet, ikke bare om en JSON-tolker klarer å lese teksten.

Logg leverandør og modell, skjemaversjon, svarstatus, valideringsutfall og regelen som stoppet en post. Behandle inndata og svarinnhold etter virksomhetens krav til lagring og tilgang. Når en feil må undersøkes, viser loggen hvilken kontrakt og kontroll som gjaldt, uten at et teknisk gyldig svar automatisk blir regnet som riktig.

Les også:

• Slik måler du RAG: et troverdig svar kan fortsatt bygge på feil treff
• Syntetiske treningsdata: mer volum kan også forsterke feilene
• Slik kjøper du SpaceX-aksjen fra Norge – ASK kan ikke brukes