ReAct Prompting

ReAct strukturerer en opgave som en gentagen sekvens af tre felter: Thought, Action og Observation. Modellen formulerer et ræsonnement, vælger en handling i et defineret format, og får resultatet af handlingen tilbage som tekst i konteksten. Løkken kører videre, indtil modellen producerer et Answer-felt.

Forskellen til chain-of-thought er hvor mellemleddene kommer fra. I chain-of-thought stammer hvert skridt fra modellens egne vægte, og en fejl tidligt i kæden bliver ikke opdaget. I ReAct erstattes de faktuelle mellemled af observationer fra en søgning, en database eller et API.

Forskellen til tree-of-thought er formen. Tree-of-thought forgrener flere hypoteser og vælger mellem dem, mens ReAct typisk er lineær og i stedet henter ny information ind mellem hvert skridt. Og i forhold til rå function calling er ReAct ikke et API-format, men et mønster for, hvornår kald udføres, og hvordan resultatet indarbejdes.

Når en observation skrives ind i prompten, bliver den en del af det token-materiale, næste generering betinges på. Sandsynlighedsfordelingen for de følgende tokens flyttes dermed fra parametrisk hukommelse mod konkret tekst i context window. Det er samme mekanisme som i RAG, blot udløst af modellen selv i stedet for af et fast forudgående opslag.

Thought-feltet fungerer som en oversættelse fra et sammensat spørgsmål til ét præcist kald. Et spørgsmål med to led kan sjældent besvares af én søgning, og den mellemliggende tekst tvinger opdelingen frem, før Action-feltet skrives.

Det faste format har også en teknisk funktion. Fordi Action-linjen følger en fast syntaks, kan den parses af koden omkring modellen uden fri fortolkning. Fejlforplantning begrænses, fordi hvert led bekræftes eksternt, før det næste bygges ovenpå.

Hvis svaret allerede ligger i modellens vægte, tilføjer løkken kun latency og tokenforbrug. Et enkeltstående faktaspørgsmål eller en ren omskrivningsopgave bliver ikke bedre af tre runder Thought og Observation.

Transparens forveksles let med korrekthed. Thought-sporet er genereret tekst, ikke en protokol over den underliggende beregning, og et velformuleret ræsonnement kan stå ved siden af et forkert svar. Endnu vigtigere: en observation behandles som sand, uanset om kilden var upålidelig. Et misvisende søgeresultat forplanter sig direkte til svaret og ser mere troværdigt ud, netop fordi det står under Observation.

Håndskrevet ReAct-scaffolding er desuden ofte overflødigt på Claude Opus 5, GPT-5.6 Sol og Gemini 3.1 Pro. Disse modeller har intern reasoning og native tool-brug, og et konkurrerende tekstformat i prompten kan trække dem væk fra det trænede kaldsformat. Mindre modeller som GPT-5 nano og Claude Haiku 4.5 har stadig gavn af eksplicit struktur, men falder til gengæld oftere ud af formatet midt i en løkke.

Hele historikken sendes med i hver iteration, så tokenforbruget vokser hurtigt. Lange observationer bør trimmes eller opsummeres, inden de lægges tilbage i konteksten, ellers fortrænger de instruktionerne længere oppe.

Et loft over antal iterationer er nødvendigt i produktion. Uden det kan modellen gentage samme Action i det uendelige, typisk når et tool returnerer tomt eller fejler. Definer eksplicit, hvad der skrives i Observation ved fejl, så løkken får noget at reagere på i stedet for tavshed.