ChatGPT for udviklere: Integration og API-brug

ChatGPT kan bruges af udviklere gennem OpenAI API, hvor en applikation sender input til en model og modtager svar, strukturerede data eller værktøjskald. En god integration kræver valg af endpoint, datakontrol, fejltest og klare grænser mellem modelens forslag og applikationens handlinger.

Hvad betyder ChatGPT for udviklere i praksis?

For udviklere betyder ChatGPT ikke kun en chatboks i en browser. Det betyder adgang til sprogmodeller gennem et programmerbart interface, hvor en applikation kan sende brugerbeskeder, systeminstruktioner, dokumentuddrag eller andre input og få et svar tilbage i et format, som softwaren kan bruge.

Den tekniske kerne er et API. API’et er kontrakten mellem din kode og OpenAI-platformen: hvordan du godkender kaldet, hvilke data du sender, hvilken model der bruges, og hvordan svaret leveres tilbage.

Det giver især mening, når ChatGPT-lignende funktioner skal indgå i et produkt, en intern arbejdsgang eller et fagsystem. Eksempler kan være søgning i supportartikler, udkast til svar, klassificering af henvendelser, opsummering af dokumenter eller en assistent, der kan bruge udvalgte interne værktøjer.

Hvordan adskiller API-brug sig fra ChatGPT i browseren?

ChatGPT i browseren er et færdigt brugerprodukt. API-brug er en udviklerflade, hvor du selv bygger brugeroplevelsen, datastrømmen, adgangsstyringen og kvalitetskontrollen omkring modelkaldet. Det er forskellen på at bruge et værktøj og at bygge et værktøj ind i egen software.

En browserdialog er velegnet til individuel brug, ideudvikling og manuelt vidensarbejde. En API-integration er bedre, når samme opgave skal gentages, logges, måles og kobles til eksisterende systemer. Hvis læseren først skal forstå den generelle brugeroplevelse, giver en grundlæggende introduktion til ChatGPT et andet udgangspunkt end en teknisk integration.

API’et gør ikke automatisk et system sikkert, korrekt eller produktionsklart. Det giver en teknisk adgang til modelkapaciteter. Resten afhænger af arkitektur, dataafgrænsning, test, rettighedsstyring og den konkrete brugeropgave.

Hvilket endpoint bør en ny integration starte med?

OpenAI beskriver Responses API som den anbefalede vej til nye projekter, mens Chat Completions fortsat er understøttet. Det gør Responses API til et naturligt startpunkt, når en ny integration skal kunne håndtere tekst, værktøjer, samtaler over flere trin eller multimodale input.

Chat Completions findes stadig i mange eksisterende kodebaser. Hvis du vedligeholder en ældre integration, kan det være mere realistisk at forbedre den gradvist end at omskrive alt på én gang. Ved nye projekter bør valget derimod begynde med den aktuelle API-dokumentation, ikke med gamle kodeeksempler fra nettet.

Endpoint-valget handler også om ansvar. Jo mere state, værktøjsbrug og automatisering du lægger ind i integrationen, desto mere skal applikationen kunne forklare, logge og begrænse hvert trin. En simpel tekstfunktion kan ofte være stateless. En assistent med flere handlinger kræver tydeligere styring.

Hvordan ser en enkel API-integration ud?

En enkel integration består typisk af fem dele: en API-nøgle, en serverkomponent, et modelvalg, et inputformat og en håndtering af svaret. API-nøglen bør ligge i et miljø, som brugeren ikke kan se. Kaldet bør som udgangspunkt gå fra din backend, ikke direkte fra en offentlig frontend.

OpenAI stiller officielle SDKer til rådighed, men API’et kan også bruges via en almindelig HTTP-klient. SDKer gør ofte håndtering af godkendelse, streaming, fejl og svarformater lettere, mens direkte HTTP kan give mere kontrol i systemer med egne klientbiblioteker.

Hvordan styrer du input, kontekst og svarformat?

Et modelkald bør ikke blot sende en løs brugerbesked videre. Det bør beskrive opgaven, afgrænse den relevante kontekst og angive, hvilket svarformat applikationen forventer. Ellers bliver integrationen svær at teste, fordi små ændringer i input kan give store forskelle i svar.

Kontekst kan komme fra brugerens aktuelle handling, fra et dokument, fra en database eller fra tidligere trin i samme arbejdsgang. Jo mere kontekst du sender, desto større bliver både omkostning, latency og risiko for at blande irrelevante oplysninger ind i svaret.

Når svaret skal bruges maskinelt, bør det ikke kun være fri tekst. Structured Outputs kan bruges, når applikationen forventer bestemte felter, værdityper eller en fast JSON-struktur. JSON mode kan sikre gyldig JSON, men det garanterer ikke i sig selv, at indholdet matcher et bestemt schema.

Hvornår giver function calling og værktøjer mening?

Function calling bruges, når modellen skal foreslå, at applikationen kalder en bestemt funktion med bestemte argumenter. Modellen udfører ikke selv handlingen. Din kode skal læse kaldet, validere argumenterne, udføre funktionen og sende resultatet tilbage til modellen eller brugerfladen.

Det er nyttigt, når en assistent skal slå ordrestatus op, hente kalenderdata, oprette en sag, klassificere en henvendelse eller beregne noget med en eksisterende service. Her bør modellen ikke få fri adgang til systemet. Den bør kun kunne kalde de funktioner, du eksplicit har defineret.

Funktionsdefinitioner fylder også i konteksten og tæller som input. Store værktøjskataloger kan derfor gøre kald dyrere og sværere at styre. En praktisk løsning er at give modellen få, tydeligt beskrevne funktioner ad gangen og lade applikationen afgøre, hvilke der er relevante for situationen.

Hvordan håndterer du samtaletilstand og historik?

Hver modelanmodning bør behandles som en afgrænset hændelse, medmindre integrationen aktivt bevarer samtaletilstand. OpenAI beskriver flere måder at håndtere historik på: du kan selv sende tidligere beskeder med i næste kald, eller du kan bruge API-funktioner, der bevarer state under bestemte betingelser.

Valget påvirker både privatliv, fejlretning og produktadfærd. Manuel historik giver ofte mere kontrol, fordi du selv vælger, hvilke tidligere oplysninger der sendes med. Bevarelse af state kan være praktisk i længere samtaler, men kræver skarpere beslutninger om sletning, adgang og logning.

For en produktionsintegration er en kort, relevant samtalehistorik som regel bedre end en lang ukontrolleret. Den gør svarene mere forudsigelige, sænker omkostninger og mindsker risikoen for, at gamle oplysninger påvirker nye svar.

Hvordan bør udviklere tænke om data og privatliv?

Data er et arkitekturspørgsmål, ikke kun et juridisk bilag. Før en integration går i drift, bør du vide, hvilke brugerdata der sendes til API’et, hvor længe de kan være relevante, om der sendes personoplysninger, og hvem der kan se logs i dit eget system.

OpenAI oplyser, at data sendt til API’et ikke bruges til at træne eller forbedre OpenAI-modeller, medmindre kunden aktivt tilvælger deling. Samtidig kan API-brug omfatte abuse monitoring logs og application state, afhængigt af endpoint og indstillinger. Det gør datakontrol til et konkret teknisk valg.

Organisationer i Danmark skal samtidig vurdere egne databehandleraftaler, formål, adgangsrettigheder og interne slettefrister. En teknisk integration kan være korrekt bygget og stadig være forkert placeret, hvis den sender unødvendigt følsomme oplysninger ud af et fagsystem. Derfor bør beskyttelse af data ved brug af AI-APIer indgå tidligt i designet.

Hvordan tester du kvaliteten af en ChatGPT-integration?

Kvalitetstest bør tage udgangspunkt i de opgaver, brugeren faktisk skal løse. Det er ikke nok at prøve fem venlige eksempler. Du bør teste korte beskeder, uklare beskeder, fejlbehæftede data, tomme felter, lange dokumenter, irrelevante instruktioner og situationer, hvor systemet skal afvise en handling.

• Lav faste testcases med forventet svaradfærd, ikke kun forventet ordlyd.
• Log modelversion, inputtype, valgt endpoint, svartid og fejltype.
• Valider struktureret output mod schema, før data gemmes eller sendes videre.
• Test grænser for værktøjskald, så modellen ikke kan udløse handlinger uden nødvendig kontrol.
• Gentag test, når model, instruktioner, schema eller interne datakilder ændres.

Den bedste måleenhed afhænger af opgaven. En søgeassistent kan vurderes på kildepræcision. En klassifikator kan måles på fejlrate per kategori. En kundeservicehjælper kan måles på, om svaret er relevant, korrekt afgrænset og ikke lover mere, end organisationen kan holde.

Hvad skal være på plads før produktion?

En prototype kan fungere med få linjer kode. En produktionsintegration skal kunne tåle fejl, trafik, misbrug og ændrede brugerinput. OpenAI fremhæver blandt andet sikker adgang, robust arkitektur, håndtering af høj trafik, rate limits og latency som dele af overgangen fra prototype til drift.

Et praktisk kontrolforløb kan se sådan ud:

1. Afgræns præcis, hvilken opgave modellen må løse.
2. Vælg endpoint, model og outputformat ud fra opgaven.
3. Gem nøgler og konfiguration uden for klientkode og offentlige repositorier.
4. Definér, hvilke data der må sendes, logges og gemmes.
5. Indbyg timeouts, retries, fejlbeskeder og fallback-adfærd.
6. Overvåg omkostning, svartid, fejlrate og uventede svarmønstre.

Der bør også være en plan for modelskift. API-platforme udvikler sig, og modelnavne, endpointanbefalinger og kapaciteter kan ændre sig. Derfor bør integrationen have konfiguration, test og dokumentation, som gør det muligt at skifte model uden at omskrive hele produktet.

Hvornår er en AI-agent bedre end et almindeligt API-kald?

Et almindeligt API-kald passer bedst til en afgrænset opgave: omskriv en tekst, klassificer en henvendelse, udtræk felter eller svar på et spørgsmål ud fra kendt kontekst. En AI-agent passer bedre, når systemet skal gennemføre flere trin, bruge værktøjer, følge en plan og reagere på mellemresultater.

Forskellen kan forklares som kontrol mod fleksibilitet. Et almindeligt kald er lettere at teste og begrænse. En agentisk arbejdsgang kan løse mere sammensatte opgaver, men kræver flere stopklodser, bedre logning og tydeligere ansvar for, hvilke handlinger der må udføres.

Hvis opgaven kan løses med et enkelt kald og et klart schema, er det ofte den bedste løsning. Hvis opgaven kræver søgning, beregning, datatræk og beslutning i flere runder, kan det være relevant at sammenligne med AI-agenter og AI-workflows.

Hvornår giver fine-tuning mening?

Fine-tuning bør ikke være første svar på en usikker integration. Mange problemer skyldes uklare instruktioner, for bred kontekst, manglende schema, svage testcases eller forkert modelvalg. De problemer bør løses i applikationslaget, før man træner en specialiseret modelvariant.

Fine-tuning kan være relevant, når opgaven er stabil, eksemplerne er mange og kvaliteten skal forbedres på en gentagen mønstergenkendelse. Det kan for eksempel være klassifikation, formatnær omskrivning eller en snæver domænestil, hvor generelle instruktioner ikke er nok.

Der er også driftsmæssige omkostninger. Træningsdata skal udvælges, renses og vedligeholdes. Modellen skal evalueres efter træning, og resultaterne skal sammenlignes med en stærk standardmodel. En forklaring af fine-tuning af sprogmodeller viser, hvorfor teknikken først giver mening, når opgaven er velafgrænset.

Hvilke fejl går igen i API-projekter?

Mange fejl opstår, fordi integrationen behandles som en tekstgenerator i stedet for et softwaremodul. Modellen kan være stærk til sprog, men applikationen skal stadig håndtere validering, adgang, logs, undtagelser, dataminimering og brugersikkerhed.

• API-nøgler placeres i frontendkode eller deles i interne dokumenter.
• Alle brugerdata sendes videre, selv om kun få felter er nødvendige.
• Fri tekst bruges som maskinelt output, hvor et schema ville være mere stabilt.
• Værktøjskald udføres uden tilstrækkelig validering af argumenter.
• Omkostninger og rate limits opdages først, når brugen vokser.

Den robuste løsning er sjældent én ekstra regel. Den er en lille kæde af kontroller: begræns input, vælg præcist outputformat, valider før handling, log tekniske hændelser og mål løbende på de fejltyper, der faktisk påvirker brugeren.

En god arbejdsrækkefølge begynder med brugeropgaven og slutter med drift. Start ikke med den mest avancerede model eller den mest frie agentarkitektur. Start med den mindste integration, der løser en konkret opgave, og udvid først når testdata viser, at der er behov.

For mange projekter er den mest praktiske rækkefølge: simpel tekstfunktion, struktureret output, kontrollerede værktøjskald, samtaletilstand, evalueringsdatasæt og derefter eventuel agentisk orkestrering. Hvert trin bør have sin egen grund til at eksistere.

Den rækkefølge gør integrationen lettere at forklare til udviklere, ledelse, sikkerhedsansvarlige og brugere. Den gør det også lettere at stoppe ved et niveau, hvor løsningen er nyttig, uden at systemet bliver mere komplekst end opgaven kræver.

Hvilke kilder ligger til grund?

Artiklen bygger især på OpenAIs officielle dokumentation om SDKer og API-nøgler, Responses API, function calling, Structured Outputs og datakontroller i OpenAI-platformen.