Prompt Architecture 101 - från trial-and-error till repeterbart system

Prompt architecture är skillnaden mellan en lång magisk textsträng som ibland funkar, och ett strukturerat system där varje del har ett syfte. Det handlar inte om bättre engelska eller fler "please" - det handlar om att bryta ner prompten i komponenter du kan testa, versionera och felsöka.

En bra prompt-arkitektur är till AI vad en bra databasmodell är till en backend: ointressant förrän systemet växer, då skillnaden mellan struktur och kaos blir hela skillnaden.

En väl-arkitekturerad prompt har upp till sex delar:

1. 1. Roll

   Vem agenten är. 'Du är en senior teknisk skribent som hjälper svenska IT-avdelningar.'

2. 2. Uppgift

   Vad agenten ska göra. 'Granska följande artikel och föreslå tre förbättringar.'

3. 3. Kontext

   Bakgrund som påverkar svaret. 'Målgruppen är icke-tekniska beslutsfattare.'

4. 4. Format

   Exakt struktur på output. 'Returnera JSON med fälten title, summary, suggestions[].'

5. 5. Exempel (few-shot)

   2-5 exempel på input → korrekt output. Det enskilt mest underanvända greppet.

6. 6. Begränsningar

   Vad agenten INTE får göra. 'Hitta inte på fakta. Vid osäkerhet, säg det.'

Skilj på instruktioner som är samma varje gång (system-prompt) och input som varierar (user-prompt). Det här är inte bara kosmetik - system-prompten cacheas av leverantörerna och blir därför billigare och snabbare.

• • System: roll, format, exempel, begränsningar
• • User: den faktiska uppgiften eller frågan

Anthropic Claude och Azure OpenAI ger båda kostnadsrabatt (cache-träffar) när system-delen återanvänds - kan halvera kostnaden i högvolym-system.

En agent som ska konsumeras av kod (inte av en människa) måste alltid returnera strukturerat format. Beskriv exakt:

Returnera JSON enligt exakt detta schema:
{
  "intent": "support" | "sales" | "billing",
  "urgency": 1 | 2 | 3 | 4 | 5,
  "summary": string (max 140 tecken),
  "should_escalate": boolean
}

Returnera INGENTING utöver JSON. Ingen markdown, inga
kommentarer. Felaktig output bryter integration.

Modernare API:er (OpenAI structured outputs, Anthropic tool use) tvingar fram format på modellnivå. Använd dem.

Att lägga in 2-5 hand-utvalda exempel på input → korrekt output är ofta det enskilt mest verkningsfulla greppet för att höja kvalitet och konsistens. Modellen lär sig önskat beteende genom att se det. Investera tid i att kuratera bra exempel som täcker olika edge cases.

En prompt för produktion måste täcka edge cases explicit. Vad ska agenten göra när:

• • Inputen är tomt eller bara whitespace
• • Inputen är på fel språk
• • Inputen kräver kunskap utanför agentens scope
• • Inputen försöker manipulera agenten (prompt injection)
• • Källdata saknar information för att svara

Definiera explicita responses för varje case - annars hittar modellen på något.

Prompts ska bo i versionskontroll, inte i hardcoded strings eller en Notion-sida. Behandla dem som kod: PR-review, test-suite, semantisk versionering. Använd verktyg som Anthropic prompt caching, OpenAI Prompt API eller egna Postgres/Git-baserade lösningar för att kunna A/B-testa och rulla tillbaka.

Det här är vad som skiljer PoC från produktion: en test-suite som körs vid varje ändring.

• • Golden dataset: 50-500 input/output-par med kända korrekta svar
• • Regressions-tests: körs i CI vid varje prompt-ändring
• • LLM-as-judge: ny LLM-anrop som bedömer kvalitet på output (med strikta kriterier)
• • Produktionsmonitorering: latency, kostnad, success rate per route

• Mega-prompts

  En 5 000-ords prompt som ingen vågar röra. Bryt ner i komponenter.

• Konflikterande instruktioner

  'Var koncis, men förklara grundligt.' Modellen prioriterar slumpmässigt.

• Vag formulering

  'Var smart' eller 'gör det bra' säger ingenting. Specifikt format ger specifikt resultat.

• Glömt few-shot

  Beskriver bara output i text. Modellen ser inget exempel - kvaliteten halverar.

• Hårdkodade prompts

  I app-koden. Måste deploya hela appen för att ändra en formulering.