IDs semánticos

Enriquezca el mismo tipo de entidad una y otra vez y seguirá redescubriendo las mismas cosas del mundo real —la misma empresa, el mismo efecto secundario de un medicamento, la misma persona— descritas con palabras ligeramente distintas cada vez. Un ID semántico es un identificador estable, con alcance de organización, que Entity Enricher asigna a un objeto a partir de sus campos clave, de modo que esos casi duplicados se colapsan en una sola identidad por la que puede agrupar, deduplicar y unir.

El problema: la misma cosa, distintas palabras

La identidad de un objeto se construye a partir de sus campos clave, y puede haber uno o varios. Dos ejemplos:

Una clave

Un efecto secundario indexado por name

Aparece como Headache, Céphalée y Cephalalgia en distintas ejecuciones e idiomas. Un mismo campo clave, tres grafías, un solo concepto real.

Dos claves

Una empresa identificada por nombre + país

Acme Inc. · Estados Unidos y Acme Incorporated · Estados Unidos son la misma empresa, mientras que Acme Inc. · Alemania es distinta. La segunda clave desambigua; por eso un objeto puede tener más de una.

La coincidencia de cadenas simple falla en todos estos casos; un humano sabe cuáles son iguales. Los ID semánticos codifican ese criterio automáticamente.

Qué es un ID semántico

Cómo funciona

Cuando el modelo devuelve su resultado, Entity Enricher resuelve cada ID semántico en seis pasos, empezando por el más barato. Los cuatro pasos previos al embedding son pura comparación de texto, por lo que una identidad resuelta ahí no cuesta absolutamente nada:

1
Redactar el texto de identidad
Combine los campos clave del objeto en una sola cadena, en su idioma principal. La clave de una entidad anidada también contribuye, como desambiguador: una película cuyo título comparte con otra se distingue por el nombre de su director. La contrapartida es que todos los hermanos que remiten a la misma entidad relacionada arrastran ese mismo valor, así que, cuando una clave relacionada solo hace que los hermanos se lean igual, elimínela de los participantes. Los elementos dentro de los arrays nunca se incorporan: cada elemento de un array tiene su propia identidad. La lista de participantes de identidad del editor de esquemas muestra exactamente qué valores componen el texto y permite reordenarlos o cambiarlos: los esquemas que eligen los mismos participantes en el mismo orden acuñan ID idénticos. El texto se normaliza (se pasa a minúsculas, se descartan los paréntesis y se colapsan los espacios) para reducir las diferencias triviales. Si todos esos campos clave llegan vacíos, no hay nada por lo que identificar el objeto y no se puede asignar ningún ID, de modo que el objeto se elimina en lugar de conservarse como un objeto anónimo sobre el que no se puede agrupar, unir ni deduplicar: un objeto anidado pasa a ser null en su elemento padre y un elemento de una lista se descarta de la lista. La entidad enriquecida en sí nunca se elimina; simplemente no tiene ID.
2
Buscar una coincidencia exacta
Si ese texto normalizado exacto ya se ha visto antes en su organización, su ID existente se reutiliza de inmediato, sin llamada al modelo ni coste.
3
Coincidir por un código, si lo hay
Cuando una de las claves de identidad propias del objeto es un código —un campo restringido por un patrón, o uno cuyos ejemplos parecen identificadores—, se compone primero y se compara por separado (el código de una entidad relacionada nunca hace las veces: todos los hermanos que remiten a esa entidad lo comparten). Una coincidencia exacta de código zanja la identidad de inmediato, con independencia del texto que la rodee, de modo que LC-39A unifica todas las formas en que se haya escrito el resto del texto. Igual de importante es que funciona a la inversa: un código distinto veta una fusión que el paso de embeddings habría aceptado, porque dos cosas con identificadores distintos son dos cosas por muy parecidas que se lean.
4
Coincidir con las mismas palabras en cualquier orden
Antes de gastar un embedding, se comparan las propias palabras como conjunto: si las palabras de un texto están contenidas en las del otro, se trata de la misma identidad escrita con distinta extensión: «Boeing» y «The Boeing Company». Esto detecta justamente las diferencias de verbosidad que los embeddings miden como muy distantes, y no cuesta nada: igual que en el paso de texto exacto, un acierto aquí significa que no hay llamada de embedding ni cargo.
5
Incrustar y comparar
De lo contrario, el texto se convierte en embedding y se compara, por significado, con los conceptos existentes del mismo tipo de concepto (el nombre del tipo de entidad de forma predeterminada, modificable en el editor para que esquemas con nombres distintos compartan un mismo espacio de conceptos) mediante similitud vectorial, de modo que “Acme Inc.” y“Acme Incorporated” queden juntos.
6
Consultar al juez
Los conceptos más cercanos se entregan a un modelo de lenguaje pequeño, que responde a una sola pregunta: ¿alguno de ellos nombra la misma cosa del mundo real? Ve cada designación como partes etiquetadas, nunca la puntuación de similitud, que solo lo invitaría a fiarse de la geometría. Si dice que sí, ese ID se reutiliza y la nueva redacción se recuerda como otra grafía del mismo concepto, de modo que la próxima aparición sale gratis. Si dice que no, o no puede determinarlo, se crea un ID totalmente nuevo: nunca al revés, porque dos filas son fáciles de fusionar después y una fila fusionada por error no lo es.

Por qué un modelo y no un número: la similitud por sí sola falla en ambos sentidos. Dos grafías de un mismo astillero pueden puntuar muy lejos entre sí, mientras que una afección y su opuesta («aguda» frente a «crónica») puntúan casi idéntico. Ningún umbral las separa; solo lo hace saber qué significan las palabras. El umbral del juez (por defecto 0.5, ajustable por propiedad) solo decide hasta dónde buscar candidatos por los que valga la pena preguntar: nunca decide la identidad.

ID de entrada vs. ID generados

Que un ID se genere depende de si ya está presente en la entrada para ese objeto. Esto es lo que permite el ida y vuelta: enriquezca una vez para obtener los ID, luego vuelva a pasar un ID conocido en ejecuciones posteriores para adjuntar nuevos datos a la misma identidad: más económico e inequívoco.

ID ya presente en la entrada → conservado (búsqueda)

Si el objeto que envía ya lleva un ID semántico, se trata como una búsqueda: el ID se conserva textualmente, el registro se vincula a ese concepto existente y no hay embedding: sin coste, sin coincidir-o-acuñar. Le está diciendo a la plataforma «este objeto ya está identificado en nuestra base de datos».

No hay ID en la entrada → generado

Si el objeto no tiene ID semántico, la plataforma genera uno con los pasos anteriores. A partir de ese momento, ese ID se convierte en el identificador estable del objeto en la base de datos de su organización.

Un valor presente pero irreconocible (que no es un ID de concepto real) se ignora y, en su lugar, se genera un ID.

Cómo habilitarlo

1
Elija un modelo de embedding (una vez por organización)
Un propietario elige un modelo con capacidad de embedding en Ajustes → Organización → Valores predeterminados como modelo de embedding predeterminado de la organización (un ajuste sujeto al plan; consulte Modelos y precios para saber qué modelos pueden generar embeddings). Los vectores almacenados no son comparables entre modelos, así que, una vez que existen conceptos, el ajuste solo puede borrarse: el cambio se ejecuta como una migración desde la página de IDs semánticos, que vuelve a generar el embedding de cada concepto y conserva sus IDs. Sin modelo, los IDs semánticos simplemente se omiten.
2
Añadir IDs semánticos al esquema
Dos formas, ambas en el Editor de flujos de trabajo:
  • Automáticamente durante la generación: marque «Generar ID semánticos para los tipos»; todo objeto con una clave (propia o la de un objeto anidado 1-1) obtiene uno, incluida la entidad raíz.
  • Manualmente — use el control «+ Añadir ID semántico» en cualquier objeto o en el pie de la entidad.

La resolución consume una pequeña cantidad de uso de embeddings por enrichment (medido como cualquier llamada a un model). La caché de coincidencia exacta hace que las repeticiones sean gratuitas, y los ID proporcionados en la entrada no tienen ningún coste.

Dónde aparecen los ID y qué hacer con ellos

Los ID resueltos aparecen en el JSON de salida del enriquecimiento (el campo id de cada objeto), en los conceptos semánticos del detalle del registro y todos juntos en la página de ID semánticos, donde se explora y se depura el vocabulario que forman. Úselos para:

Así se ve un ID resuelto desde el lado del vocabulario: varias grafías, un solo concepto, un único total de uso; y la etiqueta auto marca la forma que incorporó el juez de identidad.

Complementa la fusión multimodelo

La fusión reconcilia las discrepancias entre modelos dentro de una misma ejecución; los ID semánticos reconcilian la misma entidad a lo largo de ejecuciones y del tiempo. Ambos trabajan juntos.

Documentación relacionada

Conceptos básicos
Claves de búsqueda y fusión, sobre las que se construyen los IDs semánticos
Enriquecimiento multilingüe
Contraer las grafías en distintos idiomas en una sola identidad
Fusión multimodelo
Reconciliar entre modelos dentro de una misma ejecución
Editor de flujos de trabajo
Añadir IDs semánticos a cualquier objeto
La página de ID semánticos
Explorar, curar y desduplicar el vocabulario resultante