同じ種類のエンティティを何度もエンリッチしていると、同じ現実世界の対象——同じ企業、同じ薬の副作用、同じ人物——が、そのたびに少しずつ異なる言葉で表現され、繰り返し再発見されることになります。セマンティックIDは、Entity Enricherがオブジェクトのキーフィールドから割り当てる、組織スコープで安定した識別子です。これにより、こうした準重複が、グループ化・重複排除・結合が可能な1つのアイデンティティにまとまります。
オブジェクトのアイデンティティは、そのキーフィールドから構築されます — 1つの場合も複数の場合もあります。2つの例を示します：
name をキーとする副作用実行や言語をまたいで Headache、Céphalée、Cephalalgia として現れます。1つのキーフィールド、3つの表記、実際には1つの概念です。
名前＋国をキーとする企業Acme Inc. · United States と Acme Incorporated · United States は同じ会社ですが、Acme Inc. · Germany は別の会社です。2 つ目のキーが区別を可能にします。だからこそ、1 つのオブジェクトが複数のキーを持つことができます。
単純な文字列一致ではこれらすべてに対応できませんが、人間ならどれが同じかを判断できます。セマンティックIDはその判断を自動的に符号化します。
stringプロパティ（デフォルトではidという名前）で、不透明で安定した識別子を保持します。preserve）フィールドです。常に文字列であり、キーになることはなく、多言語対応でもなく、1 つのオブジェクトにつき最大 1 つです。manufacturer）、または配列内の各項目（例: 各 side_effect）。モデルが結果を返した後、Entity Enricherは各セマンティックIDを4つのステップで解決します（コストの低い順に）：
「Acme Inc.」 と 「Acme Incorporated」 は互いに近くに配置されます。0.92、プロパティごとに調整可能）を上回るスコアの場合、そのコンセプトのIDが再利用されます。それ以外の場合は、まったく新しいIDが生成され、次回のために保存されます。しきい値のトレードオフ: しきい値が高いほど厳格になり(誤ったマージが減ります)、低いほど緩やかになります(より積極的な重複排除)。デフォルトの0.92でマージが過剰または不足する場合は、プロパティごとに調整してください。
IDが生成されるかどうかは、そのオブジェクトについて入力内にすでに存在しているかどうかで決まります。これによりラウンドトリップが可能になります。まず一度エンリッチメントを実行してIDを取得し、その後の実行で既知のIDを渡すことで、同じアイデンティティに新しい事実を追加できます。より低コストで曖昧さもありません。
送信するオブジェクトがすでにセマンティックIDを持っている場合、それはルックアップとして扱われます。IDはそのまま保持され、レコードは既存のコンセプトにリンクされ、埋め込みは行われません — コストもなく、match-or-mintもありません。プラットフォームに対して「このオブジェクトはすでに当社のデータベースで識別済みです」と伝えていることになります。
オブジェクトにセマンティックIDがない場合、プラットフォームは上記の4つのステップでIDを生成します。そのIDは、それ以降、組織のデータベース内でそのオブジェクトの安定した識別子になります。
存在するが認識できない値（実際のコンセプトIDではないもの）は無視され、代わりにIDが生成されます。
解決はエンリッチメントごとにわずかな埋め込み使用量を消費します（他のモデル呼び出しと同様に従量課金されます）。完全一致キャッシュにより繰り返しは無料になり、入力で指定された ID には費用がかかりません。
解決された ID は、エンリッチメント出力の JSON（各オブジェクトの id フィールド）と、レコード詳細のセマンティックコンセプトに表示されます。次の用途に使用できます：
fusionは単一の実行内におけるmodel間の相違を調整し、semantic IDは実行と時間をまたいで同一のentityを調整します。この2つは連携して機能します。