Erkennen Sie Schema-Eigenschaften, deren Werte zwischen Modellen oder zwischen Durchläufen variieren, und korrigieren Sie sie, bevor sie Ihre Daten verunreinigen – für Anreicherungen, die reproduzierbar, vergleichbar und präzise sind.
Entity Enricher behandelt LLMs als abfragbare Wissensdatenbanken. Das funktioniert nur, wenn ein Eigenschaftsname eine einzige reproduzierbare Antwort festlegt. Eine Eigenschaft wie annual_revenue tut das nicht: Welches Geschäftsjahr? Welche Währung? Millionen oder Einheiten? Jedes Modell – und jeder erneute Durchlauf desselben Modells – kann einen anderen Rahmen wählen, sodass die Werte voneinander abweichen, selbst wenn kein Modell falsch liegt.
Volatile Eigenschaften schaden allem Nachgelagerten: Die Multi-Modell-Fusion sieht Konflikte, die in Wirklichkeit Rahmungsunterschiede sind, und die Konsistenzstreuungen im Benchmark vergrößern sich aus Gründen, die nichts mit der Modellqualität zu tun haben. Die Nichtdeterminismus-Prüfung findet diese Eigenschaften und sagt Ihnen, wie Sie sie festlegen.
Jede markierte Eigenschaft wird einer von vier Ursachen zugeordnet, jede mit ihrer eigenen Lösung:
| Ursache | Beispiel | Abhilfe |
|---|---|---|
| Zeitlich | ceo, stock_priceceo_2025 | Ein sich änderndes Faktum ohne Ankerdatum – legen Sie den Zeitraum fest oder strukturieren Sie es in ein nach Zeitraum indiziertes Array um. |
| Mehrdeutig | annual_revenuerevenue_fy2024_usd_millions | Der Name legt Einheit, Währung, Zeitraum oder Umfang nicht fest – betten Sie den fehlenden Rahmen in den Namen oder die Beschreibung ein. |
| Subjektiv | reputationesg_risk_rating_sustainalytics | Keine objektive Grundwahrheit – ersetzen Sie sie durch einen messbaren Näherungswert oder eine feste Skala; andernfalls bleibt sie als Hinweis markiert. |
| Mehrwertig | top_competitorstop_3_competitors_by_revenue | Mehrere gleichermaßen korrekte Antworten, meist eine unbegrenzte Liste – begrenzen Sie sie und geben Sie das Sortierkriterium an. |
Umbenennen ist nicht die einzige Lösung: Für Schema-Eigenschaften schlägt der Analyzer auch eine Beschreibungskorrektur vor, die den fehlenden Rahmen festlegt. Eine präzisere Beschreibung erreicht die anreichernde KI genauso wie der Name, bricht aber nie Ihren Datenvertrag – daher ist sie die bevorzugte Lösung für bereits verwendete Schemas.
Nachdem ein Beispiel generiert wurde, überprüft es der Analyzer. Eindeutige Umbenennungen werden automatisch auf von der KI erfundene Schlüssel angewendet (nie auf Felder, die Sie selbst benannt haben), und strukturelle Korrekturen werden für bis zu zwei Korrekturrunden an den Generator zurückgegeben. Beispiele, die auf angehängten Dokumenten basieren, werden übersprungen – ihre Werte stammen aus dem Quelldokument, nicht aus dem Gedächtnis des Modells.
Sobald ein generiertes Schema gespeichert wurde, versieht ein Nachlauf jede Eigenschaft mit ihrem Nichtdeterminismus-Level. Dieser Schritt ist bestmöglich: Schlägt er fehl, bleibt die Generierung selbst davon unberührt.
Die Schaltfläche „Erneut prüfen“ analysiert nur Eigenschaften, die noch keine Annotation haben, und wechselt zu einer vollständigen Neuanalyse, sobald jede Eigenschaft annotiert ist.
Beispiel-JSON, das Sie zur Schema-Erstellung einfügen, kann zustandslos analysiert werden – Sie erhalten einen Bericht über riskante Eigenschaftsnamen, ohne dass etwas verändert wird.
Die Prüfung ist nur beratend. Sie blockiert niemals die Generierung, lehnt niemals eine Anreicherung ab, und ihre Annotationen werden aus jedem Prompt entfernt, der an die anreichernden Modelle gesendet wird – sie informiert Sie, nicht die KI.
Markierte Eigenschaften zeigen im Schema-Editor ein „variiert“-Badge: Bernstein für mittleres Risiko, Rot für hohes Risiko. Beim Überfahren des Badges erscheint die Analyzer-Notiz, die erklärt, was variiert und warum. Als deterministisch eingestufte Eigenschaften tragen kein Badge.
Ein Urteil wird über Name und Beschreibung einer Eigenschaft gemeinsam gefällt – wird eine Eigenschaft 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 möchten Sie nach dem Anwenden einer vorgeschlagenen Umbenennung: Die erneute Prüfung bestätigt, ob der neue Name deterministisch ist.
Die Prüfung lässt sich pro Schema über das Überlaufmenü des Schema-Editors abschalten. Bei Deaktivierung wird der Nachlauf nach der Generierung übersprungen, und die Abzeichen, die Schaltfläche „Erneut prüfen“ sowie Veraltet-Warnungen werden ausgeblendet. Vorhandene Annotationen bleiben erhalten (nur ausgeblendet), und beim erneuten Aktivieren der Prüfung an einem noch nie analysierten Schema wird sie automatisch ausgeführt.
Schemas, die aus angehängten Dokumenten generiert werden, starten mit deaktivierter Prüfung: Ihre Werte werden aus dem Quelldokument übernommen, sodass eine Varianz des Modellwissens von Lauf zu Lauf nicht zutrifft.
Analyzer-Notizen werden in Ihrer Oberflächensprache verfasst – ein französischer Nutzer sieht französische Erklärungen, ein japanischer japanische. Vorgeschlagene Eigenschaftsnamen bleiben englisch, entsprechend den Namenskonventionen für Schemas.
Jede Analyse ist ein echter (günstiger) Modellaufruf, der als eigener Prompt auf dem Datensatz erfasst und wie jede andere KI-Nutzung von den Credits abgezogen wird. Inkrementelle erneute Prüfungen kosten nur die tatsächlich analysierten Eigenschaften.
Die Schema-Generierung selbst ist angewiesen, deterministische Namen und Beschreibungen zu erzeugen (festgelegte Zeiträume, Einheiten, Sortierkriterien), sodass die meisten Schemas sauber herauskommen und der Analysator nur die Nachzügler abfangen muss.
Die Prüfung ist programmatisch verfügbar:
| Erkennen | Beschreibung |
|---|---|
POST /api/schema/analyze-sample | Eingefügtes Beispiel-JSON analysieren – zustandsloser Bericht, nichts wird geändert |
POST /api/schema/saved/{id}/analyze | Ein gespeichertes Schema analysieren und Annotationen schreiben – standardmäßig inkrementell, force=true analysiert alles neu |
analyze_sample_determinism | MCP-Tool – derselbe zustandslose Beispielbericht von Claude oder einem beliebigen MCP-Client |
analyze_schema_determinism | MCP-Tool – ein gespeichertes Schema annotieren; mit edit_schema kombinieren, um eine vorgeschlagene Umbenennung anzuwenden |
Weitere Informationen zur Authentifizierung und zum vollständigen Tool-Katalog finden Sie in der API-Referenz und im MCP-Server-Leitfaden.