Navnekonsistens – når modellen tror, du er tre virksomheder

Modellen tror måske, du er tre forskellige virksomheder

En AI-model forsøger at knytte det, den læser, til én enhed – en specifik virksomhed, med en specifik historie og et specifikt sæt egenskaber. Den gør det ved at lede efter signaler om, at flere tekstbidder faktisk handler om samme ting. Skrives dit navn på fire forskellige måder på fire forskellige steder, uden nogen eksplicit kobling mellem dem, har modellen ingen garanti for, at »Citation Lab ApS«, »CitationLab«, »Citation Lab« og »CL« er én og samme virksomhed. Den kan lige så godt læse det som tre eller fire svagere enheder, hver med sin egen, tyndere brøkdel af den samlede autoritet – og ingen af dem stærke nok til at blive anbefalet frem for en konkurrent med ét, konsekvent navn.

Hvor navnevarianterne faktisk opstår

Ingen beslutter sig for at splitte deres enhed med vilje. Varianterne sniger sig ind, fordi forskellige dele af en virksomheds digitale fodaftryk opsættes af forskellige personer, på forskellige tidspunkter, uden at nogen ser dem samlet bagefter.

Ingen af kilderne i tabellen ovenfor er forkerte isoleret set. Problemet opstår først, når ingen af dem er eksplicit koblet til de andre – så står de som fem ubesvarede spørgsmål i stedet for fem bekræftelser på samme svar.

Én kanonisk form, kontrollerede alias: sameAs og alternateName

Løsningen er hverken at tvinge identisk ordlyd frem overalt (juridiske navne og markedsføringsnavne har forskellige formål og bør have lov til at afvige) eller at ignorere varianterne og håbe, at modellen selv finder ud af det. Løsningen er at vælge én kanonisk form – typisk mærkenavnet, ikke det fulde juridiske navn – og eksplicit deklarere resten som kendte varianter af netop den enhed.

Teknisk gøres dette med to egenskaber i schema.org-markeringen for organisationen: alternateName lister alternative navne (forkortelser, tidligere navne), enheden er kendt under, mens sameAs peger til andre autoritative profiler af samme enhed – Wikidata, Wikipedia, LinkedIn-siden, det centrale virksomhedsregister. Sammen siger de: »disse strenge og disse profiler er alle den samme, ene enhed«, i stedet for at overlade koblingen til gætteri.

Virksomhedsregisteret og Wikidata: de stærkeste ankre

Ikke alle kilder vejer lige tungt i den vurdering. Et udsagn på egen hjemmeside er let at skrive og lige så let at ignorere. Et struktureret, offentligt register er noget andet: det centrale virksomhedsregister giver et verificeret registreringsnummer og registreret navn, der ikke er selvpubliceret af virksomheden selv, og Wikidata giver en struktureret, maskinlæsbar post, som mange videngrafer allerede henter fra. Begge er netop den type ankre, en model – eller systemet bag den – kan krydstjekke andre kilder mod, og de bør stå eksplicit i sameAs-listen, hvor virksomheden er registreret i dem.

Navneskift, fusion og domæneskift uden at miste enheden

Den mest almindelige fejl ved et navneskift eller en fusion er stille udfasning: det gamle navn holder brat op med at blive brugt, uden at noget fortæller verden – eller en AI-model – at det nye navn er en fortsættelse af samme enhed, ikke en helt ny en. Korrekt håndteret er overgangen en eksplicit kobling, ikke en udslettelse: opsæt 301-redirect fra gammelt til nyt domæne, hvor det er relevant, behold det gamle navn i alternateName som en deklareret tidligere variant, og opdater det centrale virksomhedsregister, Wikidata og LinkedIn til det nye navn så hurtigt som praktisk muligt. Gjort rigtigt arver den nye enhed historikken og autoriteten fra den gamle, i stedet for at starte fra nul som en ukendt nykommer.

Samme problem har et navn: personer

Entitetssplitning rammer ikke kun firmanavne. En grundlægger, der omtales med fuldt navn i en byline, med kun initialer i en presseomtale og med et forkortet kaldenavn på LinkedIn, kan splittes i flere svagere personenheder på nøjagtig samme måde som en virksomhed med fire navnevarianter. Løsningen er strukturelt identisk: én kanonisk form af navnet brugt konsekvent i egne kanaler, og de øvrige varianter eksplicit deklareret via sameAs på personens egen enhed – i stedet for overladt til, at en model skal gætte sig til, at »grundlæggeren« og initialerne på forsiden er den samme person.

Selvtjek: spørg en model om to af dine navnevarianter

Selvtjek. Vælg to kendte måder at skrive virksomhedens navn på – for eksempel det fulde juridiske navn og den korte brandversion. Spørg en AI-model »hvad er [navnevariant A]?« og derefter, i en ny samtale, »hvad er [navnevariant B]?«.

Får du to tydeligt forskellige svar – forskellig beskrivelse, forskellige detaljer, eller i værste fald at den ene variant slet ikke genkendes – har du et entitetsproblem, ikke bare en stilistisk uenighed om, hvordan navnet skal skrives. Får du i det væsentlige det samme svar begge gange, er varianterne formentlig allerede koblet godt nok sammen.