Обогащая один и тот же тип сущности снова и снова, вы постоянно заново обнаруживаете одни и те же реальные объекты — ту же компанию, тот же побочный эффект препарата, того же человека — каждый раз описанные немного разными словами. Семантический ID — это стабильный идентификатор в рамках организации, который Entity Enricher присваивает объекту на основе его ключевых полей, поэтому такие почти-дубликаты сводятся к одной идентичности, по которой вы можете группировать, дедуплицировать и объединять данные.
Идентичность объекта строится из его ключевых полей — и их может быть одно или несколько. Два примера:
nameОно появляется как Headache, Céphalée и Cephalalgia в разных запусках и на разных языках. Одно ключевое поле, три написания, одно реальное понятие.
название + странаAcme Inc. · United States и Acme Incorporated · United States — это одна и та же компания, тогда как Acme Inc. · Germany — другая. Второй ключ устраняет неоднозначность; именно поэтому объект может содержать более одного.
Простое сопоставление строк не срабатывает ни в одном из этих случаев; человек понимает, какие из них совпадают. Семантические ID кодируют это суждение автоматически.
string у объекта (по умолчанию с именем id), содержащее непрозрачный стабильный идентификатор.preserve) поле: всегда строка, никогда не ключ, никогда не многоязычное, не более одного на объект.manufacturer) или каждого элемента массива (например, каждого side_effect).После того как модель возвращает результат, Entity Enricher разрешает каждый семантический идентификатор за четыре шага — сначала самый дешёвый:
«Acme Inc.» и«Acme Incorporated» оказываются рядом.0,92, настраивается для каждого свойства), ID этого концепта используется повторно. Иначе создаётся совершенно новый ID и сохраняется на будущее.Компромисс порога: более высокий порог строже (меньше случайных слияний); более низкий — мягче (более агрессивная дедупликация). Настраивайте его для каждого свойства, когда значение по умолчанию 0.92 объединяет слишком много или слишком мало.
Будет ли ID сгенерирован, зависит от того, присутствует ли он уже во входных данных для этого объекта. Именно это позволяет выполнять круговой обмен: обогатите один раз, чтобы получить ID, а затем передавайте известный ID в последующих запусках, чтобы привязать новые факты к той же сущности — дешевле и без неоднозначности.
Если отправляемый вами объект уже содержит семантический ID, он трактуется как поиск: ID сохраняется дословно, запись связывается с этим существующим концептом, и эмбеддинга нет — ни затрат, ни поиска-или-создания. Вы сообщаете платформе, что «этот объект уже идентифицирован в нашей базе данных».
Если у объекта нет семантического ID, платформа создаёт его с помощью четырёх шагов выше. Этот ID с этого момента становится стабильным идентификатором объекта в базе данных вашей организации.
Присутствующее, но нераспознаваемое значение (не настоящий ID концепта) игнорируется, и вместо него генерируется ID.
Разрешение расходует небольшое количество эмбеддингов на каждое обогащение (тарифицируется как любой вызов модели). Кэш точных совпадений делает повторы бесплатными, а предоставленные во входных данных ID ничего не стоят.
Разрешённые ID появляются в выходном JSON обогащения (поле id у каждого объекта) и в семантических концепциях в деталях записи. Используйте их, чтобы:
Слияние согласовывает расхождения между моделями в рамках одного запуска; семантические ID согласовывают одну и ту же сущность между запусками и во времени. Оба механизма работают вместе.