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