// Zusammenspiel

Die Übergabe zwischen Classifier und Recognizer

Die beiden Module rufen sich nicht gegenseitig auf. Sie sind über Artefakte gekoppelt: der Classifier hinterlässt Pfad und Metadaten, der Recognizer liest sie und schließt daraus auf sein Modell. Diese lose Kopplung ist der Grund, warum Teilläufe, Wiederholungen und Korrekturen alle am selben Punkt wieder einsetzen können.

// Modul A · schreibt

Classifier

01 ABLAGEPFAD
<Klassifikator>/<Kategorie>/<Datei>
02 BLOB-METADATEN
AnalysedCategory
CategoryConfidence
03 JOURNAL-STUFE
Classified · Dokumentschlüssel
Übergabe
über Artefakte
kein direkter
Modulaufruf
// Modul B · liest

Recognizer

01 KLASSIFIKATOR AUS PFAD
Erstes Pfadsegment = Name des Klassifikatormodells
02 MODELL-NACHSCHLAG
Erkennungsmodell, dessen unterstützter Klassifikator passt
03 KATEGORIE-PRÜFUNG
Deckt das Modell die erkannte Dokumentart ab?
// Drei Ausgänge der Kategorie-Prüfung
Treffer

Modell deckt die Kategorie ab

Der Regelfall: die Analyse startet sofort mit dem zugeordneten Modell und seiner Engine. Kein Eingriff, kein Wartezustand.

Auto-Onboarding

Kategorie trainiert, Modell fehlt

Die Automatik legt selbst ein Erkennungsmodell an: Feldschema aus dem auslösenden Dokument vorgeschlagen, Analyzer veröffentlicht, das Dokument als dauerhaftes Beispiel angehängt. Die Zielsystem-Zuordnung bleibt bewusst offen — ungeprüfte Daten erreichen so nie das Zielsystem. Höchstens einmal pro Kategorie.

Übersprungen

Mit Grund, nicht stillschweigend

Bleibt kein Modell übrig, wird der Fall mit Klartextbegründung ins Journal geschrieben — „kein Erkennungsmodell für Klassifikator X“ oder „Kategorie Y im Modell Z nicht konfiguriert“. Ein Dokument verschwindet nie.

// Der Vertrag zwischen den Modulen
Artefakt Erzeugt von Ausgewertet von
Ablagepfad mit Klassifikator und Kategorie Classifier zur Laufzeit Recognizer — Modellsuche
Erkannte Dokumentart am Blob Classifier zur Laufzeit Recognizer — Kategorie-Prüfung
Konfidenz der Zuordnung Classifier zur Laufzeit Klassifikations-Gate, Journal, Monitor
Unterstützter Klassifikator je Modell Konsole FormRecognizerConfig Recognizer — Modellsuche
Unterstützte Kategorien je Modell Konsole FormRecognizerConfig Kategorie-Prüfung, Auto-Onboarding
Trainierte Kategorien und Schwellwert Konsole ClassifierConfig Klassifikations-Gate, Auto-Onboarding
// Engine-Wahl ist Sache des Modells

Jedes Erkennungsmodell trägt seine Engine: klassisch trainierte Feldextraktion oder ein autorisiertes Feldschema. Der Recognizer verzweigt pro Modell — alles danach ist engine-neutral, weil beide Wege dasselbe Ergebnisformat erzeugen. Der Classifier bleibt davon vollständig unberührt.

trainiertes Modell autorisiertes Schema ein Ergebnisformat
// Zwei Konsolen, eine Kette
ClassifierConfig
Trainingsdaten je Kategorie sammeln, Klassifikator bauen, ad hoc testen, Konfidenz-Schwellwert setzen.
FormRecognizerConfig
Hier entstehen die Erkennungsmodelle: mit dem Klassifikator und seinen Kategorien verknüpfen, festlegen welche Felder und Tabellen ausgelesen werden und wohin das Ergebnis im Zielsystem fließt.
Automatik · Content Understanding (CU)
Das Feldschema muss nicht von Hand angelegt werden: Content Understanding liest ein Beispieldokument und schlägt die zu extrahierenden Felder selbst vor. FormRecognizerConfig übernimmt den Vorschlag, veröffentlicht den Analyzer und hängt das Dokument als dauerhaftes Beispiel an — ein neues Erkennungsmodell entsteht so ohne manuelle Feldarbeit.
Beide Konsolen konfigurieren nur — gestartet und entschieden wird in der Verarbeitungskette.
// Demo

An Ihren eigenen Belegen gezeigt

Wir richten die Kette für eine Ihrer Dokumentarten ein und führen echte Dokumente durch — von der Zuführung bis in das Zielsystem. Wir melden uns innerhalb eines Werktags.

NexoGraph Dokumente

Dokumente erkennen, auslesen und zustellen — von der Zuführung bis ins Zielsystem.

© 2026 NexoGraph UG (haftungsbeschränkt) Köln · Deutschland
IT