Navnekonsistens – når modellen tror du er tre selskaper

Modellen tror kanskje du er tre forskjellige selskaper

En AI-modell prøver å knytte det den leser til én entitet – en spesifikk virksomhet, med en spesifikk historie og et spesifikt sett egenskaper. Den gjør det ved å lete etter signaler om at flere tekstbiter faktisk handler om samme ting. Skrives navnet ditt fire forskjellige måter på fire forskjellige steder, uten noen eksplisitt kobling mellom dem, har ikke modellen noen garanti for at «Citation Lab AS», «CitationLab», «Citation Lab» og «CL» er én og samme virksomhet. Den kan like gjerne lese det som tre eller fire svakere entiteter, hver med sin egen, tynnere brøkdel av den totale autoriteten – og ingen av dem sterke nok til å bli anbefalt foran en konkurrent med ett, konsekvent navn.

Hvor navnevariantene faktisk oppstår

Ingen bestemmer seg for å splitte entiteten sin med vilje. Variantene sniker seg inn fordi ulike deler av en virksomhets digitale fotavtrykk settes opp av ulike personer, på ulike tidspunkt, uten at noen ser dem samlet i etterkant.

Ingen av kildene i tabellen over er feil isolert sett. Problemet oppstår først når ingen av dem er eksplisitt koblet til de andre – da står de som fem ubesvarte spørsmål i stedet for fem bekreftelser på samme svar.

Én kanonisk form, kontrollerte alias: sameAs og alternateName

Løsningen er verken å tvinge frem identisk ordlyd overalt (juridiske navn og markedsføringsnavn har ulike formål og bør få lov til å avvike) eller å ignorere variantene og håpe modellen finner ut av det selv. Løsningen er å velge én kanonisk form – typisk merkenavnet, ikke det fulle juridiske navnet – og deklarere resten eksplisitt som kjente varianter av akkurat den entiteten.

Teknisk gjøres dette med to egenskaper i schema.org-markeringen for organisasjonen: alternateName lister alternative navn (forkortelser, tidligere navn) entiteten er kjent under, mens sameAs peker til andre autoritative profiler av samme entitet – Wikidata, Wikipedia, LinkedIn-siden, Brønnøysundregisteret. Sammen sier de: «disse strengene og disse profilene er alle den samme, ene entiteten», i stedet for å overlate koblingen til gjetning.

Brønnøysund og Wikidata: de sterkeste ankrene i Norge

Ikke alle kilder veier likt i den vurderingen. En påstand på egen nettside er lett å skrive og like lett å ignorere. Et strukturert, offentlig register er noe annet: Brønnøysundregisteret gir et verifisert organisasjonsnummer og registrert navn som ikke er selvpublisert av virksomheten selv, og Wikidata gir en strukturert, maskinlesbar post som mange kunnskapsgrafer allerede henter fra. Begge er nettopp den typen ankre en modell – eller systemet bak den – kan krysssjekke andre kilder mot, og de bør stå eksplisitt i sameAs-listen der virksomheten er registrert i dem.

Navnebytte, fusjon og domenebytte uten å miste entiteten

Den vanligste feilen ved et navnebytte eller en fusjon er stille utfasing: det gamle navnet slutter brått å brukes, uten at noe forteller verden – eller en AI-modell – at det nye navnet er en fortsettelse av samme entitet, ikke en helt ny en. Riktig håndtert er overgangen en eksplisitt kobling, ikke en utradering: sett opp 301-redirect fra gammelt til nytt domene der det er relevant, behold det gamle navnet i alternateName som en deklarert tidligere variant, og oppdater Brønnøysundregisteret, Wikidata og LinkedIn til det nye navnet så raskt som praktisk mulig. Gjort riktig arver den nye entiteten historikken og autoriteten til den gamle, i stedet for å starte på null som en ukjent nykommer.

Samme problem har et navn: personer

Entitetssplitting rammer ikke bare firmanavn. En grunnlegger som omtales med fullt navn i en byline, med kun initialer i en presseomtale, og med et forkortet kallenavn på LinkedIn, kan splittes i flere svakere personentiteter på nøyaktig samme måte som et selskap med fire navnevarianter. Løsningen er identisk i struktur: én kanonisk form av navnet brukt konsekvent i egne kanaler, og de øvrige variantene deklarert eksplisitt via sameAs på personens egen entitet – ikke overlatt til at en modell skal gjette seg til at «grunnleggeren» og initialene på forsiden er den samme personen.

Vil du lese mer om hvordan entitetsautoritet bygges mer generelt – utover navnekonsistens alene – dekker forklaringen av entitetsautoritet de fem kildene som veier tyngst.

Selvsjekk: spør en modell om to av navnevariantene dine

Selvsjekk. Velg to kjente skrivemåter av virksomhetens navn – for eksempel det fulle juridiske navnet og den korte merkevareversjonen. Spør en AI-modell «hva er [navnevariant A]?» og deretter, i en ny samtale, «hva er [navnevariant B]?».

Får du to tydelig ulike svar – forskjellig beskrivelse, forskjellige detaljer, eller i verste fall at den ene varianten ikke gjenkjennes i det hele tatt – har du et entitetsproblem, ikke bare en stilistisk uenighet om hvordan navnet skal skrives. Får du i det vesentlige samme svar begge ganger, er variantene trolig allerede koblet godt nok sammen.