Functieaanroepen in de OpenAI-API: wat het daadwerkelijk doet en hoe je het op de juiste manier gebruikt

Je geeft het bericht van een gebruiker door aan de GPT API, en in plaats van een antwoord in natuurlijke taal geeft het model je een gestructureerd JSON-object terug dat je precies vertelt welke functie je moet aanroepen en met welke argumenten. Dat is functieaanroepen — en het verandert het soort applicaties dat je met LLM’s kunt bouwen.

De meeste ontwikkelaars horen “function calling” en nemen aan dat het model namens hen code uitvoert. Dat doet het niet.

Bij functieaanroepen voert de LLM zelf de functie niet uit. In plaats daarvan identificeert het het juiste functie, verzamelt alle vereiste parameters en levert de informatie in een gestructureerd JSON-formaat.

Je applicatie blijft verantwoordelijk voor het uitvoeren van de feitelijke logica. Het model vertelt je alleen wat je moet uitvoeren en met welke invoer.

Dat onderscheid is belangrijker dan het klinkt, en beïnvloedt alles — van hoe je je integratie ontwerpt tot hoe je over veiligheid denkt.

Wat functieaanroepen werkelijk is — en wat mensen steeds verkeerd begrijpen

Functieaanroepen (ook wel toolaanroepen genoemd) bieden een krachtige en flexibele manier voor OpenAI-modellen om te interfacen met externe systemen en toegang te krijgen tot data buiten hun trainingsdata.

De naamgeving is de eerste bron van verwarring. Mensen denken dat het model iets uitvoert. Dat doet het niet.

Er zijn veel namen en verklaringen voor functieaanroepen, maar het komt neer op één uitspraak: “functieaanroepen is een soort gestructureerde output-capaciteit van een large language model.” LLM’s roepen zelf geen functies aan; ze suggereren welke functie je zou moeten aanroepen uit vooraf gedefinieerde functies die je aan de LLM aanbiedt in een prompt.

De tweede verwarring gaat over het oude API-oppervlak.

De parameters functions en function_call zijn afgeschaft met de release van de 2023-12-01-preview-versie van de API. De vervanger voor functions is de parameter tools.

Als je een tutorial volgt die de oude parameter functions gebruikt, werk je al met verouderde syntax. Gebruik in plaats daarvan tools en tool_choice.

Een functie is een specifiek soort tool, gedefinieerd door een JSON-schema. Een functiedefinitie stelt het model in staat om data door te geven aan je applicatie, waar jouw code toegang kan krijgen tot data of acties kan uitvoeren die door het model worden voorgesteld.

Dat schema is wat functieaanroepen een betrouwbaarheidsvoordeel geeft ten opzichte van puur prompten — je hoopt niet dat het model de output correct formatteert, je dwingt structuur af op API-niveau.

Hoe functieaanroepen werken in de OpenAI API — stap voor stap

Toolaanroepen is een meerstapsconversatie tussen je applicatie en een model via de OpenAI API. De toolaanroep-flow heeft vijf stappen op hoog niveau: doe een verzoek aan het model met tools die het kan aanroepen...

Dit is hoe elke stap er in de praktijk uitziet.

Stap 1: Definieer je functiesschema’s. Je beschrijft elke beschikbare functie als een JSON-object in de parameter tools. Het schema bevat de functienaam, een beschrijving in natuurlijke taal die het model gebruikt om te beslissen wanneer het die moet aanroepen, en een blok parameters dat de conventies van JSON Schema volgt.

Hoe gedetailleerder je description is — in termen van de situaties waarin de functie kan en moet worden aangeroepen — hoe beter. Let er wel op dat functiebeschrijvingen deel uitmaken van de prompt en dus net zo goed tokens verbruiken.

Stap 2: Verstuur het verzoek. Je roept de Chat Completions API aan met het bericht van de gebruiker en je tools-lijst. Het model ziet beide.

Stap 3: Het model beslist of het een functie moet aanroepen.

Een functieaanroep verwijst naar een speciaal soort respons die je van het model kunt krijgen als het een prompt onderzoekt en vaststelt dat het, om de instructies te volgen, een van de beschikbare tools moet aanroepen. Als het model een prompt ontvangt zoals “what is the weather in Paris?” kan het reageren met een toolaanroep voor de tool get_weather, met Parijs als argument voor de locatie.

Stap 4: Jouw code voert de functie uit. Je parseert de respons van het model, extraheert de functienaam en argumenten, en voert de daadwerkelijke code uit in jouw runtime. De API retourneerde gestructureerde JSON — jij bepaalt wat je ermee doet.

Stap 5: Stuur het resultaat terug.

Je stuurt vervolgens alle tooldefinities, de oorspronkelijke prompt, de toolaanroep van het model en de output van de toolaanroep terug naar het model om uiteindelijk een tekstueel antwoord te ontvangen

— iets als “Het weer in Parijs is vandaag 25°C.”

Eén detail dat de meeste tutorials overslaan:

wanneer je strict: true instelt in je functiedefinitie, garandeert Structured Outputs dat de door het model gegenereerde argumenten voor een functieaanroep exact overeenkomen met het JSON Schema dat je hebt opgegeven.

strict op true zetten zorgt ervoor dat functieaanroepen betrouwbaar voldoen aan het functieschema, in plaats van best effort. OpenAI raadt aan om strict-modus altijd in te schakelen.

Altijd. Er is geen goede reden om het niet te doen.

Er is ook nog parallelle functieaanroep om rekening mee te houden.

Afhankelijk van de gebruikersvraag zal het model parallelle functieaanroepen gebruiken als je de nieuwste modellen gebruikt die op of na 6 november 2023 zijn uitgebracht.

Dit betekent dat één enkel verzoek zoals “what’s the weather in London and Tokyo?” twee gelijktijdige toolaanroepen kan triggeren in plaats van ze sequentieel te koppelen.

Reële use-cases voor functieaanroepen

Het weervoorbeeld is overal omdat het helder is. Echte productie-use-cases zijn rommeliger en interessanter.

Klantsupport-pijplijnen met live data

Functieaanroepen is nuttig voor een groot aantal use-cases — bijvoorbeeld een AI-assistent die de nieuwste klantdata uit een intern systeem moet ophalen wanneer een gebruiker vraagt “what are my recent orders?” voordat het een antwoord kan genereren.

Het model achterhaalt de intentie, extraheert de klant-ID uit de context en roept de interne API van je CRM aan. Geen fragiele regex. Geen prompt-templates die al breken bij een ontbrekende komma.

Gestructureerde data-extractie op schaal

Een data-extractiepijplijn die onbewerkte tekst ophaalt, omzet in gestructureerde data en opslaat in een database is een andere sterke match. Je krijgt consistente schema’s over duizenden documenten zonder per documenttype parsinglogica met de hand af te stemmen.

Natuurlijke taal naar API-vertaling

Door LLM aangestuurde oplossingen voor extraheren en taggen van data, applicaties die natuurlijke taal kunnen helpen omzetten naar API-calls of geldige databasequery’s, en conversationale kennisophaal-engines die interacteren met een kennisbank — al deze profiteren van de garantie op het output-formaat van functieaanroepen. Wanneer de output downstream systemen moet aansturen, kun je variabiliteit niet tolereren.

Agentische workflows met meerdere tools

Voor ontwikkelaars maakt functieaanroepen realtime data-toegang mogelijk om trainingsafkapdatums te omzeilen door live aandelenkoersen, weer of recente database-items op te halen. Het maakt ook actievergunning mogelijk — het transformeert de LLM van een passieve observator in een actieve deelnemer die toestand wijzigt, zoals e-mails verzenden, CRM’s bijwerken of code deployen.

Het belangrijkste onderscheid met een gewone chatbot: het model genereert niet alleen tekst, het orkestreert daadwerkelijke operaties in je systemen.

Best practices voor functieaanroepen — wat ontwikkelaars meestal verkeerd doen

Dit is de sectie die de meeste tutorials volledig overslaan, waardoor teams om 2 uur ’s nachts rare productiefouten debuggen.

Te vage beschrijvingen schrijven. Het model gebruikt je functiebeschrijving om te beslissen wanneer het die moet aanroepen. Als je beschrijving generiek is — iets als “verwerkt gebruikersverzoeken” — heeft het model geen betrouwbaar signaal om het te triggeren. Wees specifiek over de triggerconditie en de verwachte inputvorm. Beschouw de beschrijving als een contract, niet als een label.

Te veel functies tegelijk aanbieden

Functiebeschrijvingen kunnen een aanzienlijk aantal tokens in de invoerprompt verbruiken.

Het laden van definities voor 50+ tools in de systeemprompt creëert twee problemen: kosten en latency, aangezien tooldefinities invoertokens verbruiken; en nauwkeurigheidsdegradatie, aangezien de mogelijkheid van het model om de juiste te selecteren afneemt naarmate het aantal toolopties toeneemt.

Begin met de kleinste set functies die je use-case daadwerkelijk nodig heeft.

Aannemen dat het model geen parameters zal hallucineren. Dat zal het.

Het model kan parameters hallucineren

— vooral voor optionele velden die niet duidelijk begrensd zijn door een enum. Dit is precies waarom strict: true belangrijk is: het ontneemt het model de mogelijkheid om velden buiten je schema te verzinnen.

De meerbeurtenlus niet afhandelen. Ontwikkelaars bouwen vaak het happy path — gebruiker vraagt, model roept functie aan, klaar.

De modellen kunnen functieaanroepen genereren die niet overeenkomen met het schema dat je hebt gedefinieerd of proberen een functie aan te roepen die je niet hebt opgenomen. Als het model onverwachte functieaanroepen genereert, probeer dan een zin op te nemen in het systeembericht die zegt: “Gebruik alleen de functies die je zijn verstrekt.”

Bouw voor de randgevallen.

De bevestigingsstap overslaan vóór write-operaties.

Wees je bewust van de reële impact van functieaanroepen die je van plan bent uit te voeren, vooral die acties triggeren zoals code uitvoeren, databases bijwerken of meldingen verzenden. Voor functies die acties ondernemen, is het sterk aan te raden een stap te implementeren waarin de gebruiker de actie bevestigt voordat deze wordt uitgevoerd.

Als een functieaanroep data kan verwijderen, geld kan verzenden of externe toestand kan wijzigen, moet een mens deze eerst goedkeuren.

Overwegingen rond veiligheid en betrouwbaarheid

Functieaanroepen vergroten wat een LLM kan doen. Ze vergroten ook wat een aanvaller het kan laten doen.

De primaire dreiging hier is promptinjectie.

De einddoelen van promptinjecties variëren maar kunnen bestaan uit het exfiltreren van privédata via downstream toolaanroepen, het nemen van niet-uitgelijnde acties, of anderszins het modelgedrag op een onbedoelde manier veranderen.

Wanneer je functieaanroepen e-mails kunnen verzenden, databases kunnen bevragen of webhooks kunnen triggeren, is een injectie-aanval niet zomaar een chatbot die off-script gaat — het is een potentieel datalek.

Naarmate AI-systemen verder gaan dan chat en tools beginnen aan te roepen en acties te ondernemen, wordt promptinjectie een veel serieuzer probleem. Een schadelijke instructie verborgen in een webpagina, document of externe tool kan proberen systeemgedrag te overschrijven, gevoelige informatie bloot te leggen of acties te triggeren die het model nooit zou mogen ondernemen.

De mitigatiestrategie kent een paar concrete lagen.

Ontwerp workflows zodat onbetrouwbare data nooit direct het gedrag van de agent aanstuurt. Extraheer alleen specifieke gestructureerde velden — zoals enums of gevalideerde JSON — uit externe input om te voorkomen dat injectierisico tussen knooppunten doorstroomt.

Daarbovenop,

controleer altijd de door het model gegenereerde functieaanroepen. Dit omvat het controleren van de parameters, de aan te roepen functie en het waarborgen dat de aanroep in lijn is met de bedoelde actie.

Een ongemakkelijke waarheid:

“Promptinjectie, net als oplichting en social engineering op het web, zal waarschijnlijk nooit volledig ‘opgelost’ worden.”

Dat is OpenAI’s eigen oordeel. De praktische implicatie is dat je geen agentische systemen met functieaanroepen moet ontwerpen in de veronderstelling dat het model altijd zal doen wat je verwacht. Verdediging in de diepte — validatie, gescope permissies, mens-in-de-lus bij destructieve operaties — is de enige verstandige houding.

Functieaanroepen vs. prompt-engineering — wanneer gebruik je welke

Deze vergelijking komt voortdurend terug. Het korte antwoord: ze lossen verschillende problemen op, en ze door elkaar halen leidt tot over-geëngineerde prompts waar functieaanroepen zouden volstaan, of broze functiesschema’s waar een goed geformuleerd system prompt eenvoudiger zou zijn.

Prompt-engineering omvat het opstellen van tekstinvoer om de interne redeneerlijn van de LLM te sturen — het vragen om “think step-by-step”, bijvoorbeeld.

Het vormt hoe het model redeneert. Functieaanroepen daarentegen bepalen wat het model produceert als output en leiden het direct naar je systeem.

Toolaanroepen is de mogelijkheid die de LLM in staat stelt om met externe systemen te interageren. Terwijl je prompt-engineering gebruikt om het model te helpen beslissen welke tool te gebruiken, is toolaanroepen het mechanisme dat de actie daadwerkelijk uitvoert. Je hebt waarschijnlijk beide nodig, maar ze dienen verschillende doelen.

Een belangrijk technisch voordeel van functieaanroepen ten opzichte van prompt-gebaseerde gestructureerde output:

toolaanroepen is een concept dat in het model is ingebakken. Er is geen noodzaak om tokens en moeite te verspillen om het model uit te leggen dat het een specifiek formaat moet teruggeven.

Wanneer je een prompt opstelt die zegt “return your answer as JSON with fields X, Y, and Z,” besteed je tokens aan instructies die het model mogelijk inconsistent opvolgt. Met functieaanroepen vindt schema-afdwinging plaats op API-niveau.

API’s voor functieaanroepen, inmiddels native ondersteund in veel LLM-platforms, bieden een formele, door schema’s gedreven interface die strikte datavalidatie en integratie met programmatische workflows mogelijk maakt.

Dat is de praktische reden om het te verkiezen boven prompt-engineering voor data die naar downstream systemen moet stromen: betrouwbaarheid is niet optioneel zodra je in productie bent.

De praktische vuistregel: als de output een downstream systeem moet aansturen — een database-write, een API-call, een beslissingspad in je code — gebruik functieaanroepen. Als de output voor een mens is om te lezen, is prompt-engineering meestal voldoende en goedkoper.

Belangrijkste punten

Als je wilt experimenteren met functieaanroepen over verschillende modellen — GPT-5.4, claude opus 4.7, gemini 3.1 pro — zonder voor elk aparte API-credentials te beheren, biedt CometAPI je toegang tot al deze via één endpoint en key, wat cross-model testen aanzienlijk minder frictie geeft.

CometAPI lost de infrastructuuroverhead op:

✅ Uniforme syntaxis voor functieaanroepen over 15+ modellen

✅ Één enkele API-sleutel — geen aparte accounts voor OpenAI/Anthropic/Google

✅ Automatische schemavertaling — één keer schrijven, overal testen

✅ Ingebouwde kostenmonitoring — vergelijk tokenverbruik per model in realtime

Begin met testen met gratis credits → Toegang krijgen