Så kopplar jag varje faktapåstående till en primärkälla
När jag började faktagranska AI-content sparade jag länkar per artikel. Det var bättre än inga källor, men fortfarande för grovt. Fem länkar längst ned säger inte vilken källa som stödjer vilket påstående. Därför flyttade jag relationen från artikel → källor till claim → evidens.
När jag började faktagranska AI-content sparade jag länkar per artikel. Det var bättre än inga källor, men fortfarande för grovt. Fem länkar längst ned säger inte vilken källa som stödjer vilket påstående. Därför flyttade jag relationen från artikel → källor till claim → evidens.
Det låter som en datamodellsdetalj. I praktiken är det det som gör en stor contentbank möjlig att underhålla.
Bryt först ned texten i verifierbara claims
Första steget är att hitta materiella påståenden. Jag behöver inte skapa claim IDs för varje adjektiv. Jag vill fånga sådant som kan vara sant eller falskt och som påverkar läsarens förståelse: regler, belopp, datum, produktfunktioner, forskningsresultat och andra externa fakta.
En mening kan innehålla flera claims. Därför blir den först atomiserad:
Varje del kan då få egen evidens och freshness.
Primärkälla är en relation, inte en URL-lista
I min ledger vill jag minst spara:
support_scope är viktigt. Källan kanske bara stödjer en del av claimen. Utan det är det lätt att en korrekt URL ger en falsk känsla av verifiering.
En claim kan behöva flera källor
”En primärkälla per claim” är en bra default, men inte en lag. Vissa claims kombinerar exempelvis en officiell produktfunktion med ett eget benchmark. Då behöver de separeras eller bära två evidensobjekt med olika roller.
Jag vill hellre dela en claim än att gömma tre premisser bakom en citation.
Olika claims kräver olika auktoritet — och färre kan vara bättre än fler
Vilken typ av källa som duger beror på vilken typ av claim det är. Produktbeteende bör stödjas av aktuell leverantörsdokumentation, en rättsregel av ansvarig myndighet eller lagtext, och ett forskningsresultat av originalpapret. En sekundär guide kan vara bra för kontext men är en svag ensam grund för ett materiellt påstående.
Claims har också olika datumrisk. Ett historiskt faktum åldras sällan; ett API-beteende kan ändras imorgon. När en claim riskerar att bli inaktuell sparar jag därför källans eget datum separat från retrieved_at, inte bara det senare.
Det här får en praktisk konsekvens: om ett sidospår i artikeln bara kan bäras av en svag källa och inte behövs för sökintentionen, tar jag hellre bort sidospåret. Faktagranskning handlar inte om att maximera antalet referenser utan om att varje materiellt påstående ska bära sin egen vikt.
Spara exakt vad källan stöder
När source ledger byggs sparar jag en kort evidensnotering, inte bara sidans titel. Den ska kunna svara på: vilken del av källan använde vi och vad bevisar den faktiskt?
Det minskar risken att en framtida reviewer ser en auktoritativ domän och automatiskt antar att allt i stycket stöds där.
Kvalificering måste följa claimen
Verdict behöver fler lägen än TRUE/FALSE:
VERIFIEDQUALIFIEDUNRESOLVEDCONFLICTREMOVED
Om en regel bara gäller under vissa förutsättningar ska reservationen ligga i claim-objektet och följa med när texten återanvänds. Annars kan en senare Writer plocka själva huvudregeln men tappa undantaget.
När primärkälla saknas
Det finns områden där primärkälla inte är tillgänglig eller där frågan i sig gäller andrahandsanalys. Då ska systemet inte låtsas. Jag märker source type och sänker evidensstyrkan.
En trovärdig sekundärkälla kan vara användbar för kontext. Men om artikeln påstår något om en aktuell produktfunktion och leverantörens dokumentation finns, bör bloggen normalt inte vara enda stödet.
Rendera provenance i publicerad text
En intern ledger räcker inte om slutartikeln gör materiella externa claims utan synliga källor. Det var en konkret regression vi hittade i de första BijoyIQ-batcherna: Publisher Gate kunde säga READY trots att source ledger fanns men länkarna inte syntes i finaltexten.
Nu är synlig source rendering en gate. Det betyder inte att varje mening behöver en fotnot. Det betyder att läsaren ska kunna förstå var viktiga externa påståenden kommer ifrån.
Google lyfter både sourcing, first-hand expertise och originalinformation i sin people-first guidance. För mig är synlig provenance också enklare: den gör texten mer granskningsbar oavsett ranking.
Gör ändringar spårbara
Den stora vinsten kommer när en källa uppdateras. Eftersom relationen är claim-level kan jag söka:
Då blir uppdatering ett dependency-problem i stället för en manuell jakt genom hundratals artiklar.
Det är därför jag inte längre ser källhänvisningar som en redaktionell slutdetalj. De är en del av contentmodellens datalager. Texten är bara en rendering av claims vars evidensstatus redan ska vara känd.
Källor
Relaterade artiklar
- Jag genererade 220 artiklar med AI — här är problemet jag underskattade
- Så gör jag AI-text mindre mekanisk utan att lägga in medvetna fel
- Content generation vs content production — en viktig skillnad
- Hur jag hanterar regler, belopp och datum i AI-genererade artiklar
- Hur jag bygger en single source of truth för AI-genererat innehåll