Von gescannten Laborberichten zu strukturierten Daten: Abwägungen bei der OCR-Architektur
Wie ein budgetbeschränktes Gesundheits-Start-up OCR-Bibliotheken, Google Cloud APIs sowie ein selbst gehostetes Vision-LLM abwägen kann, um medizinische Scans in strukturiertes JSON umzuwandeln.
Quellen: How We Chose Our OCR Architecture for a Medical Reports Pipeline (Part 1 of 2)
Ein Foto eines Laborexpräts in eine Zeile umzuwandeln, die „Hemoglobin, 13,2, g/dL, Referenzwert 12,0–15,5“ anzeigt, klingt nach einem OCR-Problem, doch die reine Texterkennung ist nur der erste Schritt. Die eigentliche Herausforderung besteht darin, aus einem unordentlichen Scan kostengünstig, zuverlässig und ohne Datenleckage Bedeutung zu gewinnen. Diese Anleitung zeigt die architektonischen Entscheidungen hinter einem solchen Extraktionsprozess für ein MVP medizinischer Berichte, damit Sie dieses Vorgehen bei ähnlichen Problemen der Dokumentverarbeitung mit begrenztem Budget wiederverwenden können.
Die Anforderung, die alles bestimmt
Stellen Sie sich ein Produkt für die Frühphase der Gesundheitsvorsorge vor. Patienten laden einen gescannten medizinischen Bericht hoch – entweder als PDF oder als Foto eines ausgedruckten Labortests auf dem Handy. Das System muss diesen Bericht in strukturierte Gesundheitsdaten umwandeln, die sowohl der Patient als auch sein Arzt durchsehen können und die später von künstlicher Intelligenz zur Analyse genutzt werden können. Jede Dateneintragung benötigt vier Elemente: den Namen des Parameters, seinen gemessenen Wert, die Einheit sowie den Referenzbereich.
Dieser letzte Satz ist der Schlüssel. Ein Tool, das nur einen Block erkannter Zeichen zurückgibt, erfüllt die Anforderung allein noch nicht. Es muss weiterhin entschieden werden, welches Zahlwert zu welchem Test gehört, welche Zeichenkette eine Einheit darstellt und welche Zahlpaare einen normalen Bereich bilden. Jede Entscheidung bezieht sich darauf, wo dieser „Verständnis“-Schritt stattfindet und was er kostet.
Die Einschränkungen waren typisch für ein MVP: ein kleines Team, ein begrenztes Budget für die Infrastruktur sowie eine erwartete Anfangsmenge von etwa 500 hochgeladenen Berichten pro Tag, was in etwa 30.000 Seiten pro Monat entspricht.
Entscheidung 1: Wahl der Programmiersprache
Der Vorteil von Pythons Ökosystem ist real
Fragt man sich „Welche Sprache bietet die besten OCR- und ML-Tools?“, gewinnt Python ohne große Diskussion. Reife Open-Source-Engine wie PaddleOCR und EasyOCR sind in erster Linie für Python konzipiert, OpenCV verfügt dort über erstklassige Bindings, und die meisten Beispiele zur Computervision gehen davon aus. Ein von Grund auf entwickelter OCR-Pipeline würde natürlich in Python beginnen.
Auch ist es wichtig, ehrlich darüber zu sein, was nicht als Unterscheidungsmerkmal gilt. Googles Vision API war eine der in Betracht gezogenen kostenpflichtigen Optionen, und Google stellt Client-Bibliotheken für Python sowie Go zur Verfügung. Daher begünstigte die Verfügbarkeit der SDKs keines dieser Sprachen.
Warum Go dennoch gewann
Die entscheidenden Faktoren betrafen das umgebende System und nicht den OCR-Prozess selbst. Der Rest des asynchronen Pipelines war bereits als Go-Worker geplant: Er verarbeitet Aufgaben aus Redis Streams, lädt hochgeladene Dateien aus dem Cloudflare R2-Objektspeicher herunter und schreibt die Ergebnisse in Postgres. Die Umsetzung des Extraktionsschritts in Python hätte bedeutet, für eine einzige Funktion zwei verschiedene Worker-Umgebungen mit separater Bereitstellung, Abhängigkeitsverwaltung und Überwachung betreiben zu müssen. Der Entwickler war außerdem bei der Erstellung solcher infrastrukturorientierten Dienste mit Go am produktivsten.
Die allgemeine Lektion: Die Sprache mit dem umfangreichsten Bibliothekskatalog ist nicht automatisch die richtige. Wenn der Extraktionsvorgang auf den Aufruf eines Modells über HTTP reduziert werden kann – was letztendlich der Fall ist – lohnt es sich oft, für die gesamte Worker-Schicht eine einzige Laufzeitumgebung zu verwenden, anstatt sich auf einen kaum genutzten tiefen Bibliothekskatalog zu verlassen.
Entscheidung 2: Cloud-APIs gegen Self-Hosting – Preisvergleich
Das Team verglich vier Optionen im Hinblick auf die erwarteten 30.000 Seiten pro Monat. Die unten angegebenen Zahlen sind die Schätzungen aus der Bewertungszeit; die Preise in der Cloud ändern sich, daher sollten Sie vor der Verwendung immer die aktuellen Preislisten prüfen.
- Google Cloud Vision mit
DOCUMENT_TEXT_DETECTION. Es werden Rohtexte zusammen mit Koordinaten zurückgegeben, ohne strukturierte Felder. Bei etwa 1,50 US-Dollar pro 1.000 Seiten entspricht das in etwa 45 US-Dollar pro Monat.
Die Zahlen richtig interpretieren
Die Vision API scheint günstig zu sein, löst aber ein anderes Problem. Sie teilt Ihnen mit, dass die Zeichen „13.2“ an bestimmten Koordinaten erscheinen; sie hat keine Ahnung, dass es sich um einen Hämoglobinspiegel handelt. Sie müssten den gesamten Parsingschicht selbst entwickeln, weshalb ihr Preis nicht mit den Optionen vergleichbar ist, die strukturierte Daten liefern.
Document AI liefert zwar Struktur, doch Kosten von fast 1.000–2.000 US-Dollar pro Monat sind eine hohe variable Kosten für ein Produkt, das noch keinen Umsatz erzielt hat.
Gemini Flash ist der wirklich interessante Konkurrent. Die tokenbasierte Preiskalkulation für gescannte Seiten liegt im selben Bereich wie das Self-Hosting, und Sie müssen keine GPU-Infrastruktur betreiben. Warum also nicht dieses wählen?
Warum Self-Hosting dennoch vorteilhafter ist
Drei Argumente entschieden die Wahl:
- Kostenobergrenze. Ein dedizierter Knoten kostet unverändert, egal ob er 5.000 oder 50.000 Seiten verarbeitet. Eine gebührenbasierte API weist keine Obergrenze auf: Ein Anstieg der Nutzungsrate, wiederholte Versuche oder eine Massenimportierung zeigen sich direkt auf der Rechnung.
- Datenisolation. Medizinische Berichte enthalten geschützte Gesundheitsinformationen. Die Extraktion innerhalb des eigenen privaten Netzwerks der Teammitglieder bedeutet, dass Patientendokumente bei jedem Hochladen niemals an eine Drittanbieter-API gesendet werden, wodurch ganze Kategorien von Compliance-Anforderungen sowie Diskussionen mit Lieferanten vermieden werden, für die ein MVP-Team kaum Kapazitäten hat.
- Keine externen Quoten oder Latenzzeiten. Es gibt keine Gebührenlimits, Konkurrenzstufen oder zusätzliche Netzwerkwege auf dem kritischen Pfad.
Daraus resultierte, dass sowohl die Optionen von Google Cloud als auch Vertex AI verworfen wurden und man sich für einen vollständig selbst gehosteten Stack entschied.
Es hilft auch, die andere Seite zu betrachten. Eine konstante Serverrechnung ist nur bis zur Leistungsfähigkeit eines einzelnen Geräts vorhersehbar; darüber hinaus muss man eigene Hardware kaufen und selbst für die Kapazitätsplanung sowie die Verfügbarkeit sorgen. Selbsthosting beseitigt auch keine Compliance-Pflichten, da man weiterhin für die Speicherung, den Zugriffskontroll und die Überwachung dieser Daten verantwortlich ist. Bei einer kleinen, konstanten Arbeitslast mit sensiblen Eingaben spricht in der Regel etwas für Selbsthosting; bei stark schwankenden, schnell wachsenden Datenmengen und einem Team ohne Kapazitäten für den Betrieb ist eine verwaltete API möglicherweise die bessere Wahl.
Entscheidung 3: Auf traditionelle OCR-Bibliotheken verzichten
Open-Source-Engines wie PaddleOCR und Docling sind zwar in der Lage, solche Aufgaben zu bewältigen, doch ihre Ausgabe ist für die Anzeige konzipiert. In der Regel erhält man Inhalte, die in Layout-Tags eingebettet oder als Markdown formatiert sind, damit sie in einer Benutzeroberfläche oder im HTML-Bereich gut dargestellt werden. Das ist ideal, wenn eine Person das Ergebnis liest, doch unpraktisch, wenn Code „Hemoglobin: 13.2 g/dL“ als sauberes Feld extrahieren muss.
Die Überbrückung dieses Unterschieds ist an sich ein eigenständiges Projekt. Man müsste Werte aus der Tagstruktur extrahieren, durch viele Versuche und Fehler vorgehen, um mit unterschiedlichen Laboren und Berichtsformaten zurechtzukommen, und vermutlich OpenCV für Vor- oder Nachverarbeitung von Tabellen sowie Bereichen einsetzen, die vom Engine nicht sauber segmentiert wurden. All das kommt zusätzlich zu der Arbeit hinzu, die bereits für die Integration und Bereitstellung des OCR-Engines erforderlich ist. Für ein MVP stellt das eine erhebliche Menge an Entwicklungsarbeit dar – schließlich handelt es sich dabei um Infrastruktur und nicht um das eigentliche Produkt.
Eine Einschränkung verdient besondere Betonung: Diese Bewertung spiegelt die Einschätzung des Teams wider, nicht ein endgültiges Urteil über diese Tools. Ingenieure mit umfangreicherer Erfahrung in PaddleOCR oder Docling kennen möglicherweise einen schnelleren Weg, um von deren strukturierten Ausgaben saubere Felder zu erhalten. Zudem entwickeln sich beide Projekte schnell weiter, weshalb es sinnvoll ist, ihre aktuellen Ausgabeformate erneut zu überprüfen.
Entscheidung 4: Ein selbst gehostetes Vision-LLM, angepasst an das Budget
Bedeutung extrahieren statt Zeichen
Die Alternative zu „OCR und anschließend Erstellung eines Parsers für die OCR-Ausgabe“ besteht darin, ein visionfähiges Sprachmodell beides auf einmal erledigen zu lassen. Klassisches OCR erkennt Zeichen. Ein Vision-LLM kann bei einer gut strukturierten Anfrage die gescannte Seite betrachten und direkt Felder für Parameter, Wert und Einheit zurückgeben, wodurch der Zwischenschritt des Auswählens von Markdown-Tags weggelassen wird.
Die Vision-Fähigkeit ist hier unerlässlich und kein optionales Upgrade. Ein rein textbasiertes Modell kann bei einem gescannten Bild nicht helfen, da es noch keinen Text gibt. Das Modell muss die Pixel selbst lesen.
Der Ansatz birgt eigene Risiken, und es lohnt sich, bereits von Anfang an dafür zu planen. Sprachmodelle können Ziffern falsch interpretieren oder plausibel aussehende Werte erzeugen, die auf der Seite nicht vorhanden sind. Insbesondere kleinere Modelle liefern nicht immer genau die JSON-Struktur, nach der man gefragt hat. Bei Gesundheitsdaten spricht das dafür, die Antwort des Modells defensiv zu parsen, die Werte anhand erwarteter Typen und Bereiche zu überprüfen sowie einen Weg bereitzustellen, damit Nutzer oder Ärzte das ursprüngliche Dokument einsehen und korrigieren können.
Auswahl eines Modells, das tatsächlich ausgeführt werden kann
Die Auswahl des Modells folgte derselben Budgetlogik. Qwens größere Modelle mit Vision-Fähigkeiten sind leistungsstark, doch das Selbsthosten eines Modells in dieser Gewichtsklasse erfordert mehr VRAM und Rechenleistung, als für die Infrastruktur sinnvoll war, die das Team aus dem MVP-Budget bezahlte. Die Entscheidung fiel auf MiniCPM-V: ein weitaus kleineres Modell, das Ollama auf günstigem Hardware ohne Belastung bereitstellen kann – dennoch ausreichend gut für die strukturierte Extraktion aus Bildern von Laboreporten.
Falls Sie dieses Verfahren wiederholen, testen Sie die Kandidat-Modelle an einer repräsentativen Stichprobe Ihrer echten Dokumente, einschließlich verschwommener Handyfotos und ungewöhnlicher Laboraufbauten, anstatt sich auf Leaderboard-Werte zu verlassen. Das beste Modell auf dem Papier ist nutzlos, wenn Sie es sich nicht leisten können, es bereitzustellen.
Was die Implementierung als Nächstes benötigt
Die obige Architektur legt fest, was ausgeführt wird; der Produktionsprozess muss weiterhin klären, wie dies geschieht. Die anschließenden Arbeiten umfassen die Umwandlung von PDFs in Bilder, die vom Modell gelesen werden können, die Strukturierung der Ollama-API-Anfrage und des Prompts, das defensive Parsen von JSON, falls ein kleines Modell vom gewünschten Format abweicht, sowie die Verwendung von Redis Streams im Go-Worker, damit Berichte bei steigendem Volumen zuverlässig verarbeitet werden.
Kernpunkte
- Definieren Sie zunächst die gewünschten Ausgabedaten (hier: Name, Wert, Einheit, Referenzbereich), bevor Sie Tools vergleichen; roher OCR-Text und strukturierte Daten sind unterschiedliche Produkte mit verschiedenen Preisen.
- Wählen Sie die Programmiersprache für das gesamte System aus, nicht nur aufgrund der umfangreichsten Bibliotheken eines einzelnen Komponenten.
- Vergleichen Sie Cloud-Lösungen anhand äquivalenter Ausgabedaten und bewerten Sie anschließend Kostenobergrenzen, Datenaussonderung sowie Quoten neben dem Nennpreis.