Hur jag låter ett AI-system kritisera sitt eget arbete
Det är lätt att bygga en AI-funktion som avslutar med instruktionen ”granska ditt svar en gång till”. Det ger ibland bättre text. Jag räknar det ändå inte som ett robust review-system.
Det är lätt att bygga en AI-funktion som avslutar med instruktionen ”granska ditt svar en gång till”. Det ger ibland bättre text. Jag räknar det ändå inte som ett robust review-system. Om samma agent både formulerar lösningen, väljer vad som är viktigt och bedömer om den själv lyckades, delar skapandet och kontrollen samma blinda fläckar.
I min contentfabrik blev den skillnaden tydlig. Writer får skriva från godkänd evidens. Fact Checker får ifrågasätta claims. Editor får förbättra prosa utan att ändra sakinnebörden. Publisher Gate får säga READY eller BLOCKED men får inte uppfinna det som saknas. Det är inte nio agenter för sakens skull. Det är separation mellan produktion och kontroll.
Självkritik är inte samma sak som kontroll
En enkel self-review är användbar för lokala problem: saknat steg, oklar formulering, fel format eller ett uppenbart motsägelsefullt svar. Jag använder den gärna innan ett resultat skickas vidare. Men den bör inte bära de dyraste besluten ensam.
Problemet är epistemiskt. En modell som precis skapade ett felaktigt antagande kan också bedöma det antagandet som rimligt. Därför försöker jag flytta viktiga kontroller från ”tyck om ditt eget svar” till kriterier som kan verifieras utifrån en annan referens: source ledger, schema, golden dataset, policy eller explicit acceptanskriterium.
Ge kritikern ett annat kontrakt
Det första jag ändrar är inte modellen utan rollen. Producenten får ett mål: skapa något. Kritikern får ett annat: hitta brott mot kontraktet. För en artikel kan kontrollen exempelvis vara:
Det gör reviewn falsifierbar. Fact Checker behöver inte avgöra om artikeln ”känns bra”. Den ska hitta specifika typer av fel.
Kritik måste ha testbara kriterier
Ju mer abstrakt reviewfrågan är, desto större risk att modellen bara producerar en välformulerad åsikt. Jag föredrar därför blandade graders. Vissa kontroller ska vara deterministiska: fil finns, JSON validerar, alla länkar har rätt format, state transition är tillåten. Andra kräver modellbedömning: motsvarar texten intent, är en reservation bortredigerad, finns verklig information gain?
OpenAI:s eval- och grader-gränssnitt speglar samma uppdelning: utvärdering kan göras med exakta string checks, likhetsmått eller model-based graders. Det viktiga är inte produkten i sig utan designprincipen: olika fel behöver olika bedömare.
När samma modell kan räcka
Jag använder inte automatiskt en dyrare eller annan modell som reviewer. Om uppgiften är låg risk och reviewkriteriet tydligt kan samma modell i en separat kontext vara tillräcklig. Separationen av kontext och instruktion gör ofta mer nytta än att bara byta modellnamn.
Jag eskalerar när felet är dyrt, när producenten och reviewern tenderar att dela samma bias eller när reviewn behöver annan information än producenten hade. Ett bra exempel är fact-checking: reviewern bör få source ledger och claim map, inte bara samma artikel och instruktionen ”var kritisk”.
När en separat reviewer behövs
Tre signaler får mig att separera kontrollen tydligare. För det första när output ska ut i världen: publicering, mejl, databaswrite eller ekonomiskt beslut. För det andra när fel kan se övertygande ut; faktafel i välskriven text är farligare än trasig JSON. För det tredje när jag vill kunna mäta felet över tid.
Därför blev Publisher Gate en egen roll. Den får inte skriva om artikeln. Om den hittar saknad evidens måste ärendet tillbaka uppströms. Annars kan gaten bli en andra Writer och hela separationen försvinner.
Gör kritik till data
En reviewer som bara säger ”förbättra tydligheten” lär mig nästan ingenting. Jag vill ha en felkod och ett reproducerbart exempel:
Då kan samma fel läggas till i evals och regressionstester. Det är där review börjar ge compound value: varje upptäckt fel kan bli ett test som nästa version måste klara.
Stoppa endless review loops
Multi-agent review har en egen risk: Writer ändrar, Reviewer invänder, Writer ändrar tillbaka och systemet bränner tokens utan att bli bättre. Jag sätter därför retry-budget per feltyp. Efter exempelvis två misslyckade försök ska systemet antingen blockera eller eskalera till människa. ”Försök igen tills det går” är inte en kontrollstrategi.
Ett annat skydd är ägarskap. Endast den stage som äger felet får lösa det. Fact Checker ska inte skriva om SEO. SEO-reviewern ska inte kvalificera juridiska claims. Gränserna gör både fel och kostnader mer observerbara.
Min praktiska reviewer-stack
Jag tänker numera i fyra nivåer: lokalt self-check, deterministisk validator, specialist-reviewer och slutlig publisher gate. Alla artiklar behöver inte alla nivåer, men risk avgör hur långt kedjan går. Det viktiga är att kritikern har något bättre än producentens magkänsla att jämföra med.
För mig är därför ”AI som kritiserar AI” inte en särskild magisk förmåga. Det är klassisk kvalitetssäkring översatt till probabilistiska system: separera ansvar, definiera feltyper, ge reviewern rätt evidens och gör resultaten mätbara. När det fungerar blir kritik inte ännu en prompt. Den blir en del av systemets testyta.