Prompt Chaining

Prompt chaining deler en opgave op i flere separate kald til modellen. Hvert kald løser ét delproblem, og output bliver input til det næste kald. Kæden styres af din kode, ikke af modellen.

Det er den vigtigste forskel til chain-of-thought. Ved chain-of-thought foregår hele ræsonnementet inden for ét svar i ét context window, og du får kun det færdige resultat plus modellens egen udlægning af vejen dertil. Ved chaining eksisterer hvert mellemresultat som et selvstændigt objekt, du kan læse, gemme, validere eller kassere.

Forskellen til ReAct-prompting er, hvem der bestemmer rækkefølgen. I ReAct beslutter modellen selv, hvilket skridt der kommer nu, ud fra hvad den lige har observeret. I en kæde er rækkefølgen fastlagt på forhånd. Du bytter fleksibilitet for forudsigelighed.

I praksis findes der mellemformer. En kæde kan indeholde forgreninger baseret på en klassifikation fra et tidligere step, og et enkelt led i kæden kan internt bruge en agent-loop.

En prompt konkurrerer altid om modellens opmærksomhed. Når én prompt indeholder fem instruktioner, fordeles vægten mellem dem, og instruktioner sidst i rækken bliver ofte behandlet overfladisk eller helt overset. Deler du op, får hver instruktion et helt kald for sig selv.

Hvert nyt kald starter desuden med et rent context window. Fejl i step 1 kan stadig forplante sig gennem indholdet, men modellens delvist forkerte formuleringer, halvfærdige udkast og sidespor fra step 1 er væk. Ved lange enkeltprompts bliver de tidlige tokens ved med at påvirke det, der genereres senere.

En tredje effekt handler om outputformat. Et step, der kun skal producere en liste med hovedpunkter, kan tvinges til stram JSON eller ren punktform. Det er langt sværere at kontrollere formatet på et mellemresultat, der kun eksisterer inde i en længere fritekst.

Endelig kan hvert step få sin egen model. Ekstraktion og oversættelse kan køre på Gemini 3.7 Flash eller Claude Haiku 4.5, mens det ene led, der kræver reel vurdering, kører på Claude Opus 5 eller GPT-5.6 Sol.

Reasoning-modeller har flyttet grænsen mærkbart. Opgaver, der for få år siden krævede tre led, håndterer Claude Opus 5 og Gemini 3.1 Pro nu i ét kald med intern tænkning. Bygger du en kæde for at kompensere for noget, modellen allerede kan, betaler du ekstra latency og flere API-kald uden at vinde accuracy.

Kæder skader, når stepsene ikke er reelt adskilte. Hvis step 2 har brug for nuancer fra kildeteksten, som step 1 komprimerede væk, arbejder step 2 på et fattigere grundlag end en enkelt prompt ville have haft. Sammenfatning efterfulgt af analyse er et klassisk eksempel på tabt information.

Kæden giver også falsk tryghed omkring fejl. Mellemresultater ser velformede ud, selv når de er faktuelt forkerte, og et pænt struktureret step 1 bliver derfor sjældent kontrolleret. Fejlen dukker først op til sidst, hvor den er svær at spore tilbage.

Ved korte opgaver æder overhead gevinsten. Tre kald á 200 tokens til GPT-5 nano er hverken hurtigere eller mere præcist end ét velformuleret kald.

Et godt snit går der, hvor du kan beskrive mellemresultatet præcist, uden at henvise til det næste step. Kan du ikke definere, hvad step 1 skal levere, uden at forklare hvad step 2 skal bruge det til, hører de to ting formentlig sammen i én prompt.

Et andet kriterium er testbarhed. Hvis du kan skrive en simpel kontrol af et mellemresultat, altså feltnavne, antal punkter eller sprogkode, har snittet værdi. Kan kvaliteten kun bedømmes ved at læse slutresultatet, er leddet mest af alt ekstra overflade at fejle på.

Start med den korteste kæde, der virker, og del først et step op, når du kan pege på en konkret fejltype, opdelingen fjerner.