マルチモデルフュージョン - Entity Enricher ドキュメント

マルチモデルフュージョン

同じ enrichment を複数の AI model で実行すると、Entity Enricher はその結果を単一の高信頼度な出力へ fusion できます。fusion は model 出力間の競合を検出し、決定論的なルールまたは LLM による arbitration で解決します。

フュージョンパイプライン

モデル出力
Claude の結果
GPT-4 の結果
Gemini の結果
コンフリクト検出
すべてのモデルにわたって
すべてのフィールドを比較
解決
ルールベースのマージ
または
LLM調停
マージ結果
単一出力と
競合監査証跡

ステップ1: 競合の検出

競合検出器は、すべてのモデル出力にわたってすべてのフィールドを比較します。すべてのモデルが一致するフィールドはそのまま通過します。モデルが一致しないフィールドは、解決が必要な競合としてフラグ付けされます。

フィールドタイプ別の比較ルール
比較方法一致の意味
スカラー正規化された完全一致(トリム済み・小文字化・丸め済み)正規化後、すべての値が等しい
多言語対応言語ごとの比較各言語キーがモデル間で一致
配列集合比較(順序に依存しない)順序に関係なく同じ項目
オブジェクトプロパティ単位の再帰処理すべてのネストされたプロパティが一致
NullNullは欠損と等しい同等として扱われます
例: 2つのモデルで「Sanofi」をエンリッチする
Claude の出力
revenue: 42.2
gmp_status: true
description: “Sanofi is a global...”
GPT-4 の出力
revenue: 44.1
gmp_status: true
description: “Sanofi SA is a...”
結果: gmp_status = agreed | revenue = conflict (42.2 vs 44.1) | description = conflict(テキストが異なる)

ステップ2: 競合の解決

コンフリクトは、サイドバーでアービトレーションモデルを選択したかどうかに応じて、2 つの方法のいずれかで解決されます。

オプションA

ルールベースのマージ

各フィールドのデータ型に基づいて確定的なルールが適用されます。追加の LLM 呼び出しは不要で、解決は即座かつ無料です。

フィールドタイプルール根拠
文字列多数決。同数の場合は最長の値を採用します通常は詳細が多いほど良い結果になります
数値中央値外れ値に強い
ブール値多数決。同数の場合は true を優先します安全側のデフォルト
多言語対応言語ごとの多数決投票各言語を個別に解決
配列すべての項目の和集合すべての情報を保持
オブジェクトフィールド単位の再帰処理ネストされたフィールドにルールを適用
Null と 値null 以外を優先データの欠落は、いかなる値よりも望ましくありません

同点の決着方法: 投票が同数の場合、より高価なmodelの値が(能力の代理指標として)優先され、次にmodel名のアルファベット順で決まります。

オプションB

LLM調停

サイドバーで arbitration model を選択すると、競合はインテリジェントな解決のために LLM へ送られます。arbitrator は entity のコンテキスト、schema のフィールド説明、およびすべての競合値を受け取り、理由付きで判断を下します。

arbitratorが返す内容
選択された値最も正確だと判断された値
ソースmodel選択された値がどのモデルに由来するかです。
推論他の候補ではなくその値を選んだ理由
信頼度判断にどれだけ自信があるか(高、中、低)

フォールバック: arbitrationのmodelが失敗した場合(タイムアウトやエラー)、システムは自動的にルールベースのマージにフォールバックするため、常に結果が得られます。

ステップ3: 統合結果

競合解決後、システムは単一の統合結果を構築し、データベースに「アービトレーション」レコードとして保存します。すべての統合結果には監査証跡が含まれるため、各競合がどのように解決されたかを追跡できます。

監査証跡(アービトレーションのメタデータ)

マージされたすべての結果には、フュージョンのプロセスを記録するメタデータが含まれます:

“method”: “rule_based” | “llm”
“source_record_ids”: [“uuid-1”, “uuid-2”]
“total_fields”: 23
“agreed_fields”: 18
“conflicted_fields”: 5
“decisions”: [{ path, chosen_value, rule_used, ... }]

UIに表示される内容

フュージョンが完了すると、結果パネルの「統合」タブに以下が表示されます:

1
サマリーヘッダー
解決方法(ルールベースまたはLLM)と、「18件一致 / 5件解決 / 全23フィールド」のような件数を表示します。
2
マージ済み JSON
合意された値と解決された競合を単一のJSONドキュメントに統合した、完全な構造化出力です。
3
コンフリクトレポート
各競合の展開可能なカードで、フィールドパス、解決方法バッジ (多数決、中央値、和集合など)、選択された値がハイライトされたすべてのモデル値、LLM 調停が使用された場合は推論テキストを表示します。

バッチ処理での自動フュージョン

バッチエンリッチメントでは、2つ以上のモデルを選択すると融合が自動的に行われます。「Merge Results」を手動でクリックする必要はありません。エンティティに対してすべてのモデルが完了するとすぐに融合が実行され、統合された結果が個々のモデル出力とともに表示されます。

ストリーミングfusion: 単一entityおよびbatchのenrichmentの両方において、fusionの進捗はServer-Sent Events経由でストリーミングされます。fusion_startedconflicts_detectedfusion_completedのイベントをリアルタイムで確認できます。

ルールベース vs LLMアービトレーション:それぞれの使いどころ

ルールベース(無料・即時)
  • 投票ロジックが有効に機能する、主に事実データや数値データ向け
  • コストが重要となる大量処理またはバッチ処理
  • 競合がほとんど想定されないシンプルなスキーマ
  • 決定論的で再現可能な結果が欲しい場合
LLM調停(追加コスト)
  • 解決にコンテキストが重要となる複雑なスキーマ
  • 投票では不十分なテキストデータ(説明、要約)
  • 理由付きで説明可能な判断が必要な場合
  • 精度が追加コストに見合う、重要度の高いエンリッチメント