Tree-of-Thought (ToT)

Tree-of-Thought beder modellen om at åbne flere løsningsveje parallelt, vurdere dem mod hinanden og først derefter vælge. En prompt kan bede om tre til fem forskellige tilgange til et problem, en kort udfoldelse af hver, en eksplicit vurdering og en begrundet konklusion. Strukturen svarer til et søgetræ: grene der udforskes, sammenlignes og beskæres.

Forskellen til Chain-of-Thought er retningen. CoT producerer én sammenhængende kæde af mellemtrin og holder fast i den, også når det første valg af tilgang var uheldigt. ToT gør valget af tilgang til et eksplicit trin i sig selv, så en dårlig gren kan afskrives i stedet for at bære hele svaret.

Forskellen til self-consistency ligger i, hvor sammenligningen foregår. Self-consistency kører den samme prompt flere gange og tager det svar, der optræder oftest, uden at modellen ser de øvrige forsøg. ToT lægger alle grene i samme context window, hvor de kan holdes op mod hinanden med eksplicitte kriterier. Til databaseoptimering betyder det, at indeksering, denormalisering og partitionering bliver vejet mod hinanden i samme svar, ikke afgjort ved flertal.

En sprogmodel genererer token for token, betinget af det der allerede står. Når de første sætninger har lagt sig fast på indeksering som løsning, gør det efterfølgende tekst om indeksering mere sandsynlig. Effekten er nyttig, når retningen er rigtig, og kostbar når den er forkert.

ToT bryder den binding ved at tvinge flere begyndelser frem, før nogen af dem uddybes. Grenene skrives uafhængigt, så ingen af dem er betinget af, at en anden gren allerede har fastlagt rammen. Det giver et bredere spænd af kandidater end en enkelt kæde ville producere.

Evalueringstrinnet virker, fordi vurdering og generering er forskellige opgaver med forskellig sværhedsgrad. At bedømme om partitionering passer til et skrivetungt workload er lettere end at finde løsningen fra bunden. Når alle grene står i konteksten, har modellen desuden konkret materiale at sammenligne, i stedet for at skulle bedømme noget den ikke har formuleret.

Problemer med ét rigtigt svar får intet ud af flere grene. Faktaopslag, formatkonvertering, oversættelse og simpel kodegenerering bliver blot dyrere og længere. Prisen er reel: en ToT-prompt kan bruge fem til ti gange så mange output-tokens som et direkte svar.

Teknikken giver falsk tryghed, når grenene ikke er reelt forskellige. Beder du om tre tilgange til et problem, hvor kun én er nærliggende, får du ofte én rigtig løsning og to udvandede varianter af den. Evalueringen ser grundig ud og peger på det svar, du ville have fået alligevel.

Evalueringen er heller ikke stærkere end modellens viden om domænet. Mangler prompten centrale oplysninger om læse- og skrivemønstre, hardware og forespørgselstyper, bliver vurderingen af databasegrenene generisk. Struktureret sammenligning af utilstrækkeligt grundlag ser mere overbevisende ud, end den er.

Små modeller som GPT-5 nano og Claude Haiku 4.5 taber ofte tråden i strukturen. Grenene smelter sammen, eller evalueringen bliver en opremsning uden reelle valg.

Modeller med udvidet reasoning som Claude Opus 5, GPT-5.6 Sol og Gemini 3.1 Pro udfører allerede en del grenudforskning internt. De prøver alternativer, forkaster dem og vender tilbage, uden at du beder om det. Manuel ToT oven på det giver ofte overlappende arbejde og dobbelt token-forbrug.

Den del af ToT, der stadig bærer, er kriterierne. Du kan angive hvilke dimensioner grenene skal vurderes på, og hvor mange reelle alternativer du vil se dokumenteret. Det styrer ikke tænkningen, men det gør valget synligt og efterprøveligt, hvilket den interne reasoning ikke i sig selv leverer.

Det gælder også revisionsbehovet. Skal en beslutning kunne begrundes over for andre bagefter, har du brug for de afviste alternativer skrevet ned. Her er ToT-strukturen en dokumentationsform lige så meget som en reasoning-teknik.