Så skiljer du källbelagda påståenden från antaganden i AI-utkast

Ett källbelagt påstående i ett AI-utkast kommer från ett visst dokument, ett dataset eller en godkänd källa som du kan öppna och kontrollera direkt. Ett antagande är något som modellen har fyllt i för att källmaterialet inte sa det rakt ut. På sidan ser de likadana ut, och det svåra är att skilja dem åt innan en granskare godkänner texten.

Därför är de svåra att skilja åt i ett AI-utkast

Välskriven text är inte samma sak som text med källor, och när ett utkast flyter bra kan du inte veta vilket av dem du har framför dig. Får en modell en prompt skriven under tidspress avslutar den ofta meningen så att den låter som ett säkert svar, oavsett om underlaget stöder det eller inte. I den färdiga texten syns inte längre skillnaden mellan ”källan säger detta” och ”detta är en rimlig gissning”, och läsaren kan inte få tillbaka den i efterhand.

Det händer i alla verktyg, så fort tonen i ett utkast inte längre hänger ihop med underlaget bakom det. Risken bär bolaget som lämnar ifrån sig utkastet, eftersom kunden ser ett färdigt stycke och inte resonemanget bakom.

Vad som skiljer ett källbelagt påstående från ett antagande

Gå igenom varje påstående med de här kontrollerna innan det går till granskning.

Kontroll	Källbelagt påstående	Antagande
Kan du öppna källan?	Ja, det hänvisar till ett visst dokument eller dataset	Ingen källa, eller en vag hänvisning som ”branschdata”
Säger källan exakt detta?	Källan anger påståendet, inte något närliggande	Påståendet går längre än källan eller generaliserar utöver den
Är det markerat?	Visas som källbelagt, med källan bifogad	Visas som antagande, flaggat så att granskaren kan ta ställning

Den mittersta raden är den viktigaste kontrollen. En källa kan vara äkta och ändå bli uttänjd. En rapport som säger att användningen ökade i en region blir ett stycke längre ner ett påstående om att användningen ökade överallt. Källhänvisningen är äkta, men påståendet den nu sitter vid är inte det som rapporten sa.

Så ser ett korrekt flaggat antagande ut

Ett antagande är inget problem i sig. Varje utkast måste fylla luckor som källmaterialet inte täcker, och där hör bolagets egen bedömning ofta hemma. Problemet är ett antagande som ser ut som fakta, där granskaren inte kan se skillnaden utan att göra om researchen själv.

För att flagga ett antagande korrekt skriver du rakt ut vad som antas och varför, direkt vid påståendet, i stället för att gömma det i en fotnot eller låta det vara outtalat. ”Förutsatt att kundens nuvarande antal anställda ligger kvar under Q3” är en mening som en granskare kan godkänna, justera eller stryka på några sekunder. Om ett stycke i tysthet bygger vidare på samma antagande utan att nämna det måste granskaren rekonstruera resonemanget från början, och det tar längre tid än att skriva avsnittet själv.

Ett konkret exempel

Ta ett avsnitt om konkurrensbilden i ett utkast till en marknadsanalys. Källmaterialet är ett antal företagswebbplatser och två branschrapporter som teamet har godkänt för det här uppdraget.

Ett källbelagt påstående, korrekt skrivet: ”Enligt [Rapport X] har tre av de fem största leverantörerna i kategorin lanserat en mobilapp det senaste året.” Meningen anger källan och säger bara det som rapporten säger. En granskare kan öppna rapporten, hitta raden och gå vidare.

Ett antagande, korrekt skrivet: ”Förutsatt att mindre leverantörer följer samma mönster inom 12 till 18 månader, utifrån hur kategorin historiskt har tagit till sig nya funktioner.” Ingenting här presenteras som fakta från rapporten, eftersom det inte är det. Det är en prognos som teamet väljer att göra, och den kallas för vad den är.

Felet uppstår någonstans mittemellan. Säg att det i utkastet står ”marknaden rör sig snabbt mot produkter där mobilen kommer först”. Det låter säkrare än båda versionerna ovan, men det finns varken en källa eller ett uttalat antagande bakom. En läsare kommer att tro att det kommer från rapporten, och rapporten sa aldrig det. Det är den meningen som granskaren måste hitta, och den är lätt att missa när utkastet inte visar vilka rader som är källhänvisningar och vilka som är prognoser.

En snabb kontroll innan utkastet går till granskning

Gå igenom varje utkast som AI har hjälpt till med i den här ordningen innan det går till granskning:

Plocka ut varje specifikt påstående: en siffra, ett datum, ett namngivet faktum, en jämförelse.
Fråga för vart och ett om det går att spåra till en riktig källa som du kan öppna, eller om det fyller en lucka.
Kontrollera att källan faktiskt säger det som påståendet säger, och inte en närliggande eller bredare version av det.
Kontrollera att antagandena är markerade som antaganden i texten, och inte bara i ditt eget huvud som granskare.
Lös eller flagga allt som inte klarar steg 2 till 4 innan det når kunden.

Kontrollen går snabbt om utkastet togs fram med den i åtanke och långsamt om det inte gjorde det. När inget underlag finns bifogat måste granskaren göra det här ur minnet eller med en ny sökning, för varje påstående, varje gång. De flesta bolag betalar redan den kostnaden utan att sätta namn på den.

Var det här passar in i bolagets arbetssätt

Inget av detta ersätter granskning av en expert, men det ändrar vad granskaren gör. Om underlaget redan sitter vid varje påstående kontrollerar granskaren det. Får granskaren ett stycke utan källor blir jobbet att göra om researchen, med modellens självsäkra formuleringar framför sig och inte sina egna. Guiden om tillförlitligt kundarbete med AI beskriver hela flödet som det här ingår i: godkända källor in, synligt underlag hela vägen och granskning av en expert före leverans.

När ett bolag väl har ett sätt att granska som fungerar för en viss typ av leverans är det värt att göra det upprepbart, i stället för att bygga upp det från början vid nästa liknande brief. Det tar vi upp i artikeln om återanvändbara AI-arbetsflöden.