Wie ich ein Labor aus 13 PDF- und KI-Werkzeugen gebaut habe, die zusammenarbeiten

Das Labor dieser Website entstand aus einem konkreten Bedarf: Ich brauchte eine Testumgebung für die Technologien, die ich bei Kunden einsetze, und wollte, dass sie auch Menschen nützt, die täglich mit Dokumenten arbeiten. Heute umfasst es 13 Werkzeuge – Viewer, PDF-Editor, OCR, Scanner, Übersetzung, Zusammenfassung, Suche nach legalen PDFs, KI-Folien und mehr – in sieben Sprachen. So habe ich es gebaut.

Problem und Rahmenbedingungen

• Niedrige Kosten: ein NestJS-Backend auf einem kleinen Cloud-Dienst, keine eigene Infrastruktur.
• Datenschutz: Wo möglich, sollen Dateien das Gerät des Nutzers nicht verlassen.
• Sieben Sprachen und SEO: Jedes Werkzeug muss in jeder Sprache über Google auffindbar sein.
• Anonyme Werkzeuge: keine Registrierungspflicht – also Schutz vor Missbrauch.

Entscheidung 1: im Browser, wenn möglich – auf dem Server, wenn nötig

Viewer, PDF-Editor (zusammenfügen, teilen, drehen, Wasserzeichen) und die erste Stufe der OCR laufen komplett im Browser, mit pdf.js und pdf-lib: Das Dokument wird nie hochgeladen. Der Server kommt nur ins Spiel, wenn es unvermeidlich ist: Aufrufe von KI-Modellen, aufwendige OCR mit Tesseract, Formatkonvertierungen.

Entscheidung 2: erst der Text, dann die OCR

Jede Seite wird zuerst nach ihrer Textebene gefragt. Unter 40 Zeichen werte ich sie als Scan und schicke sie in die OCR; derselbe Schwellenwert gilt im Browser und auf dem Server, damit beide Wege konsistente Ergebnisse liefern. OCR ist langsam, deshalb gibt es eine Obergrenze von 20 Seiten pro Dokument.

Entscheidung 3: Grenzen offen nennen, nicht verstecken

Lange Dokumente werden für die KI in Blöcke aufgeteilt. Ab 15 Blöcken kürze ich lieber und sage es dem Nutzer, statt Laufzeit und Kosten bei einer extremen Datei explodieren zu lassen:

// Hard cap on blocks per document: beyond it the file is
// truncated honestly instead of exploding latency and cost.
const chunks = allChunks.slice(0, this.MAX_CHUNKS); // 15
const truncated = allChunks.length > this.MAX_CHUNKS;
// "truncated" goes back to the UI: the user is told, not surprised

Entscheidung 4: Werkzeuge, verbunden durch einen Workspace

Der eigentliche Nutzen liegt in den Ketten: Scanner → OCR → Übersetzung, Suche → Zusammenfassung. Deshalb habe ich einen Workspace ergänzt, der das Ergebnis eines Werkzeugs an das nächste übergibt, ohne Dateien herunter- und wieder hochzuladen. Ausführlich beschrieben habe ich das in diesem Artikel.

Entscheidung 5: KI-Kontingente

Anonyme Werkzeuge plus Aufrufe von KI-Modellen sind eine gefährliche Mischung fürs Budget. Zusätzlich zum Minutenlimit habe ich ein Tageslimit pro IP-Adresse und ein globales Tagesbudget an Tokens eingeführt, mit einem Notschalter. Ohne sie könnte ein einziges automatisiertes Skript in einer Stunde das Budget eines Monats verbrauchen.

Die Fehler, aus denen ich am meisten gelernt habe

• Meine eigenen Sicherheits-Header blockierten meine eigene Vorschau. Die Standardeinstellungen von Helmet verbieten, Backend-Antworten in einem iframe einer anderen Origin anzuzeigen: Ich musste eine gezielte Ausnahme schaffen, nur für diese Route und nur für mein Frontend.
• Auf Smartphones zeigte die PDF-Vorschau nur die erste Seite. Der native Viewer mobiler Browser macht das oft: Auf Mobilgeräten rendere ich die Seiten jetzt mit pdf.js, über einen Proxy mit einer festen Liste erlaubter Domains, um Missbrauch zu verhindern.
• Quellen müssen live geprüft werden. Für die Suche nach legalen PDFs habe ich Internet Archive, Project Gutenberg, arXiv und Europe PMC behalten; andere vielversprechende Quellen flogen raus, weil sie im echten Test HTML-Seiten statt PDFs lieferten.
• Titel in nur einer Sprache. Wochenlang hatten die Werkzeugseiten feste Titel und Beschreibungen, fast alle auf Englisch: Die Versionen in den anderen Sprachen waren für Google praktisch unsichtbar.

Das Ergebnis

Dreizehn Werkzeuge in sieben Sprachen, mit vorgerenderten Seiten für jede Sprache und dem Großteil der Verarbeitung im Browser. Das nützlichste Ergebnis ist aber ein anderes: ein Repertoire erprobter Lösungen – PDF-Verarbeitung, OCR, KI-Kontingente, sichere Proxys, i18n –, das ich in Kundenprojekten wiederverwende.

Fazit

Der Bau des Labors hat mich drei Dinge gelehrt: alles im Browser verarbeiten, was dort geht, Grenzen offen nennen statt sie zu verstecken, und jede Ressource schützen, die Geld kostet. Wenn du ein Projekt mit Dokumenten oder KI hast, schreib mir: Ein ähnliches Problem habe ich wahrscheinlich schon gelöst.