セマンティックID

同じ種類のエンティティを何度もエンリッチしていると、同じ現実世界の対象——同じ企業、同じ薬の副作用、同じ人物——が、そのたびに少しずつ異なる言葉で表現され、繰り返し再発見されることになります。セマンティックIDは、Entity Enricherがオブジェクトのキーフィールドから割り当てる、組織スコープで安定した識別子です。これにより、こうした準重複が、グループ化・重複排除・結合が可能な1つのアイデンティティにまとまります。

問題：同じものを、異なる言葉で

オブジェクトのアイデンティティは、そのキーフィールドから構築されます — 1つの場合も複数の場合もあります。2つの例を示します：

1つのキー

`name` をキーとする副作用

実行や言語をまたいで Headache、Céphalée、Cephalalgia として現れます。1つのキーフィールド、3つの表記、実際には1つの概念です。

2つのキー

`名前`＋`国`をキーとする企業

Acme Inc. · United States と Acme Incorporated · United States は同じ会社ですが、Acme Inc. · Germany は別の会社です。2 つ目のキーが区別を可能にします。だからこそ、1 つのオブジェクトが複数のキーを持つことができます。

単純な文字列一致ではこれらすべてに対応できませんが、人間ならどれが同じかを判断できます。セマンティックIDはその判断を自動的に符号化します。

semantic IDとは

•オブジェクト上の単一のstringプロパティ（デフォルトではidという名前）で、不透明で安定した識別子を保持します。
•安定かつorganization単位 — 同じ現実世界の対象は、enrichment、batch、時間をまたいで同一のIDに解決されますが、これはあなたのorganization内に限られます。
•自動的に割り当てられ、LLMによって割り当てられることはありません — エンリッチメント後のパスで計算されるため、モデルがハルシネーションを起こすことはありません。これはパススルーフィールドです（入力値はそのまま通過します）。常に文字列であり、key になることも、preserve になることも、多言語になることもなく、1オブジェクトにつき最大1つです。
•任意のオブジェクトで許可されます — エンティティ全体（ルート）、1対1のネストされたオブジェクト（例: manufacturer）、または配列内の各項目（例: 各 side_effect）。

仕組み

モデルが結果を返した後、Entity Enricher は各セマンティック ID を 6 つのステップで解決します（コストの低い順）。埋め込みより前の 4 つのステップは純粋なテキスト比較のため、そこで確定した同一性にはコストがまったくかかりません:

アイデンティティテキストを作成

オブジェクトのキーフィールドを、主要言語で1つの文字列に連結します。ネストされたエンティティのキーも、曖昧さを解消する要素として寄与します。たとえば、別の映画と同じタイトルを持つ映画は、監督名によって区別されます。反面、同じ関連エンティティを参照する兄弟要素はすべて同じ値を持つため、関連キーが兄弟要素を似通わせるだけの場合は、参加要素から外してください。配列内の項目が取り込まれることはありません。各配列項目は自身の識別情報を持ちます。スキーマエディタの識別参加要素リストには、テキストを構成する値が正確に表示され、並べ替えや変更ができます。同じ参加要素を同じ順序で選んだスキーマは、同一のIDを発行します。テキストは正規化され（小文字化、括弧内の削除、空白の圧縮）、些細な差異を抑えます。これらのキーフィールドがすべて空で返ってきた場合、オブジェクトを識別する手がかりがなく、IDを割り当てられません。そのため、グループ化も結合も重複排除もできない匿名のオブジェクトとして残すのではなく、削除されます。ネストされたオブジェクトは親の中でnullとなり、リスト内の項目はリストから除外されます。エンリッチメントの対象となるエンティティ自体が削除されることはありません。単にIDを持たないだけです。

完全一致を検索します

その正規化済みテキストがまったく同じ形で組織内で以前に確認されている場合、既存のIDが即座に再利用されます — モデル呼び出しもコストもありません。

コードがあれば、コードで照合します

オブジェクト自身の識別キーの1つがコード（パターン制約のあるフィールド、または例が識別子のように見えるフィールド）である場合、それが最初に構成され、単独で比較されます（関連エンティティのコードが代わりを務めることはありません。そのエンティティを参照する兄弟要素はすべて同じコードを共有するためです）。コードが完全に一致すれば、周囲の文言にかかわらず識別は即座に確定します。そのためLC-39Aは、テキストの残りの部分がどのように書かれていてもすべて同一にまとめます。同じくらい重要なのは、逆方向にも働くことです。異なるコードは、埋め込み処理であれば受け入れていたはずの統合を拒否します。識別子が異なる2つのものは、どれほど似た表記であっても別のものだからです。

順序を問わず同じ単語で照合します

埋め込みを使う前に、単語そのものが集合として比較されます。一方のテキストの単語がもう一方に含まれていれば、それは同じ同一性を異なる長さで書いたものです — “Boeing” と “The Boeing Company” のように。これは、埋め込みが 大きく離れている と判定してしまう冗長さの違いを的確に捉え、しかもコストはかかりません。完全一致のステップと同様、ここで一致すれば埋め込みの呼び出しも課金も発生しません。

埋め込みと比較

それ以外の場合、テキストは埋め込まれ、同じコンセプトタイプ（デフォルトではエンティティタイプ名。エディターで上書き可能なため、異なる名前のスキーマでも1つのコンセプト空間を共有できます）の既存のコンセプトと、ベクトル類似度を用いて意味的に比較されます。そのため、「Acme Inc.」と「Acme Incorporated」が互いに近くに配置されます。

ジャッジに問い合わせる

最も近いいくつかの概念が小規模な言語モデルに渡され、そのモデルは1つの質問に答えます。そのいずれかが 現実世界の同じ対象 を指しているか、という質問です。モデルは各名称をラベル付きの要素として見ます。類似度スコアは決して見せません。見せれば幾何学的な近さを信用してしまうだけだからです。「はい」であれば、そのIDが再利用され、新しい表記は同じ概念の別表記として記憶されるため、次回の出現はコストがかかりません。「いいえ」または判断できない場合は、まったく新しいIDが作成されます。その逆は決してありません。2行を後から統合するのは簡単ですが、誤って融合した1行はそうではないからです。

数値ではなくモデルを使う理由: 類似度だけでは、どちらの方向にも誤ります。同じ造船所を指す2つの表記がまったく離れたスコアになることもあれば、ある症状とその対極（「急性」と「慢性」）がほぼ同一のスコアになることもあります。これらをしきい値で分けることはできません。分けられるのは、言葉の意味に関する知識だけです。ジャッジ下限（既定値 0.5、プロパティごとに調整可能）が決めるのは、問い合わせる価値のある候補をどこまで探すかだけであり、同一性を判断することは決してありません。

入力 ID と生成された ID

IDが生成されるかどうかは、そのオブジェクトについて入力内にすでに存在しているかどうかで決まります。これによりラウンドトリップが可能になります。まず一度エンリッチメントを実行してIDを取得し、その後の実行で既知のIDを渡すことで、同じアイデンティティに新しい事実を追加できます。より低コストで曖昧さもありません。

入力にすでにIDがある場合 → 保持（ルックアップ）

送信するオブジェクトがすでにセマンティックIDを持っている場合、それはルックアップとして扱われます。IDはそのまま保持され、レコードは既存のコンセプトにリンクされ、埋め込みは行われません — コストもなく、match-or-mintもありません。プラットフォームに対して「このオブジェクトはすでに当社のデータベースで識別済みです」と伝えていることになります。

入力にIDがありません → 生成しました

オブジェクトにセマンティックIDがない場合、プラットフォームが上記の手順で生成します。この ID は以降、組織のデータベースにおけるそのオブジェクトの安定した識別子になります。

存在するが認識できない値（実際のコンセプトIDではないもの）は無視され、代わりにIDが生成されます。

有効化する方法

埋め込みモデルを選択します（組織ごとに1回）

オーナーは 設定 → 組織 → デフォルト で埋め込みに対応したモデルを組織のデフォルト埋め込みモデルとして選択します（プランに依存する設定です。どのモデルが埋め込みに対応しているかはモデルと料金をご覧ください）。保存されたベクトルはモデル間で比較できないため、コンセプトが存在した後は設定をクリアすることしかできません。切り替えはセマンティック ID ページからの移行として実行され、すべてのコンセプトが再埋め込みされ、その ID は保持されます。モデルが設定されていない場合、セマンティック ID は単にスキップされます。

スキーマにセマンティックIDを追加

2つの方法があり、どちらもWorkflow Editor内で行います。

生成時に自動的に — 「型のセマンティック ID を生成する」にチェックを入れます。キーを持つすべてのオブジェクト（自身のキー、または 1 対 1 のネストされたオブジェクトのキー）は、ルートエンティティを含めてセマンティック ID を取得します。
手動で — 任意のオブジェクトまたはentityのフッターにある「+ semantic IDを追加」コントロールを使用します。

解決はエンリッチメントごとにわずかな埋め込み使用量を消費します（他のモデル呼び出しと同様に従量課金されます）。完全一致キャッシュにより繰り返しは無料になり、入力で指定された ID には費用がかかりません。