Att generera 220 artiklar är enkelt. Att verifiera dem är det svåra.
Jag har redan skrivit om ögonblicket då 220 AI-artiklar blev 2 051 faktapåståenden att kontrollera. Den här artikeln handlar om nästa problem: vad gör man när skrivmaskinen producerar snabbare än verifieringssystemet kan konsumera?
Jag har redan skrivit om ögonblicket då 220 AI-artiklar blev 2 051 faktapåståenden att kontrollera. Den här artikeln handlar om nästa problem: vad gör man när skrivmaskinen producerar snabbare än verifieringssystemet kan konsumera?
Det är en annan flaskhals. Om en modell kan skapa tio utkast på den tid en människa verifierar ett enda regelpåstående är fler writers inte lösningen. Då behöver produktionen styras av evidenskapacitet.
När skrivkapaciteten blir större än verifieringskapaciteten
Jag tänker numera på contentpipeline som två kapaciteter:
Om den första accelererar och den andra står still byggs en kö av osäker text. Det kan se ut som produktivitet i dashboarden eftersom antalet drafts ökar. I verkligheten växer work-in-progress och publiceringsrisken.
Därför vill jag hellre begränsa nya drafts än skapa ett lager på 500 texter som ingen har hunnit verifiera.
Mät claims per artikel
Artiklar är dålig kapacitetsenhet. En 2 000-ordstext om en tidlös arbetsmetod kan ha fem materiella externa claims. En 800-ordstext om migrationsregler, priser eller modellfunktioner kan ha trettio.
Jag räknar därför verifieringsarbete på claimnivå och märker claim_type. Exempel:
Det gör att två artiklar med samma ordlängd kan få helt olika QA-budget.
Riskprioritera verifieringskön
FIFO är enkelt men inte alltid rätt. Jag prioriterar först claims som både är materiella och tidskänsliga. Ett felaktigt datum eller myndighetskrav kan ändra artikelns slutsats. Ett mindre bakgrundspåstående kan vänta.
En praktisk prioritet kan beräknas från impact, freshness och source uncertainty. Jag behöver inte låta LLM:n hitta på en exakt sannolikhet; modellen kan klassificera dimensionerna och ett deterministiskt system kan sedan ordna kön.
Verifiera en gång, återanvänd evidensen
Nästa stora effekt kommer när samma claim används i flera artiklar. Jag vill inte verifiera samma regel tio gånger som tio separata copy-paste-uppgifter. Claim och source ska vara egna objekt som flera artiklar kan referera till.
Det är därför source ledger och single source of truth blir viktigare än fotnoter. När en källa ändras kan jag hitta alla beroende claims och artiklar.
Freshness skapar återkommande arbete
Verifiering är inte bara en publiceringskostnad. Vissa claims förfaller. Produktpriser, API-beteenden, lagar, myndighetsregler och aktuella modellfeatures behöver en freshness policy.
Jag kan exempelvis ange:
Det betyder inte att allt ska kollas varje vecka. Det betyder att systemet vet vilka delar av corpus som är känsliga för förändring.
Blockera throughput som saknar QA-kapacitet
Den viktigaste produktionsregeln är därför obekväm: om verifieringskön växer för snabbt ska writer-kapaciteten strypas. Det är motsatsen till hur många AI-content demos säljs, men det är nödvändigt om READY ska betyda publicerbar.
Google säger uttryckligen att generativ AI kan vara användbar för research och struktur, men att massproduktion utan mervärde kan bryta mot scaled-content-policy. För mig är det ännu ett argument för att mäta publicerbar kvalitet i stället för antal genererade sidor.
Min produktionsregel
Jag skulle hellre ha:
än:
Det första systemet har låg WIP och tydlig sanningsstatus. Det andra har mycket text men dålig kontroll över vad som faktiskt går att stå för.
Så när AI gör skrivandet billigt flyttar jag flaskhalsen medvetet till verifiering. Det är där kvalitetsbudgeten ska ligga. Den mest värdefulla optimeringen är då inte ”skriv snabbare”, utan att återanvända evidens, prioritera rätt claims och stoppa produktionen innan osäker text blir teknisk skuld.