Die entscheidende Frage bei einem lokalen Dokumentenassistenten lautet nicht: Welches Sprachmodell ist aktuell das größte? Sie lautet: Kann das System eine Antwort auf die freigegebene, gültige Dokumentversion zurückführen – und schweigen, wenn die Belege nicht ausreichen?
Für Maschinenbauer ist das keine akademische Feinheit. Servicehandbücher, Stücklisten, Wartungsanweisungen, Zeichnungen und Kundenspezifikationen enthalten geistiges Eigentum, widersprüchliche Revisionen und Informationen mit unterschiedlichen Zugriffsrechten. Ein überzeugender Demo-Chat reicht deshalb nicht aus.
Dieser Beitrag beschreibt eine produktionsorientierte Referenzarchitektur mit FastAPI, vLLM, PostgreSQL und pgvector. Sie ist keine erfundene Kundenfallstudie und enthält keine universellen Genauigkeits- oder Laufzeitversprechen. Hardware- und Budgetkorridore sind transparente Planungsannahmen, die vor jeder Einführung mit den realen Dokumenten und Lastprofilen validiert werden müssen.
1. Erst die Abnahmekriterien, dann das Modell
Ein belastbarer Pilot beginnt mit vier Entscheidungen. Ohne sie lässt sich weder die passende GPU auswählen noch seriös beurteilen, ob RAG den Prozess verbessert.
Dokumentgrenze
Welche Formate, Sprachen, Zeichnungen, Tabellen und OCR-Scans gehören zum Scope? Welche Quellen sind ausdrücklich ausgeschlossen?
Gültigkeit
Welche Revision ist freigegeben? Wie werden veraltete, zurückgezogene oder noch nicht geprüfte Dokumente behandelt?
Zugriffsmodell
Welche Rollen dürfen welche Baureihe, welches Kundenprojekt oder welche Serviceebene durchsuchen?
Antwortvertrag
Welche Quellenangabe ist Pflicht, wann muss das System ablehnen und welche Entscheidungen bleiben ausschließlich beim Menschen?
2. Eine Referenzarchitektur mit überprüfbarer Beweiskette
Die zentrale Designregel lautet: Identität und Dokumentberechtigung werden vor dem Retrieval durchgesetzt. Das Sprachmodell sieht nur die wenigen freigegebenen Passagen, die der Retrieval-Layer für diese Anfrage ausgewählt hat – niemals den gesamten Dokumentbestand.
Referenzfluss: lokale Quellen werden versioniert, berechtigungsgefiltert gesucht und erst danach an den ebenfalls lokal betriebenen Inferenzdienst übergeben. Evaluation und Freigaberegeln bilden ein separates Kontrollsystem.
Ingestion ist ein kontrollierter Datenprozess
Parser, OCR und Tabellenextraktion erzeugen Chunks mit Dokument-ID, Seite, Abschnitt, Sprache, Revision, Freigabestatus und ACL. Der Originaltext bleibt mit jedem Chunk verknüpft.
Retrieval kombiniert Bedeutung und exakte Begriffe
Vektorsuche findet semantisch ähnliche Passagen; PostgreSQL-Volltextsuche hält Artikelnummern, Fehlercodes, Werkstoffbezeichnungen und Normen auffindbar. Ein Reranker ordnet die gemeinsame Kandidatenliste.
Inferenz ist austauschbar
vLLM stellt lokal eine OpenAI-kompatible HTTP-Schnittstelle bereit. Dadurch bleibt die Anwendung vom konkreten Open-Weight-Modell entkoppelt und ein Modellwechsel erfordert keinen Neuaufbau der gesamten API.
Die Antwort bleibt ein Entwurf mit Belegen
Das System liefert Status, Antwort, Quellen und Konfidenzsignale in einem festen Schema. Bei widersprüchlichen Revisionen, fehlenden Belegen oder unzulässigem Scope lautet der Status „insufficient_evidence“.
3. Warum pgvector allein noch kein gutes RAG-System ergibt
Ein HNSW-Index beschleunigt die Ähnlichkeitssuche, löst aber weder Berechtigungen noch Versionskonflikte. Gerade bei starken Filtern kann eine approximate Suche weniger Treffer liefern, weil pgvector Filter nach dem Indexscan anwendet. Iterative Scans, Partial Indexes oder Partitionierung müssen deshalb am realen Datenprofil geprüft werden.
Für technische Dokumentation ist Hybrid Retrieval meist robuster: semantische Ähnlichkeit beantwortet natürliche Fragen, Volltextsuche schützt den Recall bei exakten Kennungen. Beide Ergebnislisten können beispielsweise per Reciprocal Rank Fusion zusammengeführt und anschließend gererankt werden.
CREATE TABLE chunks (\n id uuid PRIMARY KEY,\n document_id uuid NOT NULL,\n revision text NOT NULL,\n approval_state text NOT NULL,\n acl text[] NOT NULL,\n page_no integer,\n body text NOT NULL,\n search tsvector GENERATED ALWAYS AS\n (to_tsvector('german', body)) STORED,\n embedding vector(1024) NOT NULL\n);\n\nCREATE INDEX chunks_embedding_hnsw\n ON chunks USING hnsw (embedding vector_cosine_ops);\n\nCREATE INDEX chunks_search_gin\n ON chunks USING gin (search);Die Dimension 1024 ist nur ein Beispiel und muss exakt zum gewählten Embedding-Modell passen. In der eigentlichen Query werden Mandant, ACL, Freigabestatus und Revision serverseitig aus der Identität abgeleitet – nicht aus frei editierbaren Feldern des Clients.
4. Der API-Vertrag erzwingt Belege und eine echte Ablehnung
Das Sprachmodell bleibt probabilistisch. Deterministisch werden dagegen die Grenzen: erlaubte Eingaben, Retrieval-Filter, Ausgabeschema, Quellenprüfung und Freigabeprozess. Ein maschinenlesbarer Ablehnungsstatus ist ehrlicher und operativ nützlicher als eine höflich formulierte Vermutung.
class Citation(BaseModel):\n document_id: UUID\n revision: str\n page: int | None\n excerpt: str\n\nclass RagAnswer(BaseModel):\n status: Literal[\"answered\", \"insufficient_evidence\"]\n answer: str | None\n citations: list[Citation]\n\n@router.post(\"/query\", response_model=RagAnswer)\nasync def query(request: Query, user: User = Depends(require_user)):\n evidence = await retrieve_with_acl(request.question, user)\n return await answer_only_from(evidence, request.question)In Produktion braucht diese vereinfachte Skizze zusätzlich Timeout- und Größenlimits, Rate Limiting, Audit-Events, Tracing, einen geprüften Prompt und eine serverseitige Verifikation, dass jede ausgegebene Citation tatsächlich aus dem freigegebenen Retrieval-Set stammt.
5. On-Premise ist ein Standort, kein Sicherheitskonzept
Ein Server im eigenen Gebäude verhindert nicht automatisch Datenlecks. BSI und ANSSI empfehlen für LLM-basierte Systeme Zero-Trust-Prinzipien; OWASP behandelt außerdem die gesamte RAG-Kette – von Ingestion und Embeddings bis zur Ausgabe – als Angriffsfläche.
Egress standardmäßig sperren
Inference, Embeddings, Telemetrie und Fehlerberichte dürfen nicht unbemerkt externe Dienste aufrufen. Ausnahmen werden explizit freigegeben und protokolliert.
ACL vor dem Retrieval
Mandant, Rolle, Produktlinie und Projektzugriff werden aus SSO bzw. Directory-Gruppen abgeleitet und in der Datenbankquery erzwungen.
Quellen als nicht vertrauenswürdig behandeln
Auch interne PDFs können Prompt-Injection-Inhalte enthalten. Dokumenttext ist Datenkontext, keine ausführbare Anweisung, und darf keine Tools oder Policies überschreiben.
Version und Herkunft sichern
Hash, Quelle, Importzeit, Freigabestatus und Revisionsbeziehung machen nachvollziehbar, aus welchem Dokument eine Aussage stammt.
Ausgaben begrenzen
Schema-Validierung, Citation-Check, erlaubte Markdown-Elemente und fehlende Tool-Rechte reduzieren die Wirkung manipulierter oder fehlerhafter Antworten.
Logs minimieren
Audit-Logs brauchen Nutzer, Dokument-IDs, Policy-Entscheidung und Zeit – nicht zwingend den vollständigen vertraulichen Prompt oder Dokumenttext.
Wichtig: Lokale Verarbeitung kann Datenschutz- und Geheimhaltungsrisiken reduzieren, garantiert aber weder DSGVO- noch NDA-Konformität. Rechtsgrundlage, Aufbewahrung, Rollen, TOMs, Betriebsprozesse und gegebenenfalls eine Datenschutz-Folgenabschätzung bleiben organisationsspezifisch.
6. Hardware nach Modell, Kontext und Gleichzeitigkeit dimensionieren
VRAM wird nicht nur von Modellgewichten belegt. KV-Cache, Kontextlänge, Batch-Größe und parallele Anfragen bestimmen die reale Kapazität. vLLM weist deshalb GPU-KV-Cache und geschätzte maximale Parallelität aus; diese Werte müssen unter dem eigenen Lastprofil geprüft werden.
Pilot · einzelne GPU
Planungsprofil: 32–48 GB VRAM, 128 GB RAM und 2–4 TB NVMe für quantisierte Modelle im Bereich kleiner bis mittlerer Parameterklassen, begrenzte Parallelität und einen abgegrenzten Dokumentbestand.
Geeignet für Evaluation und ein kleines Pilotteam; keine Hochverfügbarkeit und keine Zusage für eine bestimmte Antwortzeit.
Fachbereich · Serverklasse
Planungsprofil: 48–96 GB GPU-Speicher mit ECC, mindestens 256 GB RAM, redundanter NVMe-Speicher und getrennte Dienste für Inferenz, Datenbank und Ingestion. NVIDIA L40S (48 GB) und RTX PRO 6000 Blackwell Server Edition (96 GB) zeigen zwei aktuelle Speicherklassen – keine pauschalen Kaufempfehlungen.
Für mehr Nutzer, längere Kontexte oder größere Modelle; nachhaltige Parallelität wird mit repräsentativen Fragen und Dokumentlängen gemessen.
Produktiv · ausfallsicher
Mindestens zwei Inferenzknoten, replizierte Datenbank, gesicherter Objektspeicher, Monitoring und definierter Wiederanlauf. GPU- und Storage-Redundanz richten sich nach RTO, RPO und erlaubter Degradierung.
Für geschäftskritische Workflows, mehrere Standorte oder verbindliche Betriebszeiten; benötigt Betriebsverantwortung statt nur eines leistungsstarken Rechners.
Die Dokumentanzahl allein ist kein brauchbarer GPU-Indikator: Embeddings liegen typischerweise in der Datenbank, während Modell, Kontext und Gleichzeitigkeit den Inferenzspeicher treiben. Vor Beschaffung gehört deshalb ein Lasttest mit p50/p95-Latenz, Tokenlängen, Warteschlange und KV-Cache-Auslastung.
7. Realistische Kostenkorridore für die Entscheidung
Die teuerste Komponente ist selten nur die GPU. Datenbereinigung, Berechtigungen, DMS-Anbindung, Evaluation, Sicherheitsfreigabe und Betrieb entscheiden darüber, ob aus einem Demo-Chat ein nutzbares System wird. Für eine erste Budgetdiskussion nutze ich folgende Korridore:
Diese Beträge sind unverbindliche Planungsgrößen für die beschriebene Referenzarchitektur, keine Marktstatistik und kein Angebot. Hardware, Lizenzen, Umsatzsteuer, interne Aufwände und laufender Betrieb sind separat zu kalkulieren. Ein kleiner, sauber definierter Pilot ist wirtschaftlich sinnvoller als ein zu früher Enterprise-Einkauf.
8. Was vor dem Go-live gemessen werden muss
Ein Modell-Benchmark beantwortet nicht, ob das System die eigenen Handbücher zuverlässig nutzt. Entscheidend ist ein versionierter Testsatz aus realen, von Fachexperten bewerteten Fragen – einschließlich absichtlich unbeantwortbarer und unzulässiger Anfragen.
Retrieval Recall@k: Wird die richtige Passage überhaupt in den Kandidaten gefunden?
Citation Precision: Belegt die zitierte Seite tatsächlich die konkrete Aussage?
Fachliche Korrektheit: Bestätigt ein zuständiger Experte Antwort und Interpretation?
Abstention: Verweigert das System Antworten bei fehlender oder widersprüchlicher Evidenz?
Berechtigungsisolation: Liefert kein Testfall Inhalte außerhalb der Rolle oder des Mandanten?
Betriebsprofil: p50/p95-Latenz, Fehlerrate und Warteschlange unter repräsentativer Parallelität.
Erst diese Baseline erlaubt einen seriösen Vergleich zwischen Modellen, Chunking-Strategien, Rerankern und Hardware. Zielwerte werden gemeinsam mit dem Fachbereich festgelegt; sie dürfen nicht aus einem fremden öffentlichen Benchmark übernommen werden.
9. Build or buy: Für wen ist eine individuelle Lösung sinnvoll?
Individuelles On-Premise RAG passt, wenn …
- technische IP oder NDA-Dokumente das Firmennetz nicht verlassen dürfen;
- Revisionen, Produktlinien und rollenbasierte Zugriffe Teil der Antwortlogik sind;
- DMS, SharePoint, Fileserver, ERP oder Serviceportal integriert werden müssen;
- Quellen, Ablehnungen und Audit-Events für Freigaben nachvollziehbar sein müssen.
Eine Standardlösung reicht eher, wenn …
- nur wenige, unkritische und öffentlich teilbare Dokumente durchsucht werden;
- keine individuellen Berechtigungen oder Quellsysteme erforderlich sind;
- der Prozess noch keinen verantwortlichen Owner und keine messbaren Abnahmekriterien hat.
Technische Quellen
Die Referenzarchitektur orientiert sich an Primärdokumentation und aktuellen Sicherheitsempfehlungen. Herstellerangaben belegen nur technische Spezifikationen, nicht die Eignung für einen konkreten Workload.
- BSI & ANSSI — Design Principles for LLM-based Systems with Zero Trust
- OWASP — RAG Security Cheat Sheet
- vLLM — OpenAI-kompatibler lokaler Inferenzserver
- vLLM — Parallelism, KV-Cache und Kapazitätsplanung
- pgvector — HNSW, Filter und iterative Index-Scans
- PostgreSQL — Volltextsuche und Ranking
- NVIDIA — L40S, 48 GB ECC-GPU-Speicher
- NVIDIA — RTX PRO 6000 Blackwell Server Edition, 96 GB
Lässt sich Ihre Dokumentenlandschaft sinnvoll lokal erschließen?
In einem 30-minütigen Architekturgespräch prüfen wir nicht zuerst ein Modell, sondern den Prozess: Dokumentquellen, Berechtigungen, Revisionslogik, gewünschte Beweiskette und betriebliche Grenzen.
Das Ergebnis ist eine klare Einschätzung, ob ein abgegrenzter On-Premise-RAG-Pilot technisch und wirtschaftlich sinnvoll ist – oder ob eine einfachere Lösung ausreicht.
Häufige Fragen
Ist On-Premise RAG automatisch DSGVO-konform?
Nein. Lokale Verarbeitung reduziert mögliche Datenübermittlungen, ersetzt aber keine Rechtsgrundlage, Lösch- und Aufbewahrungsregeln, Zugriffskontrollen, technische und organisatorische Maßnahmen oder gegebenenfalls eine Datenschutz-Folgenabschätzung.
Wie viele Dokumente passen in ein solches System?
Die Zahl der Dokumente bestimmt vor allem Storage, Ingestion und Indexgröße. Die GPU wird stärker durch Modellgröße, Kontextlänge und parallele Anfragen belastet. Deshalb ist „Dokumentanzahl pro GPU“ keine seriöse allgemeine Kennzahl.
Welches lokale Modell ist das beste für technische Handbücher?
Das lässt sich ohne den eigenen Testsatz nicht seriös beantworten. Sprache, Tabellen, gewünschte Antwortlänge, Hardware und Berechtigungslogik beeinflussen die Wahl. Die Architektur sollte einen Modellwechsel erlauben, statt den gesamten Prozess an ein Modell zu koppeln.
Kann RAG Halluzinationen vollständig verhindern?
Nein. RAG kann Antworten stärker an Quellen binden, aber Retrieval und Generierung können weiterhin fehlschlagen. Citation-Prüfung, Abstention, strukturierte Outputs, Evaluation und menschliche Freigabe reduzieren das Risiko, beseitigen es aber nicht.
Wie lange dauert ein sinnvoller Pilot?
Ein abgegrenzter Pilot ist typischerweise in drei bis sechs Wochen planbar, wenn Dokumentzugang, Fachverantwortliche und Abnahmekriterien bereitstehen. Komplexe OCR-, DMS-, SSO- oder Berechtigungsthemen können den Zeitraum verlängern.