Logisk Reasoning & Problemløsning

Use-casen dækker de opgaver, hvor svaret ikke findes i en kilde, men skal udledes. Du giver modellen et problem med flere variable, modstridende hensyn eller uklare præmisser, og beder om en analyse frem for en tekst. Output er typisk en argumentation, en vurdering eller et beslutningsgrundlag.

Grænsen mod almindelig tekstgenerering går ved, om der er noget at regne ud. En markedsføringstekst kræver formulering, ikke deduktion. Grænsen mod RAG går ved, om problemet er mangel på viden eller mangel på bearbejdning. Skal du finde ud af, hvad der står i en kontrakt, er det søgning. Skal du finde ud af, om to klausuler modsiger hinanden, er det reasoning.

Ren matematik og kodning hører også hjemme i egne kategorier. Her handler det om semi-strukturerede problemer, hvor der ikke findes en algoritme, og hvor kvaliteten måles på argumentets holdbarhed.

Grundmekanikken er, at modellen genererer mellemregninger som tokens, før den svarer. Reasoning-modeller som GPT-5.6 Sol og Claude Opus 5 gør dette internt og kan bruge et stort antal tokens på analysen, før du ser en linje. Jo mere komplekst problemet er, jo mere afhænger resultatet af, at modellen får lov at bruge den plads.

Et typisk forløb har fire led. Først en problemformulering, hvor du fastlægger, hvad der skal afgøres, og hvilke begrænsninger der gælder. Så en eksplicit liste over kendte fakta og antagelser. Derefter selve analysen. Til sidst en kontrol, hvor du eller en anden model gennemgår argumentet for spring og modsigelser.

Kvaliteten afgøres først og fremmest af inputtets præcision. En model kan ikke udlede noget om forhold, du ikke har nævnt, og den vil sjældent spørge af sig selv, medmindre du beder om det. Claude Sonnet 5 er ofte tilstrækkelig til afgrænsede analyser, mens problemer med mange indbyrdes afhængige led som regel kræver de tungere modeller.

Den hyppigste fejl er, at modellen accepterer din problemformulering ukritisk. Beder du om en analyse af, hvilken af tre leverandører du skal vælge, får du en sammenligning af de tre, også selvom den rigtige konklusion er, at ingen af dem passer. Modellen optimerer mod at besvare spørgsmålet, ikke mod at stille et bedre.

Dernæst er der glidende præmisser. I lange analyser kan en antagelse fra trin to blive omformuleret undervejs, så konklusionen i trin syv hviler på noget lidt andet. Fejlen er svær at opdage, fordi hvert enkelt skridt ser rimeligt ud. Bed derfor om, at antagelser står samlet og uændret ét sted.

Endelig er sikkerheden i tonen ikke korreleret med rigtigheden. Et fejlbehæftet argument præsenteres i samme rolige, velstrukturerede sprog som et korrekt. Det gør formatet farligt, fordi det ligner en gennemarbejdet rapport, uanset hvad der står i den.

Den forklaring, du får at se, er en tekst, modellen har genereret. Den er ikke nødvendigvis en beskrivelse af, hvordan svaret faktisk opstod. Modellen kan nå en konklusion og derefter producere en plausibel begrundelse for den.

Det betyder, at du ikke kan validere et svar ved at læse dets egen forklaring og finde den overbevisende. Du validerer ved at teste konklusionen mod noget uafhængigt: data, en fagperson, et modeksempel eller en ny session, hvor du beder om argumenter imod. Bruger du reasoning som beslutningsstøtte, skal ansvaret for konklusionen blive hos et menneske, der kan begrunde den uden at henvise til modellen.