DocumentAI

Maritime DocAI

Charterverträge, Crew-Zertifikate, PSC-Berichte

Erstellt von Rogue AI · Lokale multimodale OCR, ohne Cloud · Selbst gehostet · Lokales Labor

Als internes Portfolio-Projekt gebaut und anschließend in mehreren Iterationen an echten Schifffahrtsdokumenten verfeinert.

Maritime DocAI — Charterverträge, Crew-Zertifikate, PSC-Berichte

Das Problem

Reedereibetriebe ertrinken in unstrukturiertem Papier: Charterverträge, Crew-Zertifikate, Port-State-Control-Berichte, Konnossemente. Die entscheidenden Fakten — Laytime-Klauseln, Ablaufdaten von Zertifikaten, Mängelcodes — sind in PDFs höchst unterschiedlicher Qualität vergraben, von sauberen Digitaldokumenten bis zu gescannten, gestempelten, gefaxten Seiten. Die naheliegende Lösung wäre eine Cloud-Dokument-KI-API, doch Schiffsdokumente enthalten kommerziell sensible Konditionen und personenbezogene Crew-Daten, und jede Seite an eine Drittanbieter-API zu schicken wirft sowohl Kosten- als auch Datenschutzfragen auf, die ein Betrieb lieber vermeidet.

Was ich gebaut habe

Eine einzige selbst gehostete Web-App, mit der man ein Schiffsdokument als PDF hochlädt und strukturierte Felder zurückbekommt — Dokumenttyp, zentrale Klauseln, Zertifikats- und Ablaufdaten, PSC-Mängel — mit hervorgehobenen compliance-relevanten Punkten, exportierbar als strukturierte Daten. Jeder Schritt läuft auf der lokalen Maschine: ein lokales multimodales Modell übernimmt die OCR und liest die Dokumentbilder, ein lokales LLM extrahiert die Felder. Keine Seite verlässt die Maschine. Uploads liegen in kurzlebigen In-Memory-Sitzungen statt in einer Datenbank, das Werkzeug verarbeitet und exportiert also und vergisst dann.

Architektur

Next.js 16 + React 19 Frontend und API-Routen

Eine einzige TypeScript/Tailwind-App liefert die Upload-Oberfläche und beherbergt die API-Routen, die die Extraktion steuern. Es gibt keinen separaten Backend-Dienst — derselbe Next.js-Prozess übernimmt Upload, Orchestrierung und Export, was die Bereitstellung auf einen einzigen Container reduziert.

Lokale multimodale OCR mit llava über Ollama

Gescannte und bildbasierte Seiten werden von einem multimodalen llava-Modell gelesen, das von einer gemeinsam genutzten Ollama-Instanz im lokalen Netzwerk (Port 11434) bereitgestellt wird. Weil das Modell die Seite als Bild sieht, bewältigt es Layout und Stempel, die eine spröde reine Text-OCR verpassen würde — um den Preis, nur so gut zu sein wie der vorliegende Scan.

Lokale LLM-Feld-Extraktion, ohne Cloud

Extraktion und Compliance-Markierung laufen gegen ein lokales Ollama-Modell — kein externer API-Aufruf verlässt den Host. Die App kann LLM-Aufrufe optional über eine gemeinsame lokale CLI-Brücke leiten, doch die Voreinstellung ist vollständig lokales Ollama, damit das Werkzeug offline weiterarbeitet und keine Dokumentdaten an Dritte gesendet werden.

Zustandslose In-Memory-Sitzungen — keine Datenbank

Es gibt keine Datenbank. Hochgeladene Dokumente und ihre extrahierten Felder liegen in In-Memory-Sitzungen mit kurzer TTL (etwa 60 Minuten) und werden danach verworfen. Das ist ein bewusster Kompromiss: Er minimiert ruhende Daten und vereinfacht das Bedrohungsmodell, bedeutet aber auch, dass die App eine Extraktionshilfe ist und kein führendes System.

Gehärtete Bereitstellung in einem einzigen Docker-Container

Die App wird als ein einziger Docker-Container ausgeliefert, nur an localhost gebunden, schreibgeschützt betrieben, mit allen entzogenen Linux-Capabilities, gesetztem no-new-privileges, tmpfs für Scratch-Speicher sowie konservativen Speicher- und PID-Grenzen. Sie hängt an ihrem eigenen isolierten Netzwerk plus dem gemeinsamen Ollama-Netzwerk, sodass sie ausschließlich mit dem lokalen Modellserver spricht.

Tech-Stack

Next.jsOllamallavaDocker

Was zuerst gebrochen ist

▸
Multimodale Modelle lesen, was sie sehen können, nicht das, was man sich wünscht — ein sauberer Chartervertrag als nativer PDF-Text wird nahezu perfekt extrahiert, während ein gefaxter, gestempelter, handschriftlich annotierter PSC-Bericht im besten Fall nur ungenau verarbeitet wird. Layout und Scan-Qualität zählen mehr als die Modellgröße.
▸
Die gesamte Pipeline lokal zu halten, beseitigt eine ganze Klasse von Problemen, über die man nicht mehr streiten muss: keine Auftragsverarbeitungsvereinbarung mit Dritten, keine Abrechnung pro Seite, keine Frage, wo der Passscan eines Crew-Mitglieds landet. Bezahlt wird dieser Tausch mit GPU-Zeit und geringerem Durchsatz auf einer einzelnen Maschine.
▸
Feld-Extraktion ist nur dann nützlich, wenn sie Unsicherheit zulässt. Einen selbstbewussten Wert für ein Feld zurückzugeben, das das Modell nie wirklich gefunden hat, ist schlimmer als gar nichts zurückzugeben — die ehrliche Ausgabe ist das Feld, der Wert und eine Markierung, wenn die Quelle mehrdeutig ist.

Ergebnis

Das Ergebnis ist ein funktionierender Nachweis, dass die Extraktion von Schiffsdokumenten — Charterverträge, Crew-Zertifikate, PSC-Berichte — vollständig auf selbst gehosteter Infrastruktur laufen kann, ohne Cloud-Abhängigkeit und ohne dass Dokumentdaten die Maschine verlassen. Es ist ehrlicherweise ein Build im Portfolio-Maßstab: allein gebaut, in einem lokalen Labor betrieben und vor allem bei sauberen Dokumenten genau, während es bei schlechten Scans an Qualität verliert. Was es belegt, ist die Architektur, nicht eine Produktivhistorie: lokale multimodale OCR plus lokale LLM-Extraktion ist eine tragfähige, datensouveräne Alternative zur Cloud-Dokument-KI für eine Domäne, in der die Dokumente sensibel und die Layouts chaotisch sind.

Ehrliche Grenzen

Dies ist ein selbst gehostetes Werkzeug, allein gebaut und als Portfolio-Demo in einem lokalen Labor betrieben — der frühere öffentliche Demo-VPS wurde abgeschaltet, es steht also keine große Produktiv-Nutzerbasis dahinter. Die Genauigkeit der Dokument-KI schwankt stark mit Layout und Scan-Qualität: PDFs mit nativem Text werden sauber extrahiert, während niedrig aufgelöste Scans, Stempel und Handschrift unzuverlässig sind und von einem Menschen geprüft werden müssen. Sitzungen liegen im Arbeitsspeicher mit kurzer TTL und es gibt keine Datenbank, also ist nichts ein führendes System — es ist eine Extraktionshilfe, keine Compliance-Instanz.