Full Field Anchor Search

Technologie-Erklärung zur kontextbasierten Datenextraktion & Mandanten-Profiling

1. Das Problem: Warum einfaches Regex scheitert

Klassische OCR-Systeme suchen oft "blind" nach Mustern im Text (Regular Expressions). Das führt bei komplexen Dokumenten häufig zu Fehlern.

❌ Das alte Problem (Blindes Regex)

Der Algorithmus sucht nach einem Preis (Zahl mit Komma). Er findet:

Kundennummer: 12.345
Telefonnummer: 030 123456
Einzelpreis statt Gesamtpreis

Ergebnis: Falsche Buchung, Chaos in der Buchhaltung.

✅ Die Lösung (Anchor Search)

Der Algorithmus sucht zuerst nach einem Ankerwort (z.B. "Gesamtbetrag").

Erst wenn er den Anker gefunden hat, sucht er in einem Radius von 60 Zeichen rechts daneben oder darunter nach dem Wert.

Ergebnis: 99,9% Trefferquote beim korrekten Endbetrag.

2. Wie die "Full Field Anchor Search" funktioniert

Das System definiert 5 Dimensionen von Ankern. Für jede Dimension kann eine Liste von Synonymen definiert werden.

[Dokument Text]

Sehr geehrter Kunde,
Ihre Kundennummer ist 50020.

Rechnungsnummer: ....... RE-2023-001
Leistungsdatum: ......... 12.05.2024

Position 1 ..... 100,00
Gesamtbetrag: ........... 119,00 €

Das System ignoriert die Kundennummer "50020", obwohl sie wie eine Rechnungsnummer aussieht, weil kein Anker in der Nähe ist. Es findet "RE-2023-001" zielsicher, weil der Anker "Rechnungsnummer" direkt davor steht.

Die 5 Dimensionen

#️⃣ Nummern-Anker: Findet Rechnungsnummern (Trigger: "Rechnung Nr.", "Beleg", "Invoice No").
📅 Datums-Anker: Findet das Rechnungsdatum (Trigger: "Leistungsdatum", "Datum", "Date").
💰 Gesamt-Anker: Findet den Bruttobetrag (Trigger: "Zahlbetrag", "Gesamtsumme", "Total").
📉 Netto-Anker: Findet den Nettowert (Trigger: "Nettowarenwert", "Zwischensumme").
🏛 Steuer-Anker: Findet den MwSt-Betrag (Trigger: "Umsatzsteuer", "Tax", "VAT").

3. Mandantenfähigkeit & Profile (Redis Architecture)

Das mächtigste Feature des KAI Backends ist die Trennung von Code und Logik. Jede Firma (Mandant) oder jeder Lieferant kann unterschiedliche Bezeichnungen auf Rechnungen verwenden.

Anstatt den Python-Code zu ändern, erstellen Sie einfach ein Parsing-Profil im Dashboard. Dieses Profil wird in der Redis-Datenbank gespeichert und zur Laufzeit in die KI geladen.

Szenario: Zwei verschiedene Lieferanten

Feature	Lieferant A (Deutschland)	Lieferant B (USA)
Bezeichnung für Summe	"Zahlbetrag"	"Amount Due"
Bezeichnung für Steuer	"Umsatzsteuer 19%"	"Sales Tax"
Profil-Lösung	Profil "Standard_DE" lädt Anker: ["Zahlbetrag", "Umsatzsteuer"]	Profil "Import_USA" lädt Anker: ["Amount Due", "Sales Tax"]
Code-Änderung nötig?	NEIN	NEIN

4. Technischer Ablauf im Backend

So fließen die Daten durch das System (z.B. in workspace_features.py):

Ein Dokument wird geladen (PDF/Bild).
Der Orchestrator prüft, ob ein profile_name übergeben wurde.
Falls JA: Lädt das System die spezifischen Anker-Listen aus Redis (z.B. parsing_profile:Lieferant_A).
Falls NEIN: Lädt das System die globalen Defaults aus config.json.
Die Funktion _internal_extract_invoice_details iteriert durch alle Anker.
Für jeden Anker wird extract_near_anchor aufgerufen, um den Wert im Textfenster (60 Zeichen) zu finden.
Das Ergebnis ist ein präzises JSON-Objekt.

Wirtschaftlicher Vorteil:
Da diese Logik extrem präzise ist (basierend auf der Struktur des Dokuments), muss das System viel seltener auf teure KI-Modelle (GPT-4, Gemini) zurückgreifen. Das spart bei tausenden Rechnungen signifikant API-Kosten.