IDs semânticos

Enriqueça o mesmo tipo de entidade uma e outra vez e continua a redescobrir as mesmas coisas do mundo real — a mesma empresa, o mesmo efeito secundário de um medicamento, a mesma pessoa — descritas com palavras ligeiramente diferentes de cada vez. Um ID semântico é um identificador estável, no âmbito da organização, que o Entity Enricher atribui a um objeto a partir dos seus campos-chave, para que esses quase-duplicados se reduzam a uma identidade pela qual pode agrupar, desduplicar e fazer junções.

O problema: a mesma coisa, palavras diferentes

A identidade de um objeto é construída a partir dos seus campos-chave — e pode haver um ou vários. Dois exemplos:

Uma chave

Um efeito secundário indexado por name

Aparece como Headache, Céphalée e Cephalalgia em diferentes execuções e idiomas. Um campo-chave, três grafias, um conceito real.

Duas chaves

Uma empresa indexada por nome + país

Acme Inc. · Estados Unidos e Acme Incorporated · Estados Unidos são a mesma empresa — enquanto Acme Inc. · Alemanha é uma diferente. A segunda chave desambigua; é por isso que um objeto pode ter mais do que uma.

A correspondência simples de cadeias de texto falha em todos estes casos; um humano sabe quais são iguais. Os IDs semânticos codificam esse juízo automaticamente.

O que é um semantic ID

Como funciona

Depois de o modelo devolver o resultado, o Entity Enricher resolve cada ID semântico em seis passos — do mais barato para o mais caro. Os quatro passos anteriores ao embedding são pura comparação de texto, por isso uma identidade resolvida nessa fase não tem qualquer custo:

1
Compor o texto de identidade
Junte os campos-chave do objeto numa única cadeia de texto, no seu idioma principal. A chave de uma entidade aninhada também contribui, como desambiguador: um filme cujo título é partilhado por outro filme distingue-se pelo nome do realizador. O reverso é que todos os irmãos que referem a mesma entidade relacionada transportam esse mesmo valor, por isso, quando uma chave relacionada só faz com que os irmãos se leiam da mesma forma, retire-a dos participantes. Os itens dentro de arrays nunca são incluídos: cada item de um array tem a sua própria identidade. A lista de participantes na identidade do editor de esquemas mostra exatamente que valores compõem o texto e permite reordená-los ou alterá-los — esquemas que escolhem os mesmos participantes pela mesma ordem cunham IDs idênticos. O texto é normalizado (passado a minúsculas, parênteses removidos, espaços colapsados) para reduzir diferenças triviais. Se todos esses campos-chave vierem vazios, não há nada que identifique o objeto e nenhum ID pode ser atribuído — por isso o objeto é removido, em vez de ficar como um objeto anónimo que nada pode agrupar, associar ou desduplicar: um objeto aninhado passa a null no elemento que o contém e um item dentro de uma lista é retirado da lista. A entidade enriquecida em si nunca é removida; simplesmente não tem ID.
2
Procurar uma correspondência exata
Se esse texto normalizado exato já tiver sido visto anteriormente na sua organization, o seu ID existente é reutilizado de imediato — sem chamada ao modelo, sem custo.
3
Corresponder por um código, se existir
Quando uma das chaves de identidade próprias do objeto é um código — um campo restringido por um padrão, ou cujos exemplos parecem identificadores —, é composto em primeiro lugar e comparado isoladamente (o código de uma entidade relacionada nunca o substitui: todos os irmãos que referem essa entidade o partilham). Uma correspondência exata de código resolve a identidade de imediato, seja qual for a redação em redor, pelo que LC-39A unifica todas as formas como o resto do texto foi escrito. Igualmente importante, funciona no sentido inverso: um código diferente veta uma fusão que o passo de embedding teria aceitado, porque duas coisas com identificadores diferentes são duas coisas, por muito parecidas que se leiam.
4
Corresponder pelas mesmas palavras em qualquer ordem
Antes de gastar um embedding, as próprias palavras são comparadas como conjunto: se as palavras de um texto estiverem contidas nas do outro, trata-se da mesma identidade escrita com extensões diferentes — “Boeing” e “The Boeing Company”. Isto apanha exatamente as diferenças de verbosidade que os embeddings medem como muito distantes, e não custa nada: tal como no passo de texto exato, uma correspondência aqui significa nenhuma chamada de embedding e nenhum custo.
5
Incorporar e comparar
Caso contrário, o texto é incorporado e comparado, por significado, com os conceitos existentes do mesmo tipo de conceito (o nome do tipo de entidade por predefinição — substituível no editor para que esquemas com nomes diferentes partilhem um mesmo espaço de conceitos) utilizando similaridade vetorial — para que “Acme Inc.” e“Acme Incorporated” fiquem lado a lado.
6
Consultar o juiz
Os conceitos mais próximos são entregues a um pequeno modelo de linguagem, que responde a uma única pergunta: algum deles designa a mesma coisa no mundo real? Vê cada designação como partes etiquetadas — nunca a pontuação de semelhança, que apenas o levaria a confiar na geometria. Se responder que sim, esse ID é reutilizado e a nova formulação fica registada como mais uma grafia do mesmo conceito, pelo que a ocorrência seguinte não tem custo. Se responder que não, ou não conseguir determinar, é criado um ID totalmente novo — nunca o inverso, porque duas linhas são fáceis de unir mais tarde e uma linha erradamente fundida não é.

Porquê um modelo e não um número: a semelhança, por si só, falha nos dois sentidos. Duas grafias do mesmo estaleiro podem obter pontuações muito distantes, ao passo que uma condição clínica e o seu oposto (“aguda” versus “crónica”) pontuam de forma quase idêntica. Nenhum limiar separa estes casos; só o conhecimento do significado das palavras o consegue. O limiar do juiz (por predefinição 0,5, ajustável por propriedade) decide apenas até onde procurar candidatos que valha a pena questionar — nunca decide a identidade.

IDs de entrada vs. IDs gerados

Se um ID é gerado depende de já existir um presente na entrada para esse objeto. É isto que lhe permite fazer round-trip: enriqueça uma vez para obter IDs e, depois, passe um ID conhecido em execuções posteriores para associar novos factos à mesma identidade — mais barato e sem ambiguidade.

ID já presente no input → mantido (consulta)

Se o objeto que envia já contém um semantic ID, é tratado como uma consulta: o ID é mantido tal como está, o record é associado a esse conceito existente e não há embedding — sem custo, sem match-or-mint. Está a dizer à plataforma “este objeto já está identificado na nossa base de dados”.

Sem ID na entrada → gerado

Se o objeto não tiver ID semântico, a plataforma gera um com os passos acima. A partir daí, esse ID passa a ser o identificador estável do objeto na base de dados da sua organização.

Um valor presente mas não reconhecível (que não é um ID de conceito real) é ignorado, sendo gerado um ID em vez disso.

Como ativá-lo

1
Escolha um modelo de embedding (uma vez por organização)
Um proprietário escolhe um modelo com capacidade de embedding em Definições → Organização → Predefinições como modelo de embedding predefinido da organização (uma definição condicionada pelo plano; consulte Modelos e Preços para saber que modelos suportam embeddings). Os vetores guardados não são comparáveis entre modelos, por isso, assim que existirem conceitos, a definição só pode ser limpa — mudar de modelo é executado como uma migração a partir da página IDs Semânticos, que volta a gerar o embedding de todos os conceitos e mantém os respetivos IDs. Sem um modelo, os IDs semânticos são simplesmente ignorados.
2
Adicionar IDs semânticos ao esquema
Duas formas, ambas no Editor de Fluxo de Trabalho:
  • Automaticamente na geração — marque “Gerar IDs semânticos para tipos”; cada objeto com uma chave (a sua própria, ou uma num objeto aninhado 1-1) recebe um, incluindo a entidade raiz.
  • Manualmente — utilize o controlo “+ Adicionar ID semântico” em qualquer objeto ou no rodapé da entidade.

A resolução consome uma pequena quantidade de utilização de embeddings por enriquecimento (medida como qualquer chamada de modelo). A cache de correspondência exata torna as repetições gratuitas e os IDs fornecidos na entrada não têm qualquer custo.

Onde os IDs aparecem e o que fazer com eles

Os IDs resolvidos aparecem no JSON de saída do enriquecimento (o campo id de cada objeto), nos conceitos semânticos do detalhe do registo e todos juntos na página de IDs semânticos, onde o vocabulário que formam é consultado e curado. Use-os para:

É este o aspeto de um ID resolvido do lado do vocabulário: várias grafias, um conceito, um total de utilizações — e a etiqueta auto assinala a forma que o juiz de identidade incorporou.

Complementa a fusão de múltiplos modelos

A fusão reconcilia discordâncias entre modelos dentro de uma única execução; os IDs semânticos reconciliam a mesma entidade ao longo de execuções e do tempo. Os dois funcionam em conjunto.

Documentação relacionada

Conceitos Fundamentais
Chaves de pesquisa e de fusão, sobre as quais os IDs semânticos se baseiam
Enriquecimento Multilingue
Unir grafias de diferentes idiomas numa só identidade
Fusão Multi-Modelo
Reconcilie entre modelos numa única execução
Editor de Fluxo de Trabalho
Adicionar IDs semânticos a qualquer objeto
A página de IDs semânticos
Navegue, faça a curadoria e elimine duplicados no vocabulário resultante