Zum Inhalt

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:

  1. 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.
  2. 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.
  3. 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.
  4. Datenmodell-Schicht — Inventar mit typisierten Einträgen und Embedding-Vektoren, Layout-Registry, Anwendungs-Zustand mit Folien, Scope, Versionen und Chat-Verlauf.
  5. 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:

  1. Der Structure-Planner entwirft eine Folien-Grobstruktur aus Briefing und Inventar (Folientitel, Reihenfolge, Folienrollen).
  2. Der Layout-Advisor weist jeder Folie ein passendes Layout aus dem Katalog zu.
  3. 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.
  4. Der Validator prüft jede Folie dreistufig (Regel-, Embedding-, LLM-Check). Auffällige Folien gehen in eine Korrekturschleife mit bis zu zwei Iterationen.
  5. 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: cairosvg für Diagrammgrafiken (mit Cairo/Pango als Systemabhängigkeiten).
  • Datenmodelle: pydantic und dataclasses.
  • 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.