Обогащая один и тот же тип сущности снова и снова, вы постоянно заново обнаруживаете одни и те же реальные объекты — ту же компанию, тот же побочный эффект препарата, того же человека — каждый раз описанные немного разными словами. Семантический 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.5, настраивается для каждого свойства) определяет лишь то, насколько далеко искать кандидатов, о которых стоит спросить, — но никогда не решает вопрос тождества.
Будет ли ID сгенерирован, зависит от того, присутствует ли он уже во входных данных для этого объекта. Именно это позволяет выполнять круговой обмен: обогатите один раз, чтобы получить ID, а затем передавайте известный ID в последующих запусках, чтобы привязать новые факты к той же сущности — дешевле и без неоднозначности.
Если отправляемый вами объект уже содержит семантический ID, он трактуется как поиск: ID сохраняется дословно, запись связывается с этим существующим концептом, и эмбеддинга нет — ни затрат, ни поиска-или-создания. Вы сообщаете платформе, что «этот объект уже идентифицирован в нашей базе данных».
Если у объекта нет семантического ID, платформа создаёт его по описанным выше шагам. С этого момента такой ID становится постоянным идентификатором объекта в базе данных вашей организации.
Присутствующее, но нераспознаваемое значение (не настоящий ID концепта) игнорируется, и вместо него генерируется ID.
Разрешение расходует небольшое количество эмбеддингов на каждое обогащение (тарифицируется как любой вызов модели). Кэш точных совпадений делает повторы бесплатными, а предоставленные во входных данных ID ничего не стоят.
Разрешённые ID появляются в выходном JSON обогащения (поле id у каждого объекта), в семантических концептах в деталях записи и все вместе — на странице семантических ID, где образуемый ими словарь можно просматривать и курировать. Используйте их, чтобы:
Слияние согласовывает расхождения между моделями в рамках одного запуска; семантические ID согласовывают одну и ту же сущность между запусками и во времени. Оба механизма работают вместе.