Hvad er værktøjskald? Sådan omsætter AI-modeller beslutninger til handlinger

Værktøjskald er den mekanisme, der gør det muligt for en AI-model at anmode om en bestemt funktion eller ekstern funktionalitet ved hjælp af strukturerede argumenter. Det omsætter modellens beslutning til en maskinlæsbar handling, så software kan søge, beregne, hente poster, køre kode eller opdatere et andet system, uden at modellen skal forsøge at efterligne handlingen med tekst.

Værktøjskald er grundlæggende for moderne AI-agenter. En model kan ræsonnere sig frem til, hvad der bør ske, men det omgivende program afgør, om den ønskede handling er gyldig og godkendt, om den udføres, og om resultatet sendes tilbage til modellen, så den kan træffe sin næste beslutning.

Hvorfor modeller har brug for værktøjer

En sprogmodel har væsentlige begrænsninger. Dens indlærte viden har en skæringsdato, den kan ikke pålideligt udføre alle beregninger, den har ikke automatisk adgang til private data eller aktuelle oplysninger, og den kan ikke påvirke softwaresystemer alene ved at generere tekst.

Værktøjer udvider modellens muligheder, så den blandt andet kan:

• søge efter aktuelle oplysninger;
• forespørge i en database eller vidensbase;
• køre kode eller udføre præcise beregninger;
• læse og skrive filer;
• oprette supportsager, begivenheder, beskeder eller transaktioner;
• betjene en browser eller en anden brugergrænseflade.

Et værktøj gør ikke i sig selv modellen mere vidende. Det giver programmet en kontrolleret måde at indhente dokumentation eller udføre en handling på.

Et værktøjs definition

Værktøjsbeskrivelsen bør forklare både, hvornår værktøjet skal vælges, og hvornår det ikke skal. »Søg i poster« er upræcist, fordi modellen ikke kan se, om der søges blandt kunder, dokumenter eller på det offentlige internet. »Søg efter godkendte kundekonti ved hjælp af virksomhedsnavn eller konto-id; må ikke bruges til generel websøgning« giver modellen en brugbar afgrænsning.

Programmer beskriver hvert tilgængeligt værktøj i et struktureret format. En definition indeholder typisk:

• Navn: en stabil identifikator, f.eks. get_weather eller create_support_ticket.
• Beskrivelse: en præcis forklaring af, hvad værktøjet gør, og hvornår det bør bruges.
• Inputskema: de påkrævede og valgfrie argumenter, deres datatyper og de tilladte værdier.
• Outputkontrakt: dokumentation af det resultat eller de fejltilstande, som programmet returnerer.

Mange værktøjsgrænseflader bruger JSON Schema eller en beslægtet typet repræsentation. Et snævert og entydigt skema mindsker risikoen for, at modellen finder på parametre eller kombinerer valgmuligheder, der ikke passer sammen.

Sådan fungerer værktøjskaldets arbejdsgang

Forestil dig, at en bruger spørger: »Har jeg nogle møder i Manchester næste tirsdag, og kommer det til at regne?«

1. Applikationen giver kontekst. Den sender brugerens anmodning, systeminstruktioner og definitioner af de valgte værktøjer til modellen.
2. Modellen vælger et værktøj. Den kan anmode om et kalenderopslag med et datointerval og et lokationsfilter.
3. Applikationen validerer anmodningen. Den kontrollerer værktøjets navn, de påkrævede argumenter, tilladelsesomfanget og forretningsreglerne.
4. Kørselsmiljøet udfører værktøjet. Det kalder kalendersystemet og returnerer de matchende begivenheder eller en tydelig fejlmeddelelse.
5. Modellen observerer resultatet. Den ser, at der er et møde i Manchester, og anmoder om et vejrværktøj til den pågældende by og dato.
6. Applikationen gentager kontrollerne og udførelsen.
7. Modellen formulerer det endelige svar. Den sammenholder de verificerede resultater og henviser til de relevante oplysninger.

Modellen foreslår kald; applikationen udfører dem. Det er en af de vigtigste ting at vide om brug af værktøjer. Et sikkert kørselsmiljø behandler aldrig modeloutput som kode, der automatisk er godkendt til at blive kørt.

Valg af værktøj kan være automatisk eller begrænset

En applikation kan lade modellen afgøre, om der er brug for et værktøj, kræve et bestemt værktøj, begrænse valget til et udvalg eller forbyde brug af værktøjer i et svar. Disse muligheder er nyttige i forskellige arbejdsgange.

Automatisk valg understøtter fleksible assistenter. Krav om et bestemt valg er nyttigt til opgaver som struktureret dataudtræk, hvor hver anmodning bør gå gennem en bestemt funktion. Begrænsning af de tilgængelige værktøjer mindsker forvirring og risiko: Et trin, der aflæser en faktura, behøver ikke adgang til et værktøj, der sender e-mails.

Værktøjskald sammenlignet med struktureret output

Begge funktioner beder modellen om at producere data, der passer til et skema, men de har forskellige formål.

Struktureret output formaterer modellens svar til en applikation – for eksempel ved at udtrække et produktnavn, en mængde og en risikoklassificering. Værktøjskald anmoder om, at applikationen udfører en handling og returnerer en observation.

Et struktureret resultat kan afslutte interaktionen. Et værktøjskald fortsætter som regel en løkke: anmodning, udførelse, observation og ny beslutning.

Værktøjskald sammenlignet med API’er

En API er en grænseflade, som software bruger til at kommunikere med et andet system. Værktøjskald er det modelvendte beslutningslag, der vælger en handling og angiver argumenterne. En værktøjsimplementering fungerer ofte som et omslag om en API, men kan også omslutte en databaseforespørgsel, en lokal funktion, et kommandolinjeprogram eller en handling i brugergrænsefladen.

De bedste værktøjer giver sjældent direkte adgang til en hel kompleks API. De tilbyder opgaverettede handlinger med tydelig betydning, begrænset omfang og resultater, som en model kan fortolke. »Refunder ordre« med validerede politikinput er sikrere og lettere at bruge end et generisk anmodningsværktøj, der kan kalde et hvilket som helst endpoint.

Hvad kendetegner et godt AI-værktøj?

Tydeligt formål. Navnet og beskrivelsen bør adskille værktøjet fra lignende funktioner. Overlappende værktøjer fører til inkonsekvente valg.

Små, typede input. Påkrævede felter bør være tydeligt angivet, og begrænsede værdier bør så vidt muligt angives med opregninger. Undgå at tvinge modellen til at konstruere store, skrøbelige datamængder.

Nyttige output. Returnér tilstrækkelige oplysninger til at understøtte den næste beslutning, herunder stabile identifikatorer og en tydelig status for succes eller fejl. Skjul ikke en delvis fejl i en venligt formuleret besked.

Idempotens, hvor det er muligt. Det er som regel sikkert at gentage en læsehandling; gentagelse af en betaling eller afsendelse af en besked kan medføre, at handlingen udføres flere gange. Værktøjer med stor påvirkning bør bruge idempotensnøgler eller en anden sikkerhedsforanstaltning.

Begrænsede tilladelser. Et skrivebeskyttet søgeværktøj bør ikke arve skriverettigheder. Adgangsoplysninger og autorisation hører hjemme i kørselsmiljøet, ikke i prompten.

Almindelige fejl ved værktøjskald

Gentagelser kræver deres egen politik. Det kan være harmløst at gentage en søgning, der kun læser data, men hvis man gentager et betalingsværktøj eller et værktøj, der sender beskeder, kan det medføre, at en uigenkaldelig handling udføres flere gange. Idempotensnøgler, transaktionsidentifikatorer og tydelige bekræftelsestilstande gør det muligt for køretidsmiljøet at afgøre, om det første forsøg mislykkedes, eller om det blot ikke returnerede et svar.

• Forkert værktøj: Modellen vælger en funktion med en lignende beskrivelse.
• Ugyldige argumenter: Et obligatorisk felt mangler, er fejlformateret eller er semantisk umuligt.
• Hallucineret resultat: Modellen svarer, som om værktøjet havde fungeret, uden at afvente en observation.
• Tvetydige fejl: Værktøjet returnerer et tomt output, og modellen tolker det som »ingen poster fundet«.
• Usikker kædning: Indhold fra ét værktøj, som ikke er betroet, får modellen til uhensigtsmæssigt at kalde et andet værktøj.
• Dublerede bivirkninger: En timeout udløser et nyt forsøg, efter at den første handling allerede er gennemført.
• Overbelastning med værktøjer: For mange irrelevante definitioner mindsker præcisionen i valget og optager kontekst.

Tilladelser og menneskelig godkendelse

Værktøjer kan grupperes efter risiko. Skrivebeskyttet datahentning kan udføres automatisk inden for et begrænset dataområde. Reversible udkast eller foreslåede ændringer kan gennemføres med logføring. Eksterne, økonomiske eller destruktive handlinger samt handlinger med juridisk betydning bør som regel kræve godkendelse.

Godkendelsen skal være informeret. En bekræftelsesgrænseflade bør vise den præcise handling, målet, de vigtigste parametre og den sandsynlige konsekvens. »Tillad værktøjet?« er ikke nok, hvis værktøjet sender en e-mail til 5.000 modtagere eller sletter en produktionsressource.

OpenAIs oversigt over værktøjer til at bygge agenter understreger, at værktøjer skal bruges som en del af en agentplatform med sporing og observerbarhed. De tilhørende kontrolmekanismer er ikke valgfrit ekstraudstyr; det er dem, der gør det muligt at anvende handlinger valgt af modellen i praksis.

Sådan evaluerer du brugen af værktøjer

Evaluer valg, argumenter, udførelse, fortolkning og den endelige opgaveløsning hver for sig. En model kan vælge det rigtige værktøj, men udfylde det forkerte felt, eller modtage et korrekt resultat og drage den forkerte konklusion. Når hele forløbet logføres, bliver disse fejltyper synlige, og et stærkt afsluttende svar kan ikke skjule usikker eller uhensigtsmæssigt ressourcekrævende adfærd.

Et afsluttende svar kan se korrekt ud, selvom en agent har valgt en ineffektiv eller usikker fremgangsmåde. Evalueringen bør derfor måle både resultater og forløb.

Nyttige målepunkter omfatter præcision i valget af værktøj, gyldigheden af argumenter, opgaveløsning, antal kald, svartid, omkostninger, genopretning efter fejl, unødvendig adgang til følsomme data, dublerede bivirkninger og overholdelse af godkendelsesregler. Gennemfør gentagne forsøg, fordi modellens adfærd kan variere.

Sådan læser du diagrammerne over værktøjskald

Læs diagrammerne over værktøjskald fra det nummererede input hen mod det observerbare resultat. Sammenligningen isolerer den grænse, der adskiller værktøjskald fra den nærmeste genvej, mens kontrolforløbet viser, hvor beføjelser eller usikkerhed skal kontrolleres, før de får konsekvenser i den virkelige verden. Etiketterne er almindelig, responsiv sidetekst, så de kan oversættes, ombrydes og tilpasses på en telefon.

I artiklen Hvad er værktøjskald? Sådan omsætter AI-modeller beslutninger til handlinger fungerer illustrationen som et kort, ikke som en garanti. En faktisk implementering kan kombinere trin, gentage et trin eller indføre et godkendelsestrin for et menneske. Det afgørende er, om teamet kan identificere de samme funktioner i det implementerede system, udpege en ansvarlig for hver grænse og afprøve overgangen mellem dem. Hvis et trin ikke kan observeres eller måles, bliver det vanskeligt at diagnosticere fejl dér.

Det skal du huske om værktøjskald

Værktøjskald bygger bro mellem modellens vurdering og handling i software. Modellen identificerer en funktion og foreslår strukturerede input; applikationen validerer, godkender og udfører handlingen og returnerer derefter observationen.

Veldesignede værktøjer gør AI-systemer mere opdaterede, kompetente og nyttige. Dårligt designede værktøjer kan få almindelige modelfejl til at føre til konsekvenser uden for systemet. Det afgørende ingeniørarbejde handler om skemaer, tilladelser, fejlhåndtering, observerbarhed og grænserne for udførelse.