RAG richtig bauen: warum die meisten Firmen-Chatbots schlecht antworten

Pexon Consulting | 11 Min. Lesezeit | 09.06.2026

TL;DR

RAG richtig bauen ist 2026 die am häufigsten unterschätzte Engineering-Disziplin im Enterprise-AI-Markt: Die meisten Firmen-Chatbots, die wir in Erstgesprächen erleben, liefern bei zufällig ausgewählten Anfragen 30-55% relevante Antworten — der Rest ist halluziniert, irrelevant oder schlicht falsch. Pexon Consulting baut RAG-Pipelines mit Hybrid-Retrieval, Reranking und sauberem Quellen-Cite-Pattern, die auf 85-92% Relevanz kommen. Hier die ehrlichen Gründe, warum die Standard-Ansätze scheitern — und was wir konkret anders machen.

Warum so viele Firmen-Chatbots schlecht antworten

Wir hören das aktuell wöchentlich: Ein CTO eines Mittelständlers hat einen Firmen-Chatbot bauen lassen — oft durch eine Inhouse-Initiative oder einen externen Berater, der einen LangChain-Tutorial in zwei Wochen umgesetzt hat. Drei Monate nach Roll-out ist die Nutzung niedrig, das Feedback bitter: „Antworten sind oft falsch“, „Findet nicht, was er finden sollte“, „Erfindet Sachen“. Die Mitarbeiter nutzen lieber Google oder fragen den Kollegen.

Das Problem ist nicht das LLM. Claude Sonnet 4.6 oder GPT-4o sind 2026 erstklassige Generierungs-Modelle — wenn sie den richtigen Kontext bekommen, antworten sie korrekt. Das Problem ist die Retrieval-Pipeline, die den falschen Kontext liefert. Wenn die Top-3-Treffer aus der Vektor-Datenbank die Frage nicht wirklich beantworten, halluziniert das LLM oder antwortet vage.

Konkret sehen wir vier strukturelle Fehler in der Praxis. Erstens: Nur Dense Embeddings, kein BM25. Dense Embeddings sind gut für semantische Ähnlichkeit, aber schlecht für exakte Begriffs-Matches (technische IDs, Norm-Nummern, eigene Produktnamen). Zweitens: Naive Chunking mit fixer Token-Größe, ohne Rücksicht auf Dokumenten-Struktur. Drittens: Keine Reranking-Schicht — die Top-3 aus dem Vektor-Search sind oft nicht die Top-3 für die konkrete Frage. Viertens: Keine Quellen-Cites, sodass User die Antwort nicht plausibilisieren können.

Was die Pexon-RAG-Pipeline anders macht

Architektur in vier Schritten:

Schritt 1: Semantisches Chunking pro Doku-Typ. Statt fixer 500-Token-Chunks bauen wir Chunking-Strategien pro Doku-Typ. Bei Lastenheften nach Sektionen, bei FAQ nach Frage-Antwort-Paaren, bei Code nach Funktionen, bei Wiki-Artikeln nach Überschriften. Das klingt nach Mehraufwand, ist aber für 80% der Use-Cases eine 30-Minuten-Engineering-Aufgabe pro Doku-Typ — und der Qualitäts-Effekt ist erheblich.

Schritt 2: Hybrid Retrieval mit BM25 plus Dense. Bei jeder Anfrage werden zwei Such-Schichten parallel ausgeführt. Dense Embeddings (typisch über e5-mistral oder bge-large für deutsche Inhalte) für semantische Ähnlichkeit, BM25 für exakte Begriffs-Treffer. Die Top-20 aus beiden werden zusammengeführt, Duplikate entfernt, Resultat sind 25-35 Kandidaten.

Schritt 3: Cross-Encoder-Reranking. Ein dedizierter Cross-Encoder (typisch bge-reranker-v2-m3 oder ein deutsch-spezialisierter Reranker) bewertet jedes Kandidaten-Chunk gegen die Anfrage und sortiert neu. Aus den 25-35 Kandidaten werden die Top-5 für den finalen LLM-Kontext ausgewählt. Diese Schicht ist der größte Quality-Hebel — und wird in Standard-RAG-Tutorials oft weggelassen.

Schritt 4: Generierung mit Pflicht-Cites. Das LLM bekommt die Top-5-Chunks als Kontext, mit klarer Anweisung im System-Prompt: Jede Aussage muss mit einer Quellen-Referenz belegt sein, ohne Quelle keine Aussage. Bei niedriger Konfidenz wird die Antwort entsprechend markiert. User sieht im UI die Quellen mit Klick-Link, kann jede Antwort prüfen.

Drei konkrete Verbesserungs-Hebel aus Pilotprojekten

Hebel 1: Reranker einbauen. Bei einem Pilotkunden waren wir mit Standard-Dense-Retrieval bei 67% Antwort-Relevanz. Nach Einbau eines Cross-Encoder-Rerankers sprang das auf 81% in einer Woche. Das ist der mit Abstand wirkungsvollste Engineering-Schritt für die meisten RAG-Setups.

Hebel 2: Chunking pro Doku-Typ. Bei einem zweiten Kunden war das Problem, dass naive 500-Token-Chunks die Frage-Antwort-Paare in der FAQ zerrissen — der Chatbot lieferte die Frage, aber nicht die zugehörige Antwort. Sektion-basiertes Chunking auf den FAQ-Quellen brachte 15 Prozentpunkte Relevanz-Steigerung in zwei Tagen Engineering.

Hebel 3: Multi-Modal für Tabellen. Viele technische Dokumente enthalten zentrale Information in Tabellen — Toleranzen, Material-Kennwerte, Preislisten. Standard-RAG verliert das, weil Tabellen nicht sauber als Text geparst werden. Wir nutzen GPT-4o Vision oder Claude Vision direkt auf den Tabellen-Bildern, embedden die strukturierten Outputs zusätzlich. Bei einem technischen Wissensportal hat das die Trefferquote bei Tabellen-bezogenen Fragen von 41% auf 87% gehoben.

Diese Hebel wirken nur, wenn jemand sie dauerhaft nachzieht, denn Retrieval-Qualität ist kein Projektergebnis, sondern ein Betriebsthema. In unseren Projekten läuft das über einen firmeninternen KI-Chatbot mit RAG-Anbindung, bei dem Chunking, Reranking und Quellenpflege Teil des Betriebs sind.

Was RAG NICHT lösen kann — die ehrlichen Limitationen

Hier liegt der Punkt, den wir Kunden klar mitgeben, damit die Erwartung realistisch bleibt.

RAG kann nicht Fragen beantworten, deren Antwort nicht in den Quellen steht. Klingt trivial, wird aber oft ignoriert. Wenn dein Wiki nicht erklärt, warum eine bestimmte Konstruktions-Entscheidung 2018 so getroffen wurde, kann RAG diese Frage nicht beantworten — egal wie gut der Retriever ist. Hier brauchst du Audio-Interview-Pipelines mit den Original-Entscheidern, wie im Wissensdatenbank-Blog beschrieben.

RAG ist nicht gut bei Cross-Doku-Reasoning. Wenn die Antwort die Synthese aus fünf Dokumenten erfordert, die jeweils nur einen Teil-Aspekt liefern, schlägt klassisches RAG fehl. Hier brauchst du Agent-basierte Multi-Turn-Recherche, bei der das System iterativ aus dem Kontext heraus weitere Suchanfragen stellt. Das ist Engineering mit eigenem Setup-Aufwand.

RAG ist nicht das richtige Werkzeug für strukturierte Daten. Stammdaten aus dem ERP, Kennzahlen aus dem Data Warehouse, Transaktions-Historien — das gehört nicht in einen Vector Store. Hier brauchst du Tool-Use über MCP-Server gegen die strukturierten Quellen, nicht RAG. Mehr im Universal MCP Client Blog.

RAG braucht laufende Quellen-Pflege. Bestandsindex muss kontinuierlich aktualisiert werden, sonst veralten die Antworten. Wir bauen das mit Change-Triggern aus SharePoint, Confluence, ERP-DBs — neue oder geänderte Dokumente landen automatisch im Index, alte werden invalidiert. Ohne diesen Mechanismus ist der Chatbot nach drei Monaten nicht mehr aktuell.

Häufig gestellte Fragen

Welche Vector-DB für Mittelstand?

Für 80% der Setups reicht Postgres mit pgvector. Skaliert problemlos bis zu 5-10 Millionen Chunks bei moderater Last. Für höhere Last oder Multi-Tenant-Setups empfehlen wir Qdrant oder Weaviate. Pinecone und ähnliche SaaS-Lösungen vermeiden wir bei DSGVO-relevanten Kunden, weil die Daten extern liegen.

Welches Embedding-Modell für deutsche Inhalte?

Aktuell e5-mistral-7b-instruct oder bge-large-de sind die zwei führenden Optionen für deutsche Inhalte. Bei mehrsprachigen Setups multilingual-e5-large. Wir benchmarken vor jedem Sprint mit dem konkreten Doku-Bestand, weil die Trefferqualität je nach Domäne stark schwanken kann.

Wie groß sollen die Chunks sein?

Standard-Faustregel 200-800 Tokens, aber die richtige Größe hängt vom Doku-Typ ab. Bei FAQ-Paaren typisch 100-300 Tokens, bei langen Wiki-Artikeln 500-800. Bei strukturierten Tabellen oft ein Chunk pro Tabelle. Naive Single-Size für alle Typen ist der größte Anti-Pattern.

Wie messen wir die RAG-Qualität?

Wir bauen mit jedem Kunden ein Eval-Set aus 50-150 realen Fragen, die typische Anwendungsfälle abdecken. Jede Frage hat eine erwartete „korrekt und vollständig“-Antwort, geprüft von einem Fachexperten. Bei jeder Pipeline-Änderung läuft das Eval-Set und liefert eine harte Zahl: Wie viel Prozent der Fragen werden mit „korrekt und vollständig“ beantwortet. Ohne dieses Eval-Pattern fliegen alle Optimierungs-Entscheidungen blind.

Wann lohnt sich Fine-Tuning des Embedding-Modells?

Selten. Bei sehr domänen-spezifischen Inhalten (Spezial-Branche mit eigenem Fach-Vokabular, das in Standard-Modellen schlecht abgebildet ist) kann Fine-Tuning 5-10 Prozentpunkte Trefferqualität bringen. Aufwand ist 4-8 Wochen Engineering plus eigenes Trainingsset. Wir empfehlen das erst, wenn alle anderen Hebel ausgeschöpft sind.

Nächster Schritt

Wenn euer Firmen-Chatbot heute schlechte Antworten liefert oder ihr gerade eine RAG-Pipeline baut: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise einem Engineering-Lead. Du beschreibst die Quellen-Landschaft und die aktuelle Pipeline, wir skizzieren die Verbesserungs-Hebel mit Festpreis-Sprint.

Verwandte Themen