Fast jedes RAG-Projekt im Unternehmen erreicht in der Demo 80 % Genauigkeit – und weigert sich dann, weiter zu steigen. Die fehlenden 20 % liegen nicht im Modell, sondern im Retrieval, im Chunking und im Evaluation Harness, das niemand gebaut hat. Ein grösseres Modell wird Sie nicht retten.

Retrieval-Augmented Generation ist das am häufigsten eingesetzte und am wenigsten verstandene Muster in der Enterprise-KI. Die Demo ist trügerisch einfach: ein paar Dokumente embedden, die besten Treffer in einen Prompt packen, und die Antworten sehen grossartig aus. Dann kommt das System vor echte Nutzerinnen und Nutzer mit echten Fragen, die Genauigkeit stagniert bei rund 80 %, und der Reflex des Teams ist, zu einem leistungsfähigeren Modell zu greifen. Das funktioniert fast nie, denn die Fehler sind Retrieval-Fehler – und auch ein klügeres Modell kann nicht über Kontext schlussfolgern, den es nie bekommen hat.

Wir haben RAG-Systeme mehrfach vom «beeindruckenden Piloten» zum «vertrauenswürdigen Bestandteil eines regulierten Workflows» gebracht, und die Arbeit, die diese Lücke schliesst, ist bewusst unspektakulär.

Das eigentliche Problem: Müll abgerufen, selbstbewusster Unsinn geliefert

Zerlegen Sie eine falsche RAG-Antwort, und Sie finden eine von drei Ursachen, in dieser Reihenfolge der Häufigkeit:

1. Der richtige Chunk wurde nie abgerufen. Er existiert im Korpus, aber der Retriever hat ihn unterhalb des Cut-offs eingestuft. Das Modell antwortet dann aus irrelevantem Kontext – und zwar flüssig, was schlimmer ist als ein offensichtliches Scheitern.
2. Der richtige Chunk wurde abgerufen, aber verstümmelt. Ein naiver 512-Token-Split hat eine Tabelle halbiert, eine Klausel von ihrer Bedingung getrennt oder eine Überschrift von ihrem Inhalt abgeschnitten. Die Information ist technisch vorhanden und semantisch zerstört.
3. Das Modell hat guten Kontext ignoriert. Der seltenste Fall – und der einzige, den ein besseres Modell nennenswert behebt.

Teams geben ihr Budget für Fall drei aus, und ihre Fehler liegen in den Fällen eins und zwei. Wenn Sie sonst nichts messen, messen Sie den Retrieval Recall – den Anteil der Fragen, bei denen die nötige Information tatsächlich im Kontextfenster gelandet ist. Wir sehen regelmässig Piloten mit 70 % Recall, deren Teams sich fragen, warum die End-to-End-Genauigkeit feststeckt.

Die Architektur, die Sie über 80 % bringt

Produktives RAG ist eine Pipeline aus fünf Stufen, von denen jede für sich Ihre Obergrenze deckelt. Ein besseres Modell verbessert eine Stufe; die Gewinne liegen in den anderen vier.

1. Parsing und Chunking, das Struktur respektiert

Hören Sie auf, nach Token-Anzahl zu splitten. Splitten Sie entlang der Dokumentstruktur – Abschnitte, Klauseln, Tabellengrenzen –, sodass jeder Chunk ein in sich geschlossener Gedanke ist. Stellen Sie die Überschriftenhierarchie jedem Chunk als Präfix voran, damit «der Satz beträgt 1,5 %» auch «Abschnitt 4.2 – Verzugszinsen» mit sich trägt. Bei Dokumenten mit Tabellen extrahieren Sie die Tabellen separat und rendern sie als Markdown; ein Chunk, der eine Tabellenzeile von ihrem Kopf trennt, ist wertlos. Diese eine Änderung hat bei uns die End-to-End-Genauigkeit um 8–12 Punkte verbessert – mehr als jeder Modellwechsel.

2. Hybrid Retrieval statt reiner Vektoren

Dense Embeddings sind hervorragend bei Semantik und schwach bei exakten Treffern – Produktcodes, Kontonummern, definierte Rechtsbegriffe, alles, wo das wörtliche Token zählt. Reine Vektorsuche verfehlt «Klausel 7(b)», weil diese semantisch nichtssagend ist. Lassen Sie Keyword-Retrieval (BM25) und Vektor-Retrieval parallel laufen und fusionieren Sie die Ergebnisse. Für Unternehmenskorpora voller Identifikatoren ist Hybrid Retrieval nicht optional.

3. Reranking vor dem Kontextfenster

Rufen Sie breit ab – die Top 30 oder 50 Kandidaten –, und lassen Sie dann einen Cross-Encoder-Reranker jeden Kandidaten gegen die eigentliche Anfrage bewerten; behalten Sie die besten 5. Retrieval optimiert auf Recall, Reranking auf Precision; Sie brauchen beides. Ein Reranker ist im Vergleich zur Generierung günstig und die wirkungsvollste Komponente, die den meisten Piloten komplett fehlt.

4. Grounding-Disziplin im Prompt

Weisen Sie das Modell an, nur aus dem bereitgestellten Kontext zu antworten, den verwendeten Chunk zu zitieren und «in den bereitgestellten Dokumenten nicht gefunden» zu sagen, wenn das Retrieval leer zurückkommt. Ein RAG-System, das sich weigert zu raten, ist dasjenige, das ein Compliance-Team freigibt. Keine Quelle, keine Antwort.

5. Ein Evaluation Harness ab dem ersten Tag

Eine Pipeline, die Sie nicht messen können, können Sie nicht verbessern. Bauen Sie einen Satz von 100–300 echten Frage-Antwort-Paaren aus tatsächlichen Nutzeranfragen und bewerten Sie jede Änderung separat nach Retrieval Recall und Antwortkorrektheit, damit Sie wissen, welche Stufe sich bewegt hat. Ohne das tunen Sie nach Anekdoten, und das nächste Modell-Update wirft Sie unbemerkt zurück.

Durchgerechnetes Beispiel: Richtlinien-Assistent für ein Telekommunikationsunternehmen

Ein Telekommunikationsunternehmen wollte für seine Support-Mitarbeitenden einen internen Assistenten über rund 12’000 Seiten Produkt-, Preis- und Prozessdokumentation. Der Pilot, auf die übliche Weise gebaut (feste 512-Token-Chunks, reine Vektorsuche, ein Modell der GPT-Klasse), erreichte auf einem Set von 200 Fragen 79 % Antwortgenauigkeit. Der Plan des Teams: auf ein besseres Modell warten.

Stattdessen haben wir die unspektakulären Schichten neu gebaut und das Modell unverändert gelassen:

• Strukturbewusstes Chunking mit Überschriften-Präfixen und separater Tabellenextraktion: Recall 71 % → 86 %.
• Hybrid Retrieval aus BM25 und Vektoren (entscheidend für Tarifcodes): Recall 86 % → 92 %.
• Cross-Encoder-Reranking, 40 abrufen → 6 behalten: Antwortgenauigkeit 84 % → 91 %.
• Grounding-Prompt mit obligatorischen Quellenangaben und einem expliziten «nicht gefunden»-Pfad: halluzinierte Antworten auf Fragen ausserhalb des Scopes sanken von 18 % auf unter 3 %.

End-to-End-Antwortgenauigkeit: 79 % → 93 %, gleiches Modell, in rund fünf Wochen. Das spätere Modell-Upgrade brachte zwei weitere Punkte – nützlich, aber ein Rundungsfehler neben der Pipeline-Arbeit.

Die Vertrauensmetrik der Mitarbeitenden war wichtiger als die Genauigkeitszahl: Sobald das System verlässlich «nicht gefunden» sagte, statt einen Tarif zu erfinden, wurde die Nutzung von sporadisch zum Standard. Ein System, das in 7 % der Fälle falsch liegt, aber ehrlich mit seiner Unsicherheit umgeht, schlägt eines, das in 7 % der Fälle falsch liegt und dabei jedes Mal selbstsicher auftritt.

Die Metrik, die Vertrauen tatsächlich vorhersagt: ehrliche Verweigerung

Die Genauigkeit bekommt die Aufmerksamkeit, aber die Metrik, die darüber entscheidet, ob ein RAG-System genutzt wird, ist sein Verweigerungsverhalten – was es tut, wenn es etwas nicht weiss. Ein System, das jede Frage beantwortet, auch jene ausserhalb seines Korpus, erzieht seine Nutzer zum Misstrauen, weil sie eine fundierte Antwort nicht von einer selbstbewussten Vermutung unterscheiden können. Ein System, das bei Fragen ausserhalb des Scopes sagt «das ist in meinen Dokumenten nicht abgedeckt», verdient sich Vertrauen für die Antworten, die es gibt, weil die Nutzer lernen: Wenn es antwortet, meint es das auch. Wir messen die Halluzinationsrate auf einem bewusst ausserhalb des Scopes liegenden Fragenset als eigenständige Kennzahl, getrennt von der Genauigkeit bei Fragen innerhalb des Scopes – denn die beiden Fehlerarten haben völlig unterschiedliche Gegenmittel und völlig unterschiedliche Auswirkungen auf die Akzeptanz.

Die Verweigerung richtig hinzubekommen ist überwiegend eine Engineering-Entscheidung, keine Prompting-Frage. Der Retriever sollte Relevanzscores zurückgeben, und unterhalb einer kalibrierten Schwelle sollte das System ablehnen, statt schwachen Kontext an das Modell weiterzureichen und auf das Beste zu hoffen. Das ist dieselbe Konfidenzschwellen-Logik, die auch die Eskalation an Menschen steuert: Wenn die Retrieval-Konfidenz niedrig ist, besteht die sichere Aktion darin, die Lücke einzugestehen, statt zu generieren. Teams, die das überspringen, landen bei der schlechtesten Kombination – einem System, das gelegentlich und selbstbewusst genau bei den Fragen falsch liegt, die es hätte ablehnen sollen. Das ist der schnellste Weg, eine Nutzerbasis dauerhaft zu verlieren.

Eine Feinheit bei der Messung verdient es, benannt zu werden. Wenn Sie nur mit Fragen testen, die Ihr Korpus beantworten kann, werden Sie die Verweigerungs-Fehlerart nie sehen – und ein System ausliefern, das Antworten auf Fragen ausserhalb des Scopes erfindet, sobald echte Nutzer sie stellen. Und das werden sie ständig tun. Ein ernsthaftes RAG-Eval-Set enthält deshalb einen bewussten Anteil an unbeantwortbaren und adversarialen Fragen, bewertet danach, ob das System korrekt abgelehnt hat. Recall und Genauigkeit sagen Ihnen, wie gut die Antworten sind; die Verweigerungsrate bei Eingaben ausserhalb des Scopes sagt Ihnen, ob Sie dem System überhaupt vertrauen können. Beides gehört vom ersten Tag an ins Harness.

Fallstricke

• Zuerst dem Modell nachjagen. Liegt der Recall unter 90 %, ist ein besseres Modell die falsche Investition. Reparieren Sie das Retrieval.
• Keine Trennung von Retrieval- und Generierungsmetriken. Eine einzige End-to-End-Genauigkeitszahl verbirgt, wo der Fehler liegt, und macht jede Verbesserung zum Ratespiel.
• Das ganze Dokument embedden. Die Granularität zählt; ein einziger Vektor für ein 40-seitiges PDF findet alles und nichts.
• Zugriffsrechte im Retrieval ignorieren. Wenn der Index die Dokumentberechtigungen nicht respektiert, zeigt Ihr Assistent munter Inhalte an, die der Nutzer nie sehen dürfte. Retrieval muss berechtigungsbewusst sein.
• Von einem statischen Korpus ausgehen. Dokumente ändern sich. Ohne Reindexing-Pipeline zitiert Ihr Assistent innerhalb eines Quartals selbstbewusst die Preise vom letzten Jahr.

Entscheidungs-Checkliste, bevor Sie einen RAG-Piloten skalieren

1. Wie hoch ist unser Retrieval Recall auf einem echten Fragenset – getrennt von der Antwortgenauigkeit?
2. Erhält das Chunking Struktur, Tabellen und Überschriftenkontext?
3. Nutzen wir Hybrid Retrieval, oder scheitern exakte Identifikatoren unbemerkt?
4. Gibt es einen Reranker zwischen Retrieval und Kontextfenster?
5. Zitiert das System Quellen und verweigert es die Antwort, wenn das Retrieval leer ist?
6. Respektiert das Retrieval dieselben Berechtigungen wie die Quelldokumente?
7. Haben wir ein Evaluation Harness, das Regressionen beim nächsten Modell-Update abfängt?

Die gridz-Sicht

RAG ist zu 80 % Daten-Klempnerei und zu 20 % Modell – und die Branche verteilt ihre Aufmerksamkeit genau im falschen Verhältnis. Die Teams, deren Assistenten Vertrauen geniessen und genutzt werden, sind jene, die in Parsing, Hybrid Retrieval, Reranking und Evaluation investiert haben, bevor sie das Modell angefasst haben. Wenn Ihr RAG-Pilot in den hohen Siebzigern feststeckt, ist der Engpass mit ziemlicher Sicherheit der Retrieval Recall – und der lässt sich in Wochen beheben, nicht in Quartalen. Wir bauen solche Systeme für regulierte Umgebungen, in denen eine selbstbewusst falsche Antwort ein Haftungsrisiko ist: fundiert, mit Quellenangaben, berechtigungsbewusst und gemessen. Sprechen Sie uns an, wenn Ihr Pilot den Sprung in die Produktion schaffen soll.