Wie ich mit AIDocSynth das Dokumentenchaos durch automatisierte Klassifizierung und semantische Ablage nach MIT-Standards löse. Offline-First-Architektur mit OCR, lokalen LLMs und Prompt-Optimierung.
Autor: Tobias Müller, ispringen.dev
Ich kenne das Problem aus eigener Erfahrung. Über Monate sammeln sich PDF-Rechnungen, gescannte Verträge und Office-Dokumente an. Anfangs halte ich mich noch an selbst gesetzte Regeln für Dateinamen und Ordnerstrukturen. Doch mit der Zeit schleichen sich Inkonsistenzen ein. Eine Rechnung benenne ich Rechnung_2025-01.pdf, die nächste 2025_Rechnung_Januar.pdf. Aus drei geplanten Ordnerebenen werden schnell sieben oder mehr. Irgendwann verbringe ich mehr Zeit mit Suchen als mit Arbeiten.
Die größte Hürde ist nicht das Fehlen von Tools, sondern das Fehlen automatisierter, konsistenter Regeln.
Backups auf der NAS sichern zwar die Daten, lösen aber nicht das eigentliche Problem, die Wiederauffindbarkeit. Ohne klare semantische Metadaten bleibt jede Suche ein Ratespiel. Tiefe Ordnerhierarchien verschärfen das Problem. Studien zeigen, dass Nutzer sich Pfade mit mehr als vier Ebenen kaum merken können. Die Suchzeit steigt exponentiell.
Bestehende Lösungen helfen nur bedingt. Cloud-Dokumentenmanagementsysteme ersetzen das Dateisystem durch eigene Datenbanken. Lokale Suchtools wie grep oder Windows Search finden zwar Dateien, klassifizieren sie aber nicht automatisch. Händisches Verwalten wird dadurch nicht erleichtert. Es fehlt ein Tool, das intelligente Benennung und Sortierung übernimmt, ohne bestehende Strukturen zu ersetzen.
Die Methode Data Management: File Organization der MIT Libraries zeigt den Weg. Sie definiert klare Regeln für semantische Hierarchien und konsistente Benennungskonventionen. Doch ohne Automatisierung entsteht ein Teufelskreis. Je mehr Dateien, desto höher der manuelle Aufwand, desto inkonsistenter die Ablage. Typische Inkonsistenzen in manueller Benennung sind:
Rechnung_2025-01.pdf vs. 2025_Rechnung_Januar.pdfScan_Handy.jpg vs. Vertrag_Mobilfunk_20250120.jpgDokument1_final_v2.pdf ohne inhaltlichen BezugBestehende Ansätze im Vergleich:
| Lösungstyp | Klassifizierung | Automatische Ablage | Offline-fähig |
|---|---|---|---|
| Cloud-DMS | Ja | Ja | Nein |
| Lokale Suchtools | Nein | Nein | Ja |
| AIDocSynth | Ja | Ja | Ja |
AIDocSynth löst das Problem durch eine klare Verarbeitungskette. Ich ziehe eine PDF- oder Bilddatei per Drag & Drop in die App. Sofort startet die Verarbeitung. On-Device OCR extrahiert den Text, selbst aus Scans. Dafür nutze ich doctr, eine lokale OCR-Bibliothek. Keine Cloud-Uploads, keine Datenschutzbedenken.
Ein optimierter System-Prompt steuert die LLM-Klassifizierung. Er definiert zwölf Metadatenfelder wie headline, specifier und target_directory. Jedes Feld hat strikte Formatvorgaben. Die headline darf maximal 15 Zeichen lang sein, der target_directory muss ein relativer Pfad ohne führenden Schrägstrich sein. Das LLM generiert daraus strukturierte Metadaten im JSON-Format.
Die Datei wird automatisch in die semantisch passende Ordnerstruktur einsortiert. Der Zielname folgt dem Schema [headline]_[yyyymmdd]_[specifier].[ext]. Die Sortierung orientiert sich an den MIT-Standards für File Organization: flache Hierarchien, Domain als oberste Ebene, maschinenlesbare Namen. Die LLM-Abstraktionsschicht unterstützt lokale Modelle wie Ollama, aber auch OpenAI API und Azure OpenAI.
Die eigentliche Innovation liegt nicht in der Kombination von OCR und LLM, sondern in der Prompt-Optimierung für kleine Modelle.
Die Methode Data Management: File Organization der MIT Libraries zeigt den Weg.
Metadatenfelder des System-Prompts:
headline: Prägnantes Substantiv (≤ 15 Zeichen)specifier: Unterscheidungsmerkmal (≤ 20 Zeichen)target_directory: Relativer Pfad nach MIT-StandardsVergleich der LLM-Provider-Integration:
| Provider | Modellbeispiel | Offline-fähig | API-Kosten |
|---|---|---|---|
| Ollama | mistral-small3.1 | Ja | Nein |
| OpenAI | gpt-4o-mini | Nein | Ja |
| Azure | gpt-4 | Nein | Ja |
Tabelle 1: Vergleich der LLM-Provider-Integration.
Die Architektur ist modular aufgebaut und besteht aus drei Hauptkomponenten: einer Drag-and-Drop-Oberfläche (GUI), einer Verarbeitungs-Pipeline im Hintergrund und einer Abstraktionsschicht für die Anbindung verschiedener Sprachmodelle.
Die Pipeline führt folgende Schritte vollautomatisch aus:
Entwickler können dank Pydantic-Modellen und strikter Datenvalidierung eigene Provider für Sprachmodelle einbinden. Die Benutzeroberfläche basiert auf Qt und reagiert in Echtzeit über asynchrone Signals, damit die UI während der Verarbeitung nicht einfriert.
Kleine Modelle wie Mistral Nemo mit 3 Milliarden Parametern sind weniger zuverlässig bei komplexen Tasks wie Dokumentenklassifizierung. Ich habe viel Arbeit in die Prompt-Optimierung gesteckt, um trotzdem stabile Ergebnisse zu erzielen. Der System-Prompt definiert zwölf Metadatenfelder mit strikten Constraints. Die headline ist auf 15 Zeichen begrenzt, der target_directory muss ein relativer Pfad ohne führenden Schrägstrich sein.
Der Analysis-Prompt nutzt Template-Variablen wie {{ content_string }} und {{ directory_structure_json }}. Die bestehende Ordnerstruktur wird als JSON eingebunden. Das Modell lernt so aus vorhandenen Mustern und vermeidet disruptive Umzüge. Pydantic-Validierung sichert die JSON-Ausgabe ab und löst bei Fehlern einen Retry aus.
Es gibt einen dokumentierten Trade-off. Bei Ordnerstrukturen mit mehr als acht Ebenen sind größere Modelle zuverlässiger. Die Prompt-Optimierung ermöglicht es dennoch, ressourcenschonende Modelle offline zu nutzen. Der System-Prompt ignoriert explizit Zusatzinformationen wie Datenschutzerklärungen, um den Fokus auf den Hauptinhalt zu legen.
Constraint-Beispiele aus dem System-Prompt:
headline: ≤ 15 Zeichen, prägnantes Substantiv (z. B. “Rechnung”)specifier: ≤ 20 Zeichen, Unterscheidungsmerkmal (z. B. “Strom_202601”)target_directory: relativer Pfad, flache Hierarchie (z. B. “Finanzen/Verträge”)Vergleich der Modellzuverlässigkeit:
| Modell | Parameter | Komplexität (Ebenen) | Offline-fähig |
|---|---|---|---|
| Mistral Nemo | 3B | ≤ 8 | Ja |
| Mistral Small 3.2 | 22B | > 8 | Ja |
| GPT-4o-mini | ~30B | > 12 | Nein |
Tabelle 2: Vergleich der Modellzuverlässigkeit.
Die Architektur von AIDocSynth ist pragmatisch und skalierbar. Ich beginne mit der DropArea, die Dateipfade per Drag & Drop entgegennimmt. Der MainController legt einen Job mit Status pending an und aktualisiert die JobTableModel. Ein Worker Thread führt die asynchrone Pipeline aus. Backup im .aidocsynth/backup-Verzeichnis, Text-Extraktion via doctr oder native Extraktion, LLM-Klassifizierung mit System- und Analysis-Prompt, Dateiumbenennung und -verschiebung nach target_directory und target_filename.
Der Provider-Layer abstrahiert verschiedene LLM-Anbieter durch ein einheitliches Interface. Das LLMProviderProtocol definiert Methoden wie classify_document(). Die JobTableModel aktualisiert die UI in Echtzeit über Qt-Signals und zeigt Status wie pending, processing, completed oder failed an. Modulare Services für OCR, LLM und File-Operations sind als separate Python-Klassen implementiert und über Dependency Injection angebunden.
Job-Status und UI-Aktualisierung:
Vergleich des Provider-Interfaces:
| Methode | Parameter | Rückgabe |
|---|---|---|
classify_document() | content: str, prompt: str | DocumentMetadata (Pydantic) |
is_available() | – | bool |
Tabelle 3: Vergleich des Provider-Interfaces.
AIDocSynth schließt eine echte Marktlücke. Bestehende Lösungen adressieren entweder Legacy-Code-Dokumentation wie A.I.DOC oder Template-basierte Dokumentengenerierung wie AI Document. Keine dieser Lösungen bietet intelligente Sortierung bestehender Dateien. AIDocSynth kombiniert OCR, LLM-Klassifizierung und automatische Ablage nach MIT-Standards.
AIDocSynth schließt eine echte Marktlücke. Bestehende Lösungen adressieren entweder Legacy-Code-Dokumentation oder Template-basierte Dokumentengenerierung.
Die Offline-First-Architektur ist ein entscheidender Vorteil. On-Device OCR via doctr und lokale LLM-Integration mit Ollama erfüllen DSGVO-Anforderungen und vermeiden Cloud-Abhängigkeiten. Beta-Tester schätzen die Einfachheit: “Ich schiebe nur noch die PDFs in das Feld. Sekunden später ist alles sortiert.” Die Roadmap sieht Erweiterungen wie einen Wizard für Ersteinrichtung und ein Plug-in-System für Custom-Prompts vor.
Ich denke, die größte Marktlücke ist nicht das Fehlen von Dokumenten-Tools, sondern das Fehlen intelligenter Assistenten, die bestehende Dateien ohne manuellen Aufwand konsistent strukturieren. Offline-First ist keine Option, sondern technische Notwendigkeit. Sensible Daten gehören nicht in die Cloud, und lokale Modelle wie Mistral Small 3.1 beweisen, dass Performance kein Ausschlusskriterium mehr ist.
Vergleich der Lösungsansätze:
| Lösungstyp | Intelligente Sortierung | Offline-fähig | Zielgruppe |
|---|---|---|---|
| AIDocSynth | Ja | Ja | Endnutzer, Entwickler |
| Cloud-DMS (z. B. AI Document) | Nein | Nein | Unternehmen |
| OCR-Tools (z. B. Tesseract) | Nein | Ja | Entwickler |
Tabelle 4: Vergleich der Lösungsansätze.
Cite this article
Tobias Müller (2026): *AIDocSynth: Intelligente Dateiverwaltung mit OCR, LLM und MIT-Standards.* https://ispringen.dev
Lizenz: CC BY 4.0 – Bitte mit Namensnennung „Tobias Müller, ispringen.dev“.
Ich stehe gerne für Fragen und Diskussionen zur Verfügung. Die beste Anlaufstelle ist das GitHub-Repository, wo Issues und Diskussionen geführt werden.