Open WebUI mit eigenen Dokumenten (RAG): interner Wissens-Chatbot

Pexon Consulting | 10 Min. Lesezeit | 19.06.2026

TL;DR

Open WebUI hat eingebaute RAG-Funktion, reicht aber für Enterprise-Wissens-Chatbots aus SharePoint, Confluence oder größeren PDF-Beständen nicht aus — die produktive Antwort ist Open WebUI plus externe RAG-Pipeline (Azure AI Search oder pgvector) plus Document-Intelligence-Ingestion. Pexon Consulting baut den Setup in 4 Wochen als Festpreis-Sprint zwischen 32 und 58k EUR.

Warum die eingebaute RAG-Funktion oft nicht reicht

Wir hören das oft im Sprint-Discovery: „Wir haben Open WebUI mit der eingebauten Knowledge-Funktion getestet. 50 PDFs hochgeladen, läuft super. Jetzt sollen 8.000 Dokumente aus SharePoint dazu kommen — und plötzlich fallen die Antworten qualitativ ab.“

Die eingebaute RAG-Funktion ist für kleine Wissens-Sets gedacht. Bei produktiven Enterprise-Setups stößt sie an vier Grenzen.

Grenze 1: Volumen. Bei mehr als 1.000-2.000 Dokumenten leidet die Retrieval-Qualität, weil die eingebaute Chunking-Strategie zu einfach ist.

Grenze 2: Format-Robustheit. PDFs mit Tabellen, Excel-Files, Word-Dokumente mit Bildern werden suboptimal verarbeitet. Mehr zur Document-Intelligence-Pipeline-Architektur.

Grenze 3: Permission-Layer. Eingebaute RAG zeigt allen Usern alle Dokumente. Bei Multi-Team-Setups oder Compliance-Anforderungen Pflichthölle. Mehr zum Entra-ID-Permission-Layer-Pattern.

Grenze 4: Quell-System-Sync. Eingebaute Knowledge ist Upload-basiert. Wenn SharePoint-Dokumente sich ändern, müsst ihr neu hochladen.

Die Pexon-Standard-Architektur

Open WebUI als Frontend, externe RAG-Pipeline als Backend.

Komponente 1: Document Intelligence für Ingestion. Microsoft Azure Document Intelligence liest PDFs, Word, Excel strukturiert. Custom-Modelle für domain-spezifische Dokumente (Verträge, Datenblätter, Lastenhefte) werden trainiert.

Komponente 2: Azure AI Search als Vector-Store. Index mit Metadata pro Chunk: tenant_id, allowed_groups, source_document, chunk_position. Bei Retrieval wird User-Permission-Filter angewendet. Mehr zum Azure AI Search vs pgvector-Vergleich.

Komponente 3: RAG-API als Middleware. Pexon-Standard-Komponente, die Open WebUI plus AI Search verbindet. Liefert Retrieval-Treffer mit Citation, schreibt Audit-Trail.

Komponente 4: LiteLLM als LLM-Gateway. Routing zwischen Provider-Backends nach Daten-Klassifikation. Mehr im LLM-Gateway-Konzept.

Das Permission-Pattern im Detail

Wichtigster Differenzierungspunkt gegenüber eingebauter RAG.

Pro Dokument wird die ACL aus dem Quell-System (z.B. SharePoint) übernommen — welche Gruppen oder User dürfen das Dokument sehen. Im Vector-Index landet diese ACL als Metadata allowed_groups.

Bei jeder Anfrage liefert Open WebUI den User-Identity an die RAG-API. Die API holt die Gruppen-Memberships aus Entra ID, filtert den Index-Lauf auf allowed_groups ∈ user_groups.

# Beispiel: Retrieval mit Permission-Filter
def retrieve_with_permissions(query, user_id):
    user_groups = get_entra_groups(user_id)  # Memberships aus Microsoft Graph
    
    results = ai_search_client.search(
        search_text=query,
        vector=embed(query),
        filter=f"allowed_groups/any(g: search.in(g, '{','.join(user_groups)}'))",
        top=10
    )
    
    audit_log.write({
        "user_id": user_id,
        "query_hash": hash(query),
        "result_doc_ids": [r["doc_id"] for r in results],
        "groups_applied": user_groups
    })
    
    return results

Damit sieht der HR-User nur HR-Dokumente, der Vorstands-User auch Vorstandsprotokolle. Audit-Trail dokumentiert jede Anfrage.

Pexon-Sprint und Investment

4-Wochen-Festpreis-Sprint:

• Woche 1 — Discovery und Architektur. Quellen-Inventur (SharePoint, Confluence, File-Server), Permission-Mapping, Document-Bestand-Analyse.
• Woche 2 — Ingestion und Indexierung. Document-Intelligence-Pipeline, AI-Search-Setup, Permission-Layer-Konfiguration.
• Woche 3 — RAG-API und Open-WebUI-Integration. RAG-Middleware, Open-WebUI-Plugin-Konfiguration, LLM-Gateway-Anbindung.
• Woche 4 — Audit, Übergabe. Audit-Pipeline, Pen-Test der Permission-Layer, Schulung.

Investment-Festpreis: 32-58k EUR je nach Komplexität. Untere Spanne bei einfacher Single-Source-Anbindung, obere Spanne bei Multi-Source mit komplexer Permission-Struktur.

Häufig gestellte Fragen

Reicht die eingebaute RAG-Funktion wirklich nie?

Bei kleinen Pilot-Setups (50-500 Dokumente, 1 Team, keine ACL-Anforderung) reicht sie aus. Sobald ihr in Production-Setups landet oder Compliance-Druck habt, ist die externe Pipeline der pragmatische Pfad.

Was bei sehr großen Dokumenten-Beständen (>100.000)?

Skaliert linear. Wir haben Setups bei einem Versicherungs-Kunden mit über 180.000 Dokumenten produktiv. Initial-Indexierung dauert 12-24 Stunden, inkrementelle Updates im Sekunden-Bereich pro Dokument.

Wie verhält sich Onyx zu diesem Setup?

Onyx liefert eine ähnliche Pipeline plus 40+ vorgefertigte Connectoren. Bei klar SharePoint-zentrischen Setups ist die Pexon-Custom-Pipeline pragmatischer; bei Multi-Source-Anforderungen lohnt Onyx. Mehr im Onyx vs Open WebUI-Vergleich.

Was bei nicht-Microsoft-Quell-Systemen (Confluence, Notion, Jira)?

Wir bauen Custom-Konnektoren oder nutzen Onyx als Connector-Layer. Engineering-Aufwand pro Quelle 2-4 Tage.

Wie sicher ist die Permission-Übernahme?

In Pexon-Setups führen wir Pen-Tests mit synthetischen Cross-Permission-Anfragen. Bei aktuellen Setups erreichen wir 100% Treff-Genauigkeit bei korrekt konfiguriertem Sync. Bei Pflegehysterie in den Quell-ACLs (SharePoint mit direkten User-Permissions statt Gruppen) sind die Setups schwieriger — Pre-Sprint-Bereinigung der ACLs ist Pflicht. Mehr zum Multi-Tenant-RAG-Pattern.

Nächster Schritt

Wenn ihr Wissens-Chatbot mit eigenen Dokumenten und Permission-Layer braucht: 60-Minuten-Architektur-Call. Wir skizzieren den Sprint.

Verwandte Themen