Architektur

Style ist eine zustandsarme Webanwendung mit klar getrennten Schichten für Benutzeroberfläche, Profil- und Dokumentenverarbeitung sowie LLM-Anbindung. Die Anwendung wird als Container ausgeliefert und ist auf den Betrieb hinter einem Reverse-Proxy vorbereitet. Die Geschäftslogik verteilt sich auf vier Module, die je einen klar abgegrenzten Verantwortungsbereich kapseln.

Auf einen Blick

• Webanwendung auf Basis von Gradio mit vier funktional getrennten Tabs.
• Vier Kernmodule: LLM-Client, Dokumentverarbeitung, Profilverwaltung, Export.
• LLM-Anbindung über OpenAI-kompatible REST-API.
• Profile als JSON-Dateien im Dateisystem; Profilbibliothek wird beim Start eingelesen.
• Im Wesentlichen zustandsfreie Arbeitsbereiche; nur die Feinabstimmung hält einen sitzungsbezogenen Zustand.
• Containerisiert über Docker; konfigurierbar über Umgebungsvariablen, mit Reverse-Proxy-Unterstützung.

Architekturbeschreibung

Komponenten und Schichten

Die Anwendung gliedert sich in eine Präsentationsschicht (Gradio-UI mit den vier Tabs Transformieren, Stil analysieren, Feinabstimmung, Stilübersicht), eine Anwendungslogik (vier fachliche Module) und eine Integrationsschicht zur LLM-API. Profile, Texte und Prompts werden als Dateien auf dem Dateisystem gehalten.

flowchart TB
    User([Nutzer:in]) --> UI[Gradio-Oberfläche]

    UI --> T1[Transformieren]
    UI --> T2[Stil analysieren]
    UI --> T3[Feinabstimmung]
    UI --> T4[Stilübersicht]

    T1 --> DocProc
    T1 --> ProfMgr
    T1 --> LLM
    T1 --> Export

    T2 --> DocProc
    T2 --> ProfMgr
    T2 --> LLM
    T2 --> Export

    T3 --> ProfMgr
    T3 --> LLM
    T3 --> Export

    T4 --> ProfMgr

    subgraph Module
      DocProc[Document Processor]
      ProfMgr[Profile Manager]
      LLM[LLM Client]
      Export[Export Handler]
    end

    LLM <-->|OpenAI-kompatibel| LocalLLM[Lokales LLM]
    DocProc <--> Files[(Texte: TXT/MD/DOCX)]
    ProfMgr <--> Profiles[(Profilbibliothek)]
    LLM --> Prompts[(Prompt-Vorlagen)]
    Export --> Outputs[(Export-Dateien)]

Workflow

Ein typischer Ablauf folgt einem konsistenten Muster über alle vier Tabs hinweg. Eingaben (Profil und/oder Text) werden über die Gradio-Oberfläche entgegengenommen. Der Document Processor lädt Dateien — TXT direkt, Markdown direkt, DOCX über python-docx mit Erhalt von Überschriften, Listen und Tabellen — und überführt sie in eine einheitliche Markdown-Repräsentation. Der Profile Manager liest beim Start sämtliche JSON-Profile aus dem Verzeichnis profiles/ ein und stellt sie der UI als Auswahl bereit; hochgeladene Profile werden ad hoc geladen. Aus einem geladenen Profil wird entweder der hinterlegte Transformations-Prompt extrahiert oder — wenn dieser fehlt oder zu umfangreich ist — ein kompakter Prompt aus den strukturierten Profildaten erzeugt.

Die so vorbereiteten Eingaben werden durch den LLM Client zusammen mit einer der drei Prompt-Vorlagen (style_analysis.txt, style_transformation.txt, diff_analysis.txt) verbunden und über die OpenAI-kompatible Chat-Completions-Schnittstelle an das Modell übergeben. Vor jedem Aufruf prüft der Client den Token-Bedarf mit tiktoken (Encoding cl100k_base) gegen ein konfigurierbares Limit und bricht bei Überschreitung mit einer Meldung ab.

Im Bereich Feinabstimmung kommt zusätzlich ein sitzungsgebundener Zustand zum Einsatz: Ein optional geladenes Basisprofil und bis zu fünf nacheinander analysierte Vorher-Nachher-Paare werden in einem In-Memory-State gehalten und beim Export in ein verfeinertes Profil zusammengeführt.

Der Export Handler erzeugt schließlich die Ausgabedateien — Texte als TXT, Markdown oder DOCX, Profile als JSON, einzelnen Prompt als TXT oder als vollständiges ZIP-Paket (Profilparameter, Prompt, Beispielsätze).

LLM-Einsatz

Der LLM-Einsatz ist bewusst flach gehalten: pro Nutzeraktion ein einzelner Modellaufruf, ohne agentische Schleifen, ohne Retrieval, ohne Embedder oder Reranker. Die strukturelle Qualität entsteht stattdessen aus dem expliziten Profilschema und den drei festgelegten Prompt-Vorlagen. Die Mehrstufigkeit liegt im Workflow zwischen den Tabs (Analyse → Profil → Transformation → Feinabstimmung), nicht innerhalb eines einzelnen Aufrufs. Drei Aufgaben sind als getrennte Vorlagen modelliert:

• style_analysis.txt — Extraktion der vier Dimensionen Linguistik, Lexik, Pragmatik, Struktur sowie repräsentativer Beispielsätze.
• style_transformation.txt — Anwendung eines Stilprofils auf einen Text, inhaltlich substanzerhaltend, optional mit zusätzlichem Feedback.
• diff_analysis.txt — Extraktion systematischer Änderungsmuster aus einem Vorher-Nachher-Paar, optional gegen ein vorhandenes Basisprofil.

Konfiguration und Deployment

Die Anwendung wird in einem Docker-Container ausgeliefert (Python 3.11-slim als Basis, Ausführung als Non-Root-Benutzer). Konfiguration erfolgt über Umgebungsvariablen — insbesondere OPENAI_BASE_URL, OPENAI_API_KEY und MODEL_NAME für die LLM-Anbindung sowie GRADIO_SERVER_NAME, GRADIO_SERVER_PORT und GRADIO_ROOT_PATH für den Webserver. GRADIO_ROOT_PATH erlaubt den Betrieb hinter einem Reverse-Proxy unter einem Unterpfad. Ein Healthcheck prüft die Erreichbarkeit der Gradio-Oberfläche.

Robustheit

• Der Token-Bedarf wird vor jedem LLM-Aufruf berechnet und gegen ein konfigurierbares Limit geprüft.
• Profile mit fehlendem oder überlangem Transformations-Prompt werden über eine Fallback-Generierung aus den strukturierten Daten kompensiert.
• Nicht erkennbare oder nicht unterstützte Dateiformate werden vor der Verarbeitung mit einer klaren Fehlermeldung abgewiesen.

Technologie-Übersicht

• Sprache und Laufzeit: Python 3.11.
• Webframework: Gradio (≥ 5.47).
• LLM-Anbindung: OpenAI Python SDK gegen OpenAI-kompatible Endpunkte (z.B. LM Studio, Ollama mit OpenAI-Adapter).
• Tokenisierung: tiktoken (Encoding cl100k_base).
• Dokumentverarbeitung: python-docx, markdown.
• Konfiguration: python-dotenv, Umgebungsvariablen.
• Deployment: Docker, Docker Compose; Healthcheck und Reverse-Proxy-Support über GRADIO_ROOT_PATH.