Varför jag börjar med workflow innan jag väljer modell
När en ny modell släpps är det lätt att tänka att produktbeslutet börjar där: ska jag använda GPT, Claude eller Gemini? I praktiken har jag fått bättre resultat genom att skjuta på modellvalet. Jag börjar med att rita jobbet, statesen och felkostnaden. Först därefter väljer jag modell per steg.
När en ny modell släpps är det lätt att tänka att produktbeslutet börjar där: ska jag använda GPT, Claude eller Gemini? I praktiken har jag fått bättre resultat genom att skjuta på modellvalet. Jag börjar med att rita jobbet, statesen och felkostnaden. Först därefter väljer jag modell per steg.
Det låter som en liten metodskillnad. För mig har det förändrat både kostnad, arkitektur och hur lätt systemen går att byta ut senare.
"Vilken modell?" är ofta en för tidig fråga
Anta att jag bygger en AI-CV-coach. Om jag börjar med modellen riskerar jag att designa produkten efter vad modellen kan demonstrera: ett stort textfält, en lång systemprompt och ett genererat CV.
Om jag börjar med workflowet ser jobbet annorlunda ut:
Nu blir modellfrågan flera frågor. Behöver extraction samma modell som rewriting? Ska verifiering vara LLM-baserad alls? Vilka steg är deterministiska? Var krävs human approval? Det är ett bättre designunderlag.
Jag delar upp jobbet efter felkostnad
Varje steg får ungefär tre attribut:
- ambiguity – hur mycket språkligt/semantiskt resonemang krävs?
- verifiability – går resultatet att kontrollera automatiskt?
- impact – vad kostar ett fel?
En formatterare kan ha låg ambiguity, hög verifiability och låg impact. En investeringsanalys som väger konfliktande rapportdata har hög ambiguity och högre impact. De ska inte automatiskt få samma modell eller samma autonomy.
Det här leder till en enkel routingprincip:
Jag använder inte siffrorna som vetenskaplig scoring. De tvingar bara fram rätt frågor innan jag börjar benchmarka modeller.
Deterministiska steg ska inte kidnappas av LLM:n
En av de största kostnads- och kvalitetsvinsterna är att låta kod äga det kod är bra på.
Om en state transition kräver:
behöver jag inte fråga en frontier-modell "tycker du att artikeln känns redo?". Jag kan validera filerna och statusen deterministiskt.
Modellen kan fortfarande göra de kvalitativa bedömningarna inne i varje review. Men orkestreringen behöver inte vara probabilistisk. Det här minskar både kostnad och blast radius.
Workflowet visar var dyrare reasoning faktiskt behövs
I en stor prompt är det svårt att veta vilken del som kräver den starkaste modellen. När processen bryts ned blir det synligt.
I min contentfabrik kan research discovery ofta ske med relativt billig kapacitet, medan evidence audit av konfliktande källor kan motivera mer reasoning. Metadata- eller schema-kontroll bör vara script. Final prose behöver god språkkvalitet men inte nödvändigtvis samma tool access som Researcher. Det gör model routing konkret. Jag routar arbete, inte varumärken.
Benchmarks måste följa arbetssteget
Om jag vill jämföra två modeller testar jag dem på samma verkliga deljobb.
Exempel för en Evidence Auditor:
- upptäcker den att required first-hand evidence saknas?
- skiljer den mellan VERIFIED och QUALIFIED?
- stoppar den vid källkonflikt?
- hittar den på rimliga broar när evidensen saknas?
- hur mycket kostar 100 sådana reviews?
Det är mer användbart än att jämföra generella benchmarkpoäng eller fråga modellerna själva vilken som är bäst.
För Writer kan evalsetet i stället mäta fidelity, struktur, information gain och om nya claims introduceras. Modellvalet blir alltså ett resultat av lokala evals.
Vendor lock-in minskar när kontraktet är stabilt
Om all business logic ligger i en systemprompt som är fintrimmad för en viss modell blir modellbyte dyrt. Om workflowet har explicita inputs, outputs och pass/fail-villkor blir modellen mer utbytbar.
Jag vill kunna byta:
mot:
utan att Writer eller Publisher Gate behöver förstå skillnaden. Det här fungerar bara om agentens kontrakt är stabilt och evalsetet kan visa om bytet faktiskt blev bättre.
Kostnad är mer än pris per token
En billig modell kan bli dyr om den skapar fler retries, fler manuella reviews eller fler fel. En dyr modell kan vara billig på ett steg där ett enda misstag kostar mycket.
Jag försöker därför tänka i kostnad per godkänt arbetsresultat, inte bara input/output-pris.
Ett förenklat mått:
Jag behöver inte sätta exakt SEK-värde på allt. Måttet gör bara tydligt varför "billigast per miljon tokens" inte automatiskt är rätt val.
Permissions hör också till workflowet
Modellval och säkerhet blandas ofta ihop. En starkare modell ska inte få bredare permissions bara för att den är starkare.
OpenAI beskriver, i sin nuvarande vägledning om Codex-säkerhet, vikten av tydliga boundaries, approvals och telemetry för coding agents. Jag använder samma princip generellt: tool access kommer från arbetssteget.
Researcher kan browse/read. Writer behöver inte deploy. Publisher kan eventuellt få write/publish, men då bakom explicit gate. En modelluppgradering förändrar inte den behörighetsmodellen.
Human-in-the-loop placeras före modellvalet
Om ett steg kräver mänskligt godkännande på grund av risk bör det vara ett arkitekturkrav, inte något jag lägger till efter att modellen misslyckats.
I CV-flödet ska användaren godkänna materiella förändringar. I finansiell analys är KAN INTE BEDÖMA ett giltigt utfall. I content får saknad evidens stoppa publicering.
När det är definierat i workflowet kan jag därefter testa vilken modell som bäst minskar antalet onödiga eskaleringar utan att öka falska pass. Det är en mycket bättre optimeringsfråga än "vilken modell är smartast?".
Ett konkret modellagnostiskt kontrakt
För varje AI-steg vill jag kunna skriva något i stil med:
Först när det kontraktet finns benchmarkar jag modeller. Det är också en bättre grund för framtiden. Modeller ändras snabbt. Produktens jobb, risker och källor ändras långsammare.
När jag ändå väljer modell tidigt
Det finns undantag. Om en produktidé bygger på en unik capability — exempelvis en specifik multimodal input, mycket lång kontext eller ett visst tool ecosystem — kan runtime-valet påverka arkitekturen från början.
Men även då försöker jag definiera capability-kravet neutralt:
sedan väljer jag en modell som uppfyller det. Jag undviker formuleringen "produkten är byggd på modell X" när det egentligen är capabilityn jag behöver.
Workflow före modell är också ett organisationsval
Det här arbetssättet gör systemen lättare att förklara för andra. En kollega behöver inte förstå modellfamiljer för att förstå vilket steg systemet är i, vilken data som används, vem som får godkänna, vad som händer vid fel och vilka outputs som sparas.
Det gör AI-produkten mindre mystisk och mer lik vanlig systemdesign.
Källor
- OpenAI: Running Codex safely at OpenAI
- OpenAI: Introducing the Codex app
- Anthropic: Create custom subagents
Slutsats
Jag väljer inte modell först eftersom modellen är en implementation av ett arbetssteg, inte definitionen av produkten. När workflow, risk, validation och human gates är tydliga blir det mycket enklare att avgöra var en dyr modell behövs, var en billig räcker och var ingen LLM borde finnas alls.