Udbyderne tilbyder ræsonnement på forskellige måder. OpenAI bruger ræsonnementsindsats og tilstande på understøttede modeller, Anthropic beskriver adaptive og extended thinking, og Google beskriver thinking levels eller budgets for understøttede Gemini-modeller. Produktbetegnelser og parametre ændrer sig, så vælg ud fra aktuelle udbyderdokumenter og målt opgaveydelse frem for en fast liste over modelnavne.
Nogle ræsonnerende modeller kan have gavn af en anden promptstil end konfigurationer uden ræsonnement. OpenAIs aktuelle vejledning anbefaler at begynde med direkte prompts og undlade at bede om en tankekæde. Betragt bredere påstande om stilladsering, roller og selvkritik som hypoteser, der skal testes på din model og arbejdsgang, ikke som regler, der automatisk kan overføres mellem udbydere.
Denne artikel forklarer, hvad ræsonnerende modeller er, hvornår du skal bruge dem, hvordan du skriver gode prompts til dem, og hvilke faldgruber der rammer selv erfarne AI-brugere.
Hvad indstillinger for ræsonnement ændrer
Udbydere bruger betegnelser som ræsonnement, thinking, indsats og budget om indstillinger, der kan ændre tokenforbrug, svartid og outputkvalitet. Afhængigt af udbyder og konfiguration kan ræsonnementsindhold være skjult, opsummeret, udeladt eller returneret i separate blokke. Udled ikke en udbyders skjulte proces af en betegnelse eller af stilen i det endelige svar.
Ræsonnement kan forbedre resultaterne på visse vanskelige opgaver med flere trin, men gevinsten afhænger af model, indsatsindstilling, prompt og evaluering. Det kan også øge svartiden og mængden af fakturerede ræsonnementstokens. Valget mellem en konfiguration med lavere svartid og mere ræsonnement er derfor en arkitekturbeslutning, der skal benchmarkes, ikke en universel opgradering.
Eksempler på produktfamilier med ræsonnement i 2026 omfatter:
- OpenAI-tilstande til ræsonnement. OpenAI har lanceret modeller i o-serien og GPT-tilstande med ræsonnement. Tilgængelighed og udfasningsdatoer varierer mellem produkter og abonnementer, så kontrollér den aktuelle modelvejledning, før du standardiserer.
- Claude-modeller med thinking. Anthropics aktuelle dokumentation angiver, at thinking er tilgængeligt på aktuelle Claude-modeller, men den understøttede konfiguration varierer. Nogle bruger adaptive thinking, mens manuel
budget_tokensikke understøttes eller er udfaset på andre. Følg tabellen for den enkelte model i stedet for at anvende én generisk parameteropskrift. - DeepSeek R1. Artiklen om R1 beskriver modelfamilien og træningsmetoden. Kontrollér DeepSeeks aktuelle officielle dokumentation for understøttede modeller og adgangsmetoder.
- Gemini-tilstande med thinking. Understøttede Gemini API-modeller har udbyderspecifikke kontroller til thinking, som er beskrevet i Geminis vejledning om thinking.
- Andre udbydertilbud. Betragt produktnavne, rettigheder og kontroller som tidsfølsomme. Kontrollér dem i udbyderens aktuelle officielle dokumentation, før du indfører eller anbefaler dem.
Produkterne varierer i modeladfærd, understøttede kontroller, pris, svartid og synligheden af ræsonnementsoutput. Gå ikke ud fra, at en parameter eller promptregel kan overføres uændret mellem udbydere.
Hvornår du bør teste mere ræsonnement
En ræsonnerende model eller en indstilling med større indsats kan være en relevant sammenligning. Brug disse opgavesignaler og grænser, når du definerer forsøget:
- Problemet har flere trin, der bygger på hinanden. Matematik, logik, planlægning i flere trin og kode, hvor en tilstand skal følges.
- En konfiguration med mindre ræsonnement fejler fortsat på de samme evaluerede tilfælde. En ræsonnerende model eller en større indsats er da et relevant eksperiment. Sammenlign konfigurationerne på de samme tilfælde.
- Opgaven kræver omhyggelig sammenligning eller afvejning. Beslutninger med flere kriterier, arkitekturvalg og leverandørvurderinger.
- Evalueringen indeholder særtilfælde, som konfigurationer med mindre ræsonnement overser. Mål disse tilfælde direkte i stedet for at udlede ræsonnementskvalitet af flydende tekst.
- Opgaven har væsentlige konsekvenser. Vælg ikke mere ræsonnement, blot fordi indsatsen er høj. Inden for økonomi, jura, medicin, sikkerhed eller produktionsdrift skal du bruge autoritative kilder, kvalificeret gennemgang, validerede kontroller og en dokumenteret beslutningsgrænse. Test derefter, om ræsonnementskonfigurationen forbedrer de tilfælde, der har betydning.
Tilfælde, hvor et udgangspunkt med mindre ræsonnement kan være konkurrencedygtigt:
- Samtaler, hvor svartid er afgørende. Brug kun mere ræsonnement, hvis den målte kvalitetsgevinst retfærdiggør en langsommere dialog.
- Generering og udkast, hvor evalueringerne ikke viser en fordel. En konfiguration med lavere svartid kan være bedre til kreativ iteration. Sammenlign outputkvalitet i stedet for at antage, at mere ræsonnement hjælper eller skader.
- Enkel informationssøgning. Et kildeforankret opslag eller en konfiguration med mindre ræsonnement kan opfylde kvalitetsmålet med lavere svartid og pris. Kontrollér kilden i begge tilfælde.
- Hurtig iterativ forfinelse. Lavere svartid kan forbedre dialogen, men sammenlign det endelige opgaveresultat frem for blot at tælle beskeder.
- Opgaver, hvor du har brug for kontrollerbare mellemresultater. Ræsonnerende modeller kan skjule den interne ræsonnering. Bed om de beregninger, kilder, testresultater eller andre artefakter, du faktisk skal kontrollere. En synlig CoT-redegørelse er ikke i sig selv dokumentation.
En nyttig beslutningsregel er kun at øge ræsonnementet, når den forventede kvalitetsgevinst er den målte svartid og pris værd i den konkrete arbejdsgang.
Promptmønstre, der bør sammenlignes
Begynd med en direkte prompt, der fokuserer på resultatet, og sammenlign derefter disse mønstre, når de kan ændre resultatet væsentligt:
1. Brug en direkte prompt som udgangspunkt for OpenAI
For OpenAIs ræsonnerende modeller siger OpenAIs anbefalinger, at prompts som ”tænk trin for trin” er unødvendige og undertiden kan forringe resultatet. Andre udbydere stiller andre kontroller til rådighed, så sammenlign en direkte prompt med den mere strukturerede variant, du overvejer.
Dårligt: Tænk trin for trin. Løs dette omhyggeligt. Vis dine beregninger. [problem]
Godt: [problem]
Angiv problemet tydeligt, og kontrollér konklusionen. For andre udbydere skal du følge den aktuelle dokumentation og teste den understøttede prompt eller kontrol.
2. Sammenlign direkte prompts med processtilladsering
Omfattende stilladsering kan gentage arbejde, som en ræsonnerende model allerede udfører. Begynd med målet, relevant kontekst, faste begrænsninger, krævet dokumentation og outputformat. Fjern kun procestrin, når en evaluering viser, at den enklere prompt bevarer den nødvendige adfærd.
Kandidat med processtilladsering: Angiv først de vigtigste begrænsninger. Opregn derefter mulighederne. Vurdér så hver mulighed i forhold til hver begrænsning. Vælg derefter. Begrund til sidst. Outputformat: …
Direkte kandidat: Hjælp mig med at vælge mellem mulighed A og mulighed B. Kontekst: […]
Den enklere prompt giver modellen plads til at vælge en fremgangsmåde, samtidig med at de reelle begrænsninger og outputkontrakten bevares.
3. Test kombinationer af teknikker i stedet for at antage, at de hjælper
Prompts med tankekæde, selvkritik og træsøgning tilføjer instruktioner og tokens. Gå ikke ud fra, at en kombination af dem forbedrer det evaluerede svar.
Hvis din prompt indeholder ”tænk trin for trin, kritisér derefter dit eget svar, og revidér det så”, skal du sammenligne den med en enklere version. Behold den variant, der klarer sig bedst på repræsentative tilfælde.
4. Brug kun roller, når de tilfører oplysninger om opgaven
Detaljerede personaer tilføjer ofte oplysninger, der ikke kan efterprøves, uden at ændre opgaven. Brug en rolle, når den fastlægger område, målgruppe, politik eller terminologi. Ellers bør du beskrive arbejdet direkte. Hvis rollen ser ud til at forbedre resultatet, skal du bekræfte gevinsten på de samme evalueringstilfælde frem for intuitivt at tilskrive den personaen.
En kort rolle kan være nyttig til at fastlægge tone og sprogligt register. Sammenlign den med tilsvarende konkrete instruktioner, når ensartethed er vigtig.
Dårligt: Du er en backendudvikler i verdensklasse med 20+ års erfaring…
Godt: Hjælp mig med at ræsonnere over dette problem i distribuerede systemer. [problem]
5. Bed om dokumentation, ikke skjult tænkning
Nogle produkter skjuler eller opsummerer den interne ræsonnering. Hvis du beder modellen om at ”vise sin ræsonnering”, anmoder du om en genereret forklaring, ikke nødvendigvis modellens private spor eller dokumentation for, at svaret er korrekt.
Hvis du har brug for revisionsspor, skal du bede om en kort begrundelse og kontrollerbar dokumentation. Anthropics aktuelle API kan returnere opsummeret ræsonnement eller udelade det afhængigt af model og konfiguration. Ingen af delene erstatter kontrol af resultatet.
Hvad prompten bør indeholde
Et nyttigt udgangspunkt indeholder:
Konkrete oplysninger. Giv modellen de tal, datoer, præcise begrænsninger, filer og andre input, der er nødvendige for at løse og kontrollere opgaven.
Åben indramning, når outputkontrakten tillader det. ”Her er situationen. Her er det, jeg vil finde ud af. Hvad mener du?” kan være et nyttigt udgangspunkt, som du sammenligner med en mere fast skabelon.
Ærlig usikkerhed. Fortæl modellen, hvad du ikke ved. ”Jeg er ikke sikker på X eller Y; hjælp mig med at identificere den dokumentation, der kan skelne mellem dem” er mere nyttigt end at skjule tvetydigheden.
Tilladelse til at være uenig. ”Sig fra, hvis min indramning er forkert” eller ”fortæl mig, hvad jeg ikke har overvejet” kan afdække andre perspektiver end en prompt, der alene beder om støtte til dit eksisterende standpunkt.
Konkrete data. Regneark, kode og dokumenter kan give modellen reelle artefakter at arbejde med i stedet for abstrakte spørgsmål. Del dem kun, når værktøjet er godkendt til oplysningerne, og fjern først data, som ikke er nødvendige for opgaven.
Gennemarbejdede eksempler
Eksempel 1: En fejlfindingsopgave
Forestil dig, at du har en vanskelig fejl.
Prompt med processtilladsering:
Du er en erfaren softwareudvikler med speciale i TypeScript. Tænk trin for trin over denne fejl.
Find først de relevante kodedele. Følg derefter datastrømmen. Find så de sandsynlige årsager. Anbefal til sidst en rettelse.
Her er fejlen: [description] Her er koden: [code]
Direkte prompt:
Hjælp mig med at finde denne fejl.
Symptomer: [description] Relevant kode: [code] Det har jeg allerede prøvet: [list]
Sammenlign den direkte prompt med versionen med processtilladsering på repræsentative fejl, og mål korrekthed, krævet dokumentation, svartid og pris. Udled ikke af dette eksempel alene, at den direkte version er bedre.
Eksempel 2: En strategisk beslutning
Struktureret prompt:
Du er en erfaren strategikonsulent. Jeg prøver at beslutte, om produkt X skal lanceres. Anvend rammen [framework name]. Først … [long structured prompt]
Direkte prompt:
Jeg prøver at beslutte, om produkt X skal lanceres. Kontekst:
- Vi er en virksomhed med 50 medarbejdere og $5M ARR.
- Produktet vil tage 2 kvartaler at bygge.
- Det ligger op ad vores hovedprodukt, men konkurrerer ikke direkte med det.
- To af vores 10 største kunder har efterspurgt det.
- Vores teamkapacitet er allerede presset.
Hjælp mig med at gennemtænke dette. Sig fra over for svag ræsonnering. Fortæl mig, hvad jeg ikke har overvejet.
Den direkte prompt giver modellen plads til at vælge analysestruktur. Sammenlign den med den strukturerede variant ud fra de samme beslutningskriterier, før du tager nogen af dem i brug som skabelon.
Eksempel 3: Kompleks kodeanalyse
Prompt med processtilladsering:
Analysér denne kode for ydelsesproblemer. Tænk trin for trin. Find først datastrukturerne, følg derefter algoritmens kompleksitet, og udpeg så konkrete flaskehalse. [code]
Direkte prompt:
Hvad gør denne kode langsom? Den tager i øjeblikket ~3 sekunder på et typisk input; jeg vil have den ned under 500ms.
[code]
Test, om den direkte prompt finder den relevante flaskehals og giver en gyldig rettelse. Kontrollér alle forslag med profileringsdata, test og benchmarks.
Faldgruber ved ræsonnerende modeller
Her er en kort liste over forhold, der rammer selv erfarne brugere:
Svartiden. Mere ræsonnement kan øge svartiden, undertiden betydeligt. Mål den faktiske fordeling for din model og arbejdsgang, herunder timeouts, i stedet for at planlægge efter et generisk skøn.
Prisen. Udbyderne opgør ræsonnement forskelligt, og modelpriser ændres. Mål fakturerede input-, output- og ræsonnementstokens på repræsentative forespørgsler, og sammenlign den samlede opgavepris i stedet for at antage en fast multiplikator.
Et svar når grænsen for generering. Ræsonnements- og svartokens deler grænser forskelligt mellem udbydere. Hvis et svar stopper for tidligt, skal du kontrollere udbyderens stopårsag og tokenopgørelse. Afgræns derefter opgaven eller justér kun de kontroller, som den konkrete model understøtter. Gå ikke ud fra, at alle API’er accepterer et generisk thinking-budget.
Lange, fastlåste eller uproduktive svar. Du kan opleve usædvanligt lang svartid, timeouts, gentagelser eller et endeligt svar, der ikke løser opgaven. Registrér den observerbare fejl og konfigurationen. Prøv derefter igen inden for din politik, afgræns opgaven, eller sammenlign en anden understøttet indstilling. Påstå ikke, at du kender den skjulte årsag ud fra outputtet alene.
Flydende, men uunderbyggede konklusioner. Mere ræsonnement beviser ikke, at svaret er korrekt. Kræv ved kritiske output kilder, beregninger, test og de antagelser eller nye oplysninger, der ville ændre konklusionen. Modellens egen sikkerhedsangivelse er ikke en kalibreret garanti.
Varierende pris mellem forespørgsler. Forbruget af ræsonnementstokens kan variere med opgave og konfiguration. Følg det faktiske forbrug i stedet for at antage, at alle forespørgsler koster det samme, eller at prisen skalerer forudsigeligt med den oplevede sværhedsgrad.
En opdelt arbejdsgang, der bør testes
En mulig kandidat er et opdelt forløb:
- Konfiguration med lavere svartid til at afgrænse opgaven og identificere delspørgsmålene.
- Konfiguration med mere ræsonnement til de evaluerede delspørgsmål, hvor udgangspunktet ikke opfylder kravene.
- Godkendt produktionskonfiguration til at formatere det kontrollerede resultat til dets destination.
Sammenlign dette forløb med et udgangspunkt, der bruger én konfiguration. Mål andelen af beståede opgaver, dokumentationens fuldstændighed, fejl ved overdragelser, overholdelse af serviceniveauer, samlet svartid og samlede omkostninger. Ekstra trin er kun nyttige, når den endelige arbejdsgang klarer sig så meget bedre, at den driftsmæssige kompleksitet kan forsvares.
Et gennemarbejdet eksempel: en markedsanalyse.
- Afgrænsning: ”Jeg vil forstå markedet for X. Hjælp mig med at afgrænse analysen: Hvad skal jeg undersøge, hvilke data har jeg brug for, og hvilke spørgsmål har betydning?”
- Analyse: ”Hvad betyder de verificerede data, jeg har indsamlet, for [specific strategic question]? Angiv antagelser og mangler i dokumentationen.”
- Formatering: ”Omsæt de verificerede resultater til et oplæg på én side til vores ledelse. Bevar kilder og usikkerhed.”
Denne opdeling er en arbejdsgang, der kan testes, ikke et garanteret optimum. Sammenlign den med et udgangspunkt med én model med hensyn til kvalitet, svartid og pris.
Nogle praktiske vaner
Definér det egnede udgangspunkt. Sammenligningen skal opfylde de samme krav til data, sikkerhed, værktøjer og output som kandidaten med ræsonnement.
Fastlæg beslutningsreglen på forhånd. Vælg kvalitetsmålet, serviceniveaumålet, omkostningsgrænsen og den nødvendige minimumsforbedring, før du ser resultaterne.
Følg dine omkostninger til ræsonnerende modeller. Uanset om du bruger overvågning af abonnementsniveauet eller API-fakturering, skal du få en fornemmelse af din månedlige regning for ræsonnerende modeller. Tilpas brugen derefter.
Læg mærke til gentagne fejl i udgangspunktet med lavere svartid. Det er en nyttig udløser for at teste mere ræsonnement på de samme tilfælde.
Sammenlign én promptændring ad gangen. Når et svar er svagt, skal du afprøve en kortere prompt, mere kontekst eller en anden understøttet ræsonnementsindstilling hver for sig, så resultatet kan fortolkes.
Vælg ud fra dokumentation
Konfigurationer med ræsonnement er ikke automatisk bedre eller dårligere. Begynd med en klar, direkte prompt, bevar reelle begrænsninger og krav til dokumentation, og tilføj kun struktur eller ræsonnementsindsats, når repræsentative evalueringer berettiger det.
Brug ræsonnement bevidst, og begynd med en enkel prompt. En model med lavere svartid til udforskning efterfulgt af mere ræsonnement på evaluerede flaskehalse er ét mønster, der bør sammenlignes med en arbejdsgang med én model.
