RAG in Produktion 2026: Die Checkliste für Enterprise-Teams

„Die Demo war super. In Produktion antwortet die KI falsch, langsam oder gar nicht." Diesen Satz höre ich seit 2024 regelmäßig – zuletzt wieder bei einem CompanyGPT-Projekt, bei dem nach drei Wochen Prompt-Tuning immer noch die Hälfte der Testfragen scheiterte. Ursache: nicht das Modell, sondern Retrieval, Chunking und fehlende Zugriffskontrolle.

Ich komme aus der Enterprise Search – zehn Jahre Sinequa, Indizes, ACLs, Relevanz-Tuning. RAG ist für mich keine neue Erfindung, sondern Search plus LLM. Wer Search-Disziplin ignoriert und nur am Prompt dreht, baut keine Produktionslösung. Dieser Artikel ist meine Checkliste für Teams, die nach dem Proof of Concept ernst werden wollen.

Bei Join GmbH in Eisenach arbeite ich genau an dieser Schnittstelle: CompanyGPT für interne Wissensarbeit, mit denselben Ansprüchen an Zugriff, Relevanz und Nachvollziehbarkeit, die ich früher bei Suchprojekten hatte. Der Unterschied: Das LLM formuliert die Antwort – aber nur so gut, wie das Retrieval liefert.

Kontext ohne Hype

2024 war das Jahr der RAG-Demos: PDF hochladen, Frage stellen, Beifall. 2026 entscheidet Betriebsqualität. Halluzinationen, langsame Antworten und Datenlecks sind keine „KI-Eigenheiten" – sie sind Architekturfehler, die sich beheben lassen.

RAG in Produktion bedeutet: dokumentierte Chunking-Strategien, Hybrid Search, ACLs auf Index-Ebene, Evaluation vor jeder Änderung, Kostenkontrolle und Observability. Das klingt nach Arbeit, weil es Arbeit ist. Aber es ist vorhersagbare Arbeit – nicht monatelanges Rätselraten am System-Prompt.

1. Chunking mit System, nicht mit Default

Ein Default von 512 Token für alles reicht selten. Ich teste Chunking immer mit 20–30 echten Fragen aus dem Fachbereich – nicht mit „Was steht in Kapitel 3?"

Embedding-Modell: Wechsel des Embedding-Modells bedeutet vollständigen Re-Index. Ich dokumentiere Modellwahl und Dimensionen vor dem ersten Index-Lauf. Mischen alter und neuer Embeddings im selben Index ist keine Option.

2b. Parsing vor dem Chunking

Bevor Chunks entstehen, muss der Text stimmen. PDFs mit gescannten Seiten brauchen OCR. Tabellen in Word oder PDF brauchen layout-aware Extraktion – sonst landen Zellwerte in falscher Reihenfolge im Chunk. Das ist der häufigste Grund, warum „die KI die Tabelle falsch erklärt": Sie hat nie die richtige Tabelle gesehen.

2. Hybrid Search – nicht optional

Reine Vektor-Suche scheitert bei exakten Begriffen: Produktcodes, §-Paragraphen, Ticket-IDs, Seriennummern. Ich kombiniere:

• Dense (Embeddings) für semantische Ähnlichkeit
• Sparse (BM25/Keyword) für exakte Treffer
• Reciprocal Rank Fusion oder gewichtete Scores

In Sinequa und modernen Stacks ist Hybrid oft Standard. Bei Greenfield-Projekten mit Qdrant oder Elasticsearch plane ich Hybrid von Anfang an – nicht als späteres Upgrade.

3. ACL auf Index-Ebene

RAG ohne ACL ist ein Datenleck. Jede Abfrage muss:

1. Die User-Identität kennen (SSO, Token)
2. Filter auf Index-Ebene anwenden – nicht nur Post-Filter im Prompt
3. In der Antwort nur Quellen zeigen, die der Nutzer lesen darf

Post-Filter allein reicht nicht. Der LLM-Kontext darf nie Chunks enthalten, die der Nutzer nicht sehen darf – auch wenn die Antwort sie nicht zitiert. Das ist aus meiner Search-Zeit keine neue Regel, aber in RAG-Projekten wird sie erstaunlich oft übersehen.

4. Evaluation vor Skalierung

Ich baue ein Golden Set mit 30–50 echten Fragen – vom Fachbereich, nicht vom IT-Team erfunden:

• Faithfulness: Antwort nur aus Kontext?
• Relevance: Richtige Chunks retrieved?
• Latency: p95 unter eurem SLA?

Tools wie RAGAS oder DeepEval helfen; am Anfang reichen auch manuelle Labels in einer Tabelle. Entscheidend: vor und nach jeder Pipeline-Änderung messen. Sonst weißt du nicht, ob dein neues Chunking besser oder schlechter war.

Ich lege die Golden-Set-Fragen in einem Sheet ab: Frage, erwartete Quelle, tatsächliche Quelle, Faithfulness (ja/nein), Kommentar. Nach vier Wochen hat das Team ein gemeinsames Bild – nicht nur „gefühlt besser".

4b. Regression bei jeder Änderung

Chunking, Embedding-Modell, top-k, Reranker – jede Änderung kann Faithfulness verbessern und Relevance verschlechtern. Deshalb messe ich mindestens drei Metriken gleichzeitig. Eine Pipeline, die 95 % Faithfulness aber 40 % Relevance hat, beantwortet ehrlich – aber oft „keine Information", weil die falschen Chunks kommen.

5. Kostenkontrolle

RAG kann teuer werden – nicht am Chat-Modell, sondern an Embeddings und Volumen:

• Embedding-Cache für unveränderte Dokumente
• Kleinere Modelle für Routing und Klassifikation
• LiteLLM-Budgets pro Team
• Top-k begrenzen (5–8 Chunks reichen oft)
• Re-Index nur bei echten Dokumentänderungen, nicht wöchentlich „zur Sicherheit"

6. Observability

Ohne Logs kein Debugging bei „die KI lügt". Pro Request logge ich:

• Query (ggf. anonymisiert), retrieved Chunk-IDs, Modell, Token, Latenz
• User-Feedback (Daumen hoch/runter)
• Fehler, Timeouts, leere Retrieval-Ergebnisse

Für Piloten in Open WebUI reicht oft ein einfaches Request-Log. In Produktion gehört das ins zentrale Monitoring.

6b. Re-Index und Dokumenten-Lebenszyklus

Gelöschte Dokumente müssen aus dem Index verschwinden – nicht erst beim nächsten Big-Bang-Re-Index. Geänderte Versionen brauchen neue Chunks und Invalidierung alter. Ich plane von Anfang an: Event aus CMS/DMS → Queue → Embedding → Upsert/Delete. Ohne diesen Prozess antwortet die KI mit veralteten Preisen, alten Ansprechpartnern oder Policies, die es nicht mehr gibt. Das ist kein Halluzinationsproblem – das ist veralteter Index.

6c. Modellwechsel ohne Überraschung

Ein neues Chat-Modell lässt sich oft über LiteLLM per Alias wechseln. Ein neues Embedding-Modell bedeutet Re-Index. Ich halte beides in Runbooks getrennt – sonst denkt das Team, ein Alias-Wechsel reiche, und wundert sich über schlechtere Treffer.

7. Antworten mit Quellen

Nutzer vertrauen Antworten mit Zitaten – und verlieren Vertrauen ohne. Mein UI-Pattern:

• Inline-Referenzen [1], [2]
• Klick öffnet Originaldokument an der richtigen Stelle
• „Dazu liegen mir keine Informationen vor" als ehrliche Antwort erlauben und erwünscht

Eine KI, die immer antwortet, ist verdächtiger als eine, die Grenzen zeigt.

Agenten und MCP – wo RAG aufhört

Für Tool-Zugriff und IDE-Integration nutze ich MCP – aber MCP ersetzt keine RAG-Pipeline. Wissensfragen über Dokumente laufen über Retrieval mit ACL. Aktionen in Systemen (Ticket anlegen, Code committen) laufen über Tools mit eigenen Berechtigungen. Die Architektur muss das trennen.

Was ich in Projekten anders mache

Retrieval vor Prompt. Die ersten zwei Wochen investiere ich in Chunking, Hybrid Search und Golden Set – nicht in System-Prompt-Formulierungen.

Ein Dokumenttyp nach dem anderen. Handbücher zuerst, Tickets später, E-Mails vielleicht nie. Jeder Typ braucht eigenes Chunking.

Pilot mit echten Nutzern früh. 10 Personen aus dem Fachbereich schlagen 100 interne IT-Tests.

Kein Big-Bang-Re-Index. Inkrementelle Updates mit klarer Strategie für gelöschte und geänderte Dokumente.

Automatisierung für Ops, nicht für Wissensfragen. Wiederkehrende Prozesse (Zusammenfassung, Klassifikation) gehen an n8n. Offene Wissensfragen an RAG mit Quellen.

Zum Abschluss ein Satz, den ich in Reviews oft sage: Wenn euer Golden Set nach vier Wochen nicht größer ist als am ersten Tag, testet ihr nicht – ihr hofft. Jedes echte Nutzer-Feedback gehört ins Set, anonymisiert wenn nötig. So wird aus einer Demo ein lernendes System.

Produktions-Checkliste

1. Chunking-Strategie pro Dokumenttyp dokumentiert und getestet
2. Hybrid Search aktiv
3. ACL auf Index-Ebene implementiert und mit Test-Accounts verifiziert
4. Golden Set mit 30–50 Fragen und Metriken (Faithfulness, Relevance, Latency)
5. LiteLLM oder vergleichbare Kosten-Governance
6. Request-Logging und Feedback-Loop
7. Quellen in der UI, inklusive „keine Information"
8. Runbook für Re-Index, Modell-Wechsel und Provider-Ausfall

Fazit

RAG in Produktion ist Enterprise Search plus LLM – nicht „ChatGPT mit PDF-Upload". Wer Search-Disziplin mit LLM-Governance verbindet, baut CompanyGPT, dem Fachbereiche vertrauen. Der Rest ist Feintuning.

Unterstützung bei RAG-Architektur und Rollout? LinkedIn