Det finns tre tekniker inom promptteknik som ger mätbara och repeterbara förbättringar av svåra analytiska uppgifter: tankekedjor (chain-of-thought), självkritik och tanketräd (tree-of-thoughts). De har studerats sedan vågen av resonemangsforskning 2022–2023 – tankekedjor i Wei et al., 2022, tanketräd i Yao et al., 2023 – och trots framväxten av särskilda resonemangsnivåer (tankelägena i dagens GPT-5.x- och Claude-modeller samt DeepSeek R1) spelar teknikerna fortfarande roll. Dels för att de fortfarande är användbara med snabba modeller, dels för att de formar hur du bör prompta själva resonemangsmodellerna.
Den här artikeln förklarar vad varje teknik är, när du ska använda vilken och hur kostnaden förhåller sig till nyttan.
Vilket problem de löser
Alla tre teknikerna angriper samma grundproblem: en språkmodell genererar normalt svaret autoregressivt, token för token. Utan en separat fas för övervägande eller sökning begränsar de token som genereras tidigt snabbt det som följer och kan låsa svaret vid en svag slutsats. För enkla uppgifter är detta både bra och effektivt. För resonemang i flera steg, komplex analys eller något där svaret beror på att flera mellansteg blir rätt kan standardbeteendet ge självsäkra men felaktiga resultat.
Teknikerna tvingar modellen att lägga mer beräkningskraft på mellanliggande resonemang innan den bestämmer sig.
Tankekedjor (CoT)
Den ursprungliga och enklaste tekniken. Lägg till en formulering som ”tänk steg för steg innan du ger ditt slutliga svar” i prompten, så redovisar modellen sitt resonemang före slutsatsen.
Ett genomarbetat exempel. Jämför:
Utan teknik: Ett tåg lämnar Tallinn kl. 09.00 med hastigheten 80 km/h. Ett annat tåg lämnar Tartu kl. 09.30 och färdas mot Tallinn med hastigheten 100 km/h. Avståndet mellan städerna är 190 km. Vilken tid möts de?
med:
Med CoT: Samma fråga. Tänk steg för steg. Beräkna först hur långt det första tåget hinner innan det andra startar. Ställ sedan upp ekvationen för när de möts. Visa dina beräkningar och ge därefter ditt slutliga svar.
För svåra problem av aritmetisk typ hade modeller i GPT-3.5-klassen utan CoT felandelar på omkring 30–50 procent; versioner med CoT hade felandelar närmare 5–15 procent. Siffrorna har förändrats i takt med att modellerna har förbättrats, men riktningen – att CoT höjer träffsäkerheten i uppgifter med flera steg – har varit densamma genom flera generationer.
När du ska använda tankekedjor:
- Aritmetik i flera steg, särskilt med enheter, datum eller exakt avrundning. Även starka modeller gör misstag här.
- Logikproblem och liknande uppgifter där svaret är slutsatsen i en kedja.
- Kodfelsökning, där svaret beror på att tillståndet spåras genom koden.
- Strategisk analys, där slutsatsen beror på en avvägning mellan flera faktorer.
När du inte behöver besvära dig:
- Enkel faktahämtning. ”Vad är Estlands huvudstad?” behöver ingen CoT.
- Genereringsuppgifter. Skrivande, sammanfattning, utkast. CoT lägger bara till tokens utan kvalitetsvinst.
- Resonemangsmodeller. o3, Claude Extended Thinking och DeepSeek R1 gör redan CoT internt – att lägga till ”tänk steg för steg” i prompten är i bästa fall överflödigt och i värsta fall kontraproduktivt.
Den sista punkten är avgörande och vi återkommer till den.
Självkritik
En teknik i två omgångar. Be först modellen skapa ett svar. Be den sedan kritisera sitt eget svar och skapa en reviderad version.
Promptstrukturen:
Steg 1: [Din ursprungliga fråga]
Steg 2: Granska ditt svar ovan. Hitta eventuella misstag, svagheter eller ställen där du gjorde antaganden som kanske inte håller. Var en hård kritiker av ditt eget arbete.
Steg 3: Skapa ett reviderat svar utifrån din kritik.
Förbättringen uppstår när modellen frigörs från bundenheten till den slutsats som den första omgången skapade. När den tvingas betrakta sitt eget arbete som kritiker hittar den sådant som den inte upptäckte i den ursprungliga omgången.
En mer avancerad variant är konstitutionell/principbaserad självkritik. Du anger en uppsättning principer som svaret ska uppfylla och ber sedan modellen utvärdera svaret mot var och en.
Principer för ett bra svar på den här sortens fråga:
- Det besvarar den faktiska frågan, inte en generalisering av den.
- Det citerar konkreta belägg i stället för att svepande hänvisa till källor.
- Det redovisar uttryckligen osäkerhet där sådan finns.
- Det är välavvägt – självsäkert på starka punkter och försiktigt på svaga.
Skapa ett svar. Utvärdera det sedan mot varje princip. Revidera därefter.
Detta är tekniken bakom Anthropics arbete med Constitutional AI och liknande tillvägagångssätt i modern alignment-forskning.
När du ska använda självkritik:
- Skrivuppgifter där du vill ha en andra omgång utan att lämna samtalet.
- Analytiskt arbete där modellen sannolikt är överdrivet självsäker.
- Beslutsstöd där du vill att modellen ska hitta hålen i sitt eget argument.
- Kod där du vill ha en granskningsomgång efter genereringsomgången.
När du inte behöver besvära dig:
- Uppgifter där det inte finns något ”korrekt” svar att revidera mot (kreativt bollande, idégenerering).
- Uppgifter där du hellre gör kritiken själv (allt där ditt omdöme är själva värdet).
- Snabba samtalssvar där fördröjningen kostar mer än kvalitetsvinsten ger.
Tanketräd (ToT)
Den dyraste tekniken. I stället för att skapa en enda resonemangskedja överväger modellen uttryckligen flera vägar, utvärderar var och en och väljer den mest lovande.
En genomarbetad exempelstruktur:
Steg 1: Generera tre olika angreppssätt för det här problemet.
Steg 2: Arbeta igenom de första stegen för varje angreppssätt utan att bestämma dig för ett slutsvar.
Steg 3: Utvärdera vilket angreppssätt som sannolikt lyckas bäst och varför. Var specifik om styrkor och svagheter.
Steg 4: Välj det bästa angreppssättet och slutför lösningen.
Tanketräd fungerar eftersom vissa problem har flera rimliga angreppssätt och det första du provar inte alltid är bäst. Genom att framtvinga parallell utforskning undviker du att låsas vid en sämre väg.
Praktiskt exempel – en svår prompt:
Jag har en komplex SQL-fråga som körs för långsamt. Hjälp mig att optimera den.
Steg 1: Generera tre olika optimeringsstrategier. Steg 2: Identifiera för var och en den specifika flaskhals den skulle åtgärda och kostnaden. Steg 3: Utvärdera vilken som sannolikt ger den största vinsten med den minsta risken. Steg 4: Implementera det valda angreppssättet.
Du får något märkbart mer genomtänkt än ”här är en omskrivning”. Tre angreppssätt, en jämförelse, en rekommendation och en implementering.
När du ska använda tanketräd:
- Problem med flera trovärdiga lösningar. Arkitekturbeslut, algoritmval och strategiska val.
- Optimeringsproblem. Där det första försöket sällan är det bästa.
- Kreativa uppgifter där utforskningen är poängen. Namngivning, inramning och positionering.
- Allt där du misstänker att det uppenbara svaret är fel.
När du inte behöver besvära dig:
- Uppgifter med ett enda korrekt angreppssätt. Be inte om tre SQL-frågor när en fungerar.
- Enkla faktafrågor. Överdrivet.
- De flesta uppgifter för resonemangsmodeller – modellerna gör numera den här sortens utforskning internt.
Ett praktiskt beslutsträd
När du har ett svårt problem framför dig är frågan inte ”ska jag använda CoT, självkritik eller ToT?”. Den är ”vilken form har problemet?”.
- Linjärt problem med flera steg (aritmetik, logikproblem, strikt resonemang) → tankekedja.
- Problem där överdriven självsäkerhet är risken (analys, rekommendation, kod som bör granskas) → självkritik.
- Problem med flera rimliga angreppssätt (optimering, strategiskt val, kreativ utforskning) → tanketräd.
- Samtalsmässigt, enkelt eller generativt → ingen. Hoppa över omkostnaden.
Det finns också ett användbart metamönster: använd CoT inuti ToT inuti självkritik. Utforska tre vägar (ToT), resonera steg för steg genom var och en (CoT) och kritisera sedan den valda vägen (självkritik). Det låter överdrivet men är verkligen användbart för det svåraste analytiska arbetet. Kostnaden är fördröjning och tokens; nyttan är avsevärt bättre svar.
Hur resonemangsmodeller ändrar kalkylen
Den största förändringen sedan 2024 har varit framväxten av särskilda resonemangsmodeller – o1, o3, Claude Extended Thinking, DeepSeek R1 och Gemini 2.5 Thinking. Dessa modeller använder tankekedjor internt innan de skapar ett svar och ”tänker” ofta i tiotals sekunder eller minuter.
Detta förändrar hur de bör promptas på tre viktiga sätt:
1. Sluta lägga till ”tänk steg för steg”. Resonemangsmodeller gör redan detta. Att lägga till frasen uttryckligen kan förvirra dem eller ge överflödiga resultat. Ställ bara frågan direkt.
2. Lita på längden på modellens resonemang. Om du ställer en komplex fråga skapar modellen internt en lång resonemangskedja. Du ser inte hela kedjan (en del döljs i ”tänkande”-läget). Kompromissen är fördröjning. Ha tålamod.
3. Använd enkla, raka prompter. Resonemangsmodeller är mindre promptkänsliga än snabba modeller – de resonerar sig igenom tvetydighet i stället för att fastna i den. De överkonstruerade prompter som fungerar bra med snabba modeller (omfattande inramning, många begränsningar, strukturerade mallar) kan ibland försämra resonemangsmodellernas resultat. Prova den enklare versionen först.
Ett genomarbetat exempel. Jämför dessa två prompter till en resonemangsmodell:
Prompt A: ”Tänk steg för steg på följande fråga. Identifiera först de viktigaste begränsningarna. Lista sedan alternativen. Utvärdera därefter varje alternativ mot begränsningarna. Välj sedan. Visa ditt resonemang i varje steg. Fråga: bör vi införa fyradagarsvecka?”
Prompt B: ”Bör vi införa fyradagarsvecka? Sammanhang: B2B-SaaS med 80 anställda, kundsupportteamet arbetar måndag–fredag.”
För de flesta resonemangsmodeller ger prompt B ett bättre svar. Resonemangsmodellen vet redan hur den ska tänka igenom frågan; uttrycklig styrning kan begränsa den på sätt som försämrar resultatet.
För snabba modeller gäller motsatsen. De behöver strukturen för att skapa jämförbar kvalitet.
Detta är den viktigaste nya insikten om promptteknik sedan 2023: samma prompt som fungerar bäst för en snabb modell kan vara sämre för en resonemangsmodell och tvärtom.
Kostnad kontra nytta
Alla teknikerna har kostnader. Den ärliga redovisningen:
| Teknik | Tokenkostnad | Fördröjningskostnad | Kvalitetsvinst | När det är värt det |
|---|---|---|---|---|
| Tankekedja | ~2–3x | ~1,5–2x | 10–40 % för svåra problem | Problem med flera steg och snabba modeller |
| Självkritik | ~2x | ~2x | 5–20 % överlag | När överdriven självsäkerhet är en verklig risk |
| Tanketräd | ~3–5x | ~2–3x | 10–30 % för problem med flera angreppssätt | Svåra problem med flera vägar |
| Resonemangsmodell (inbyggt) | ~3–10x | ~5–30x | 30–100 % för svåra problem | Allt som verkligen är svårt |
För det mesta av vardagsanvändningen räcker en snabb modell utan tekniker. För svåra problem är rätt teknik (eller resonemangsmodell) värd merkostnaden. För triviala uppgifter slösar alla dessa tekniker pengar och tid.
En praktisk regel: innan du väljer en teknik, fråga om kostnaden för ett fel i den här uppgiften är tillräckligt betydande för att motivera teknikens merkostnad. Använd rätt teknik om svaret är ja. Skicka annars bara prompten.
Genomarbetat exempel: en verkligt svår uppgift
Anta att du utvärderar två leverantörsförslag och vill ha en välavvägd jämförelse.
Utan någon teknik (vanlig prompt):
Jämför dessa två leverantörsförslag [klistra in]. Vilket ska vi välja?
Du får ett garderat svar som ser båda sidor. En användbar utgångspunkt, men inte tillräckligt.
Med CoT:
Jämför dessa två leverantörsförslag. Tänk steg för steg:
- Lista kriterierna som spelar roll för vårt beslut.
- Poängsätt varje leverantör efter varje kriterium.
- Identifiera kriterierna där poängen skiljer sig mest.
- Ge sedan din rekommendation.
Du får en mycket mer strukturerad analys. Varje steg är synligt; du kan verifiera eller korrigera det.
Med självkritik ovanpå:
[samma som ovan]
Kritisera din egen analys efter rekommendationen:
- Vilka kriterier kan jag ha viktat fel?
- Vad antog jag som jag inte borde ha antagit?
- Vilket är det starkaste trovärdiga argumentet för den andra leverantören?
Skapa sedan en reviderad rekommendation om det behövs.
Kritiken upptäcker blinda fläckar i den första analysen.
Med ToT:
Jämför dessa två leverantörsförslag.
Steg 1: Generera tre olika ramverk för att fatta den här sortens beslut (till exempel riskminimerande, värdemaximerande och kapacitetsanpassat). Steg 2: Tillämpa varje ramverk. Ta fram tre rekommendationer. Steg 3: Var är ramverken överens? Var skiljer de sig åt? Steg 4: Vilket ramverk passar bäst med tanke på våra faktiska begränsningar? Slutlig rekommendation.
Du får tre olika perspektiv på valet; skillnaderna är där det intressanta resonemanget sker.
Med en resonemangsmodell:
Jämför dessa två leverantörsförslag. Vilket ska vi välja och varför? Ta med vad som skulle få dig att ändra svaret.
Resonemangsmodellen gör allt ovanstående internt. Resultatet är ofta jämförbart med eller bättre än resultatet från en kraftigt promptad snabb modell, på ungefär samma faktiska tid.
År 2026 är en resonemangsmodell med en ren prompt vanligtvis rätt val för verkligt svårt analytiskt arbete. CoT och ToT är fortfarande användbara med snabba modeller, och självkritik förblir användbart som ett extra lager oavsett underliggande modell.
Några praktiska vanor
Gör tekniken synlig för dig själv. Anteckna vilken teknik du använde i prompten – det hjälper dig att bygga upp en intuition för vad som fungerar.
Jämför resultat. Kör samma svåra prompt med och utan en teknik en gång i veckan och se hur mycket de skiljer sig. Du lär dig snabbt när tekniken motiverar sin kostnad.
Kombinera inte tekniker utan eftertanke. Att kombinera CoT + självkritik + ToT + resonemangsmodell är sällan bättre än att välja rätt teknik. Varje lager ökar kostnaden; lägg bara till lager som verkligen förbättrar svaret på just din uppgift.
Ha teknikerna i ditt bibliotek. Snippets för ”med CoT”, ”med självkritik” och ”med ToT” – tillämpade på den aktuella uppgiften – sparar verklig tid jämfört med att skriva strukturen på nytt.
Slutsatsen
Tre tekniker. Var och en har sitt optimala användningsområde. Tankekedjor för linjära problem i flera steg. Självkritik för att upptäcka överdriven självsäkerhet. Tanketräd för problem med flera angreppssätt. Resonemangsmodeller ändrar kalkylen genom att göra de två första internt – men teknikerna spelar fortfarande roll, både för snabba modeller och som mönster du kan lägga ovanpå.
Använd rätt teknik för problemet. Hoppa över dem när de inte motiverar sin kostnad. Lär dig skillnaden mellan ”svårare problem” och ”annorlunda problem” – allt annat följer av den.
