Wenn Sie dasselbe Enrichment über mehrere KI-Modelle hinweg ausführen, kann Entity Enricher die Ergebnisse zu einer einzigen, hochzuverlässigen Ausgabe fusionieren. Die Fusion erkennt Konflikte zwischen den Modellausgaben und löst sie mithilfe deterministischer Regeln oder LLM-gestützter Arbitrierung auf.
Der Konfliktdetektor vergleicht jedes Feld über alle Modell-Outputs hinweg. Felder, bei denen alle Modelle übereinstimmen, werden unverändert übernommen. Felder, bei denen die Modelle nicht übereinstimmen, werden als Konflikte markiert, die aufgelöst werden müssen.
| Typ | Vergleichsart | Übereinstimmung bedeutet |
|---|---|---|
| Skalar | Normalisierte exakte Übereinstimmung (getrimmt, in Kleinbuchstaben, gerundet) | Alle Werte nach der Normalisierung gleich |
| Mehrsprachig | Die Primärsprache des Laufs entscheidet; Übersetzungsunterschiede lösen nur eine Zusammenführung pro Sprache aus | Derselbe Text in der Primärsprache – Formulierungsvarianten einer Übersetzung sind keine Abweichungen |
| Array | Mengenvergleich (reihenfolgeunabhängig) auf der Primärsprachenansicht der Elemente | Dieselben Elemente unabhängig von Reihenfolge oder Übersetzungsformulierung |
| Objekt | Pro Eigenschaft, solange die Identitätsfelder belegen, dass beide Modelle dasselbe beschreiben – andernfalls gilt das gesamte Objekt als ein Konflikt | Alle verschachtelten Eigenschaften stimmen überein |
| Null / leer | Ein Null-, Leerstring- oder Leer-Array-Wert ist eine Enthaltung, keine Aussage | Der ausgefüllte Wert gewinnt, ohne dass ein Konflikt gezählt wird |
Konflikte werden mit einer von zwei Methoden gelöst, je nachdem, ob Sie in der Seitenleiste ein Arbitrierungsmodell ausgewählt haben.
Deterministische Regeln werden je nach Datentyp des Felds angewendet. Fast immer ist dafür überhaupt kein LLM-Aufruf nötig — die Auflösung erfolgt sofort und kostenlos. Die einzige Ausnahme sind Zahlen, bei denen die Modelle stark voneinander abweichen und die keine Regel redlich entscheiden kann; siehe unten.
| Feldtyp | Regel | Begründung |
|---|---|---|
| String | Mehrheitsentscheid; bei Gleichstand gewinnt der längste Wert | Mehr Details sind in der Regel besser |
| Zahl | Der Modellwert, der dem Median am nächsten liegt | Robust gegenüber Ausreißern, niemals ein erfundener Durchschnitt |
| Boolean | Mehrheit; bei Gleichstand gewinnt true | Konservative Voreinstellung |
| Mehrsprachig | Mehrheitsentscheid pro Sprache, Vereinigung der Sprachen | Jede Sprache unabhängig aufgelöst |
| Array | Schlüsselbewusste Vereinigung: Elemente werden anhand ihrer Schlüsselfelder gruppiert, Schreibvarianten werden zusammengefasst, übereinstimmende Elemente werden feldweise zusammengeführt | Eine Zeile pro logischer Entität, nichts geht verloren |
| Objekt | Feldweise, wenn die Identität übereinstimmt; andernfalls wird das Objekt eines Modells vollständig übernommen | Zwei Objekte zu vermischen, die verschiedene Entitäten beschreiben, würde eine dritte erfinden, die kein Modell geliefert hat |
| Null vs. Wert | Den ausgefüllten Wert bevorzugen | Fehlende Daten sind schlimmer als jeder Wert |
Stichentscheid: Bei Stimmengleichheit gewinnt der Wert des teureren Modells (als Indikator für die Leistungsfähigkeit), danach entscheidet die alphabetische Reihenfolge der Modellnamen. Wird ein ganzes Objekt atomar übernommen, kommt die Vollständigkeit – die Anzahl der gefüllten Blätter – zwischen beide Kriterien: Wenn nichts beweist, welche Entität die richtige ist, gewinnt zuerst das stärkere Modell, dann die Antwort mit mehr Informationen.
Ein verschachteltes Objekt Feld für Feld zusammenzuführen ist nur sicher, solange beide Modelle dasselbe beschreiben. Wenn die Identitätsfelder das nicht belegen — abweichende Schlüssel oder gar keine Schlüssel bei einer echten Abweichung darunter —, wird das Objekt zu einem einzigen Konflikt und die Version eines Modells wird wortwörtlich übernommen. Andernfalls würde die Fusion eine Chimäre zusammensetzen: die Adresse des einen Modells am Unternehmen des anderen. Eine Folge ist beabsichtigt, sollte aber bekannt sein: Der Gewinner wird samt seiner Lücken übernommen, ein Feld, das der Gewinner leer gelassen hat, bleibt also leer — was die Entität an der Zulassungsschranke zur Datenbank aufhalten kann. Der Grund wird in den Validierungswarnungen des Laufs mitgeführt.
„Dem Median am nächsten“ ist richtig, wenn Modelle unterschiedlich runden, und falsch, wenn Modelle einander widersprechen – 0 gegenüber 1854 ist kein Rundungsunterschied. Erreicht die relative Streuung der Werte 20 %, wird dieses Feld an einen LLM-Arbiter eskaliert, der automatisch über die übliche Modellauswahl Ihrer Organisation bestimmt wird, und der Aufruf wird wie jeder andere abgerechnet. Solche Felder werden im Fusions-Audit-Trail als automatisch eskaliert markiert, sodass eine Zusammenführung, die Tokens gekostet hat, immer ausweist, welche Felder sie verursacht haben.
Wenn Sie in der Seitenleiste ein Arbitrierungsmodell auswählen, werden Konflikte zur intelligenten Auflösung an ein LLM gesendet. Der Arbitrator erhält den Entity-Kontext, die Beschreibungen der Schema-Felder und alle widersprüchlichen Werte und trifft dann fundierte Entscheidungen.
Fallback: Wenn das Arbitrierungsmodell fehlschlägt (Timeout, Fehler), greift das System automatisch auf eine regelbasierte Zusammenführung zurück, sodass Sie immer ein Ergebnis erhalten.
Nach der Konfliktlösung erstellt das System ein einzelnes zusammengeführtes Ergebnis und speichert es als „Arbitrierung“-Datensatz in der Datenbank. Jedes zusammengeführte Ergebnis enthält einen Prüfpfad, sodass Sie nachvollziehen können, wie jeder Konflikt gelöst wurde.
Jedes zusammengeführte Ergebnis enthält Metadaten, die den Fusionsprozess dokumentieren:
Derselbe Audit-Trail wird für jeden zusammengeführten Datensatz auf der History-Seite in dessen Übersicht-Registerkarte angezeigt. Ein zusammengeführter Datensatz listet die Modelle auf, die er zusammengeführt hat, anstatt eines eigenen Modells — und wenn die Zusammenführung regelbasiert war, wurde überhaupt kein LLM-Aufruf getätigt, sodass er keinen Prompt, keine Tokens und keine Kosten enthält.
Nach Abschluss der Fusion zeigt der Tab „Zusammengeführt“ im Ergebnispanel:
Bei der Batch-Anreicherung erfolgt die Fusion automatisch, sobald Sie zwei oder mehr Modelle auswählen. Sie müssen nicht manuell auf „Ergebnisse zusammenführen“ klicken — sobald jedes Modell für eine Entität erfolgreich war, läuft die Fusion und das zusammengeführte Ergebnis erscheint neben den einzelnen Modellausgaben. Ein Lauf, bei dem ein Modell fehlgeschlagen ist, wird bewusst nicht fusioniert: Das Zusammenführen des Verbliebenen würde stillschweigend eine unvollständige Antwort als abgestimmtes Ergebnis veröffentlichen. Stellen Sie zuerst das fehlende Modell wieder her — ein erneuter Versuch seiner fehlgeschlagenen Fachgebiete fusioniert den Lauf automatisch, sobald er wieder vollständig ist.
fusion_started, conflicts_detected und fusion_completed in Echtzeit.