Promptteknik (prompt engineering)

Vad som faktiskt flyttar resultatet

Det mesta av vinsten kommer från ett fåtal oglamorösa grepp:

• Säg hur utdata ska se ut. "Returnera ett JSON-objekt med nycklarna title och steps" är värt mer än hur mycket artighet som helst. De flesta API:er stödjer dessutom ett schemastyrt läge, som är starkare än att be om det.
• Ge kontext i stället för att lita på minnet. Klistra in det faktiska dokumentet, det faktiska felmeddelandet, den faktiska koden. Det är den enskilt största förbättringen och det minskar även hallucinationer.
• Visa två eller tre exempel på indata och önskad utdata. Exempel förmedlar ton och gränsfall snabbare än ett stycke beskrivning.
• Ange begränsningarna och felfallet. Vad som ska göras när svaret inte finns i materialet, vad som ska utelämnas, vad som inte får hittas på.
• Dela upp arbetet. Ett modellanrop per beslut, kedjade, slår ett anrop som ombeds göra fem saker — och det ger dig någonstans att felsöka när det går snett.
• Lägg den avgörande instruktionen nära slutet av en lång prompt, där uppmärksamheten är starkast.

För allt du ska köra mer än ett par gånger: håll en liten uppsättning testindata och jämför promptversioner mot dem. Utan det gissar du, eftersom en ändring som fixar ett exempel rutinmässigt förstör två andra.

Vad du bör se upp med

Prompter är inte portabla, och de ersätter inte design. En prompt som trimmats mot en modell presterar ofta sämre på en annan; att byta modellversion är ett skäl att testa om, inte ett rakt utbyte. Nyare resonerande modeller har också gjort en del gamla trick meningslösa eller skadliga — att säga "tänk steg för steg" till en modell som redan resonerar internt kan vara ren störning, och utförliga rollspelsramar tillför sällan något utöver en rak, exakt instruktion.

Den bredare poängen: promptning kan inte lösa ett problem modellen faktiskt inte klarar. Behövs aktuell data, hämta den. Behövs en privat kodbas, skicka med den. Behövs ett fast beteende över tusentals anrop är finjustering eller programstruktur svaret. Att skriva om prompten en tolfte gång är hur man undviker att inse det.