Hvad betyder Værktøjsskema?
Et værktøjsskema er en maskinlæsbar kontrakt for et værktøjskald. Det kan angive feltnavne, datatyper, obligatoriske værdier og tilladte valgmuligheder. Sammen med et klart navn og en beskrivelse hjælper det modellen med at vælge værktøjet og udfylde argumenterne.
Skemaet kontrollerer struktur. Det ved ikke nødvendigvis, om et kundenummer findes, om et beløb er rimeligt, eller om den aktuelle bruger må ændre den valgte kunde. Disse forhold skal kontrolleres af den kode og adgangsstyring, der udfører handlingen.
Gør det vanskeligt at vælge forkert
Et felt som “id” er ofte for uklart. “orderId” eller et entydigt dansk feltnavn kan gøre betydningen tydeligere. Et værktøj til at søge bør adskilles fra et værktøj til at ændre, så modellen ikke skal gætte, hvilke sideeffekter der opstår. Beskriv også, hvornår værktøjet ikke skal bruges.
Obligatoriske felter og afgrænsede værdier kan reducere fejl. Hvis en dato mangler, er det bedre at tillade en eksplicit manglende værdi eller kræve afklaring end at presse modellen til at opfinde en dato for at opfylde skemaet. Ekstra felter bør håndteres efter en bevidst regel.
Returdata skal kunne skelne udfald
Et værktøj bør returnere nok information til at afgøre, om handlingen lykkedes, fejlede eller kun blev delvist udført. En tom liste kan betyde ingen fund, mens en adgangsfejl er en anden situation. Hvis disse udfald blandes sammen, kan agenten bygge en forkert forklaring på et teknisk problem. Ved ændringer er et stabilt objekt-ID og en bekræftet status ofte mere nyttigt end en løs besked om, at alt gik godt.
Et eksempel fra praksis
Et CRM-værktøj skal oprette et internt opfølgningsudkast. Skemaet kræver kontakt-ID, formål og udkasttekst og accepterer kun kendte opfølgningstyper. Serveren kontrollerer derefter, at kontakten tilhører den rigtige virksomhed, og at brugeren må oprette udkast. Værktøjet kan ikke sende email. Et testkald med et gyldigt formateret, men fremmed kontakt-ID skal afvises, selv om JSON-strukturen er korrekt.
Typiske faldgruber
- At forveksle gyldig JSON med korrekte eller tilladte oplysninger.
- At bruge tvetydige felter og værktøjer med skjulte sideeffekter.
- At lade tekniske fejl ligne et normalt resultat med nul fund.
Det skal I afklare
- Navngiv input efter deres konkrete betydning.
- Kontrollér både struktur, forretningsregler og adgang på serveren.
- Returnér entydige udfald med ID og relevant fejltype.
Spørgsmål og svar
Er JSON Schema nødvendigt?
Det er en udbredt måde at beskrive strukturen på, men en kontrakt kan have andre former. Kravet er, at input og output kan forstås og kontrolleres entydigt.
Kan et skema forhindre alle hallucinationer?
Nej. Det kan begrænse form og valgmuligheder, men en korrekt formateret oplysning kan stadig være forkert. Kildekontrol og semantisk validering er særskilte opgaver.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- Model Context Protocol: Tools ↗Navn, beskrivelse og skemaer for værktøjsinput og output.
- JSON Schema: Objects ↗Egenskaber, obligatoriske felter og kontrol af ekstra felter.