Prompten som ingen vågar röra

Prompten började som fyra meningar. ”Du är en hjälpsam assistent för Acmes kundtjänst. Svara kort och vänligt. Använd bara informationen nedan. Om du inte vet, säg det.”

Nu är den tre sidor lång. Den har en mening om rabatter som lades till efter en incident i mars. En om att aldrig nämna en viss konkurrent. Ett stycke på versaler som börjar med ”VIKTIGT”. Två instruktioner som säger emot varandra om hur långa svaren ska vara. Och längst ner står det: ”Glöm inte pingvinerna.” Ingen vet varför. Ingen vågar ta bort det.

Prompten fungerar. Ingen vet riktigt varför. Och därför vågar ingen röra den.

Vad är en prompt, egentligen?

En prompt är instruktionerna AI-modellen får innan den svarar: vem den är, vad den ska göra, vilket underlag den har och hur svaret ska se ut. Den är skriven på vanligt språk, men den styr systemets beteende lika mycket som vilken kod som helst.

Det är det viktiga att förstå. En ändring i prompten är en ändring i produkten. Den ska behandlas som kod: sparas med historik, granskas och testas innan den går ut.

Varför blir prompter röriga?

För att varje problem lagas med en ny mening, och ingen mening tas bort. Det är ett naturligt mönster, och det leder alltid till samma ställe:

• Motsägelser. ”Svara kort” i början och ”förklara utförligt” längre ner. Modellen gör sitt bästa, och svaren blir oförutsägbara.
• Versaler som slutar fungera. När allt är VIKTIGT är inget viktigt.
• Gamla lappar. En regel som lade till en fix för en äldre modell kan göra mer skada än nytta med den nya.
• Rädsla. Utan tester går det inte att veta vad en rad gör, så den får stå kvar.

Hur gör man en prompt säker att ändra?

Med tre vanor. Ingen av dem kräver nya verktyg.

1. Spara prompten där koden finns

Lägg prompten i samma kodförråd som koden som använder den. Då får ni automatiskt det som behövs: historik över varje ändring, vem som gjorde den och varför, och möjligheten att granska ändringen innan den går ut.

Ge varje version ett nummer. När något går fel kan ni då säga ”det började med version 14”, i stället för ”någon gång förra veckan”.

2. Testa före och efter varje ändring

Kör samma testfrågor före och efter, och titta på de svar som blev sämre. Det är hela metoden från Ert första test av AI-svaren, och det är den som gör att prompten slutar vara farlig.

Med tester kan ni ställa frågan ”vad gör den här raden?” och få ett svar: ta bort den, kör testerna, se vad som händer.

3. En ändring i taget

Ändra en sak, testa, spara. Om ni ändrar fem saker samtidigt och resultatet blir sämre vet ni inte vilken av dem det var. Det känns långsammare, men det går fortare än att felsöka fem ändringar på en gång.

Hur städar man en prompt som redan är rörig?

Med tester på plats går det att städa, och det brukar göra både svaren och kostnaden bättre. Gör så här:

1. Kör testerna och spara resultatet som utgångsläge.
2. Ta bort en rad, eller slå ihop två som säger samma sak.
3. Kör testerna igen. Blev inget sämre? Då behövdes raden inte. Blev något sämre? Lägg tillbaka den och skriv en kommentar om varför den finns.
4. Upprepa tills varje rad har ett skäl.

Ja, det gäller pingvinraden också. Om testerna inte märker att den försvinner, behövdes den inte.

Ersätt versaler med tydlighet. ”Om kunden frågar om rabatter: hänvisa till kampanjsidan, lova aldrig en rabatt” fungerar bättre än ”NÄMN ALDRIG RABATTER!!!”.

Och flytta regler som måste hålla till koden. Om assistenten aldrig får lova en rabatt är det säkrare att kontrollera svaret i koden än att bara be modellen låta bli. Mer om det i När AI:n har fel.

Vem får ändra prompten?

Alla som förstår verksamheten bör kunna föreslå ändringar. Men en ändring ska gå samma väg som annan kod: ett förslag, testerna körs, någon granskar, sedan går den ut.

Om personer utanför utvecklingsteamet, till exempel kundtjänst, ska kunna ändra prompten, ge dem ett enkelt sätt att föreslå ändringar som ändå passerar testerna. Ett textfält i ett adminverktyg där ändringen går direkt ut är bekvämt, men det är också en väg runt allt som gör prompten säker.

Hur versionerade prompter hanteras i ett större system, med en hash av varje version i loggen, beskrivs i A reference architecture for LLM systems in production på engelska.