同じ種類のエンティティを何度もエンリッチしていると、同じ現実世界の対象——同じ企業、同じ薬の副作用、同じ人物——が、そのたびに少しずつ異なる言葉で表現され、繰り返し再発見されることになります。セマンティック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という名前）で、不透明で安定した識別子を保持します。manufacturer）、または配列内の各項目（例: 各 side_effect）。モデルが結果を返した後、Entity Enricher は各セマンティック ID を 6 つのステップで解決します（コストの低い順）。埋め込みより前の 4 つのステップは純粋なテキスト比較のため、そこで確定した同一性にはコストがまったくかかりません:
null となり、リスト内の項目はリストから除外されます。エンリッチメント対象のエンティティ自体が削除されることはありません。単に ID を持たないだけです。LC-39A は残りのテキストがどう書かれていても統合されます。同じくらい重要なのは、逆方向にも働くことです。異なるコードは、埋め込みステップなら受け入れていたはずのマージを拒否します。識別子が異なる 2 つのものは、どれだけ似て見えても別のものだからです。“Boeing” と “The Boeing Company” のように。これは、埋め込みが 大きく離れている と判定してしまう冗長さの違いを的確に捉え、しかもコストはかかりません。完全一致のステップと同様、ここで一致すれば埋め込みの呼び出しも課金も発生しません。「Acme Inc.」と「Acme Incorporated」が互いに近くに配置されます。0.92、プロパティごとに調整可能）を上回った場合、その概念の ID が再利用されます。それ以外の場合は、新しい ID が生成され、次回のために保存されます。スコアが高くても、次の 1 点だけは例外です。2 つのテキストが同じ語で数え方だけが異なる場合 — “second stage”と“third stage” — は、数え方こそが両者を区別する要素であるため、別のものとして扱われます。同じ数を 2 通りの表記で書いた場合（2とII）は、引き続き一致します。しきい値のトレードオフ: しきい値が高いほど厳格になり(誤ったマージが減ります)、低いほど緩やかになります(より積極的な重複排除)。デフォルトの0.92でマージが過剰または不足する場合は、プロパティごとに調整してください。
IDが生成されるかどうかは、そのオブジェクトについて入力内にすでに存在しているかどうかで決まります。これによりラウンドトリップが可能になります。まず一度エンリッチメントを実行してIDを取得し、その後の実行で既知のIDを渡すことで、同じアイデンティティに新しい事実を追加できます。より低コストで曖昧さもありません。
送信するオブジェクトがすでにセマンティックIDを持っている場合、それはルックアップとして扱われます。IDはそのまま保持され、レコードは既存のコンセプトにリンクされ、埋め込みは行われません — コストもなく、match-or-mintもありません。プラットフォームに対して「このオブジェクトはすでに当社のデータベースで識別済みです」と伝えていることになります。
オブジェクトにセマンティックIDがない場合、プラットフォームが上記の手順で生成します。この ID は以降、組織のデータベースにおけるそのオブジェクトの安定した識別子になります。
存在するが認識できない値（実際のコンセプトIDではないもの）は無視され、代わりにIDが生成されます。
解決はエンリッチメントごとにわずかな埋め込み使用量を消費します（他のモデル呼び出しと同様に従量課金されます）。完全一致キャッシュにより繰り返しは無料になり、入力で指定された ID には費用がかかりません。
解決されたIDは、エンリッチメントの出力JSON（各オブジェクトのidフィールド）、レコード詳細のセマンティックコンセプト、そしてセマンティックIDページにまとめて表示されます。同ページでは、それらが構成する語彙を閲覧・整備できます。用途は次のとおりです：
fusionは単一の実行内におけるmodel間の相違を調整し、semantic IDは実行と時間をまたいで同一のentityを調整します。この2つは連携して機能します。