Tre studerade mönster för promptning och sökning är tankekedjor (chain-of-thought), självkritik och tanketräd (tree-of-thoughts). Tankekedjor utvärderades i Wei et al., 2022 och tanketräd i Yao et al., 2023, på vissa bestämda modeller och riktmärken. De studierna belägger ingen allmängiltig förbättring för dagens modeller eller för uppgifter i en verksamhet. Behandla varje mönster som en hypotes att jämföra med en direkt prompt på din egen utvärderingsuppsättning.
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.
Prompterna begär mellanliggande struktur eller ytterligare omgångar. Mer synlig text eller fler anrop kan höja kostnaden utan att visa att det underliggande svaret är riktigt.
Tankekedjor (CoT)
Det ursprungliga mönstret ber modellen att generera mellanliggande resonemang före en slutsats. I ett verkligt arbetsflöde är det bättre att begära de verifierbara artefakter du faktiskt behöver – ekvationer, antaganden, citerade belägg, testutdata eller ett kortfattat beslutsunderlag – än att behandla fritt formulerad inre berättelse som belägg.
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.
Studien från 2022 rapporterade förbättringar på flera riktmärken för aritmetik, vardagsresonemang och symboliskt resonemang för tillräckligt stora modeller, med betydande variation mellan uppgifter och modeller. Överför inte de historiska resultaten till en aktuell modell, en annan prompt eller produktionsdata. Kör båda promptvarianterna och poängsätt både slutsvaret och de mellanliggande artefakter som går att kontrollera.
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.
En kritikomgång kan fånga vissa brister, men samma modell kan upprepa eller bortförklara samma fel. Behandla självkritik som ännu en felbar bedömare. Använd deterministiska kontroller, hämtade belägg, tester eller oberoende kvalificerad granskning när konsekvenserna motiverar det.
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.
Trädsökning är ett tänkbart val när ett problem har flera rimliga angreppssätt och arbetsflödet kan utvärdera delvägar. Att generera tre alternativ garanterar varken bredd eller att alternativen undviker ett gemensamt felaktigt antagande. Definiera utvärderingskriterier och spara underlaget för den väg du väljer.
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.
Stapla inte tekniker som standard. Jämför en direkt prompt, en enskild ställning och eventuella kombinerade varianter på samma fall. Behåll den enklaste versionen som klarar kriterierna för att gå i skarp drift.
Hur resonemangsmodeller ändrar hur du testar prompter
Modeller med resonemangsförmåga exponerar reglage och beteenden som skiljer sig mellan leverantörer och versioner. Modellnamn, avvecklingsdatum, resonemangsinställningar och hur mycket av det mellanliggande innehållet som visas förändras över tid. Utgå från leverantörens aktuella dokumentation i stället för från en fryst lista i en artikel.
Detta förändrar hur du bör prompta dem på tre viktiga sätt:
1. Börja med utfallet. Ange målet, viktig kontext, begränsningar, kraven på belägg och när uppgiften räknas som färdig. OpenAI:s aktuella promptvägledning för GPT-5.6 rekommenderar att du beskriver destinationen och prövar promptförenklingar på representativa uppgifter.
2. Verifiera resultatet, inte mängden resonemang. Mer resonemangsansträngning eller längre fördröjning är inget bevis för att svaret är riktigt. Kräv källhänvisningar, beräkningar, schemavalidering, tester eller andra belägg som passar uppgiften, och mät slutresultatet.
3. Jämför en direkt prompt med nödvändig struktur. Ta bort överflödiga instruktioner en grupp i taget, men behåll verkliga begränsningar och de utdataschemata som krävs. En kortare prompt är bättre bara när den fortfarande klarar samma utvärderingar.
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.”
Prompt B är en användbar utgångspunkt, men den utelämnar beslutskriterier, belägg, konsekvenser för berörda parter och en tydlig tröskel för när uppgiften är färdig. Jämför den med en kortfattad strukturerad prompt och poängsätt båda. Utse ingen vinnare enbart utifrån promptens längd.
Olika modeller och inställningar kan reagera olika på struktur. Spara prompterna tillsammans med modell/version och utvärderingsresultat, och testa om dem vid uppgraderingar.
Kostnad kontra nytta
Teknikerna kan lägga till genererade tokens, anrop och fördröjning. Det finns ingen överförbar multiplikator utan en fastställd modell, uppgift, prompt, resonemangsinställning och stoppvillkor:
| Teknik | Vad du ska mäta | Tänkbar användning |
|---|---|---|
| Begärt mellanliggande arbete | slutlig träffsäkerhet, artefakternas riktighet, tokens, fördröjning | uppgifter med mellanliggande artefakter som går att kontrollera |
| Självkritik | upptäckta brister, nya brister som införs, falsk säkerhet, kostnaden för andra omgången | revidering mot en uttalad bedömningsmall |
| Sökning i flera vägar | vägarnas bredd, bedömarens träffsäkerhet, totalt antal anrop, svansfördröjning | problem med genuint olika kandidatangreppssätt |
| Leverantörens resonemangsläge | andel klarade uppgifter per ansträngningsnivå, tokens, fördröjning, pris | bara där en högre ansträngningsnivå förbättrar utvärderingen inför release |
Använd en direkt prompt som utgångsläge. Lägg bara till en ställning eller en resonemangsinställning när den uppmätta kvalitetsförbättringen är värd den extra kostnaden och fördröjningen för just den uppgiften.
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 skapar ett tillfälle att hitta blinda fläckar – kontrollera om den faktiskt gjorde det.
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.
Prompten begär tre infallsvinklar. Kontrollera att de är sakligt olika och underbyggda, och inte omformuleringar av ett och samma antagande.
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.
Detta är det direkta utgångsläget. Det synliga svaret bevisar inte vilken inre process som ägde rum. Jämför dess riktighet, belägg, tokens och fördröjning med de strukturerade varianterna.
För svårt analytiskt arbete: utvärdera en aktuell modell med resonemangsförmåga och en direkt prompt som börjar med utfallet innan du lägger på struktur. Behåll bara en ställning när den förbättrar utvärderingen för uppgiften.
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 representativa fall med och utan tekniken efter relevanta ändringar av modell, prompt, data eller policy. Poängsätt mot en bedömningsmall – att utdata ser olika ut är inte i sig ett kvalitetsmått.
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.
Välj den teknik som är värd sin kostnad
Teknikerna är kandidater, inte garantier: mellanliggande artefakter för kontrollerbart arbete i flera steg, självkritik för en andra omgång mot en bedömningsmall, och sökning i flera vägar för problem med genuint olika angreppssätt. Modeller med resonemangsförmåga förändrar jämförelsen, så gör om utvärderingen i stället för att föra vidare gammal promptfolklore.
Använd rätt teknik för problemet. Hoppa över dem när de inte är värda sin kostnad. Skilj ”svårare problem” från ”annorlunda problem” – valet av teknik följer av det.
