Architektur¶
Die PPT-Werkstatt ist als Container-Anwendung mit klarer Schichten-Trennung aufgebaut. Eine Web-UI nimmt Eingaben entgegen, eine Orchestrierungs-Schicht steuert vier asynchrone Pipelines, ein Bestand spezialisierter Agenten erledigt die fachlichen Aufgaben, und eine Client-Schicht spricht externe Modell-Dienste über OpenAI-kompatible REST-Schnittstellen an.
Auf einen Blick¶
- Container-basierte Auslieferung, hinter einem Reverse-Proxy unter konfigurierbarem Pfad eingebunden.
- Web-UI auf Basis eines Python-Webframeworks; chat-zentriertes Layout mit ergänzenden Folien- und Inventar-Übersichten.
- Sitzungs-basierter In-Memory-Zustand ohne Persistenz; State wird zwischen UI-Events serialisiert übergeben.
- Asynchrone Pipelines mit Event-Stream zur UI-Aktualisierung; ein Stop-Mechanismus erlaubt den Abbruch laufender Vorgänge.
- Vier Pipelines: Inventarisierung, Briefing, Plan-Erstellung, Detail-Bearbeitung.
- Über zehn fachliche Agenten, jeweils mit eigenem Prompt und engem Aufgabenbereich.
- Anbindung an externe Modell-Dienste über einen einheitlichen Async-Client.
Schichten und Komponenten¶
Die Anwendung ist in fünf konzeptionelle Schichten unterteilt:
- UI-Schicht — Web-Oberfläche mit Chat-Bereich, Datei-Upload, Folien- und Inventar-Übersicht, Vorschau und Aktionsleiste. Sie hält keinen eigenen Zustand, sondern serialisiert den Anwendungs-State zwischen den UI-Events.
- Orchestrierungs-Schicht — Vier asynchrone Pipelines bündeln die Aufgabenflüsse: Inventarisierung der hochgeladenen Dokumente, Briefing-Dialog, mehrphasige Plan-Erstellung des Foliensatzes und Detail-Bearbeitung pro Chat-Anweisung.
- Agenten-Schicht — Eigenständige Agenten mit jeweils einem klar umrissenen Aufgabenbereich: Inventar-Analyzer, Intent-Router, Intent-QA, Briefing-Agent, Structure-Planner, Layout-Advisor, Content-Extractor, Content-Balancer, Icon-Picker, Grafix-Selector, Layout-Polisher, Homogenizer und Validator.
- Datenmodell-Schicht — Inventar mit typisierten Einträgen und Embedding-Vektoren, Layout-Registry, Anwendungs-Zustand mit Folien, Scope, Versionen und Chat-Verlauf.
- Client-Schicht — Adapter zu vier externen Modell-Diensten (Primary-LLM, Fast-LLM, Embedder, Reranker), Dokumenten-Leser für die Importformate, Renderer und Exporter für die Zielformate.
Workflow¶
flowchart TD
Upload[Dokumenten-Upload] --> InvPipe
Briefing[Briefing-Dialog] --> PlanPipe
subgraph InvPipe [Inventarisierungs-Pipeline]
IA[Inventar-Analyzer]
end
InvPipe --> Inventar[(Inventar)]
Inventar --> PlanPipe
subgraph PlanPipe [Plan-Pipeline]
direction TB
Struct[Structure-Planner] --> LayoutA[Layout-Advisor]
LayoutA --> Content[Content-Extractor parallel]
Content --> Validator[Validator dreistufig]
Validator -. Korrekturschleife .-> Content
Validator --> Homog[Homogenizer]
end
PlanPipe --> Foliensatz[(Foliensatz)]
Foliensatz --> DetailPipe
DetailPipe --> Foliensatz
subgraph DetailPipe [Detail-Pipeline]
direction TB
Router[Intent-Router] --> QA[Intent-QA]
QA --> Dispatcher[Dispatcher]
Dispatcher --> Mini[Mini-Pipelines]
end
Foliensatz --> Export[Export PPTX, DOCX, Markdown]
PlanPipe -.-> Versionen[(Versionsspeicher)]
DetailPipe -.-> Versionen
subgraph Modelle [Externe Modell-Dienste]
direction LR
Primary[Primary-LLM]
Fast[Fast-LLM]
Embed[Embedder]
Rerank[Reranker]
end
InvPipe -.-> Modelle
PlanPipe -.-> Modelle
DetailPipe -.-> Modelle
Erläuterung des Workflows¶
Hochgeladene Dokumente durchlaufen zunächst die Inventarisierungs-Pipeline: Der Inventar-Analyzer (auf dem Fast-LLM) zerlegt jedes Dokument in typisierte Einträge — Text, Tabelle, Aufzählung, Beschluss, Zitat, Kennzahl, Überschrift. Jedem Eintrag wird über den Embedder ein semantischer Vektor zugewiesen. Das Ergebnis ist ein In-Memory-Inventar mit semantischer Suchstruktur.
Parallel dazu klärt der Briefing-Dialog mit dem Nutzer die Rahmenparameter der Präsentation. Sind diese vollständig, startet die Plan-Pipeline in fünf Phasen:
- Der Structure-Planner entwirft eine Folien-Grobstruktur aus Briefing und Inventar (Folientitel, Reihenfolge, Folienrollen).
- Der Layout-Advisor weist jeder Folie ein passendes Layout aus dem Katalog zu.
- Der Content-Extractor befüllt die Slots der Folien aus dem zugewiesenen Material; mehrere Folien werden parallel verarbeitet. Bei niedriger Material-Abdeckung wird ein zweiter Durchlauf mit zusätzlichem Retrieval ausgelöst.
- Der Validator prüft jede Folie dreistufig (Regel-, Embedding-, LLM-Check). Auffällige Folien gehen in eine Korrekturschleife mit bis zu zwei Iterationen.
- Der Homogenizer gleicht Stil- und Begrifflichkeits-Brüche über den gesamten Foliensatz aus.
Optional ergänzen ein Icon-Picker und ein Grafix-Selector Symbole und grafische Diagramm-Layouts.
Nach Abschluss der Plan-Pipeline arbeitet die Detail-Pipeline pro Chat-Anweisung: Der Intent-Router klassifiziert die Anweisung in einen von 28 Aktionstypen. Bei niedriger Konfidenz, Mehrfach-Aktionen oder Kontext-Konflikten greift die Intent-QA-Schicht ein, die akzeptiert, korrigiert oder eine Rückfrage anstößt. Anschließend übergibt der Dispatcher an eine Mini-Pipeline, die je nach Aktionstyp nur die betroffene Folie oder den Foliensatz als Ganzes anpasst. Vor jeder ändernden Operation wird ein Versions-Snapshot abgelegt; die letzten 15 Stände sind per Undo zurücknehmbar.
Rolle der KI-Komponenten¶
- Das Primary-LLM (mit aktiviertem Thinking-Modus) bedient die qualitätskritischen Agenten: Routing, QA, Briefing, Strukturplanung, Layout-Empfehlung, Vereinheitlichung, Validierung.
- Das Fast-LLM (ohne Thinking-Modus) bedient Bulk- und Pattern-Matching-Aufgaben: Inventar-Analyse, parallele Slot-Befüllung, Inhalts-Balancierung, Symbol- und Diagramm-Wahl.
- Der Embedder liefert Vektoren für Inventar-Einträge, Folien-Inhalte und Anfragen — Grundlage von Retrieval, semantischem Scope und Material-Coverage.
- Der Reranker ordnet die Embedder-Treffer fein: Aus einer Top-N-Auswahl wird die finale Top-K-Reihenfolge gebildet.
Die Aufteilung zweier LLM-Rollen mit unterschiedlichem Tempo und Reasoning-Aufwand ist bewusst: aufwändiges Reasoning fließt in die Aufgaben, die davon profitieren; hochfrequente Bulk-Aufgaben laufen schnell und parallel.
Nebenläufigkeit, Robustheit, Konfiguration¶
- Die Pipelines sind als asynchrone Generatoren implementiert; Events werden an die UI gestreamt, sodass Fortschritte sichtbar sind und der Vorgang per Stop-Aktion abgebrochen werden kann.
- Die Slot-Befüllung in der Plan-Pipeline erfolgt parallel; die Anzahl gleichzeitiger Folien-Verarbeitungen ist konfigurierbar.
- Die Modell-Clients sind mit Retry-Logik ausgestattet; eine Begrenzung gleichzeitiger Requests pro Endpunkt schützt vor Überlast.
- Sitzungen sind in-memory und werden bei Container-Neustart verworfen — eine bewusste Datenschutz-Eigenschaft.
- Die Konfiguration erfolgt über Umgebungsvariablen (Endpunkte, Modellnamen, Pipeline-Verhalten); ein Selbsttest prüft die Erreichbarkeit aller Modell-Dienste.
Deployment¶
Die Anwendung wird als Docker-Container ausgeliefert (Basis: Python 3.12 mit System-Bibliotheken für SVG-Rendering und Dokumenten-Verarbeitung). Sie liegt hinter einem Reverse-Proxy unter einem konfigurierbaren Pfad. Die externen Modell-Dienste sind hochschul-interne Endpunkte, die über OpenAI-kompatible REST-Schnittstellen angesprochen werden.
Technologie-Übersicht¶
- Web-UI: Gradio 6.
- Modell-Anbindung: OpenAI-kompatibler Async-Client (
openai-SDK), erweitert um modellspezifische Thinking-Parameter für Qwen-, Kimi-, GLM- und Gemma-Familien. - Dokumenten-Verarbeitung:
python-pptx,python-docx,pypdf. - Numerik und Vektoren: NumPy.
- SVG- und Bitmap-Rendering:
cairosvgfür Diagrammgrafiken (mit Cairo/Pango als Systemabhängigkeiten). - Datenmodelle:
pydanticunddataclasses. - Konfiguration:
python-dotenv. - Symbol-Bestand: Bootstrap Icons (MIT-Lizenz).
- Diagramm-Templates: eingebundenes externes Template-Projekt für Diagrammgrafiken (Fabric.js-JSON-Format).
- Eingesetzte Modelle: Kimi K2.5 als Primary-LLM, Qwen 3 (oder vergleichbares Modell) als Fast-LLM, BGE-M3 als Embedder, BGE-Reranker-v2-M3 als Reranker.