# Dokumentdaten mit Entscheidungsmodellen extrahieren

> Mit Entscheidungsmodellen lassen sich strukturierte Daten aus Dokumenten und Bildern günstig und mit geringer Latenz extrahieren. Wir zeigen, wie wir unsere API zur Dokumentextraktion mit unserem Entscheidungsmodell Strom gebaut haben.

Shashank Aggarwal · 17.10.2026 · 2 Min. Lesezeit · Engineering
Canonical: https://platform.uprelic.com/de/blog/dokumentdaten-mit-entscheidungsmodellen-extrahieren
English: https://platform.uprelic.com/blog/extracting-document-data-using-decision-models.md
Français: https://platform.uprelic.com/fr/blog/extraire-des-donnees-de-documents-avec-des-modeles-de-decision.md

---

Unser [letzter Beitrag](https://platform.uprelic.com/de/blog/rechnungen-mit-strom-analysieren) hat erklärt, wie wir eine Pipeline zur Datenextraktion aus Rechnungen gebaut haben, mit einem Entscheidungsmodell im Kern. Diesen Ansatz haben wir jetzt verallgemeinert, sodass er mit jeder Art von Dokument funktioniert, etwa Lebensläufen, Verträgen oder Formularen. Ihr könnt ihn [hier](https://platform.uprelic.com/console/demos/document-extractor) ausprobieren.

Angefangen hat es mit einem Nutzer, der mit Strom ganz bestimmte Felder aus den Typenschildern von elektronischen Geräten extrahiert, zum Beispiel aus diesem:

![Das Typenschild auf der Rückseite eines HP-Monitors, mit Produktnummer, Modellnummer und Seriennummer zwischen Prüfzeichen und Text in mehreren Sprachen](https://platform.uprelic.com/blog/media/extracting-document-data-using-decision-models/asset-label.jpg "Foto: Scott A. Miller, via Wikimedia Commons (File:HP_Pavilion_v72_17_inch_CRT_Monitor_Serial_Number_Plate_IMG_9405.JPG), CC BY 3.0, verkleinert.")

Zwei Felder waren interessant: **Modellbezeichnung und Seriennummer**. Der Ablauf sieht so aus:

1. Der Nutzer fotografiert das Typenschild mit seiner App.
2. Die App führt die Texterkennung (OCR) auf dem Gerät aus und schickt den erkannten Text an das Entscheidungsmodell, mit einer Anfrage wie der folgenden. Die Modellbezeichnungen sind vorab bekannt, deshalb sind sie die Optionen der ersten Frage. Die Seriennummer ist es nicht, deshalb sind die Optionen der zweiten Frage die per OCR erkannten Zeilen des Schilds:

```json
POST https://api.uprelic.com/v1/systemone
{
    "model": "strom-1.0.7",
    "state": "HEWLETT PACKARD\nCOLOR DISPLAY/彩色顯示器/彩色显示器/모니터\nPRODUCT NUMBER: P5303D\nModel No / 型號 / 型号/모델명: PE1165U\nASSEMBLY P/N : 262243-421\n...\nSerial No. 序號/序号:\nCNG34124S0\n...",
    "questions": {
        "q1": {
            "type": "choice",
            "criteria": {
                "PE1165U": null,
                "PE1240": null,
                ...
            },
            "instructions": "What is the model name of the device?"
        },
        "q2": {
            "type": "choice",
            "criteria": {
                "PRODUCT NUMBER: P5303D": null,
                "ASSEMBLY P/N : 262243-421": null,
                "Serial No. 序號/序号:": null,
                "CNG34124S0": null,
                ...
            },
            "instructions": "What is the serial number of the device?"
        }
    }
}
```

3. Die App zeigt dem Nutzer anhand der Antworten des Modells die Daten des Geräts an.

Ein Entscheidungsmodell passt hier gut, weil:
1. Es schnell ist: ~700 ms einschließlich Netzwerk-Roundtrip. So bleibt die App flüssig.
2. Es günstig ist: ~0,0001 €.

Das funktioniert aber nur, wenn:
1. Die OCR auf dem Gerät genau ist.
2. Eine einfache Liste von Zeilen reicht, um zu erkennen, welcher Wert zu welcher Beschriftung gehört. Die OCR macht aus „Serial No.“ und „CNG34124S0“ zwei getrennte Zeilen, und ihre Position auf dem Schild geht verloren. Bei einem einfachen Schild kann das Modell sie trotzdem zuordnen. Bei einem vollen Schild mit mehreren Nummern und Beschriftungen in mehreren Sprachen nicht.

Diese Einschränkungen gelten nicht nur für Typenschilder. Jedes Dokument mit unregelmäßig angeordnetem Text kann diesen Ablauf aus dem Tritt bringen. Deshalb haben wir einen neuen Endpunkt gebaut, `POST /v1/extract`, der beides angeht.

Ein paar interessante Details zum Endpunkt:

1. Strom sieht das Layout, nicht nur den Text. Jede Zeile wird mit ihrer Seite und Position geschickt, zusammen mit einem Bild der Seite, auf dem jede Zeile umrandet und mit ihrer ID markiert ist. So kann Strom eine Beschriftung dem Wert daneben oder darunter zuordnen, so wie ein Mensch die Seite liest.
2. Er übernimmt die OCR selbst, wenn ihr ein Bild oder ein gescanntes PDF schickt. Wir nutzen PP-OCRv6, eines der stärksten offenen OCR-Modelle, auf unseren eigenen GPUs, sodass die Datei nie unser internes Netzwerk verlässt.
3. Er verkettet mehrere Aufrufe des Entscheidungsmodells, um die Extraktion zu verbessern. Wenn die erste Strom-Anfrage zum Beispiel die besten Kandidaten für ein Feld liefert, lassen wir Strom auf dieser kleineren Auswahl noch einmal laufen, um zwischen etwa gleich wahrscheinlichen Kandidaten zu entscheiden.

Die gewünschten Felder beschreibt ihr als JSON Schema, zum Beispiel `"serial_number": {"type": "string"}`, und bekommt für jedes Feld die Zeile, in der es steht, einen typisierten Wert, eine Konfidenz und seine Position auf der Seite zurück. Um weiterhin aus einer bekannten Liste zu wählen, wie bei den Modellbezeichnungen oben, nehmt ein `enum`: `"model_name": {"enum": ["PE1165U", "PE1240"]}`.

Ihr könnt den Endpunkt [hier](https://platform.uprelic.com/console/demos/document-extractor) ausprobieren oder die [API](https://platform.uprelic.com/docs/document-extraction) in eurem bestehenden Setup nutzen.

Ergebnis der API, visualisiert:

![Dasselbe Typenschild, auf dem die von der API gefundenen Felder rot umrandet sind: Produktnummer, Nennspannung und -strom, Hersteller, Seriennummer und Herstellungsdatum](https://platform.uprelic.com/blog/media/extracting-document-data-using-decision-models/asset-label-result.jpg "Foto: Scott A. Miller, via Wikimedia Commons, CC BY 3.0, verkleinert und beschriftet.")