OpenAI API in je eigen app inbouwen

Wat de OpenAI API kan in jouw applicatie

De OpenAI API is een verzameling van modellen en capabilities die je als HTTP-service aanspreekt. Chat completions zijn de bekendste feature, maar de API reikt verder dan tekst genereren. Elk onderdeel heeft specifieke use cases waar het het sterkst in is.

• ▸Chat completions (OpenAI's nieuwste modellen): tekst genereren, samenvatten, classificeren, redeneren over gestructureerde input. OpenAI biedt verschillende prijspunten: lichtere modellen voor hoog-volume taken (classificatie, extractie), grotere modellen voor complexe redenering. Modelkeuze hangt af van use-case en budget.
• ▸Function calling: het model roept gestructureerde functies aan in je eigen code op basis van gebruikersinvoer. Daarmee bouw je AI-agents die actie ondernemen, niet alleen tekst terugsturen.
• ▸Structured output: het model retourneert altijd valide JSON conform een schema dat je opgeeft. Geen parsing-fouten, geen hallucinated velden.
• ▸Embeddings (text-embedding-3-small, text-embedding-3-large): tekst omzetten naar vectorrepresentaties voor semantic search, aanbevelingssystemen en clustering. text-embedding-3-small kost /bin/zsh.02 per miljoen tokens en volstaat voor de meeste use cases.
• ▸Vision: OpenAI's nieuwste model kan afbeeldingen analyseren, documenten uitlezen en visuele informatie combineren met tekstuele context.
• ▸Audio (Whisper, TTS): speech-to-text transcriptie en text-to-speech voor voicegestuurde interfaces of het automatisch verwerken van audio-opnames.
• ▸Fine-tuning: een basismodel trainen op eigen data zodat het consistent jouw stijl, jargon of classificatieschema toepast.

Welke capabilities relevant zijn hangt af van je use case. Ik start met een analyse van het probleem en kies daarna het model en de features die de beste prijs-kwaliteitsverhouding opleveren.

GPT versus Claude: sterke punten per scenario

OpenAI en Anthropic (Claude) zijn de twee dominante API-aanbieders. Ik werk met beide. De keuze hangt af van de specifieke eisen van je project, niet van loyaliteit aan een provider.

• ▸OpenAI's nieuwste model-mini voor hoog-volume, kostgevoelige taken: classificatie, extractie, samenvatting op grote aantallen records. De prijs per token is laag genoeg voor batch-verwerking van duizenden documenten per dag.
• ▸OpenAI's nieuwste model voor multimodale toepassingen: je hebt afbeeldingen, audio of complexe documenten nodig in dezelfde aanvraag als tekst.
• ▸reasoning-model / reasoning-model voor redeneer-intensieve taken: wiskundige probleemoplossing, code-generatie, planningslogica waarbij aantoonbaar redeneren vereist is.
• ▸Claude (Sonnet, Opus) voor nauwkeurige instructieopvolging, lange contextvensters en scenario's waar het vermijden van hallucinations zwaarder weegt dan kosten.
• ▸Hybride architectuur: voor sommige systemen gebruik ik OpenAI's nieuwste model-mini als eerste filter (goedkoop en snel) en Claude of OpenAI's nieuwste model als tweede laag voor complexe cases die de eerste laag markeert.

Ik heb geen financieel belang bij een bepaalde provider. De aanbeveling is altijd gebaseerd op de combinatie van nauwkeurigheidseisen, volume, kosten per aanvraag en de bestaande architectuur van het project.

Productie-grade integratie: wat er echt bij komt kijken

Een simpele OpenAI API-call schrijven duurt tien minuten. Een integratie die betrouwbaar draait in productie, kosten beheersbaar houdt en fouten afhandelt zonder dat gebruikers er iets van merken, is een ander verhaal.

• ▸Token-budgets per request: ik stel max_tokens in per type aanvraag en pas prompt-structuur aan om de input-tokens te beperken. Dit voorkomt dat een grote invoer onverwacht een rekening van tientallen dollars oplevert.
• ▸Retry-logica met exponential backoff: OpenAI rate-limits treffen elke integratie bij pieken. Ik implementeer automatische retries met backoff en jitter, zodat tijdelijke fouten (429-responses) transparant afgehandeld worden.
• ▸Prompt caching: voor aanvragen waarbij een groot systeemprompt of contextueel document herhaald meegegeven wordt, cache ik de prompt-prefix server-side. OpenAI biedt automatische caching voor herhaalde promptprefixen, wat tot 50% kostenreductie oplevert op hoge volumes.
• ▸Streaming voor gebruikerservaring: bij interfaces waar de gebruiker wacht op een antwoord, stream ik de response via Server-Sent Events. De eerste tokens verschijnen direct, wat de ervaring van snelheid sterk verbetert.
• ▸Output-validatie: zelfs bij structured output mode valideer ik het resultaat met een schema-validator (Zod in TypeScript, Pydantic in Python) voor het systeem verder gaat. Corrupte output wordt gedetecteerd en al dan niet automatisch opnieuw aangevraagd.
• ▸Prompt-versioning: prompts zijn code, geen inline strings. Ik sla ze op als bestanden in Git, versie ze en test nieuwe versies op een subset van data voor uitrol naar productie.
• ▸Cost-monitoring: ik log token-gebruik per aanvraag, per gebruiker of per pipeline-stap, zodat je ziet waar de API-rekening naartoe gaat en kunt bijsturen.

Dit is de infrastructuur die het verschil maakt tussen een proof-of-concept en een systeem dat je klanten durft te laten gebruiken.

Function calling correct implementeren

Function calling is een van de meest gebruikte features van de OpenAI API en ook een van de meest misbruikte. Het model bepaalt wanneer een functie aangeroepen wordt op basis van gebruikersinvoer. Als de function-definitie niet klopt, roept het model de verkeerde functie aan of vult het parameters in die niet kloppen.

Een correcte implementatie vereist nauwkeurige JSON Schema-definities per functie, heldere beschrijvingen van parameters en duidelijke instructies in het systeemprompt over wanneer welke functie passend is.

• ▸JSON Schema per functie: elk parameter heeft een type, een description en eventuele enum-waarden of constraints. Zonder description weet het model niet hoe het parameters correct moet invullen.
• ▸Parallel function calling: OpenAI's nieuwste model ondersteunt het gelijktijdig aanroepen van meerdere functies in één response. Gebruik dit alleen als de functies onafhankelijk zijn. Bij afhankelijkheden moet je sequentieel werken.
• ▸Structured output mode als alternatief: voor gevallen waarbij je altijd een specifiek JSON-object wil retourneren zonder function-calling overhead, is Structured Output (response_format: json_schema) de schonere oplossing.
• ▸Tool-keuze sturen: met tool_choice kun je het model verplichten een specifieke functie te kiezen of juist te voorkomen dat het functies aanroept. Nuttig voor gecontroleerde flows.
• ▸Foutafhandeling bij function calls: als het model een functie aanroept met ongeldige parameters, stuur ik een foutbericht terug als function-result zodat het model de aanroep kan corrigeren.

Embeddings en vector search: semantic search inbouwen

Embeddings zijn de basis van semantic search: de mogelijkheid om te zoeken op betekenis in plaats van op exacte trefwoorden. Een embedding is een numerieke vector die de semantische inhoud van een stuk tekst representeert. Twee zinnen met vergelijkbare betekenis liggen dicht bij elkaar in de vectorruimte, ook als ze geen woorden delen.

De text-embedding-3-small van OpenAI genereert vectoren van 1536 dimensies en kost /bin/zsh.02 per miljoen tokens. text-embedding-3-large genereert vectors van 3072 dimensies en is nauwkeuriger bij subtiele semantische verschillen, maar kost meer en vergt grotere opslagcapaciteit.

• ▸Postgres met pgvector: voor de meeste MKB-use-cases is pgvector in een bestaande Postgres-database voldoende. Het vermijdt een extra externe dienst en sluit direct aan op je bestaande datamodel.
• ▸Gespecialiseerde vector databases (Qdrant, Pinecone, Weaviate): zinvol bij miljoenen vectoren, of als je geavanceerde filtermogelijkheden, hybride search (vector + keyword) of schaalbare index-updates nodig hebt.
• ▸Chunking-strategie: lange documenten splits ik in overlappende segmenten van 200 tot 500 tokens per chunk. De overlap zorgt dat context rond segmentgrenzen niet verloren gaat.
• ▸Herindexering bij prompt-wijzigingen: als het embedding-model of de chunking-strategie verandert, zijn alle bestaande vectoren ongeldig. Ik bouw herindexering in als onderdeel van de deployment-pipeline.
• ▸Hybride search: voor betere recall combineer ik vector search met klassieke keyword-search (BM25 of tsvector in Postgres). Reciprocal Rank Fusion combineert de resultaten van beide methoden.

Evaluatie: hoe je weet dat de output goed is

Een AI-integratie zonder evaluatie is een black box. Je weet niet of het model de juiste antwoorden geeft, of prompt-aanpassingen verbetering brengen, of de kwaliteit over tijd daalt door model-updates van OpenAI.

Ik bouw evaluatie in als onderdeel van de integratie, niet als nagedachte. De aanpak hangt af van de taak.

• ▸Labeled test set: voor classificatie- en extractietaken stel ik een set van honderd tot vijfhonderd gelabelde voorbeelden samen. Elke prompt-wijziging wordt op deze set getest voor uitrol.
• ▸LLM-as-judge: voor open-ended generatietaken (samenvatting, advies, antwoord op vragen) gebruik ik een tweede model als evaluator. Het beoordeelt de output op nauwkeurigheid, volledigheid en stijl volgens een vooraf gedefinieerd rubric.
• ▸A/B-testen van prompts: nieuwe promptversies worden eerst uitgerold naar een klein percentage van de aanvragen. Token-gebruik, latency en de LLM-as-judge-score zijn de metrics.
• ▸Drift-monitoring: OpenAI voert regelmatig model-updates door. Ik monitor de evaluatiemetriken continu zodat een stille verslechtering zichtbaar wordt voor het een probleem wordt.
• ▸Kosten per aanvraag loggen: bij elke API-call log ik de gebruikte tokens en bereken ik de kosten. Dit maakt het mogelijk om te zien welke use cases duur zijn en waar optimalisatie zin heeft.

Wat ik niet doe

Duidelijkheid over de grenzen van mijn aanpak is onderdeel van goed advies.

• ▸OpenAI's nieuwste model inzetten waar OpenAI's nieuwste model-mini volstaat. Als de taak classificatie of extractie is op gestructureerde input, is het duurdere model zelden beter. Ik test eerst met het goedkopere model.
• ▸Geen evaluation pipeline opzetten. Een AI-systeem zonder evaluatie is een risico. Ik bouw altijd een baseline test set in, ook als het klein is.
• ▸Prompts hard-coden zonder versioning. Prompts zijn code. Ze horen in Git, met diffs en een deployment-proces.
• ▸Geen cost-monitoring inbouwen. OpenAI-rekeningen kunnen snel oplopen bij productie-volumes. Ik wil dat je ziet wat het kost per aanvraag, per dag, per gebruiker.
• ▸Een integratie afleveren zonder documentatie van de architectuurkeuzes. Je moet over zes maanden begrijpen waarom bepaalde keuzes gemaakt zijn.

Gerelateerde diensten