Validierungsregeln – Entity Enricher Dokumentation

Validierungsregeln

Acht Validierungsregeln sichern die Schemaqualität. Sie laufen im Code, sobald die KI-Schemagenerierung ihre Antwort zusammengestellt hat — ein letztes Sicherheitsnetz über einer Pipeline, die sich bereits Schritt für Schritt selbst korrigiert.

Wie die Selbstkorrektur funktioniert

Die Korrektur erfolgt dort, wo der Fehler entsteht, und nicht am Ende. Die Generierung ist eine Abfolge kleiner Aufrufe mit jeweils nur einem Anliegen, und jeder bringt seinen eigenen Validator mit: Er prüft die Antwort dieses Aufrufs, behält alles Gültige und fragt nur das erneut ab, was weiterhin fehlt. Ein Modell, das in Fragmenten antwortet, konvergiert dadurch, statt von vorn zu beginnen.

Korrekturablauf

SchrittantwortenEine eng gefasste Frage — etwa die Flags für einen Batch von Eigenschaften oder die Beschreibungen einer Domäne
Validator-ZusammenführungenGültige Einträge werden gesammelt; unbrauchbare werden einzeln verworfen und kosten den Batch nie seine guten Antworten
Falls unvollständigDer Wiederholungsversuch fordert nur die noch fehlenden Pfade an – bis zu 3 Versuche für diesen Schritt
Dann herabstufenVerbleibende Lücken werden deterministisch gefüllt und am Datensatz vermerkt – ein schwaches Modell kostet Sie also Beschreibungsqualität, nicht das Schema
ZusammenstellungDie 8 folgenden Regeln laufen als letzte Prüfung über das fertige Schema

Nur zwei Schritte können eine Generierung komplett scheitern lassen: die Benennung der Entität und die Zuordnung von Eigenschaften zu Fachdomänen. Alles andere hat einen deterministischen Fallback — deshalb sind hier auch kleine Modelle nutzbar.

Regeln für Generierung vs. Bearbeitung

Nicht alle Regeln gelten sowohl für die Schema-Generierung als auch für die KI-Bearbeitung. Regeln, die mit den Eingabedaten abgleichen, werden während der Bearbeitung übersprungen, da Sie absichtlich Felder hinzufügen oder entfernen können:

GeltungsbereichAngewendete RegelnWarum
GenerierungAlle 8 RegelnEingabedaten stehen zum Vergleich zur Verfügung
KI-BearbeitungNur Regeln 2, 3, 4, 5Keine Eingabedaten; Benutzer ändert die Struktur möglicherweise absichtlich

Die 8 Regeln

Regel 1

Anzahl der Expertisebereiche

Geltungsbereich: Nur Generierung

Die Anzahl der Fachbereiche darf das anhand Ihrer Eigenschaftsanzahl berechnete Maximum nicht überschreiten. Dies verhindert, dass die KI für kleine Schemas zu viele feingliedrige Bereiche erstellt.

Beispielfehler: Too many expertise domains: 6 defined, maximum is 3

Das Maximum wird als floor(property_count / 6) berechnet, mit einem Minimum von 1. Ein Schema mit 12 Eigenschaften erlaubt bis zu 2 Fachbereiche.

Regel 2

Mindestens eine Eigenschaft

Geltungsbereich: Beide

Jedes Schema muss mindestens eine Eigenschaft definieren. Ein leeres Schema kann nicht für die Anreicherung verwendet werden.

Beispielfehler: Schema must have at least one property

Dies erkennt Fälle, in denen die KI eine gültige JSON-Struktur erzeugt, aber vergisst, tatsächliche Felder einzuschließen.

Regel 3

Gültige JSON-Schema-Typen

Geltungsbereich: Beide

Jeder Eigenschaftstyp muss einer der Standard-JSON-Schema-Typen sein: string, number, integer, boolean, array, object oder null.

Beispielfehler: revenue: invalid type 'float'

Die KI erfindet manchmal Typen wie „float“, „decimal“ oder „date“. Diese Regel erkennt sie und fordert eine Korrektur zu einem gültigen Typ an.

Regel 4

$ref-Ziele vorhanden

Geltungsbereich: Beide

Jede $ref muss auf etwas Vorhandenes verweisen: #/$defs/... auf eine Entitätsdefinition, #/$enums/... auf einen Wertesatz. Hängende Referenzen unterbrechen die Anreicherungs-Pipeline.

Beispielfehler: manufacturer: $ref '#/$defs/Company' references undefined definition

Die beiden Namespaces sind getrennt: Eine #/$defs/-Referenz ist eine Beziehung zu einer verschachtelten Entität, während eine #/$enums/-Referenz eine Texteigenschaft auf eine geschlossene Liste zulässiger Werte beschränkt. Jede muss einen entsprechenden Eintrag in ihrem eigenen Block haben.

Regel 5

Expertise-Schlüssel vorhanden

Geltungsbereich: Beide

Der Expertise-Wert jeder Eigenschaft muss einem der definierten Expertisebereiche entsprechen. Das verhindert Tippfehler und Inkonsistenzen.

Beispielfehler: revenue: expertise 'finance' not in defined domains: ['financial_analyst']

Die KI verwendet möglicherweise „finance“ statt des definierten Schlüssels „financial_analyst“. Diese Regel erkennt die Abweichung, damit die KI sie korrigieren kann.

Regel 6

Expertise erforderlich

Geltungsbereich: Nur Generierung

Nicht-Objekt- und nicht bewahrte Eigenschaften müssen einer Expertise Domain zugewiesen sein. So wird sichergestellt, dass jedes anreicherbare Feld von einer spezialisierten Domain bearbeitet wird.

Beispielfehler: revenue: expertise is required for non-object types

Objekttypen sind ausgenommen, da ihre untergeordneten Eigenschaften ihre eigene Expertise-Domäne tragen. Erhaltene Felder sind ausgenommen, da sie unverändert durchgereicht werden.

Regel 7

Typ entspricht den Eingabedaten

Geltungsbereich: Nur Generierung

Der Schematyp jeder Property muss dem tatsächlichen Python-Typ des entsprechenden Werts in Ihren Eingabedaten entsprechen.

Beispielfehler: revenue: type mismatch - input is number but schema says 'string'

Wenn Ihre Eingabe "revenue": 42.5 enthält, muss das Schema den Typ "number" oder "integer" verwenden, nicht "string". Der Validator ist flexibel: Er akzeptiert "number" für Ganzzahlen und umgekehrt.

Regel 8

Alle Eingabeeigenschaften vorhanden

Geltungsbereich: Nur Generierung

Jeder Schlüssel in Ihren Eingabedaten muss als Eigenschaft im generierten Schema erscheinen. Dies verhindert, dass die KI stillschweigend Felder verwirft.

Beispielfehler: Missing property from input: 'headquarters'

Wenn Ihr Eingabe-JSON einen Schlüssel "headquarters" enthält, muss das generierte Schema ihn einschließen. So wird eine vollständige Abdeckung Ihrer Daten sichergestellt.

Typinferenz

Regel 7 (Typabgleich) verwendet automatische Typinferenz, um Ihre Eingabewerte mit den im Schema deklarierten Typen zu vergleichen. Die Inferenz ist flexibel, um Fehlalarme zu vermeiden:

EingabewertAbgeleiteter TypAkzeptiert auch
true / falseboolean(nur Boolean)
42integernumber
3.14numberinteger
"hello"string(nur String)
[1, 2, 3]array(nur Array)
{"key": "val"}object(nur Objekt)

Hinweis: Booleans werden vor Integers geprüft, da Boolean in manchen Sprachen ein Untertyp von Integer ist. Diese Reihenfolge verhindert, dass true als Integer interpretiert wird.

Diese Tabelle beschreibt, was der Validator akzeptiert, nicht was die Generierung erzeugt. Ein Beispielwert von 3 macht die Eigenschaft nicht zu einem Integer: Numerische Felder werden als number ausgeliefert, sofern nicht ein eigener Schritt bestätigt, dass die Größe wirklich diskret ist und kein beobachteter Wert dem widerspricht. Eine ganze Zahl in einer Stichprobe ist kein Beleg dafür, dass halbe Werte unmöglich sind – und eine falsche Integer-Deklaration würde 6.2 in einer abnehmenden Datenbank auf 6 abschneiden.

Nächste Schritte