1.  Ziel

Die Lösung wird in klar getrennte Module zerlegt, um:

• Updates unabhängig ausrollen zu können (z.B. WebUI ohne RAG anzufassen)

• Komponenten separat zu lizenzieren/verkaufen (z.B. RAG als Produkt, UI als Add-on)

• Rollen- und Netztrennung zu ermöglichen (Admin vs Guest)

• Störungen einzugrenzen (ein Service down ≠ gesamtes System down)

• Migration/Backup/Restore einfacher zu machen

• Verlagerung auf mehrere Maschinen

2.  Modul-Schnitt

Modul A —  Gateway / Webserver

Inhalt

• NGINX (Reverse Proxy, TLS, Routing)

• vHosts homecpt und guest.homecpt

• Pfadrouting / → WebUI, /rag/ → RAG API

Modul B — LLM Runtime

Inhalt

• Ollama (+ GPU)

• Model Storage (Volume)

• optional: Model aliases (z.B. mixtral:8x22b

Schnittstellen

• HTTP API :11434 (intern)

• Nutzung nur über llm-net (Docker DNS: http://ollama:11434)

Modul C — Web UI

Inhalt

• Open WebUI normal (Login)

• Open WebUI guest (ohne Login)

Schnittstellen

• intern open-webui:8080, open-webui-guest:8080

• extern via NGINX auf 80/443

Modul D — RAG Backend

Inhalt

• RAG API (FastAPI) mit Web UI

• Upload, Chunking, Embeddings, Retrieval, Answer Generation

• Reranker Service

Schnittstellen

• rag-api:8080 intern → extern via NGINX /rag/

• reranker:8090 nur intern/localhost

• hängt an llm-net (Ollama) und default net (Qdrant)

Modul E — Vector Store

Inhalt

• Qdrant + persistentes Volume

Warum getrennt?

• Datenhaltung = eigenes Lifecycle/Backup

• kann später ersetzt werden (pgvector, elastic, weaviate)

• bei Distribution wichtig (Datenschutz, Mandantentrennung, Backupstrategie)

3. Meine Ordnerstruktur sieht dann so aus

Nur die Docker!

/opt

  /ai-chat

    docker-compose.yml        (Ollama + WebUI)

  /RAG-Datenschutz

    docker-compose.yml        (RAG API + reranker + qdrant)

    rag-api/

    reranker/

    data/

4. Praktische Umsetzung

ai-chat Stack

• ollama

• open-webui

• open-webui-guest

• llm-net (external)

RAG-Datenschutz Stack

• rag-api (+ llm-net)

• reranker

• qdrant

Warum 2 Compose-Stapel statt 1?

• getrennte Updatezyklen

• unabhängige Verfügbarkeit

• leichteres Rollback pro Modul

• klare Verantwortlichkeiten

5. Zusammenfassung

Die Lösung wurde in getrennte Module zerlegt (Gateway, LLM Runtime, UI, RAG Backend, Vector Store), um Updates, Rollbacks und spätere Distribution zu vereinfachen. Diese Modularisierung reduziert Kopplung, ermöglicht differenzierte Sicherheitszonen (Admin/Gast) und erlaubt eine spätere Produktisierung einzelner Komponenten (z.B. RAG als eigenständiges Modul).