Strukturerede AI-output: valider data før integration

Lav en leverancekontrakt mellem modellen og systemet

Et menneske kan ofte forstå et svar, selv om det skifter form fra gang til gang. Et CRM eller et integrationsflow har brug for tydelige felter. Hvis modellen én gang skriver 'budget ukendt' og næste gang indsætter et gættet beløb i en forklarende sætning, bliver automatisk viderebehandling usikker. Struktureret output beskriver, hvilken form resultatet skal have.

Kontrakten kan eksempelvis kræve en kategori fra en fast liste, et kort resumé, et budgetfelt med mulighed for ukendt og en liste over oplysninger, der skal afklares. Formålet er ikke at gøre teksten mere teknisk for brugeren. Det er at skabe en kontrollerbar grænse mellem AI-fortolkningen og de systemer, der skal bruge resultatet.

Guiden bruger en tænkt projektforespørgsel som gennemgående eksempel. Modellen skal udtrække det, afsenderen faktisk har skrevet, og klargøre data til en intern vurdering. Den må ikke godkende projektet eller oprette en aftale. Den afgrænsning gør det tydeligt, hvilke oplysninger AI kan foreslå, og hvilke beslutninger der stadig kræver regler, opslag eller menneskelig vurdering. Et godt schema starter med den forskel.

Design felter ud fra den næste handling

Begynd i målsystemet. Hvilke oplysninger skal næste trin bruge, og hvilke felter ville være farlige at udfylde med et gæt? Et kontaktresumé kan være en tekst, men et kunde-id skal komme fra et kontrolleret match. Et budget kan være et tal, hvis det er oplyst, mens manglende valuta gør tallet utilstrækkeligt til visse handlinger.

Definér for hvert felt navn, type, kilde og betydning. JSON Schema kan beskrive objekters felter og hvilke felter der er krævet. Et felt bliver ikke obligatorisk alene ved at stå under properties; det kræver den relevante required-definition. Overvej også, om uventede ekstra felter skal afvises, så modellen ikke udvider kontrakten på egen hånd.

Hold første version lille. Mange felter øger antallet af definitioner og fejlforløb, teamet skal forstå. Tilføj kun et felt, hvis det skal bruges i en konkret beslutning eller kontrol. Et felt som 'strategisk potentiale' er svært at validere uden en tydelig definition. Et felt som 'nævnte systemer' kan derimod kontrolleres direkte mod henvendelsen og bruges i den næste behovsafklaring.

Gør ukendt, tom og afvist til forskellige tilstande

Ukendte oplysninger skal have en defineret repræsentation. I JSON er null en værdi, som er forskellig fra både en tom tekst og et manglende felt. Hvis budgetAmount er krævet, men må være tal eller null, kan modtageren skelne mellem et ufuldstændigt objekt og et komplet svar, hvor budgettet ikke kendes. Det gør næste handling lettere at vælge.

Brug en enum, når et felt kun må have bestemte værdier. Kategorierne projekt, support, andet og ukendt skal have tydelige definitioner. Ukendt er ikke en fejlspand for alt, modellen ikke vil forklare; den bør føre til en begrundet afklaring. Et tomt resumé bør heller ikke få lov at gå videre som et færdigt resultat, blot fordi feltet teknisk er en tekst.

Adskil desuden opgavens ukendt-status fra en teknisk afvisning eller et afbrudt modelkald. Hvis modellen ikke leverer et gyldigt resultat, skal applikationen registrere et særskilt fejl- eller stopudfald. Ellers kan en leverandørafvisning blive omsat til almindelige tomme data og skabe et misvisende indtryk af, at henvendelsen blev vurderet korrekt.

Følg ét eksempel fra tekst til valideret forslag

Antag, at afsenderen skriver: 'Vi bruger Booking A og Økonomi B. I dag kopierer vi kundeoplysninger mellem dem. Kan I hjælpe med en integration? Vi har ikke fastlagt et budget endnu.' Et passende resultat bevarer de to systemnavne, beskriver den manuelle overførsel og angiver budget som ukendt.

Et forenklet eksempel på output er:

{"category":"projekt","summary":"Ønsker integration mellem Booking A og Økonomi B til kundeoplysninger","budgetAmount":null,"budgetCurrency":null,"missingInformation":["Hvilke felter skal overføres?","Hvor ofte skal data opdateres?"],"evidence":["I dag kopierer vi kundeoplysninger mellem dem"]}

Dette er eksempeldata, ikke en universel færdig modelkonfiguration. Applikationen kontrollerer først, at objektet kan læses, og at felterne følger kontrakten. Derefter undersøges indholdet: findes systemnavnene i inputtet, er resuméet dækkende, og er der tilføjet oplysninger uden grundlag? Først efter de kontroller kan forslaget vises til en medarbejder eller bruges i et afgrænset næste trin. Et korrekt formateret budget på 50.000 ville stadig være forkert i dette eksempel, fordi afsenderen ikke har oplyst noget beløb.

Adskil struktur, betydning og rettigheder

Strukturkontrollen spørger, om data følger kontrakten: rigtige typer, påkrævede felter, tilladte kategorier og ingen uventede egenskaber. Betydningskontrollen spørger, om værdierne giver mening og har grundlag. En dato kan være korrekt formateret, men ligge før projektets start. Et beløb kan være et gyldigt tal, men høre til en anden valuta eller være hentet fra et eksempel i en vedhæftning.

Rettighedskontrollen afgør, om det næste trin må udføres for den konkrete bruger, kunde og handling. Et eksisterende kunde-id giver ikke i sig selv tilladelse til at læse kundens dokumenter eller ændre en ordre. Disse kontroller skal ligge i applikationen eller systemgrænsen, hvor de kan håndhæves uafhængigt af modellens formuleringer.

Brug tydelige udfald: godkendt forslag, kræver afklaring, afvist af en forretningsregel eller teknisk fejl. Gem korte begrundelser, som kan bruges af den næste ansvarlige. Undgå at lade modellen selv erklære hele resultatet sikkert og derefter bruge erklæringen som eneste kontrol. Dens opgave er at producere et forslag inden for formatet; systemets opgave er at vurdere, om forslaget må anvendes.

Kontrollér den konkrete leverandørs schema-understøttelse

Struktureret output er en produktfunktion med konkrete begrænsninger, ikke en ensartet garanti på tværs af alle modeller og API'er. Leverandørens aktuelle dokumentation skal vise, hvilke JSON Schema-egenskaber der understøttes, hvordan output hentes, og hvilke afvigelser integrationen skal håndtere. Brug den aftalte model og API-version i testen.

Anthropics dokumentation beskriver eksempelvis schema-begrænsninger og særskilte tilfælde med afvisning eller afbrudt output. Det understreger, hvorfor HTTP-succes ikke alene er nok. Applikationen skal også kontrollere afslutningsstatus og det faktiske indhold. Undgå at antage, at alle egenskaber i jeres lokale schema håndhæves af modellens outputfunktion.

Bevar derfor en lokal validering af den fulde kontrakt. Hvis en leverandør kun understøtter en del af schemaet, skal resten håndhæves i applikationen. Dokumentér den forskel, så en senere udvikler ikke tror, at en numerisk grænse eller en tekstlængde allerede er sikret. En ændring af model, SDK eller outputformat bør udløse en relevant regressionstest med både normale og ugyldige eksempler, før den nye konfiguration bruges i den eksisterende integration.

Lav fejlforløb, der ikke opfinder et brugbart resultat

Et fejlet output kan skyldes mange ting: netværk, tokenbegrænsning, afvisning, ukendt kategori eller modstridende kildedata. De skal ikke alle løses med samme automatiske genforsøg. En midlertidig forbindelse kan måske prøves igen, mens en uafklaret valuta kræver et spørgsmål eller en faglig vurdering.

Hvis et output ikke kan valideres, bør systemet ikke stille og roligt rette værdierne til noget, der passer. Det kan skjule en reel fejl. Kontrollerede normaliseringer, eksempelvis trimning af mellemrum i et felt, skal være dokumenterede og må ikke ændre betydningen. At omskrive en ukendt kategori til den nærmeste tilladte er en ny beslutning, som kræver en regel.

Sæt en grænse for genforsøg og gem årsagen til hvert forsøg. Hvis næste trin skriver i et eksternt system, skal det have sin egen dubletbeskyttelse. Et nyt modelkald må ikke betyde en ny CRM-opgave, hvis den første allerede blev oprettet. Brug en stabil reference for henvendelsen, kontrollér eksisterende resultat og adskil generering fra den handling, der har ekstern virkning. Ved tvetydighed skal status være synlig for en ansvarlig.

Test kontrakten med bevidst vanskelige eksempler

Et godt testsæt indeholder mere end pæne formularer. Brug manglende budget, beløb uden valuta, to modstridende tidsplaner, fejlstavede systemnavne og en tekst, hvor afsenderen citerer en anden virksomheds eksempel. Test også en vedhæftning, der ikke kan læses, og et input, der beder modellen om at ignorere det aftalte format.

For hvert eksempel beskrives både det forventede indhold og den tilladte næste handling. Manglende budget kan være et gyldigt resultat med null, mens manglende kundeidentitet kan blokere en skrivning i CRM. De to forhold bør ikke begge registreres som en generel fejl. Test også de rene softwarekontroller med ugyldige objekter, så validatorens afvisning ikke afhænger af, at modellen tilfældigvis laver en fejl.

Mål strukturel validitet og faglig korrekthed separat. En ændring kan give mere velformet JSON, men samtidig flere opdigtede værdier. Gennemgå derfor de faktiske felter mod kilden og behold et uafhængigt sæt til sammenligning af versioner. Fejl, som opstår under en pilot, kan tilføjes til en regressionssamling efter gennemgang, så de bliver synlige ved næste ændring.

Versionér dataformatet som en del af integrationen

Når et felt ændrer betydning, ændrer kontrakten sig, også selv om navnet og datatypen er de samme. Et felt kaldet budget kan først betyde kundens oplyste ramme og senere leverandørens estimat. Hvis det sker uden en versioneret ændring, kan gamle og nye data blive umulige at sammenligne.

Giv derfor schema og prompt en version, og dokumentér hvilke modtagere der bruger resultatet. Før et felt fjernes eller en kategori omdøbes, skal teamet kontrollere de efterfølgende workflows, rapporter og brugerflader. Overvej en overgang, hvor gamle resultater fortsat kan læses, og nye resultater tydeligt viser deres version. Flyt ikke bare problemet til en løs tekstforklaring, som ingen systemer ser.

Aflever en lille kontraktpakke med schema, feltdefinitioner, eksempelinput, forventede output, fejludfald og testresultater. Den gør det muligt at ændre leverandør eller model uden at genopfinde forretningens krav. Ved lancering bør driftsansvarlige kunne se, hvor valideringsfejl havner, hvem der undersøger dem, og hvordan et fejlagtigt resultat holdes væk fra næste handling. Det er denne sammenhæng mellem format og drift, der gør struktureret output værdifuldt.