Semantische ID's

Verrijk hetzelfde soort entiteit keer op keer en je blijft dezelfde dingen uit de echte wereld opnieuw ontdekken — hetzelfde bedrijf, dezelfde bijwerking van een medicijn, dezelfde persoon — elke keer met net iets andere woorden beschreven. Een semantische ID is een stabiele, tot de organisatie beperkte identifier die Entity Enricher aan een object toekent op basis van zijn sleutelvelden, zodat die bijna-duplicaten samenvallen tot één identiteit waarop je kunt groeperen, dedupliceren en joinen.

Het probleem: hetzelfde, andere woorden

De identiteit van een object wordt opgebouwd uit de sleutelvelden — en dat kunnen er een of meerdere zijn. Twee voorbeelden:

Eén sleutel

Een neveneffect met sleutel name

Het verschijnt als Headache, Céphalée en Cephalalgia door verschillende runs en talen heen. Eén sleutelveld, drie schrijfwijzen, één echt concept.

Twee sleutels

Een bedrijf met als sleutel naam + land

Acme Inc. · United States en Acme Incorporated · United States zijn hetzelfde bedrijf — terwijl Acme Inc. · Germany een ander bedrijf is. De tweede sleutel maakt het onderscheid; daarom kan een object er meer dan één dragen.

Eenvoudige tekstvergelijking faalt bij al deze gevallen; een mens weet welke hetzelfde zijn. Semantische ID's leggen dat oordeel automatisch vast.

Wat een semantische ID is

Hoe het werkt

Nadat het model zijn resultaat heeft teruggegeven, lost Entity Enricher elke semantische ID in zes stappen op — de goedkoopste eerst. De vier stappen vóór de embedding zijn pure tekstvergelijking, dus een identiteit die daar wordt vastgesteld kost helemaal niets:

1
Stel de identiteitstekst samen
Voeg de sleutelvelden van het object samen tot één tekst, in je primaire taal. De sleutel van een geneste entiteit telt ook mee, als onderscheider: een film met een titel die een andere film ook draagt, wordt onderscheiden door de naam van de regisseur. De keerzijde is dat elke sibling die naar dezelfde gerelateerde entiteit verwijst diezelfde waarde meedraagt; haal een gerelateerde sleutel dus uit de deelnemers zodra die siblings alleen maar op elkaar doet lijken. Items binnen arrays worden nooit meegenomen: elk array-item heeft zijn eigen identiteit. De lijst identiteitsdeelnemers in de schema-editor laat precies zien welke waarden de tekst vormen en laat je ze herordenen of wijzigen — schema's die dezelfde deelnemers in dezelfde volgorde kiezen, maken identieke ID's aan. De tekst wordt genormaliseerd (kleine letters, tekst tussen haakjes weggelaten, witruimte samengevoegd) om triviale verschillen weg te nemen. Als al die sleutelvelden leeg terugkomen, is er niets om het object mee te identificeren en kan er geen ID worden toegekend — het object wordt dan verwijderd in plaats van bewaard als een anoniem object waarop niets gegroepeerd, samengevoegd of ontdubbeld kan worden: een genest object wordt null in zijn ouder, en een item in een lijst verdwijnt uit die lijst. De verrijkte entiteit zelf wordt nooit verwijderd; die heeft simpelweg geen ID.
2
Zoek naar een exacte overeenkomst
Als diezelfde genormaliseerde tekst eerder in jouw organisatie is gezien, wordt de bestaande ID meteen hergebruikt — geen model-aanroep, geen kosten.
3
Matchen op een code, als die er is
Als een van de eigen identiteitssleutels van het object een code is — een veld met een patroonbeperking, of een veld waarvan de voorbeelden op identificatiecodes lijken — wordt die als eerste samengesteld en apart vergeleken (de code van een gerelateerde entiteit neemt die rol nooit over: elke sibling die naar die entiteit verwijst, deelt hem). Een exacte codematch beslecht de identiteit meteen, hoe de rest ook verwoord is, dus LC-39A brengt elke schrijfwijze van de omringende tekst samen. Minstens zo belangrijk is de omgekeerde werking: een andere code blokkeert een samenvoeging die de embeddingstap anders had geaccepteerd, want twee dingen met verschillende identificatiecodes zijn twee dingen, hoe gelijk ze ook lezen.
4
Matchen op dezelfde woorden in willekeurige volgorde
Voordat er een embedding wordt uitgegeven, worden de woorden zelf als verzameling vergeleken: als de woorden van de ene tekst in die van de andere zitten, gaat het om dezelfde identiteit, alleen korter of langer opgeschreven — “Boeing” en “The Boeing Company”. Dit vangt precies de lengteverschillen op die embeddings als ver uit elkaar meten, en het kost niets: net als bij de stap met exacte tekst betekent een treffer hier geen embedding-aanroep en geen kosten.
5
Embedden en vergelijken
Anders wordt de tekst geëmbed en op betekenis vergeleken met bestaande concepten van hetzelfde concepttype (standaard de naam van het entiteitstype — in de editor aanpasbaar, zodat schema's met verschillende namen één conceptruimte delen) met behulp van vectorsimilariteit — zodat “Acme Inc.” en“Acme Incorporated” naast elkaar terechtkomen.
6
Vraag het de beoordelaar
De paar dichtstbijzijnde concepten gaan naar een klein taalmodel, dat één vraag beantwoordt: benoemt een ervan hetzelfde ding in de echte wereld? Het ziet elke aanduiding als gelabelde onderdelen — nooit de gelijkenisscore, die het alleen maar zou verleiden op de geometrie te vertrouwen. Zegt het ja, dan wordt die ID hergebruikt en wordt de nieuwe formulering onthouden als nog een schrijfwijze van hetzelfde concept, zodat het volgende voorkomen gratis is. Zegt het nee, of weet het het niet, dan wordt er een gloednieuwe ID aangemaakt — nooit andersom, want twee rijen zijn later makkelijk samen te voegen en één ten onrechte gefuseerde rij niet.

Waarom een model en geen getal: gelijkenis alleen zit er in beide richtingen naast. Twee schrijfwijzen van dezelfde scheepswerf kunnen ver uit elkaar scoren, terwijl een aandoening en haar tegenpool (“acuut” versus “chronisch”) vrijwel identiek scoren. Geen enkele drempel scheidt die; alleen kennis van wat de woorden betekenen doet dat. De beoordelaarsdrempel (standaard 0,5, per eigenschap instelbaar) bepaalt alleen hoe ver er gezocht wordt naar kandidaten die een vraag waard zijn — nooit de identiteit.

Invoer-ID's vs. gegenereerde ID's

Of er een ID wordt gegenereerd hangt ervan af of er al een aanwezig is in de invoer voor dat object. Dit is wat je in staat stelt om een round-trip te doen: verrijk één keer om ID's te verkrijgen en geef een bekend ID later terug bij volgende runs om nieuwe feiten aan dezelfde identiteit te koppelen — goedkoper en ondubbelzinnig.

ID al aanwezig in de invoer → behouden (lookup)

Als het object dat je verstuurt al een semantische ID bevat, wordt het als een lookup behandeld: de ID wordt letterlijk behouden, het record wordt aan dat bestaande concept gekoppeld en er is geen embedding — geen kosten, geen match-of-mint. Je vertelt het platform “dit object is al geïdentificeerd in onze database.”

Geen ID in de invoer → gegenereerd

Heeft het object geen semantische ID, dan genereert het platform er een met de bovenstaande stappen. Die ID is vanaf dat moment de stabiele identificator van het object in de database van je organisatie.

Een aanwezige maar onherkenbare waarde (geen echte concept-ID) wordt genegeerd en er wordt in plaats daarvan een ID gegenereerd.

Zo schakel je het in

1
Kies een embeddingmodel (eenmalig per organisatie)
Een eigenaar kiest onder Instellingen → Organisatie → Standaardwaarden een model dat embeddings ondersteunt als het standaard embeddingmodel van de organisatie (een instelling die van je abonnement afhangt; zie Modellen & Prijzen voor welke modellen kunnen embedden). Opgeslagen vectoren zijn niet vergelijkbaar tussen modellen, dus zodra er concepten bestaan kan de instelling alleen nog worden gewist — overschakelen verloopt als een migratie vanaf de pagina Semantische ID's, die elk concept opnieuw embedt en hun ID's behoudt. Zonder model worden semantische ID's simpelweg overgeslagen.
2
Semantische ID's toevoegen aan het schema
Twee manieren, allebei in de Workflow Editor:
  • Automatisch bij het genereren — vink “Semantic ID's voor types genereren” aan; elk object met een sleutel (een eigen sleutel of een sleutel op een 1-op-1 genest object) krijgt er een, inclusief de root-entity.
  • Handmatig — gebruik de knop “+ Semantische ID toevoegen” op een object of de entiteitsvoettekst.

Resolutie kost een klein beetje embeddinggebruik per enrichment (afgerekend zoals elke modelaanroep). De exacte-match-cache maakt herhalingen gratis en door de invoer aangeleverde ID's kosten niets.

Waar de ID's verschijnen en wat je ermee doet

Herleide ID’s verschijnen in de JSON-output van de verrijking (het veld id op elk object), bij de semantische concepten in het recorddetail, en allemaal samen op de pagina Semantische ID’s, waar je het vocabulaire dat ze vormen doorbladert en cureert. Gebruik ze om:

Zo ziet een opgeloste ID eruit vanuit het vocabulaire: meerdere schrijfwijzen, één concept, één gebruikstotaal — en de tag auto markeert de vorm die de identiteitsbeoordelaar heeft samengevoegd.

Vult multi-model fusie aan

Fusie verzoent meningsverschillen tussen modellen binnen één run; semantische ID's verzoenen dezelfde entiteit over runs en tijd heen. De twee werken samen.