AI-researchassistenter har brug for et kildespor – ikke kun kildehenvisninger

AI-researchassistenter var nemme at sælge ind, da fortællingen handlede om hastighed. Bed om en konkurrentanalyse, en indholdsdisposition eller en markedsbrief, og få noget anvendeligt tilbage på få minutter. Problemet viste sig lige så hurtigt. Hvis modellen leverede et gennemarbejdet svar uden et dokumentationsspor, der kunne efterprøves, stod dit team stadig med den samme beslutning: stole på det, kontrollere det igen eller undlade at bruge det til noget vigtigt.

OpenAI’s aktuelle dokumentation ændrer det regnestykke. Når svar baseret på websøgning kan indeholde indlejrede kildehenvisninger og en komplet liste over de URL'er, der er konsulteret, handler samtalen ikke længere kun om promptkvalitet. Den bliver et operationelt spørgsmål om styring af kilder.

Det har betydning i praksis. Modellen finder, sammenfatter og formulerer stadig indhold, men forretningsrisikoen flytter sig til noget mere konkret: Hvilke kilder måtte den bruge, hvilke brugte den faktisk, hvor synlige skal kildehenvisningerne være, og hvilken kontrol skal der foretages, før et svar bliver til publiceret indhold eller en anbefaling til en kunde?

Hvad har ændret sig i praksis?

Guiden til websøgning introducerer to styringsmuligheder, der er mere nyttige, end de umiddelbart lyder. Svar, der anvender websøgning, kan indeholde indlejrede kildehenvisninger, og feltet sources kan returnere den komplette liste over URL'er, der blev konsulteret under søgningen. OpenAI skelner tydeligt mellem de to. Indlejrede kildehenvisninger viser de mest relevante referencer. web_search_call.action.sources kan synliggøre det bredere dokumentationsspor bag svaret.

For teams, der udfører reelt kommercielt arbejde, er den forskel vigtig. Nogle få synlige kildehenvisninger kan være tilstrækkelige for en læser. De er som regel ikke nok for en redaktør, strateg eller kundeansvarlig, der skal forstå, hvad modellen faktisk baserede sig på, før en brief tages i brug.

Den samme guide beskriver også filtrering på domæneniveau via allowed_domains og blocked_domains. Det gør kildepolitikken til konfiguration frem for ønsketænkning i en prompt. Hvis en arbejdsgang skal begrænses til officiel dokumentation, godkendte udgivere, domæner leveret af kunden eller en kvalitetssikret researchliste, kan det håndhæves direkte. Hvis der er domæner, som dit team ikke ønsker skal optræde i en kommerciel leverance, kan de også udelukkes på værktøjsniveau.

Det er den egentlige forandring. Kildebaseret AI-research handler ikke længere kun om at bede modellen om at være omhyggelig. Det er ved at blive en implementeringsopgave med regler, grænser og kontrolpunkter.

Guiden til formatering af kildehenvisninger fører den samme tanke videre. Den anbefalede arbejdsgang begynder med at definere, hvad modellen må henvise til, præsentere kildematerialet tydeligt, fastlægge formatet for kildehenvisninger, fortælle modellen, hvornår de er påkrævet, og efterfølgende parse dem i systemet. Guiden anbefaler også kildehenvisninger på blokniveau som et stærkt standardvalg i mange tilfælde, fordi de giver en praktisk balance mellem præcision og enkelhed.

Det er en nyttig måde at anskue det på. Kvaliteten af kildehenvisningerne er ikke noget, man tilføjer til sidst for at få et svar til at virke mere troværdigt. Den er en del af systemdesignet. Du beslutter, hvordan dokumentationen kommer ind i arbejdsgangen, og hvordan den senere skal kontrolleres.

Den samme guide skelner desuden mellem to driftsformer. Hvis du bruger værktøjer hostet af OpenAI, såsom websøgning, er automatiske indlejrede kildehenvisninger tilgængelige. Hvis du stiller dit eget kildemateriale til rådighed, skal du selv definere de enheder, der kan henvises til, og syntaksen for kildehenvisningerne. For bureauer og operationelle teams er den forskel vigtig. Research på det offentlige web og internt kildemateriale bør ikke behandles ens, men de skal stadig passe ind i én sammenhængende governancemodel.

Prompting er nu en del af produktionsinfrastrukturen

Guiden til prompt engineering fremhæver et punkt, som mange teams stadig tager for let på: Prompts til produktion bør ligge i applikationskoden tæt på den funktion, de understøtter, med typede inputs, tests og evalueringstjek. Det er ikke kun en præference for implementeringen. Det er sådan, en prompt går fra at være en skrøbelig instruktionsblok til at fungere som en kontrolleret forretningsproces.

Hvis din researchassistent udarbejder SEO-briefs, salgsforberedelse eller markedsoversigter, bør reglerne for kildehåndtering versionsstyres, gennemgås og implementeres på samme måde som anden vigtig applikationslogik. Ellers kan arbejdsgangen se stabil ud, mens kravene til dokumentation stille og roligt ændrer sig over tid.

Guiden er også tydelig om developer-meddelelsens rolle. Her skal applikationens regler og forretningslogik placeres før user-meddelelsen. I dette tilfælde betyder det, at kildebegrænsninger, krav til kildehenvisninger, outputstruktur, eskaleringsregler og markeringer til kontrol hører hjemme dér. Guidens struktur med identitet, instruktioner, eksempler og kontekst er nyttig, fordi den giver teams en enkel måde at definere, hvad assistenten er beregnet til, hvad den ikke må gøre, og hvilket materiale den må basere sig på.

OpenAI bemærker lige så vigtigt, at tilføjet kontekst kan bruges til at begrænse modellen til et bestemt sæt ressourcer. Det er kernen i styret research. Du beder ikke kun om et bedre svar. Du former det dokumentationsgrundlag, som svaret må bygge på.

Anbefalingen om at bruge repræsentative fixtures, tests og evalueringstjek, før produktionsprompts ændres, er også relevant her. Det giver teams en praktisk måde at kontrollere, at kildepolitikken stadig overholdes efter ændringer, i stedet for blot at antage, at intet er gået i stykker.

For længerevarende agentiske arbejdsgange bliver den samme vejledning endnu mere relevant. OpenAI anbefaler at planlægge opgaver grundigt, bruge indledninger ved større beslutninger om værktøjer og følge arbejdsgangens fremdrift med en TODO-mekanisme. Det passer godt til researchpipelines. Hvis en assistent skal søge, filtrere, sammenfatte, udarbejde et udkast og aflevere det videre, er et sporbart forløb langt mere nyttigt end et enkelt poleret afsnit uden synlig dokumentation for arbejdet.

Hvorfor modelvalget har betydning for governance

Guiden til best practices for reasoning tilføjer endnu et lag: design af arbejdsgangen. OpenAI beskriver reasoning-modeller som planlæggere og GPT-modeller som arbejdsheste og skriver, at mange AI-systemer vil bruge begge dele. For researchassistenter er det et praktisk mønster. En reasoning-model kan opdele spørgsmålet, afgøre, hvilken dokumentation der er nødvendig, og håndtere tvetydighed. En GPT-model kan derefter udføre skrivearbejdet hurtigt og konsekvent.

Det er vigtigt, fordi styring af kilder sjældent er en enkeltstående opgave. Nogen eller noget skal afgøre, om en forespørgsel er bred eller snæver, om domænelisten skal være stram eller åben, om modstridende dokumentation skal fremhæves, og om resultatet er klar til publicering eller først skal sendes til kontrol.

Den samme guide anbefaler også at holde prompts enkle og direkte, bruge afgrænsningstegn for at skabe tydelighed og anvende eksplicitte begrænsninger, når der er behov for strammere kontrol. Det er en nyttig påmindelse. Governanceinstruktioner skal være velovervejede, men de behøver ikke at blive oppustede eller teatralske for at virke.

En praktisk model for implementering

Hvis du vil implementere dette seriøst, er modellen forholdsvis enkel:

Definér godkendte kildegrænser for hver arbejdsgang, herunder allowlists og blocklists, hvor det er nødvendigt.
Brug websøgning, når der er behov for aktuel research, og gem både svaret og det komplette sources-output.
Kræv indlejrede kildehenvisninger eller brugerdefinerede markører afhængigt af, om assistenten anvender hostede værktøjer eller indsat materiale.
Versionsstyr promptregler i kode, og brug fixtures og evalueringstjek før udrulning.
Send output til udkast- eller kontrolkøer i stedet for at betragte et svar med kildehenvisninger som automatisk klar til publicering.

Det, denne model ikke forudsætter, er lige så vigtigt. Kildehenvisninger gør ikke i sig selv et svar sikkert. En hurtig opsummering er ikke det samme som en gennemgået brief. Og ikke alle arbejdsgange har brug for den samme kildepolitik. En assistent til salgsresearch, en assistent til SEO-indhold og en intern strategiassistent kan alle bruge lignende modeller, men som udgangspunkt bør de ikke have de samme kildegrænser, den samme detaljeringsgrad i kildehenvisningerne eller de samme tærskler for godkendelse.

Derfor er begrebet kildestyring nyttigt. Dokumentationen understøtter nu en troværdig implementeringsmodel: kildebegrænsninger på værktøjsniveau, adfærd for kildehenvisninger på outputniveau, promptregler i kode og orkestrering af modeller til arbejde i flere trin. Derfra kan et bureau eller et operationelt team tilføje de forretningsmæssige kontrolmekanismer, som dokumentationen ikke definerer for dem, eksempelvis menneskelig kontrol, køhåndtering, godkendelsesstatusser eller regler for overdragelse til et CMS.

Det er her, GrN kommer ind i billedet. Greg kan hjælpe med at bygge researchassistenter, der begrænser kilder, formaterer kildehenvisninger, bevarer anvendelige revisionsspor og sender output videre til arbejdsgange for udarbejdelse eller kontrol. Resultatet er ikke kun hurtigere research. Det er en proces, som salgs-, SEO- og indholdsteams kan efterprøve, før de bruger resultatet kommercielt.

Har du brug for hjælp til denne type opgave?

Planlæg en styret arbejdsgang til AI-research Kontakt Greg.

Kilder

Sidst ændret

2026-08-25