Wer mit lokalen oder kleinen Sprachmodellen arbeitet, landet fast zwangsläufig früher oder später bei demselben Begriff: RAG, also Retrieval-Augmented Generation. Die Verheißung klingt vernünftig. Statt nur auf das Wissen in den Modellgewichten zu vertrauen, holt man zusätzliche Dokumente, Chunks oder Datenbankeinträge aus einer externen Wissensquelle und gibt sie dem Modell als Kontext mit. So soll das System aktueller, belastbarer und nützlicher werden.

Genau deshalb ist RAG so populär. Und genau deshalb wird es in vielen Projekten fast reflexartig zum Standardmuster. Trotzdem sollte man zwei Dinge sauber auseinanderhalten: RAG ist oft sehr sinnvoll. Aber RAG ist nicht automatisch zuverlässig und nicht die einzige gute Lösung.

Was RAG tatsächlich leistet

Das grundlegende Paper ist Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks von Lewis et al. Dort wird RAG als Verbindung von parametrischem Wissen im Modell und nicht-parametrischem Wissen in einem externen Index beschrieben. Das Prinzip ist bis heute aktuell. Wissen lässt sich aktualisieren, ohne das Modell komplett neu zu trainieren. Antworten können stärker an Evidenz gebunden werden. Und gerade kleine Modelle werden dadurch in vielen praktischen Szenarien deutlich nützlicher.

Für kleine und schnelle Systeme ist das natürlich attraktiv. Ein kleines Modell mit gutem Zugriff auf die richtigen Dokumente ist in vielen Fällen wertvoller als ein größeres Modell ohne saubere Wissensanbindung. Nur folgt daraus eben noch nicht, dass jede Form von RAG schon ein gutes System ergibt.

Wo RAG in der Praxis schiefgeht

In vielen Projekten wird RAG fast wie eine Universalantwort behandelt: Vektorindex bauen, Top-k Chunks holen, in den Prompt legen, fertig. Genau dort beginnen die Probleme.

Ein RAG-System kann halluzinieren, obwohl es Dokumente hat. Es kann die falschen Dokumente ziehen, die richtigen schlecht gewichten, unglückliche Chunks erzeugen, Evidenz mit Vorwissen vermischen oder auf freie Textgenerierung setzen, obwohl die Aufgabe eigentlich ein Tool oder eine Datenbankabfrage verlangt. Vor allem aber kann es elegant weiterreden, obwohl die Evidenz schwach ist.

RAG verschiebt Halluzinationen deshalb oft nur. Aus frei erfunden wird falsch begründet. Das klingt nach Fortschritt, ist im Betrieb aber nicht zwingend harmloser.

RAG ist ein Muster, aber nicht das einzige

Gerade wenn man kleine Modelle ernst nimmt, lohnt sich ein nüchternerer Blick. Nicht jede Wissensaufgabe ist automatisch eine Retrieval-Aufgabe. Manchmal ist langer Kontext ausreichend, wenn die Dokumentmenge klein und stabil ist, auch wenn Lost in the Middle deutlich zeigt, dass mehr Kontext allein keine Zuverlässigkeit garantiert. Manchmal ist Fine-Tuning oder Continued Pretraining sinnvoller, wenn Terminologie, Stil und Aufgaben stark wiederkehren und Aktualisierung nicht täglich nötig ist.

Oft ist die Frage aber noch grundsätzlicher. Viele Probleme sind gar keine Text-Retrieval-Probleme, sondern Tool-Probleme. Preise, Bestände, Kalenderdaten, API-Status oder SQL-Abfragen sollten nicht aus Dokument-Chunks rekonstruiert werden, wenn eine exakte Quelle existiert. Genau hier wird Toolformer wichtig. Die Arbeit zeigt die Richtung: Modelle können Werkzeuge verwenden, statt alles in freier Prosa zu erraten.

Daneben gibt es eine tiefere Alternative zu klassischem Prompt-RAG: Retrieval direkt in der Modellarchitektur. RETRO ist dafür ein zentrales Beispiel. Solche retrieval-nativen Modelle deuten an, dass kleine Systeme nicht nur aus einem Modell plus Vektorindex bestehen müssen, sondern von Anfang an mit externer Erinnerung arbeiten könnten.

Schließlich ist nicht jedes Wissen in freien Chunks am besten aufgehoben. Relationale Datenbanken, Wissensgraphen, Tabellen, Event-Stores oder domänenspezifische Indizes sind oft verlässlicher als ein großer Sammelbehälter aus PDFs und Markdown. Gerade kleine Modelle profitieren davon, wenn das System die Welt für sie bereits in eine präzisere Form gebracht hat.

Wie Halluzinationen wirklich sinken

Die zentrale Frage lautet für kleine, schnelle Modelle nicht: Haben wir RAG? Die wichtigere Frage lautet: Wie zwingen wir das System dazu, nur dann zu antworten, wenn es gute Evidenz hat?

Der erste Hebel ist fast immer das Retrieval selbst. Ein schwaches Modell profitiert nur dann von RAG, wenn das Retrieval präzise ist. Gute Chunking-Strategien, Hybrid Retrieval aus Lexikon- und Embedding-Suche, Reranking und domänenspezifische Metadaten sind oft wichtiger als noch ein wenig mehr Modellgröße. Kleine Modelle leiden besonders, wenn man sie mit 20 halbrelevanten Chunks alleinlässt und hofft, sie würden daraus schon das Richtige rekonstruieren.

Ebenso wichtig ist Kontextdisziplin. Viele Systeme schieben zu viele Chunks in den Prompt. Für kleine Modelle ist das fast immer schädlich: mehr Tokens, höhere Latenz, mehr Ablenkung, mehr Vermischung irrelevanter Informationen. Ein enger, präziser, hochrelevanter Kontext ist für sie oft besser als ein großer.

Dann kommt die eigentliche Verhaltensfrage. Ein gutes System arbeitet nicht nur mit Evidenz, es ist an Evidenz gebunden. Es darf unbekannt sagen. Es darf abbrechen. Es darf widersprüchliche Quellen benennen, statt sie in glatter Prosa zu überdecken. Gerade das ist eine der wirksamsten Halluzinationsbremsen überhaupt. In vielen realen Systemen entsteht der Schaden nicht, weil ein Modell wenig weiß, sondern weil es trotz schwacher Evidenz elegant weiterredet.

Wenn die Aufgabe numerisch, tabellarisch oder transaktional ist, sollte das System möglichst nicht frei formulieren, sondern an ein Tool routen. Preise per SQL, Verfügbarkeiten per API, Rechnungen per Rechenfunktion: Solche Entscheidungen entlasten kleine Modelle von genau jenen Aufgaben, in denen freie Generation notorisch unzuverlässig ist.

Schließlich wird Verifikation immer wichtiger. Self-RAG und CRAG zeigen beide in unterschiedlicher Form dieselbe Richtung: Nicht nur abrufen, sondern Retrieval-Qualität und Antwortqualität laufend prüfen. Das System soll nicht bloß generieren, sondern sein eigenes Material misstrauisch ansehen.

Was kleine Modelle besonders gut können

Gerade kleine Modelle werden stark, wenn ihr Aufgabenraum klein und klar ist. Sie brauchen enge Domänen, gute Evidenz, wenig irrelevanten Kontext, strukturierte Ausgabeformen und im Zweifel einen Verifier-Schritt. In so einem Stack ist das Modell nicht mehr der alleinige Wissensspeicher. Es wird eher zum Koordinator zwischen Evidenz, Tools und Ausgabeformat.

Das ist keine Schwäche. Es ist vielleicht sogar die produktivere Rolle.

Ein schönes Beispiel für diese Richtung ist README. Die Arbeit zeigt in einer klar definierten medizinischen Aufgabe, dass mobile-freundliche Open-Source-Modelle mit hochwertigem Fine-Tuning und Retrieval mit sehr starken geschlossenen Modellen konkurrieren können. Die wichtige Lehre daraus ist nicht, dass jedes kleine Modell plötzlich brillant wäre. Die wichtigere Lehre lautet: Nicht immer muss das Modell größer werden. Häufig muss der Daten- und Systementwurf besser werden.

Wohin sich das wahrscheinlich entwickelt

Ich glaube nicht, dass die Zukunft einfach nur mehr RAG heißt. Wahrscheinlicher ist eine hybride Architekturwelt. Das naive Standardmuster “Embedding Search, Top 5 rein, Antwort raus” wird bleiben, aber eher als Baseline. Bessere Systeme werden Retrieval adaptiv auslösen, Retrieval-Qualität bewerten, mehrere Retrieval-Modi kombinieren, Evidenz komprimieren und viel klarer zwischen Wissensabruf und exakter Operation unterscheiden.

Ebenso wahrscheinlich ist mehr Spezialisierung. Statt eines riesigen Allzwecksystems werden wir mehr Stacks sehen, die für Support, interne Wissenssuche, regulatorische Dokumente, technische Handbücher, Medizin oder industrielle Prozessdaten gebaut sind. In solchen Domänen gewinnen kleine, schnelle Modelle nicht durch Größe, sondern durch Systemdesign.

Die Richtung ist insgesamt ziemlich klar. Weniger blindes Generieren, mehr Evidenz. Weniger Zauberglaube an den Vektorindex, mehr Architekturarbeit. Weniger “Das Modell weiß schon”, mehr “Das System muss möglichst wenig raten”.

Was zu geisten passt

Für geisten passt deshalb kein blindes “RAG überall”, sondern ein strenger, lokaler und effizienter Hybridansatz: kleine oder mittlere Modelle, enge Domänen, präzises Retrieval, Tool Use dort, wo Exaktheit zählt, klare Abbruchlogik, strukturierte Ausgaben und bei Bedarf Verifikation. Das passt besser zu CPU-effizienter Inference und kontrollierbaren Systemen als ein großes Modell, das alles in einem Schritt irgendwie schon wissen wird.

Anders gesagt: Nicht das größte Modell gewinnt, sondern das System, das am wenigsten raten muss.

Fazit

RAG ist ein wichtiges Werkzeug. Aber es ist kein Zauberwort. Wer Halluzinationen wirklich minimieren will, muss über mehr nachdenken als über einen Vektorindex: über Retrieval-Qualität, Chunking, Tool-Routing, Abbruchlogik, Verifikation und Domänengrenzen.

Gerade kleine, schnelle Modelle können hier erstaunlich stark sein, wenn man sie nicht als allwissende Antwortmaschine behandelt, sondern als Teil eines präzise gebauten Systems. Die Zukunft gehört deshalb wahrscheinlich nicht dem einen RAG-Pattern, sondern hybriden, evidenzgebundenen Architekturen, in denen kleine Modelle, Retrieval, Tools und Verifikation sauber zusammenspielen.

Weiterführende Quellen

Wenn Sie RAG, Tool Use oder retrieval-native Architekturen für lokale KI und kleine Modelle evaluieren, sprechen Sie uns gerne an: info@geisten.com