Finden Sie Schema-Eigenschaften, die mehr als eine Frage stellen könnten — sehen Sie die konkurrierenden Lesarten nebeneinander und legen Sie jede Eigenschaft auf eine einzige Bedeutung fest, bevor die Daten erhoben werden.
Entity Enricher behandelt LLMs als abfragbare Wissensdatenbanken, und ein Eigenschaftsname ist die Frage, die Sie stellen. Lässt der Name mehrere Lesarten zu, wählt jedes Modell stillschweigend eine aus — so kommt size bei einem Unternehmen von einem Modell als Mitarbeiterzahl zurück, von einem anderen als Umsatzzahl und von einem dritten als Grundfläche. Die Modelle waren sich nicht über einen Fakt uneinig. Sie haben verschiedene Fragen beantwortet, und Ihre Spalte enthält nun eine Mischung von Antworten, die kein nachgelagerter Abnehmer auseinanderhalten kann.
Erst das Festlegen der Bedeutung macht eine Anreicherung modellübergreifend vergleichbar und über die Zeit stabil. Es bereinigt auch alles Nachgelagerte: Die Multi-Modell-Fusion sieht keine Konflikte mehr, die in Wahrheit zwei Fragen sind, und Benchmark-Vergleiche bestrafen Modelle nicht länger dafür, dass sie Ihr Schema anders lesen als die Referenz.
Ein Sachverhalt, der sich schlicht im Lauf der Zeit ändert, ist keine Mehrdeutigkeit. Ein Schema ist ein dauerhafter Vertrag: Ein schlicht benanntes ceo bedeutet also „der CEO zum Zeitpunkt der Anreicherung“, und ein erneuter Lauf des Schemas im nächsten Jahr sollte den neuen zurückgeben. Die Prüfung schlägt nie vor, ein Datum im Namen festzuschreiben — das würde jeden künftigen Lauf zunichtemachen.
Die gesamte Prüfung besteht aus einer einzigen Frage, die an jede Eigenschaft gestellt wird: Wie viele verschiedene Dinge könnte ihr Name im Kontext des übergeordneten Objekts abfragen? Die Anzahl ist das Urteil.
| Lesarten | Urteil | Was das bedeutet |
|---|---|---|
| Genau eine | Löschen | Jedes Modell schlägt dasselbe nach. Kein Chip, nichts zu korrigieren. |
| Zwei oder mehr | Mehrdeutig | Jedes Modell legt sich auf seine eigene Lesart fest, sodass die Spalte unbemerkt Antworten auf verschiedene Fragen vermischt. Die Prüfung benennt die konkurrierenden Lesarten und schlägt eine Formulierung vor, die nur eine davon beibehält. |
| Keine | Nicht zuordenbar | Der Name benennt nichts, was das übergeordnete Objekt besitzt, also kann das Modell keinen Wert nachschlagen – es erfindet einen. Die aufgeführten Lesarten sind jene, die der Analyzer geprüft und verworfen hat; die Abhilfe ist eine Umbenennung oder eine Entfernung: Keine Beschreibung kann einer Entität eine Eigenschaft geben, die sie nicht hat. |
Eine Eigenschaft, die genau eine Sache benennt, kann dennoch markiert werden, wenn der Wert ohne Rahmen bleibt — der Leser weiß, wonach gefragt wird, aber nicht, in welchen Begriffen die Antwort zurückkommt. Dies sind die wiederkehrenden Muster:
| Unterfall | Beispiel | Was offen ist |
|---|---|---|
| Unklarer Bezug | Companysize | Der Name verweist auf mehrere verschiedene Fakten, die das übergeordnete Objekt tatsächlich besitzt – Mitarbeiterzahl, Umsatz, Grundfläche. Nichts am Namen trifft eine Wahl. |
| Unklares Maß oder unklare Einheit | Companyannual_revenue | Ein Fakt, aber keine Währung, kein Zeitraum und kein Brutto-/Netto-Bezug – eine plausible Antwort kann um drei Größenordnungen danebenliegen und trotzdem „richtig“ sein. |
| Unklare Skala oder Richtung | Supplierrisk_score | Kein angegebener Bereich und keine angegebene Polarität: 0–10 oder 0–100 – und bedeutet ein hoher Wert mehr Sicherheit oder mehr Risiko? Zwei Modelle können sich gegenseitig umkehren. |
| Unklarer Umfang oder unklare Abgrenzung | Companyemployees | Welche Teilmenge, welche Aggregationsebene, wessen Perspektive – der gesamte Konzern oder dieser Standort, Mitarbeiterzahl oder Vollzeitäquivalente, Auftragnehmer eingeschlossen oder nicht. |
| Nicht zuordenbar | Authorrelease_year | Ein Autor hat kein Erscheinungsjahr — seine Bücher haben eines. Das Modell kann dies nicht nachschlagen und erfindet es deshalb. Benennen Sie die Eigenschaft in etwas um, das dem übergeordneten Objekt gehört, oder verschieben Sie sie an das Objekt, das es besitzt. |
Fließtext-Eigenschaften – description, summary, notes, bio – werden nie markiert. Ihre Formulierung unterscheidet sich naturgemäß von Modell zu Modell, aber die gestellte Frage ist völlig klar, und nur das bewertet diese Prüfung. Bei Mehrdeutigkeit geht es um die Frage, nie darum, wie ähnlich sich die Antworten sehen.
Ein Urteil für sich allein („das ist unklar“) lässt Sie raten, was der Analyzer im Sinn hatte. Deshalb führt jeder Befund seine Interpretationen mit: zwei bis vier kurze, klar unterschiedene Lesarten, die die Eigenschaft zulässt, die wahrscheinlichste zuerst. Diese Liste ist der Befund — kann der Analyzer keine zwei Lesarten benennen, wird der Befund als Rauschen verworfen, statt Ihnen angezeigt zu werden.
annual_revenue bei einem UnternehmenDaneben steht eine vorgeschlagene Beschreibung, die genau eine davon beibehält — hier „Konzernumsatz in USD für das letzte abgeschlossene Geschäftsjahr, brutto vor Retouren“. Ihre Anwendung kostet nichts: Die Beschreibung erreicht das anreichernde Modell genauso wie der Name, aber die Eigenschaft behält ihren Namen, sodass sich kein Datenvertrag verschiebt. Wenn der Name selbst in die Irre führt, enthält der Befund zusätzlich vorgeschlagene Namen.
Die ausgeschriebenen Lesarten zu sehen, klärt eine Eigenschaft meist schneller als jede Erklärung: Sie erkennen die gemeinte Lesart wieder – und der Rest ist das, was Sie bisher unbemerkt erhalten haben.
Nachdem ein Beispiel erzeugt wurde, prüft der Analyzer dessen Eigenschaftsnamen und liefert einen Mehrdeutigkeitsbericht. Eindeutige Umbenennungen werden automatisch auf von der KI erfundene Schlüssel angewendet (nie auf Felder, die Sie selbst benannt haben), sodass sich das Beispiel, das Sie prüfen, bereits besser liest. Er markiert außerdem überspezialisierte Eigenschaften — Merkmale, die aus der Beispielinstanz eingesickert sind und nur zu einem Untertyp passen (die Medaillen eines Sportlers an einer generischen Person) — und schlägt einen enger gefassten Entitätstyp vor. Die Prüfung der Identitätsabgrenzung läuft hier direkt danach als eigener Aufruf: Sie klärt die Form verwandter Elemente, bevor Sie das Beispiel prüfen. Beispiele, die auf angehängten Dokumenten beruhen, werden übersprungen — ihre Werte stammen aus dem Quelldokument, nicht aus dem Gedächtnis des Modells.
Sobald ein generiertes Schema gespeichert ist, versieht ein Nachlauf jede Eigenschaft mit ihrem Mehrdeutigkeitsurteil und schlägt für die weiterhin offenen Fälle Umbenennungen vor. Beziehungsstellen sind zu diesem Zeitpunkt bereits annotiert – die Generierung beurteilt deren Scoping selbst, als einen ihrer eigenen Schritte –, sodass der Nachlauf nur Eigenschaftsnamen abdeckt. Dieser Schritt erfolgt nach bestem Bemühen: Schlägt er fehl, bleibt die Generierung selbst davon unberührt.
Die Schaltfläche „Erneut prüfen“ führt beide Prüfungen – Eigenschaftsnamen und Beziehungsstellen – als zwei parallele Aufrufe aus. Dies ist die einzige Stelle, die eine neu formulierte Beschreibung statt einer Umbenennung vorschlägt. Sie analysiert nur, was noch keine Annotation hat, und wechselt zu einer vollständigen Neuanalyse, sobald alles annotiert ist.
Beispiel-JSON, das Sie zur Schemaerstellung einfügen, kann zustandslos analysiert werden – Sie erhalten einen Bericht über mehrdeutige und nicht zuordenbare Eigenschaftsnamen sowie über verknüpfte Elemente, die Entitätsfakten mit Paarungsfakten vermischen, ohne dass etwas verändert wird.
Derselbe Befund schlägt an einer Stelle eine Umbenennung und an anderer eine Beschreibung vor – und der Grund dafür ist wissenswert. Zum Zeitpunkt der Generierung existiert die Beschreibung noch nicht unabhängig: Sie wird aus dem Namen geschrieben und kann die Mehrdeutigkeit daher nur wiederholen. Der Name ist das Einzige, was sich korrigieren lässt, und noch hängt nichts von ihm ab. Deshalb schlagen sowohl die Beispielgenerierung als auch der Nachlauf der Schemagenerierung Umbenennungen vor.
Sobald das Schema produktiv ist, verschiebt das Umbenennen einer Eigenschaft Spalten, bricht Abfragen und vergibt neue Schlüssel für synchronisierte Tabellen, während eine schärfere Beschreibung das Modell ebenso direkt erreicht und sonst nichts verändert. Die Regel ist daher einfach: Solange nichts vom Schema abhängt, benennen Sie um; sobald es produktiv ist, verankern Sie die Bedeutung in der Beschreibung – und heben Sie die Umbenennung für die Fälle auf, in denen der Name selbst das Problem ist.
Die Prüfung ist rein beratend. Nichts analysiert Ihre gespeicherten Schemas im Hintergrund: Sie läuft bei der Generierung und wenn Sie auf „Erneut prüfen“ klicken. Sie blockiert nie eine Generierung, lehnt nie eine Anreicherung ab, und ihre Annotationen werden aus jedem Prompt entfernt, der an die anreichernden Modelle geht – sie informiert Sie, nicht die KI.
Markierte Eigenschaften zeigen im Workflow-Editor einen „ambiguous“-Chip: bernsteinfarben, wenn sich die Lesarten weitgehend überschneiden und nur Randfälle abweichen, rot, wenn die konkurrierenden Lesarten wesentlich andere Daten ergeben würden. Als eindeutig eingestufte Eigenschaften tragen keinen Chip. Beim Überfahren des Chips erscheinen der Hinweis des Analyzers, die gefundenen konkurrierenden Lesarten und die vorgeschlagene Beschreibung bzw. die vorgeschlagenen Namen — Entscheidung und Korrektur stehen also im selben Tooltip.
Ein Urteil wird über Name und Beschreibung einer Eigenschaft gemeinsam gefällt — wird eine Eigenschaft also umbenannt oder ihre Beschreibung bearbeitet, entfällt ihre Annotation. Der Editor hebt solche Eigenschaften als veraltet hervor und bietet eine erneute Prüfung an, die nur das Fehlende analysiert. Genau das wollen Sie, nachdem Sie eine vorgeschlagene Korrektur angewendet haben: Die erneute Prüfung bestätigt, ob die neue Formulierung wirklich eine einzige Lesart festlegt.
Die Identitäts-Zuordnung ist eine zweite Prüfung: Sie läuft als eigener Modellaufruf parallel zur Mehrdeutigkeitsprüfung und wird gemeinsam mit ihr berichtet. Sie überprüft jede Beziehungsstelle – die Einträge eines verknüpften Arrays sowie verschachtelte Objekte: Vermischt eine davon Fakten über die verknüpfte Entität selbst (ihr Name, ihr Land) mit Fakten über die Paarung (eine für dieses übergeordnete Objekt gehaltene Rolle, eine Bezeichnung pro übergeordnetem Objekt), so teilen sich beide eine Identität – und erneute Anreicherungen überschreiben die Fakten der Paarung über alle übergeordneten Objekte hinweg. Solche Stellen tragen einen bernsteinfarbenen Chip „gemischte Fakten“, dessen Tooltip die empfohlene Struktur zeigt: die eigenen Felder der Entität in ein Unterobjekt verschachtelt, die Felder der Paarung am Eintrag belassen. Enthält der Eintrag bereits ein solches Unterobjekt, fällt die Korrektur kleiner aus – die fehlplatzierten Felder wandern in das bereits vorhandene.
Die Aufteilung wird während der Beispielgenerierung angewendet, bevor Sie das Beispiel freigeben: Die Struktur wird am ersten Beispiel festgelegt, jede umstrukturierte Stelle erscheint in den Generierungswarnungen, und die übrigen Beispiele des Batches werden gegen die festgelegte Struktur generiert. Schemas, die aus einem frischen Beispiel generiert werden, sind daher in der Regel sauber. Beispiele, die auf angehängten Dokumenten beruhen, bleiben so, wie ihre Quellen es nahelegen, und erhalten stattdessen den Chip.
Die Schemagenerierung selbst strukturiert das von Ihnen freigegebene Beispiel nie um – sie beurteilt dieselben Stellen und meldet, was sie findet. Bei einem bestehenden oder handgeschriebenen Schema liegt die Korrektur daher im Chip: Er bietet eine Aufteilung per Klick, die das Beispiel umstrukturiert und das Schema daraus neu generiert. Die Struktur ist der Vertrag, sie wird also durch Neugenerierung aus einem neuen Beispiel geändert und nie an Ort und Stelle gepatcht. Eine Stelle, die Sie nicht aufteilen, funktioniert weiterhin – sie behält lediglich eine gemeinsame Identität und den Chip. Der Chip verschwindet von selbst, sobald sich der Feldsatz des Eintrags ändert.
Die Prüfung lässt sich pro Schema über das Überlaufmenü des Workflow-Editors deaktivieren. Ist sie deaktiviert, entfällt der Durchlauf nach der Generierung, die Chips, die Schaltfläche „Erneut prüfen“ und die Veraltet-Warnungen werden ausgeblendet, und die Analyse-Endpunkte antworten mit dem Fehler ambiguity_check_disabled. Bestehende Annotationen bleiben erhalten (sie werden nur ausgeblendet); wird die Prüfung für ein nie analysiertes Schema wieder aktiviert, läuft sie automatisch.
Bei jedem generierten Schema ist die Prüfung anfangs aktiviert, auch bei Schemas, die aus angehängten Dokumenten generiert wurden. Mehrdeutigkeit ist eine Eigenschaft der Formulierung des Schemas, nicht der Herkunft der Werte eines einzelnen Laufs: Das Dokument hat diese Werte einmalig festgelegt, doch das Schema wird weiterhin für Entitäten wiederverwendet, die es nie abgedeckt hat. Was das Dokument sehr wohl verändert, ist der Schritt Beispiel – dessen Eigenschaftsnamen stammen aus dem Vokabular des Quelldokuments und werden daher nie im Code umbenannt; stattdessen trägt das daraus gebaute Schema die Prüfung.
„Der Jahresumsatz des Unternehmens“ fügt keine Information hinzu, die der Name nicht bereits enthielt; der Analyzer behandelt eine solche Beschreibung deshalb, als wäre sie gar nicht vorhanden, und beurteilt allein den Namen. Eine Beschreibung rechtfertigt ihren Platz, indem sie die Einheit, den Zeitraum, die Größenordnung oder die Abgrenzung benennt.
Hinweise und Interpretationen des Analyzers werden in Ihrer Oberflächensprache verfasst — eine französische Nutzerin sieht französische Lesarten, ein japanischer Nutzer japanische. Vorgeschlagene Eigenschaftsnamen bleiben auf Englisch, passend zu den Namenskonventionen von Schemas.
Jede Analyse ist ein echter (günstiger) Modellaufruf — zwei davon, parallel ausgeführt, wenn zusätzlich Beziehungsstellen abzugrenzen sind. Jeder wird als eigener Prompt am Datensatz erfasst, unter dem Typ ambiguity_analysis, und wie jede andere KI-Nutzung von den Credits abgezogen. Inkrementelle erneute Prüfungen kosten nur für die tatsächlich analysierten Eigenschaften und Stellen.
Die Beispiel- und die Schemagenerierung sind selbst angewiesen, pro Eigenschaft genau eine Sache zu benennen und Beschreibungen zu verfassen, die Einheit, Skala und Abgrenzung angeben – und bei strittigen Listen eine Obergrenze in der Beschreibung zu nennen, statt eine Anzahl in den Namen zu zwängen. Die meisten Schemas entstehen daher sauber, und der Analyzer muss nur die Nachzügler abfangen.
Die Prüfung ist programmatisch verfügbar:
| Erkennen | Beschreibung |
|---|---|
POST /api/schema/analyze-sample | Eingefügtes Beispiel-JSON analysieren – beide Prüfungen parallel hinter einer Anfrage, zustandsloser Bericht, nichts wird verändert |
POST /api/schema/saved/{id}/analyze | Ein gespeichertes Schema analysieren und die Annotationen beider Prüfungen schreiben – standardmäßig inkrementell, force=true analysiert alles neu |
POST /api/schema/scoping-split | Eine „gemischte Fakten“-Aufteilung auf einen Beispielsatz anwenden – deterministisch, kostenlos, nichts wird gespeichert; die zurückgegebenen Beispiele fließen wieder in die Schemagenerierung ein |
analyze_sample | MCP-Tool – derselbe zustandslose Beispielbericht, beide Prüfungen, aus Claude oder einem beliebigen MCP-Client |
analyze_schema | MCP-Tool – annotiert ein gespeichertes Schema; in Kombination mit update_schema, um eine vorgeschlagene Beschreibung oder Umbenennung anzuwenden |
Befunde kommen mit einer Art (kind: ambiguous oder unmappable), einem level, einem Hinweis, der Liste der Interpretationen und dem Korrekturvorschlag zurück. In einem gespeicherten Schema werden sie an jeder Eigenschaft als ambiguity abgelegt; die Beispielerzeugung gibt sie unter ambiguity_report zurück.
Weitere Informationen zur Authentifizierung und zum vollständigen Tool-Katalog finden Sie in der API-Referenz und im MCP-Server-Leitfaden.