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 |
Deterministische Regeln laufen bei jeder Fusion und klären alles, was sich aus den Werten der Modelle selbst belegen lässt. Wo sie eine Antwort nur bevorzugen können — ein widersprochener Wert, ein verschachteltes Objekt, das die Modelle unterschiedlich beschreiben, ein Element, das nur ein Modell erzeugt hat —, wird der Fall einer entscheidenden Instanz vorgelegt. Mit der Auswahl eines Arbitrierungsmodells in der Seitenleiste legen Sie fest, wer diese Instanz ist: die Regeln selbst oder ein LLM.
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 die von den Regeln ungeklärten Fragen diesem LLM vorgelegt. Es sieht die Identität der Entität, die Beschreibung jedes Felds und den Wert jedes Modells in Ihrer primären Anreicherungssprache — und es antwortet, indem es darauf zeigt, niemals indem es einen eigenen Wert schreibt.
Die Fragen werden Ebene für Ebene gestellt: zuerst die Entität selbst, dann jedes zugeordnete Array-Element in einem eigenen Aufruf, mit seiner eigenen Identität als Kontext („Akt I dieser Oper“) — und zu einem vom Arbiter verworfenen Element wird nie wieder gefragt. Der gemeinsame Teil des Prompts wird vom ersten Aufruf zwischengespeichert, sodass die tieferen Aufrufe parallel und zu einem Bruchteil der Kosten laufen.
Fallback: Wenn das Arbitrierungsmodell ausfällt (Timeout, Fehler), gelten die regelbasierten Entscheidungen, sodass Sie immer ein Ergebnis erhalten — und der Datensatz gibt an, welche Methode angewendet wurde.
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 Prüfpfad wird für jeden zusammengeführten Datensatz auf der Seite Verlauf im Tab „Übersicht“ angezeigt. Auch Entscheidungen innerhalb eines Arrays — ein Feld eines zugeordneten Elements, ein behaltenes oder verworfenes Element — werden aufgeführt, sodass das Weggelassene ebenso sichtbar ist wie das Behaltene. Ein per LLM arbitrierter Datensatz nennt seinen Arbiter als Modell; eine regelbasierte Zusammenführung listet stattdessen die zusammengeführten Modelle auf, da sie gar keinen LLM-Aufruf ausgelöst hat und weder Prompt noch Tokens noch Kosten verursacht.
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.