Sponge

Hintergrund

GermanGuess zeigte LLM-Grenzen bei Validierung. Bevor ich RAG baute, musste ich verstehen, wie unstrukturierte Dokumente überhaupt verarbeitbar werden. Sponge war das kontrollierte Experiment.

Problem

Wenn Transformations- und Forschungsarbeit viele Quellen umfasst, kostet das Finden dessen, was zählt, oft mehr Aufwand als die Nutzung selbst — besonders über Dokumente, Postfächer und lokale Dateien hinweg.

Ziele

• Modulare Processor-Architektur pro Dateiformat
• Asynchrone Verarbeitung mit Job-Queue
• Volltextsuche über extrahierte Inhalte
• Operative Komplexität von Multi-Service-Pipelines erleben

Architektur

Technologie-Stack

Python · FastAPI · Docker · Redis · Elasticsearch

Technische Herausforderungen

• Format-spezifische Extraktionsfehler isolieren
• Async-Verarbeitung ohne Datenverlust
• Operative Komplexität bei mehr als zwei Services
• Fehlerbehandlung als größter Zeitfresser

Abwägungen

• Modularität hilft beim Erweitern, erhöht aber Betriebsaufwand
• Drei Services (API, Redis, ES) für ein Lernprojekt — bewusst überdimensioniert zum Lernen
• Format-spezifische Extraktionsfehler schwer generisch zu behandeln

Erkenntnisse

• Modularität hilft beim Erweitern, erhöht aber Betriebsaufwand
• Fehlerbehandlung ist der größte Zeitfresser in Pipelines
• Kleine Projekte zeigen Unternehmensprobleme in Miniatur

Aktueller Status

Live (Private) — kontinuierliche Sammlung und Organisation nach eigenen Interessen.

Zukünftige Verbesserungen

• Erkenntnisse in Ada-Ingestion überführen
• OCR-Schicht für gescannte Dokumente evaluieren
• Kein aktiver Weiterbetrieb geplant

Geschätzte Meilensteine

• Erledigt — Basis-Pipeline und Dokumentation
• Optional — OCR-Evaluierung falls Ada PDF-Ingestion erweitert wird