RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt

Die Demo glänzte, die Produktion enttäuschte

Ein Kunde aus der Versicherungsbranche zeigte uns vor ein paar Monaten stolz seinen neuen Chatbot. Er sollte Fragen zu internen Policen-Dokumenten beantworten, mit Zugriff auf tausende PDFs voller Vertragsbedingungen. In der Demo liefen drei sorgfältig ausgewählte Fragen, der Bot antwortete druckreif, alle im Raum nickten. Zwei Wochen nach dem Rollout kam die erste Beschwerde: Ein Sachbearbeiter hatte nach der Kündigungsfrist für ein bestimmtes Gewerbeversicherungsprodukt gefragt, und der Bot nannte eine Frist, die schlicht falsch war: Sie stammte aus einem ähnlich klingenden, aber falschen Dokument. Das Modell hatte nicht im eigentlichen Sinn halluziniert. Es hatte präzise wiedergegeben, was ihm im Kontext vorgelegt wurde. Nur war das die falsche Textstelle.

Genau das ist die Pointe dieses Artikels, und wir sagen sie gleich zu Beginn, weil sie in praktisch jedem RAG-Debugging-Gespräch untergeht: fast jede schlechte RAG-Antwort ist kein Modell-Problem, sondern ein Retrieval-Problem. Wenn das richtige Snippet nicht im Kontext landet, kann selbst das beste LLM der Welt nur raten, und es rät oft überzeugend. Bevor du also über ein grösseres Modell, ein Fine-Tuning oder einen cleveren Prompt nachdenkst, lohnt sich zuerst die zentrale Frage: Kommt bei der Suche überhaupt das Richtige raus? Garbage in, garbage out gilt bei RAG gnadenlos.

Retrieval-Augmented Generation klingt in der Theorie fast langweilig einfach: Anstatt ein Sprachmodell aus seinem antrainierten Gedächtnis raten zu lassen, durchsuchst du zuerst deine eigene Wissensbasis nach den relevantesten Textabschnitten und gibst diese dem Modell als Kontext mit. Das Modell muss dann nicht mehr wissen, sondern nur noch lesen und zusammenfassen. Für Unternehmen ist das der naheliegende Weg, ein LLM mit internem Wissen zu füttern, ohne es teuer nachzutrainieren und ohne dass sensible Dokumente im Modellgewicht landen. Das Prinzip ist so simpel, dass praktisch jedes Tutorial es in zwanzig Zeilen Code zeigt: Dokument einlesen, in Stücke schneiden, embedden, in eine Vektordatenbank werfen, bei einer Frage die ähnlichsten Stücke holen, dem Modell servieren.

Genau diese Einfachheit ist die Falle. Ein RAG-Prototyp lässt sich an einem Nachmittag bauen: Ein RAG-System, das in Produktion verlässlich funktioniert, ist ein Informationsretrieval-Projekt mit einem LLM am Ende, kein LLM-Projekt mit ein bisschen Suche davor. Wer das umdreht, baut genau die Art von System, die in der Demo glänzt und im Alltag falsche Kündigungsfristen erfindet.

Chunking: der stille Killer der meisten RAG-Systeme

Der häufigste Fehler passiert, bevor überhaupt ein Embedding berechnet wird: beim Zerschneiden der Dokumente. Die naive Variante (alle 500 oder 1000 Zeichen ein neuer Chunk, egal was gerade dasteht) zerschneidet gnadenlos mitten in Sätzen, reisst Tabellenzeilen von ihrer Kopfzeile ab und trennt eine Absatzüberschrift von genau dem Text, den sie einleitet. Das Embedding eines solchen Fragments repräsentiert dann weder den ursprünglichen Gedanken noch lässt es sich später sinnvoll einer Frage zuordnen. Bei zu grossen Chunks passiert das Gegenteil: Mehrere Themen landen in einem einzigen Embedding-Vektor, der dadurch verwässert wird und bei semantischer Suche zu unspezifisch matched, um bei einer präzisen Frage weit oben zu landen.

Die Faustregel liegt meist zwischen 200 und 500 Tokens pro Chunk, mit 10 bis 20 Prozent Overlap zwischen benachbarten Stücken, damit ein Gedanke, der genau auf einer Chunk-Grenze sitzt, nicht komplett verloren geht. Wichtiger als die genaue Zahl ist aber das Prinzip: Chunk entlang der Struktur des Dokuments, nicht entlang einer starren Zeichenanzahl. Überschriften, Absätze, Tabellenzeilen und Listenpunkte sind natürliche Grenzen: Ein semantisch bewusstes Chunking, das diese respektiert, schlägt naives Fixed-Size-Splitting in fast jedem Praxistest deutlich. Und: Metadaten wie Quelldokument, Abschnittstitel, Datum oder Gültigkeitsbereich gehören an jeden Chunk drangehängt, sonst kannst du später weder filtern noch die Antwort belegen.

Embeddings: wenn das Modell dein Deutsch nicht versteht

Der zweite Klassiker ist die Wahl des Embedding-Modells, und zwar meist deshalb, weil sie gar nicht bewusst getroffen wurde, sondern aus einem Tutorial übernommen ist, das mit englischen Beispieldaten funktioniert hat. Viele populäre Embedding-Modelle sind primär auf Englisch trainiert und performen bei deutschen Fachtexten spürbar schlechter: Fachbegriffe aus dem Schweizer Recht, branchenspezifisches Vokabular oder zusammengesetzte Wörter, wie sie im Deutschen ständig vorkommen, werden schlicht schlechter in den Vektorraum abgebildet. Das Ergebnis sind Embeddings, die zwei thematisch unterschiedliche Absätze als ähnlich einstufen, während der eigentlich passende Absatz weiter unten in der Trefferliste verschwindet.

Das Embedding-Modell muss zur Sprache und zur Domäne deiner Dokumente passen, nicht zur Popularität auf einem Leaderboard. Für Schweizer Unternehmen mit viel deutschem, oft mehrsprachigem und fachspezifischem Content bedeutet das: mehrsprachige oder deutschsprachige Embedding-Modelle testen, idealerweise mit eigenen Dokumenten statt mit Benchmark-Datensätzen, und bei starker Fachterminologie (Recht, Medizin, Technik) zusätzlich prüfen, ob eine Domänenanpassung nötig ist. Wenn du dabei ohnehin über die technische Basis nachdenkst, lohnt sich ein Blick auf offene Modelle und ihre Auswahlkriterien. Dieselben Fragen gelten für Embedding-Modelle genauso wie für das generierende LLM.

Retrieval-Strategie, top_k und das Problem der Mitte

Selbst mit gutem Chunking und passendem Embedding-Modell scheitert reine Vektor-Ähnlichkeitssuche regelmässig an einer bestimmten Fragenkategorie: exakte Begriffe. Eine Kundennummer, eine Produktbezeichnung, ein Paragraf, ein Eigenname: all das sind Dinge, bei denen semantische Ähnlichkeit die falsche Metrik ist, weil zwei Textstellen mit ähnlicher Bedeutung, aber unterschiedlichem exaktem Begriff, im Vektorraum nahe beieinander liegen können, während die eine Stelle mit der exakt richtigen ID weiter weg liegt. Hybrid-Suche, die Vektor-Ähnlichkeit mit klassischer Keyword-Suche wie BM25 kombiniert, und ein nachgeschalteter Reranker heben die Trefferqualität in unseren Projekten regelmässig deutlich: Oft ist das der grösste Qualitätssprung, den man mit überschaubarem Aufwand erreicht, weil beide Suchparadigmen ihre jeweilige Stärke ausspielen.

Die zweite Stellschraube ist topk, also wie viele Chunks du dem Modell überhaupt mitgibst. Zu wenig, und die richtige Information fehlt schlicht im Kontext: Das Modell kann nicht antworten, was es nicht sieht. Zu viel, und du produzierst Rauschen: Modelle nutzen Informationen am Anfang und Ende eines langen Kontexts zuverlässiger als Informationen, die irgendwo in der Mitte vergraben sind (der bekannte Lost in the middle-Effekt). Ein grosszügiges topk von 20 oder 30 Chunks wirkt auf den ersten Blick sicherer, verschlechtert die Antwortqualität in der Praxis aber oft, weil das Modell die relevante Stelle im Textbrei übersieht. top_k zwischen 3 und 8 relevanten, gut gerankten Chunks ist in den meisten Fällen die bessere Wahl als eine grosse Zahl schlecht sortierter Treffer.

Datenqualität, Aktualität und die fehlende Evaluation

Selbst die beste Such-Pipeline liefert Müll, wenn die zugrunde liegende Wissensbasis Müll ist. Veraltete Preislisten neben der aktuellen Version, drei sich widersprechende Fassungen desselben Prozessdokuments, dupliziert über verschiedene Sharepoint-Ordner: Das ist in fast jedem Unternehmen, das wir kennenlernen, Realität, nicht Ausnahme. Ein RAG-System kann nicht wissen, welche der drei Versionen gilt, und wird im Zweifel eine davon zufällig ziehen, je nachdem, welche gerade am ähnlichsten zur Frage embedded wurde. Genauso wichtig: Wenn deine Antworten keine Quellenangabe enthalten (welches Dokument, welcher Abschnitt, welches Datum), ist das System nicht auditierbar, und niemand kann im Nachhinein prüfen, ob eine Antwort stimmte oder woher ein Fehler kam.

Der zweite, fast noch häufigere Mangel ist das komplette Fehlen von Evaluation. Die meisten Teams testen ein RAG-System, indem jemand ein paar Fragen in die Chat-Oberfläche tippt und subjektiv beurteilt, ob die Antwort gut klingt. Ohne ein Golden-Set aus repräsentativen Frage-Antwort-Paaren mit bekannt korrekten Quellenbelegen lässt sich Qualität nicht messen, sondern nur erahnen, und genau deshalb fallen Regressionen erst auf, wenn Kunden oder Mitarbeitende sie melden. Ein sauberes Setup misst Retrieval-Recall (landet das richtige Snippet überhaupt in den Top-k-Treffern?) und Antwortqualität (nutzt das Modell den gelieferten Kontext korrekt?) als zwei getrennte Kennzahlen, gemessen auf demselben Golden-Set nach jeder Änderung an Chunking, Embedding-Modell oder Prompt.

Diagnose: zwei Fragen trennen, bevor du irgendetwas änderst

Wenn ein RAG-System schlecht antwortet, ist der Reflex meist, am Prompt herumzubasteln oder ein grösseres Modell auszuprobieren. Das ist fast immer der falsche Hebel. Stelle stattdessen zuerst zwei Fragen sauber getrennt: Erstens, ist das richtige Snippet überhaupt im Kontext gelandet, den das Modell gesehen hat? Das prüfst du, indem du dir bei jeder fehlerhaften Antwort explizit die abgerufenen Chunks anschaust, bevor du dir die generierte Antwort überhaupt ansiehst. Zweitens, und nur wenn die erste Frage mit Ja beantwortet ist: Hat das Modell aus einem korrekten Kontext trotzdem falsch geantwortet? In unserer Erfahrung liegt das Problem in der überwältigenden Mehrheit der Fälle bei Frage eins, nicht bei Frage zwei: Das Retrieval liefert die falsche oder unvollständige Grundlage, und das Modell tut danach genau das, was man von ihm erwarten würde: Es macht aus unzureichendem Material eine plausibel klingende, aber falsche Antwort.

Diese Trennung ist auch der Grund, warum die Frage Agent oder Endpoint? hier eine klare Antwort hat. Ein Dokumenten-Q&A-System, das Fragen zu einer Wissensbasis beantwortet, ist in den allermeisten Fällen ein Endpoint, kein Agent: eine klar definierte Pipeline aus Retrieval und Generation, kein autonom planendes System mit Tool-Aufrufen und mehreren Entscheidungsschritten. Wer ein RAG-Problem mit Agent-Architektur zu lösen versucht, fügt Komplexität hinzu, ohne das eigentliche Retrieval-Problem zu beheben. Erst wenn dein System tatsächlich mehrstufig recherchieren, Tools aufrufen oder Aktionen ausführen soll, wird aus dem Q&A-Endpoint sinnvollerweise ein Agent.

Ein letzter Punkt, der in technischen RAG-Diskussionen oft untergeht: Deine Wissensbasis besteht aus internen Dokumenten: Verträgen, Handbüchern, Kundendaten, oft mit Personenbezug oder Geschäftsgeheimnissen. Bei jeder Anfrage wandern Ausschnitte davon durch die gesamte RAG-Pipeline, vom Embedding bis zum LLM-Aufruf. Wo diese Pipeline läuft und wer theoretisch Zugriff auf die Zwischenschritte hat, ist deshalb keine Nebensache, sondern Kern der Frage nach Datenhoheit. Über Managed Inference laufen sowohl das Embedding-Modell als auch das generierende LLM auf Infrastruktur, die du kontrollierst, ohne dass Dokumente zu einem US-Hyperscaler wandern, nur weil eine Bibliothek das per Default so vorsieht.

Miss zuerst das Retrieval, dann das Modell

RAG ist kein Feature, das man einmal einbaut und dann vergisst: Es ist eine Such-Pipeline, die kontinuierliche Pflege, Messung und Iteration braucht, genau wie jedes andere produktionsrelevante System. Die gute Nachricht: Die meisten Probleme sind lösbar, sobald man aufhört, sie am Modell zu suchen, und stattdessen Chunking, Embedding-Modell, Retrieval-Strategie und Datenqualität einzeln unter die Lupe nimmt. Der Versicherungskunde von oben hat sein System nicht mit einem grösseren Modell repariert, sondern mit Hybrid-Suche, sauberem Chunking entlang der Dokumentstruktur und einem Golden-Set, das seither jede Änderung vor dem Rollout absichert. Die Kündigungsfristen stimmen seither.

Wenn du ein RAG-System planst oder ein bestehendes reparieren musst, hilft selten die generische Anleitung: Meistens steckt der Fehler in einer sehr konkreten Kombination aus deinen Dokumenten, deiner Sprache und deiner Fragestellung. Wir bauen und betreiben souverän gehostete RAG-Pipelines und AI-Agents für Schweizer Unternehmen, inklusive der Diagnosearbeit, die die meisten Anbieter überspringen. Sprich mit uns, bevor du das nächste Modell-Upgrade bestellst: Oft ist es gar nicht das Modell.