RAG ist nicht tot — du verwendest es nur für das falsche Problem_

In der KI-Tooling-Welt tobt gerade eine Debatte, die mehr Hitze als Licht erzeugt — vor allem, weil beide Seiten aneinander vorbeireden. Auf der einen Seite stehen Enterprise-Software-Anbieter, die dabei zusehen, wie RAG (Retrieval Augmented Generation) zu einem Milliardenmarkt heranwächst. Auf der anderen Seite stehen alle ernsthaften KI-Coding-Tools — Claude Code, Aider, Cline, OpenAIs Codex CLI — die RAG auffällig nicht einsetzen und stattdessen auf Tree-Sitter-Parsing, Repo-Maps und agentische Dateisuche setzen.

Was stimmt nun? Ist RAG das Rückgrat der KI-gestützten Zukunft — oder eine undichte Abstraktion, die wir endlich hinter uns lassen?

Beides, eigentlich. Das Lager „RAG ist tot" und das Lager „RAG floriert" beschreiben schlicht zwei völlig verschiedene Probleme. Die einen reden über die Navigation in Codebases. Die anderen über die Abfrage von Unternehmensdokumenten. Der Fehler liegt darin, beides als dasselbe Problem zu behandeln und dieselbe Lösung zu erwarten. Sobald man sie trennt, wird das Bild deutlich klarer — und deutlich interessanter.

Was RAG eigentlich macht (und warum es so nützlich war)

Die Grundidee hinter RAG ist elegant. Du hast ein großes Korpus an Dokumenten — zu groß, um in das Kontextfenster eines LLMs zu passen. Du zerlegst diese Dokumente in Chunks, lässt jeden Chunk durch ein Embedding-Modell laufen, das dabei einen dichten Vektor erzeugt, und speicherst diese Vektoren in einer Vektordatenbank. Wenn ein Nutzer eine Frage stellt, wird die Anfrage auf dieselbe Weise eingebettet, die semantisch ähnlichsten Chunks werden gefunden und als Kontext in den Prompt des LLMs eingefügt.

Eine Zeit lang war das wirklich transformativ. Plötzlich konnte man einen Chatbot bauen, der die HR-Richtlinien des Unternehmens „kannte", oder einen Support-Assistenten, der auf der eigenen Produktdokumentation trainiert war — ohne ein Modell feinzujustieren oder auf einen neuen Trainingslauf zu warten. Die Kombination aus vorberechneten Embeddings und approximativer Nearest-Neighbor-Suche machte das Retrieval schnell und günstig — grob geschätzt rund 100-mal billiger pro Anfrage als das Laden eines großen Kontexts von Grund auf.

Das Problem ist, dass „semantisch ähnlich" eine sehr spezifische Art von Relevanz ist. Es funktioniert hervorragend, wenn Nutzer unscharfe, natürlichsprachliche Fragen an ein Korpus natürlichsprachlicher Dokumente stellen. „Was ist unsere Regelung zum Elternurlaub?" lässt sich gut auf den Abschnitt eines Mitarbeiterhandbuchs abbilden, der die Antwort enthält. Das Embedding erfasst Bedeutung — und Bedeutung ist es, wonach gesucht wird.

Aber dann begannen Leute, dieselbe Technik auf Code anzuwenden. Und genau hier fing es an zu bröckeln.

Warum Code RAG zum Scheitern bringt

Code ist kein unscharfes Dokument. Es ist ein präzises, strukturiertes Artefakt mit einem expliziten Call-Graph, Import-Ketten, Typbeziehungen und Symboltabellen. Diese strukturellen Eigenschaften sind für ein Embedding-Modell nahezu vollständig unsichtbar.

Nehmen wir eine Funktion namens process_data. Ein Embedding-Modell sieht diese zwei Wörter und deren semantisches Umfeld. Es wird andere Funktionen mit ähnlichen Namen oder ähnlichen Docstrings abrufen. Was es nicht zuverlässig abrufen wird, ist die spezifische Funktion drei Dateien weiter, die process_data tatsächlich aufruft, das Interface, das sie implementiert, oder die Testdatei, die ihre Randfälle abdeckt. Diese Beziehungen sind nicht in Bedeutung kodiert — sie sind in Struktur kodiert.

Dazu kommt das Chunking-Problem. Klassisches RAG teilt Dokumente an festen Token-Grenzen auf — etwa alle 512 Tokens. Bei Fließtext ist das lästig, aber verkraftbar. Bei Code ist es oft fatal. Eine Funktion in der Mitte aufzuteilen bedeutet, die Signatur vom Body zu trennen. Eine Klassendefinition aufzuteilen lässt die Methoden ohne ihren Kontext zurück. Das Embedding-Modell arbeitet nun mit Fragmenten, die nie als eigenständige Einheiten gedacht waren.

Hinweis: Pash Pashkows vielgeteilter Praxisbeitrag brachte es auf den Punkt: Die strukturellen Eigenschaften von Code machen ihn zu einem schlechten Kandidaten für probabilistische semantische Suche. Die Bezeichner, die Code navigierbar machen — Funktionsnamen, Klassennamen, Dateipfade — sind genau die Art von Dingen, die Exact-Match-Suche perfekt beherrscht und die Embedding-Modelle nicht mit mehr Sicherheit behandeln als jedes andere Token.

Und hier ist die Sache: Du hast bereits ein perfektes Suchwerkzeug für Code. Es heißt grep. Oder ripgrep, wenn es schnell sein soll. Oder eine AST-basierte Suche, wenn Präzision gefragt ist. Alle Aufrufer von authenticate_user finden? Ein grep-Befehl. Alle Klassen, die ein bestimmtes Interface implementieren? Eine Tree-Sitter-Abfrage. Das ist deterministisch, vollständig und sofort. Kein semantisches Rauschen, kein Embedding-Drift, keine Artefakte durch Chunk-Grenzen.

Was Coding-Agents stattdessen verwenden

Die Tools, die in 2024–2025 wirklich geliefert und das Vertrauen von Entwicklern gewonnen haben, setzen auf eine völlig andere Architektur.

Aider, entwickelt von Paul Gauthier, ist wohl das klarste Beispiel. Statt einem Vektorspeicher baut Aider eine sogenannte Repo-Map — eine komprimierte, strukturierte Darstellung des gesamten Symbol-Graphen einer Codebase. Mit ctags und Tree-Sitter extrahiert es jede Funktions-, Klassen- und Variablendefinition aus jeder Datei, baut einen Graphen auf, welche Symbole auf welche anderen verweisen, und führt ein PageRank-ähnliches Ranking durch, um die relevantesten Symbole für eine gegebene Aufgabe herauszufiltern. Das Ganze passt in wenige tausend Tokens und gibt dem LLM eine echte Karte der Codebase — statt eines Haufens losgelöster Chunks.

Die agentischen Tools — Claude Code, Cline, Codex CLI — verfolgen einen komplementären Ansatz. Anstatt irgendetwas vorab zu indizieren, lassen sie den Agenten dynamisch navigieren. Der Agent gibt Tool-Calls aus, um spezifische Dateien zu lesen, Shell-Befehle auszuführen oder nach Bezeichnern zu greppen. Er baut den Kontext iterativ auf — genauso wie ein menschlicher Entwickler eine unbekannte Codebase erkunden würde. Kein Pre-Indexing erforderlich, keine veralteten Embeddings, keine Chunk-Grenz-Pannen.

Ein einfaches Beispiel dafür, wie das auf Tool-Call-Ebene aussieht:

1
> read_file("src/auth/middleware.py")
2
> run_command("grep -r 'verify_token' ./src --include='*.py' -l")
3
> read_file("src/auth/tokens.py")
4
> read_file("tests/test_auth.py")

Vier gezielte Lesezugriffe und ein grep — und der Agent hat nun echten, präzisen Kontext darüber, wie Authentifizierung durch die Codebase fließt. Keine Embeddings, keine Retrieval-Fehler, kein veralteter Vektorindex, der gepflegt werden müsste.

Tipp: Die hier gezeigte Präferenz ist es wert, ernst genommen zu werden. Jeder große Coding-Agent, der in 2024–2025 Verbreitung fand, traf dieselbe architektonische Entscheidung — strukturbewusste Navigation statt semantischer Suche. Das ist kein Zufall.

Wo RAG tatsächlich floriert

Auf der Enterprise-Seite sieht die Geschichte fast genau umgekehrt aus. RAG stirbt im Unternehmensbereich nicht — es beschleunigt sich. Unternehmen, die Wissensdatenbanken für die Suche in juristischen Dokumenten, HR-Richtlinien-Abfragen, Compliance-Monitoring und Kundensupport aufbauen, setzen RAG in großem Maßstab ein — und das aus gutem Grund.

Geschäftsdokumente haben schlicht nicht die strukturellen Eigenschaften, die Code so gut greppbar machen. Ein 200-seitiges Mitarbeiterhandbuch hat keinen Call-Graph. Ein PDF des letzten Quartals-Boardmeetings hat keine Import-Ketten. Wenn ein Mitarbeiter fragt „Kann ich einen Monitor für das Homeoffice abrechnen?", könnte die Antwort über drei Absätze in zwei verschiedenen Dokumenten verteilt sein, in jedem anders formuliert. Semantische Ähnlichkeitssuche ist hier keine Notlösung — sie ist das beste verfügbare Signal.

Auch das Skalenargument greift. Eine unternehmensweite Wissensdatenbank kann Millionen von Dokumenten enthalten. Kontextfenster, selbst in heutiger Größe, können bei weitem nicht alles laden:

Retrieval ist bei der Unternehmens-Dokumentensuche keine Optimierung — es ist eine harte Notwendigkeit.

Allerdings hat auch Enterprise-RAG seine echten Schwachstellen:

• Chunk-Grenzen können den Kontext zerstören, der einen Textabschnitt erst verständlich macht
• Embeddings veralten, wenn Dokumente aktualisiert werden, ohne dass eine Neu-Indizierung stattfindet
• Retrieval kann technisch relevante Chunks liefern, die das LLM in die Irre führen, weil der umgebende Kontext fehlt

Die ausgereifte Antwort auf diese Schwachstellen ist das, was das LlamaIndex-Team agentisches RAG nennt — nicht eine einzelne Nearest-Neighbor-Abfrage, sondern eine mehrstufige Retrieval-Pipeline, in der ein Agent entscheidet, ob er abruft, welche Anfragen er stellt und ob der abgerufene Kontext tatsächlich ausreicht. Router-Schichten, um Anfragen an die richtige Datenquelle zu leiten. Re-Ranking-Modelle, um abgerufene Chunks zu bewerten. Reflexionsschritte, bei denen der Agent prüft, ob er genug Kontext hat, bevor er generiert. Das ist komplexer zu bauen als naives RAG, adressiert aber die meisten Schwachstellen, die RAG einen schlechten Ruf eingebracht haben.

Die eigentliche Frage ist die Datentopologie

Tritt man von den einzelnen Tools zurück, stellt man sich eigentlich folgende Frage: Welches Retrieval-Primitive passt zur Struktur meiner Daten?

Code hat explizite, navigierbare Struktur — exakte Suche nutzt diese Struktur perfekt aus, während semantische Suche Rauschen hinzufügt, ohne Präzision zu gewinnen. Unstrukturierter Fließtext hat keine ausbeutbare Struktur — semantische Suche ist oft das Beste, was man tun kann, und wenn sie richtig kalibriert ist, ist sie wirklich nützlich.

Die interessanten Grenzfälle sind Dinge wie README-Dateien und Inline-Dokumentation innerhalb einer Codebase. Das ist natürlichsprachlicher Fließtext, eingebettet in eine strukturierte Umgebung. Ein hybrider Ansatz — AST-Navigation für Code, semantische Suche für Docs und Kommentare — könnte tatsächlich die ausgereifte, konvergente Antwort für Code-Agents sein. Es ist kein Zufall, dass Tools wie Cursor genau dieses Terrain erkunden.

Der „RAG ist tot"-Diskurs handelte nie wirklich vom Sterben von RAG. Es war eine Klärung des Anwendungsbereichs. Vektoreinbettungen und semantische Suche sind mächtige Werkzeuge für das richtige Problem. Sie als universelle Retrieval-Schicht zu behandeln — auf Codebases anzuwenden, auf strukturierte Datenbanken, auf alles, das ein KI-Interface braucht — war schon immer der Fehler. Die Tools, die Coding-Agents richtig gemacht haben, haben das früh erkannt. Der Enterprise-Software-Markt, der mit genuinen unstrukturierten Daten arbeitet, hatte nie einen Grund aufzuhören.

Die Frage, die man sich vor jeder Retrieval-Architektur-Entscheidung stellen sollte, lautet nicht „Soll ich RAG verwenden?" Sie lautet: Erfasst semantische Ähnlichkeit Relevanz in meiner Domäne tatsächlich? Für die Richtlinien-Dokumente deines Unternehmens lautet die Antwort meistens ja. Für dein Python-Monorepo lautet sie mit ziemlicher Sicherheit nein — und grep wusste das schon, bevor wir alle es getan haben.