AI & automation

Reviewer agents: den enklaste kvalitetsförbättringen jag gjort

När jag började dela upp AI-flöden i specialistroller trodde jag att den stora vinsten skulle komma från bättre producenter. I praktiken kom en oproportionerligt stor del av kvaliteten från något enklare: en separat reviewer med rätt att säga nej.

Shadip Rahman 16 oktober 2026 4 min läsning
Dela
Informationsgrafik där Reviewer agents består av Varför jag separerade producent och granskare, Reviewern behöver en rubric, inte en magkänsla, En bra reviewer producerar felkoder.

När jag började dela upp AI-flöden i specialistroller trodde jag att den stora vinsten skulle komma från bättre producenter. I praktiken kom en oproportionerligt stor del av kvaliteten från något enklare: en separat reviewer med rätt att säga nej.

Varför jag separerade producent och granskare

Det största lyftet i mina agentflöden kom inte från ännu en bättre skrivprompt. Det kom när jag slutade låta samma körning både producera och godkänna sitt eget arbete. När Writer dessutom är Reviewer uppstår ett märkligt incitament: modellen känner redan till sina formuleringar, sin argumentation och sina antaganden. Den tenderar därför att försvara konstruktionen snarare än att leta efter ett konkret brott mot ett krav. Jag började i stället behandla reviewer-rollen som en separat produktkomponent med ett mycket smalare mandat.

Reviewern behöver en rubric, inte en magkänsla

"Granska kvaliteten" är nästan lika vagt som "skriv bättre". I min contentfabrik får varje reviewer därför en begränsad fråga. Fact Checker bedömer claims och evidens. SEO Reviewer bedömer intent, titlar, metadata och sökbar struktur. Internal-Link Reviewer arbetar bara mot en godkänd inventory. Publisher Gate kontrollerar att alla hårda kontrakt är uppfyllda. Ingen av dem får belöning för att vara snäll mot draften. Det ligger nära hur moderna evalsystem byggs: definiera kriterier och datakälla, kör graders och analysera utfallet i stället för att be om ett allmänt kvalitetsomdöme.

En bra reviewer producerar felkoder

Jag vill hellre ha UNSUPPORTED_CLAIM, MISSING_SOURCE, INTENT_DRIFT och DUPLICATE_SECTION än tre stycken välformulerad kritik. Felkoden gör två saker: beslutet blir maskinläsbart, och jag kan senare räkna vilka fel som faktiskt återkommer. Det gör reviewer-steget till en sensor i systemet. Om samma fel dyker upp i tio artiklar ska jag inte bara låta reviewern fortsätta hitta det; jag ska flytta kontrollen uppströms till briefen, researchern eller writern.

Reviewers ska inte skriva om allt

En vanlig anti-pattern är att reviewern svarar med en helt ny artikel. Då tappar jag provenance: jag vet inte längre vilka delar som passerade review och vilka som introducerades efter granskningen. Min regel är därför att reviewern markerar fel, föreslår minsta nödvändiga ändring och skickar tillbaka uppgiften till rätt ägare. Fact Checker kan kräva rewrite, men Writer gör den. Publisher Gate kan blockera, men får inte trolla fram evidens.

LLM-as-judge är användbart men inte sanningen

Automatiska graders är praktiska för volym och regressioner. OpenAI använder både expertgraderare och automatiserade graders i sina evalupplägg och beskriver automatiserade bedömningar som ett komplement, inte en perfekt ersättare för expertbedömning. Jag använder samma princip: en reviewer-agent kan skala kontroller som struktur, policy, coverage och matchning mot rubric. Den får inte göra en subjektiv kvalitetsbedömning till objektiv sanning bara för att svaret levereras som JSON.

Min minimala reviewer-arkitektur

För ett nytt workflow börjar jag med en enda reviewer efter producenten. Den får tre till fem explicita kriterier, ett begränsat output-schema och ett tydligt beslut: PASS, REVISE eller BLOCK. Först när jag kan visa att flera felklasser behöver olika kontext delar jag upp den i specialistreviewers. Det är viktigt: multi-agent är inte ett mål. Separation är värdefull när den gör ansvar, mätning eller kontext bättre.

Vad jag mäter efteråt

Jag följer inte bara pass rate. Jag vill veta false passes, false blocks, vilka felkoder som dominerar, hur många revisioner som behövs och hur ofta en människa överprövar reviewern. Om reviewern nästan alltid säger PASS har den sannolikt för svag rubric. Om den blockerar allt har jag antingen satt kriterierna fel eller lagt kontrollen för sent i flödet. Den enklaste kvalitetsförbättringen var alltså inte "lägg till en reviewer". Det var att göra granskningen till ett explicit, mätbart kontrakt.

Källor

Relaterade artiklar

AI-agenterPraktisk AI
Dela