Bakom en automatisk nyhetsbevakning finns många små beslut. Här berättar jag om erfarenheterna från Nirvana AI och ett möjligt arbetsflöde i TypeScript och Trigger.dev.
En av anledningarna till att vi började bygga Nirvana AI var att vi ville göra mer än att hitta nyhetsartiklar. Vi ville kunna sortera dem efter ämne och relevans och göra dem användbara för människor med olika informationsbehov.
En demonstration är ganska lätt att få till. En språkmodell läser fem artiklar och skriver fem bra sammanfattningar. Utmaningen kommer när kedjan ska fungera om och om igen, även när källor ändras, artiklar saknar metadata och samma nyhet hittas tio gånger.
Vad menar jag med en bakgrundsagent?
I praktiken är det ofta ett ganska vanligt program som körs automatiskt utan att du behöver starta varje steg. En schemaläggare sätter igång flödet, olika funktioner utför sina uppgifter och resultatet sparas eller skickas vidare. Det är inte nödvändigt att en AI-modell får bestämma allt.
Ett arbetsflöde i sex steg
- Sök: kör ett antal definierade sökningar mot källor eller API:er som du får använda.
- Samla in: spara rubrik, länk, källa, datum och textutdrag eller fulltext där rättigheterna tillåter det.
- Normalisera: omvandla resultat från olika källor till samma format och identifiera dubbletter.
- Klassificera: bedöm varje artikel utifrån en definierad uppgift eller ett ämne, gärna med möjlighet att flagga osäkra fall.
- Spara: behåll strukturerade uppgifter och källhänvisningar så att samma analys kan granskas och upprepas.
- Leverera: skapa en lista, ett kalkylark eller en sammanställning och granska slutsatserna innan de används externt.
TypeScript och Trigger.dev räcker långt
En sådan kedja går exempelvis att bygga i TypeScript, med en databas för lagring och Trigger.dev för schemalagda bakgrundskörningar. Trigger.dev kan hantera återförsök och mer långvariga uppgifter. Det här är ett exempel på en möjlig teknikstack, inte en fullständig specifikation av varje del i vår egen Nirvana AI-miljö.
Jag skulle börja i datastrukturen. En artikelpost behöver ett stabilt id, källa, URL, publiceringsdatum, titel, författare när den finns och ett fält för klassificeringsresultatet. Skilj alltid det som kommer från källan från det modellen har dragit för slutsats.
Undvik att använda AI där vanlig programkod gör jobbet bättre. Datumjämförelser, URL-normalisering, dubblettkontroll och CSV-export bör i regel vara deterministiska steg.
Varför en generell språkmodell inte alltid är bästa klassificeraren
Det är frestande att be samma språkmodell söka, bedöma, sammanfatta och skriva rapporten. Men när flödet ska köras på tusentals artiklar blir kostnad, variation och kvalitetssäkring viktiga. Modeller ändras. En enda förändrad prompt kan påverka vilka artiklar som godkänns.
Dessutom är relevans inte alltid ja eller nej. Ett enskilt ämne kan ligga i bakgrunden till en nyhet eller vara centralt utan att de förväntade sökorden förekommer. Du behöver kunna mäta både hur mycket brus som filtreras bort och vad modellen riskerar att missa.
Därför experimenterar vi med mindre och lokala modeller
Vi använder också lokala modeller och särskilda bearbetningssteg i andra arbetsflöden, bland annat inom transkription. Det har gjort mig mer intresserad av att separera sökning, klassificering och textgenerering. De har olika krav och behöver inte lösas av samma modell.
En liten modell är inte automatiskt bättre; den måste utvärderas mot ett mänskligt granskat material och jämföras med alternativen. Men om uppgiften är att fatta många liknande relevansbeslut kan en specialiserad klassificerare vara intressant.
Ur det arbetet har vi också utvecklat och delvis tränat en egen klassificerare för våra nyhetsflöden. Den är användbar som utgångspunkt, men det vore ett misstag att anta att den utan vidare förstår vad som är relevant för en helt annan byrås kunder. Därför behöver vi testa den med externa uppdrag och få återkoppling på både rätt träffar och sådant vi missar.
Heartspace har samtidigt valt att fokusera byråverksamheten på branschförbund. Jag vill ändå gärna fortsätta utveckla verktyg som fler PR-konsulter kan använda. I den sista artikeln berättar jag hur vi tänker kring designpartners, möjlig öppen källkod och ett framtida gränssnitt eller API.
Det är precis vad vi nu testar. I fjärde delen visar jag hur ett fristående klassificeringslager kan göra mediedata mer användbar. Vill du börja utan kod, läs guiden om bevakning i ChatGPT och Claude.