Funktionskald i OpenAI API'et: Hvad det faktisk gør, og hvordan du bruger det korrekt

Du sender en brugers besked til GPT API, og i stedet for et svar i naturligt sprog giver modellen dig et struktureret JSON-objekt, der fortæller dig præcis, hvilken funktion der skal kaldes, og med hvilke argumenter. Det er funktionskald — og det ændrer, hvilke typer applikationer du kan bygge med LLM'er.

De fleste udviklere hører "function calling" og antager, at modellen kører kode på deres vegne. Det gør den ikke.

Når du bruger function calling, udfører LLM'en ikke selve funktionen. I stedet identificerer den den relevante funktion, samler alle nødvendige parametre og leverer informationen i et struktureret JSON-format.

Din applikation er stadig ansvarlig for at køre den faktiske logik. Modellen fortæller dig bare, hvad der skal køres, og med hvilke input.

Den skelnen betyder mere, end den lyder til, og præger alt fra, hvordan du arkitekterer din integration, til hvordan du tænker på sikkerhed.

Hvad function calling faktisk er — og hvad folk bliver ved med at misforstå

Function calling (også kendt som tool calling) giver en stærk og fleksibel måde for OpenAI-modeller at interface med eksterne systemer og få adgang til data uden for deres træningsdata.

Navngivningen er den første kilde til forvirring. Folk tror, modellen udfører noget. Det gør den ikke.

Der er mange navne og forklaringer på function calling, men det hele kan koges ned til én sætning: "function calling er en type struktureret output-kapabilitet i en stor sprogmodel." LLM'er kalder ikke selv nogen funktioner; de foreslår, hvilken funktion du bør kalde, fra foruddefinerede funktioner, som du giver LLM'en i et prompt.

Den anden forvirring handler om den gamle API-overflade.

Parametrene functions og function_call er udfaset med udgivelsen af versionen 2023-12-01-preview af API'en. Erstatningen for functions er parameteren tools.

Hvis du følger en tutorial, der bruger den gamle functions-parameter, arbejder du allerede med forældet syntaks. Brug tools og tool_choice i stedet.

En funktion er en specifik type værktøj, defineret ved et JSON-schema. En funktionsdefinition giver modellen mulighed for at videregive data til din applikation, hvor din kode kan få adgang til data eller udføre handlinger, som modellen foreslår.

Det schema er det, der giver function calling sin pålidelighedsforskel i forhold til almindelig prompting — du håber ikke bare på, at modellen formaterer output korrekt; du håndhæver struktur på API-niveau.

Sådan fungerer function calling i OpenAI API — trin for trin

Tool calling er en flertrins-samtale mellem din applikation og en model via OpenAI API. Tool calling-flowet har fem overordnede trin: send en forespørgsel til modellen med værktøjer, den kan kalde ...

Her er, hvordan hvert af disse trin faktisk ser ud i praksis.

Trin 1: Definér dine funktionsskemaer. Du beskriver hver tilgængelig funktion som et JSON-objekt i parameteren tools. Schemaet inkluderer funktionsnavnet, en beskrivelse i naturligt sprog, som modellen bruger til at beslutte, hvornår den skal bruge den, og en parameters-blok, der følger JSON Schema-konventioner.

Jo mere detaljeret din description er — med hensyn til de situationer, hvor den kan og bør kalde funktionen — desto bedre. Bemærk dog, at funktionsbeskrivelser er en del af prompten og derfor forbruger tokens.

Trin 2: Send forespørgslen. Du kalder Chat Completions API med brugerens besked og din tools-liste. Modellen ser begge dele.

Trin 3: Modellen beslutter, om den skal kalde en funktion.

Et funktionskald refererer til en særlig type svar, du kan få fra modellen, hvis den undersøger en prompt og fastslår, at den, for at følge instruktionerne, skal kalde et af de værktøjer, der er tilgængelige for den. Hvis modellen modtager en prompt som "hvad er vejret i Paris?", kan den svare med et værktøjskald for værktøjet get_weather, med Paris som argument for lokation.

Trin 4: Din kode kører funktionen. Du parser modellens svar, udtrækker funktionsnavn og argumenter og kører den faktiske kode i dit runtime. API'en returnerede struktureret JSON — du bestemmer, hvad der skal gøres med det.

Trin 5: Send resultatet tilbage.

Du sender derefter hele værktøjsdefinitionen, den oprindelige prompt, modellens værktøjskald og outputtet fra værktøjskaldet tilbage til modellen for endelig at modtage et tekstsvar

— noget i retning af "Vejret i Paris i dag er 25°C."

En detalje, de fleste tutorials springer over:

når du sætter strict: true i din funktionsdefinition, garanterer Structured Outputs, at de argumenter, modellen genererer til et funktionskald, præcist matcher det JSON Schema, du har angivet.

At sætte strict til true vil sikre, at funktionskald pålideligt overholder funktionsschemaet i stedet for at være best effort. OpenAI anbefaler altid at aktivere strict-tilstand.

Altid. Der er ingen god grund til at lade være.

Der er også parallelle funktionskald at kende til.

Afhængigt af brugerforespørgslen vil modellen udføre parallelle funktionskald, hvis du bruger de nyeste modeller, der er udgivet den 6. november 2023 eller senere.

Det betyder, at en enkelt forespørgsel som "hvad er vejret i London og Tokyo?" kan udløse to samtidige værktøjskald i stedet for at kæde dem sekventielt.

Function calling – virkelige anvendelser

Vejr-eksemplet er overalt, fordi det er rent. Rigtige produktionsbrugssager er mere rodede og mere interessante.

Kundesupport-pipelines med live-data

Function calling er nyttigt i en lang række brugssager — for eksempel en AI-assistent, der skal hente de seneste kundedata fra et internt system, når en bruger spørger "hvad er mine seneste ordrer?", før den kan generere et svar.

Modellen udleder intention, udtrækker kunde-ID fra konteksten og kalder dit CRMs interne API. Ingen skrøbelig regex. Ingen promptskabeloner, der er så skrøbelige, at de bryder ved et manglende komma.

Struktureret dataekstraktion i skala

En dataekstraktionspipeline, der henter rå tekst, konverterer den til strukturerede data og gemmer den i en database, er et andet stærkt match. Du får konsistente skemaer på tværs af tusindvis af dokumenter uden håndtunet parselogik per dokumenttype.

Naturligt sprog til API-oversættelse

LLM-drevne løsninger til udtræk og tagging af data, applikationer, der kan hjælpe med at konvertere naturligt sprog til API-kald eller gyldige databaseforespørgsler, og konversationelle videnshentningsmotorer, der interagerer med en vidensbase — alle disse drager fordel af function callings garanti for outputformat. Når outputtet skal drive downstream-systemer, kan du ikke tolerere variabilitet.

Agentbaserede arbejdsgange med flere værktøjer

For udviklere muliggør function calling adgang til realtidsdata for at overvinde trænings-cutoffs ved at hente live-aktiekurser, vejr eller nylige databaseoptegnelser. Det muliggør også udførelse af handlinger — og transformerer LLM'en fra en passiv observatør til en aktiv deltager, der ændrer tilstand, som at sende e-mails, opdatere CRMer eller deploye kode.

Den afgørende forskel fra en almindelig chatbot: Modellen genererer ikke bare tekst, den orkestrerer faktiske operationer på tværs af dine systemer.

Function calling best practices — hvad udviklere typisk gør forkert

Det er sektionen, de fleste tutorials helt springer over, hvilket er grunden til, at teams ender med at debugge sære produktionsfejl kl. 02.

At skrive beskrivelser, der er for vage. Modellen bruger din funktionsbeskrivelse til at afgøre, hvornår den skal kalde den. Hvis din beskrivelse er generisk — noget i retning af "behandler brugerforespørgsler" — har modellen intet pålideligt signal til, hvornår den skal udløse den. Vær specifik om triggerbetingelsen og den forventede inputform. Tænk på beskrivelsen som en kontrakt, ikke en etiket.

At eksponere for mange funktioner på én gang

Funktionsbeskrivelser kan forbruge et betydeligt antal tokens i inputprompten.

At læsse definitioner for 50+ værktøjer ind i systemprompten skaber to problemer: omkostninger og latenstid, da værktøjsdefinitioner forbruger inputtokens; og nøjagtighedsforringelse, da modellens evne til at vælge den korrekte falder, når antallet af værktøjsmuligheder stiger.

Start med det mindste sæt funktioner, dit use case faktisk har brug for.

At antage, at modellen ikke vil hallucinere parametre. Det vil den.

Modellen kan hallucinere parametre

— især for valgfrie felter, der ikke er klart afgrænset af en enum. Det er præcis derfor, strict: true betyder noget: det fjerner modellens mulighed for at opfinde felter uden for dit schema.

Ikke at håndtere den fler-turn-baserede loop. Udviklere bygger ofte den glatte vej — brugeren spørger, modellen kalder en funktion, færdig.

Modellerne kan generere funktionskald, der ikke matcher det schema, du definerede, eller forsøge at kalde en funktion, du ikke inkluderede. Hvis modellen genererer uventede funktionskald, så prøv at inkludere en sætning i systembeskeden, der siger "Brug kun de funktioner, du har fået stillet til rådighed."

Byg til edge cases.

At springe bekræftelsestrinnet over før write-operationer.

Vær opmærksom på den virkelige effekt af funktionskald, som du planlægger at udføre — især dem, der udløser handlinger som at køre kode, opdatere databaser eller sende notifikationer. For funktioner, der udfører handlinger, anbefales det kraftigt at implementere et trin, hvor brugeren bekræfter handlingen, før den udføres.

Hvis et funktionskald kan slette data, sende penge eller ændre ekstern tilstand, bør et menneske godkende det først.

Sikkerheds- og pålidelighedsovervejelser

Function calling udvider, hvad en LLM kan gøre. Det udvider også, hvad en angriber kan få den til at gøre.

Den primære trussel her er prompt-injektion.

Målene med prompt-injektioner varierer, men kan inkludere eksfiltration af private data via downstream-værktøjskald, misaligned handlinger eller på anden måde at ændre modeladfærd på en utilsigtet måde.

Når dine funktionskald kan sende e-mails, forespørge databaser eller trigge webhooks, er et injektionsangreb ikke bare en chatbot, der går off-script — det er et potentielt brud.

Efterhånden som AI-systemer bevæger sig ud over chat og begynder at kalde værktøjer og udføre handlinger, bliver prompt-injektion et langt mere alvorligt problem. En ondsindet instruktion skjult på en webside, i et dokument eller et eksternt værktøj kan forsøge at tilsidesætte systemadfærd, eksponere følsomme oplysninger eller udløse handlinger, modellen aldrig burde udføre.

Afværgestrategien har nogle konkrete lag.

Design arbejdsgange, så ubetroede data aldrig direkte styrer agentadfærd. Udtræk kun specifikke strukturerede felter — såsom enums eller valideret JSON — fra eksterne input for at begrænse injektionsrisikoen fra at flyde mellem noder.

Derudover,

verificér altid de funktionskald, modellen genererer. Dette inkluderer at tjekke parametrene, den funktion der kaldes, og sikre, at kaldet stemmer overens med den tiltænkte handling.

En ubehagelig sandhed:

"Prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully 'solved.'"

Det er OpenAI's egen vurdering. Den praktiske implikation er, at du ikke bør arkitektere agentiske function-calling-systemer ud fra antagelsen om, at modellen altid vil opføre sig som tilsigtet. Defense in depth — validering, afgrænsede tilladelser, menneske-med-i-loopet for destruktive operationer — er den eneste fornuftige tilgang.

Function calling vs. Prompt Engineering — hvornår du skal bruge hvad

Denne sammenligning dukker op konstant. Det korte svar: de løser forskellige problemer, og at blande dem sammen fører til over-ingeniørede prompts, når function calling ville være tilstrækkeligt, eller skrøbelige funktionsskemaer, når en veludformet systemprompt ville være enklere.

Prompt engineering indebærer at udforme tekstinput for at guide LLM'ens interne ræsonnement — at bede den om at "tænke trin for trin", for eksempel.

Det former, hvordan modellen ræsonnerer. Function calling, derimod, former, hvad modellen producerer som output og leder det direkte ind i dit system.

Tool calling er kapabiliteten, der giver LLM'en mulighed for at interagere med eksterne systemer. Mens du bruger prompt engineering til at hjælpe modellen med at beslutte, hvilket værktøj der skal bruges, er tool calling mekanismen, der faktisk udfører handlingen. Du har sandsynligvis brug for begge, men de tjener forskellige formål.

En vigtig teknisk fordel ved function calling over prompt-baseret struktureret output:

tool calling er et koncept, der er indbygget i selve modellen. Der er ikke behov for at spilde tokens og energi på at forklare modellen, at den skal returnere et specifikt format.

Når du udformer en prompt, der siger "returnér dit svar som JSON med felterne X, Y og Z," bruger du tokens på instruktioner, som modellen måske følger inkonsistent. Med function calling sker schema-håndhævelsen på API-niveau.

Function-calling-API'er, som nu er understøttet native i mange LLM-platforme, giver en formel, skemadrevet grænseflade, der muliggør streng datavalidering og integration med programmatiske arbejdsgange.

Det er den virkelige grund til at vælge det frem for prompt engineering for enhver data, der skal flyde ind i downstream-systemer: Pålidelighed er ikke valgfrit, når du er i produktion.

Den praktiske tommelfingerregel: Hvis outputtet skal drive et downstream-system — en database-write, et API-kald, en beslutningsgren i din kode — brug function calling. Hvis outputtet er til en menneskelig læser, er prompt engineering normalt tilstrækkeligt og billigere.

Vigtigste pointer

Hvis du vil eksperimentere med function calling på tværs af forskellige modeller — GPT-5.4, claude opus 4.7, gemini 3.1 pro — uden at vedligeholde separate API-legitimationsoplysninger for hver, giver CometAPI dig adgang til dem alle via ét endpoint og én nøgle, hvilket gør krydsmodel-testning markant mindre friktionsfyldt.

CometAPI løser infrastruktur-overheadet:

✅ Ensartet syntaks for function calling på tværs af 15+ modeller

✅ Én API-nøgle — ingen separate konti for OpenAI/Anthropic/Google

✅ Automatisk schema-oversættelse — skriv én gang, test overalt

✅ Indbygget omkostningssporing — sammenlign tokenforbrug per model i realtid

Start med at teste med gratis credits → Få adgang