同じ enrichment を複数の AI model で実行すると、Entity Enricher はその結果を単一の高信頼度な出力へ fusion できます。fusion は model 出力間の競合を検出し、決定論的なルールまたは LLM による arbitration で解決します。
競合検出器は、すべてのモデル出力にわたってすべてのフィールドを比較します。すべてのモデルが一致するフィールドはそのまま通過します。モデルが一致しないフィールドは、解決が必要な競合としてフラグ付けされます。
| 型 | 比較方法 | 一致の意味 |
|---|---|---|
| スカラー | 正規化された完全一致（トリム済み・小文字化・丸め済み） | 正規化後、すべての値が等しい |
| 多言語対応 | 実行の主要言語が決定します。翻訳の違いは言語ごとのマージを引き起こすだけです | 主要言語で同じテキスト — 翻訳の言い回しの違いは不一致とはみなされません |
| 配列 | 項目の主要言語ビューに対する集合比較（順序非依存） | 順序や翻訳の言い回しに関係なく、同じ項目 |
| オブジェクト | アイデンティティフィールドによって両モデルが同じ対象を記述していると確認できる限りはプロパティ単位で、確認できない場合はオブジェクト全体が 1 つの競合になります | すべてのネストされたプロパティが一致 |
| null / 空 | null・空文字列・空配列の値は、主張ではなく棄権として扱われます | 競合としてカウントされることなく、値が入っている方が採用されます |
コンフリクトは、サイドバーでアービトレーションモデルを選択したかどうかに応じて、2 つの方法のいずれかで解決されます。
各フィールドのデータ型に基づいて決定論的なルールが適用されます。ほとんどの場合、LLM 呼び出しは一切不要で、解決は即座かつ無料です。唯一の例外は、モデル間で大きく食い違う数値です。これはどのルールでも正当に決着させられません。詳しくは以下をご覧ください。
| フィールドタイプ | ルール | 根拠 |
|---|---|---|
| 文字列 | 多数決。同数の場合は最長の値を採用します | 通常は詳細が多いほど良い結果になります |
| 数値 | 中央値に最も近いモデルの値 | 外れ値に強く、平均値を捏造することはありません |
| ブール値 | 多数決。同数の場合は true を優先します | 安全側のデフォルト |
| 多言語対応 | 言語ごとの多数決、言語の和集合 | 各言語を個別に解決 |
| 配列 | キーを考慮した和集合：項目はキーフィールドでグループ化され、表記ゆれは統合され、一致した項目はフィールドごとにマージされます | 論理エンティティごとに1行、情報の欠落はありません |
| オブジェクト | アイデンティティが一致する場合はフィールド単位で、一致しない場合は一方のモデルのオブジェクトを丸ごと採用します | 異なるエンティティを記述する 2 つのオブジェクトを混ぜ合わせると、どちらのモデルも返していない第 3 のエンティティを作り出してしまいます |
| Null と 値 | 値が入っている方を優先します | データの欠落は、いかなる値よりも望ましくありません |
タイブレーク： 投票が同数の場合は、（能力の代理指標として）価格の高いモデルの値が優先され、次にモデル名のアルファベット順で決まります。オブジェクト全体をアトミックに扱う場合は、その 2 つの間に完全性（値が入っている葉ノードの数）が入ります。どちらのエンティティが正しいかを証明する材料がない場合は、より強力なモデルを優先し、次により多くの情報を含む回答を選びます。
ネストされたオブジェクトをフィールド単位でマージできるのは、両方のモデルが同じ対象を記述している場合に限られます。識別フィールドがそれを裏付けない場合 — キーが異なる、あるいはキーがまったくなく実際に内容が食い違っている場合 — オブジェクト全体が 1 つのコンフリクトとして扱われ、一方のモデルの値がそのまま採用されます。そうしなければ、フュージョンはキメラを組み立ててしまいます。つまり、あるモデルの住所を別のモデルの会社に付けてしまうのです。意図的な挙動ですが、知っておく価値のある帰結が 1 つあります。採用された側は空欄も含めてそのまま取り込まれるため、採用側が空のままにしたフィールドは空のままとなり、データベースへの登録判定でエンティティが通らない原因になり得ます。その理由は実行の検証警告に記録されます。
「中央値に最も近い値」は、モデルごとに丸め方が異なる場合には適切ですが、モデル同士が矛盾している場合には不適切です。0 と 1854 の違いは丸めの差ではありません。値の相対的なばらつきが 20% に達すると、そのフィールドは組織の通常のモデル選択によって自動的に選ばれた LLM アービターにエスカレーションされ、その呼び出しは他と同様に課金されます。該当するフィールドはフュージョンの監査証跡で自動エスカレーション済みとしてフラグが付くため、トークンを消費したマージでは必ずどのフィールドが原因だったかが分かります。
サイドバーで arbitration model を選択すると、競合はインテリジェントな解決のために LLM へ送られます。arbitrator は entity のコンテキスト、schema のフィールド説明、およびすべての競合値を受け取り、理由付きで判断を下します。
フォールバック: arbitrationのmodelが失敗した場合（タイムアウトやエラー）、システムは自動的にルールベースのマージにフォールバックするため、常に結果が得られます。
競合解決後、システムは単一の統合結果を構築し、データベースに「アービトレーション」レコードとして保存します。すべての統合結果には監査証跡が含まれるため、各競合がどのように解決されたかを追跡できます。
マージされたすべての結果には、フュージョンのプロセスを記録するメタデータが含まれます:
同じ監査証跡は、Historyページの統合されたrecordのOverviewタブでも表示されます。統合されたrecordは、独自のmodelではなく統合したmodelの一覧を表示します。また、統合がルールベースで行われた場合はLLM呼び出しをまったく行っていないため、prompt、トークン、コストのいずれも伴いません。
フュージョンが完了すると、結果パネルの「統合」タブに以下が表示されます：
バッチエンリッチメントでは、2 つ以上のモデルを選択するとフュージョンが自動的に実行されます。「Merge Results」を手動でクリックする必要はありません。あるエンティティについてすべてのモデルが成功した時点でフュージョンが実行され、統合結果が各モデルの個別出力と並んで表示されます。1 つでもモデルが失敗した実行は、意図的にフュージョンされません。残りだけを統合すると、部分的な回答を合意された答えであるかのように黙って公開してしまうためです。まず不足しているモデルを回復してください。失敗した専門ドメインを再試行して実行が揃えば、自動的にフュージョンされます。
fusion_started、conflicts_detected、fusion_completedのイベントをリアルタイムで確認できます。