Was ist RAG (Retrieval-Augmented Generation)?

RAG ist eine Technik, die Dokumente zur Abfragezeit abruft und dem Prompt hinzufügt, damit ein LLM aus Daten antwortet statt aus dem Gedächtnis. Eingeführt von Lewis et al. im Jahr 2020, ist es die Prüfung mit offenem Buch gegenüber der Prüfung mit geschlossenem Buch eines nackten Modells: Statt sich auf das Auswendiggelernte aus dem Training zu stützen, liest das Modell das Material, das Sie ihm vorlegen, und antwortet daraus – verankert, aktuell, im Umgang mit privaten Daten geübt und, weil die Quellen bekannt sind, belegbar. Für Backend-Entwickler lautet die beruhigende Wahrheit unter dem Hype: RAG ist kein Framework, das Sie übernehmen müssen, sondern eine for-Schleife, die Sie längst schreiben können.

Das Wichtigste in Kürze

Die zwei Phasen

INGESTION (offline, einmal pro Dokument)
  laden → zerlegen (Chunks von ~einigen hundert Tokens, mit Überlappung)
        → jeden Chunk als Vektor einbetten
        → Vektor + Text + ACL-Metadaten in einem Index speichern

ABFRAGE (online, pro Frage)
  Frage einbetten → Ähnlichkeitssuche nach den Top-k-Chunks (meist 5–10)
        → auf das filtern, was DIESER Benutzer lesen darf
        → den Prompt um die Chunks erweitern
        → LLM erzeugt eine darin verankerte Antwort (+ Quellenangaben)

Die gesamte Online-Phase, serverseitig, in einer einzigen Funktion:

// JavaScript — Cloud Code (cloud/main.js): RAG is a for-loop, not a framework
Parse.Cloud.define('askDocs', async (req) => {
  // 1 · embed the question (LLM API key stays server-side)
  const qVec = await embed(req.params.question);

  // 2 · retrieve — similarity search, ACL-FILTERED to this user's docs
  const chunks = await vectorSearch('DocChunk', qVec, {
    limit: 6,
    aclUser: req.user, // never retrieve what the asker can't read
  });

  // 3 · augment + generate
  const context = chunks.map((c) => c.get('text')).join('\n---\n');
  return await complete(`Answer using ONLY this context:\n${context}\n\nQ: ${req.params.question}`);
  // Answer cites the retrieved chunks — grounded, and permission-safe.
});

// Flutter / Dart — Back4app Flutter SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
final answer = await ParseCloudFunction('askDocs')
    .execute(parameters: {'question': 'What is our refund window?'});
print(answer.result); // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

// iOS / Swift — Back4app Swift SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
let answer: String = try await Cloud.run(
    name: "askDocs",
    parameters: ["question": "What is our refund window?"])
print(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

// Android / Kotlin — Back4app Android SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
val params = mapOf("question" to "What is our refund window?")
val answer = ParseCloud.callFunction<String>("askDocs", params)
println(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

Warum RAG: die drei Lücken

Ein nacktes LLM hat drei strukturelle Schwächen, und RAG behebt alle drei ohne Neutraining. Halluzination – Modelle antworten selbstbewusst, ob sie es wissen oder nicht; jede Aussage in abgerufenem Text zu verankern gibt dem Modell etwas Wahres zu sagen. Der Trainings-Stichtag – das Wissen eines Modells friert zum Trainingszeitpunkt ein; das Retrieval holt die Daten von heute. Private Daten – das Modell hat Ihre Dokumente nie gesehen; das Retrieval ist der Weg, auf dem es sie zur Abfragezeit liest. Die Zugabe, die Modelle mit geschlossenem Buch nicht bieten können: Weil die abgerufenen Chunks bekannt sind, kann die Antwort ihre Quellen angeben wie Fußnoten – der größte Vertrauensvorsprung, den RAG hat.

RAG vs. Fine-Tuning

Sie sind keine Rivalen: Fine-Tuning lehrt das Modell, wie es antwortet, RAG liefert, worüber es antwortet, und ein spezialisierter Fachassistent nutzt häufig beides – eine per Fine-Tuning geformte Stimme, die aus einer abgerufenen Wissensbasis antwortet.

Ist RAG tot? Die Frage nach dem langen Kontext, beantwortet

Die ehrliche Behandlung, die allgemeine Übersichtsseiten meiden. Context Windows reichen inzwischen in die Millionen Tokens, was dem wiederkehrenden Argument “packen Sie einfach alles in den Prompt” Auftrieb gibt. Drei Tatsachen halten das Retrieval am Leben. Kosten und Latenz: einen riesigen Kontext bei jeder Anfrage verarbeiten zu lassen ist drastisch teurer und langsamer, als die passende Scheibe zu holen – im großen Maßstab um Größenordnungen. Context Rot: Studien bis 2025 fanden eine Modellgenauigkeit, die lange vor dem Füllen des Fensters abfällt – relevante Fakten, die in einem riesigen Kontext vergraben liegen, werden übersehen, ein größeres Fenster ist also nicht verlässlich die bessere Antwort. Aktualität und Zugriffskontrolle: ein statischer Mega-Prompt ist in dem Moment veraltet, in dem sich die Daten ändern, und blind dafür, wer was lesen darf. Der Konsens 2026 lautet nicht “RAG oder langer Kontext”, sondern beides – eine großzügige, passende, berechtigungsgefilterte Teilmenge abrufen und dann mit einem Long-Context-Modell darüber schlussfolgern. Reiner langer Kontext taugt nur für kleine, stabile, nicht sensible Korpora.

Im Retrieval scheitert RAG

Die Sichtweise, die Ihr Vorgehen beim Debuggen eines RAG-Systems neu ordnet: Müll abgerufen heißt Müll selbstbewusst erzeugt. Die meisten Fehler, die dem Modell angelastet werden, sind Retrieval-Fehler im Generierungskostüm – es wurden die falschen Chunks geholt, also verankert sich eine vollkommen treue Antwort im falschen Material. Damit sind zwei Stellschrauben diejenigen, die die Qualität wirklich bewegen. Chunking: zu große Stücke verwässern die Relevanz und verbrennen Prompt-Budget; zu kleine verlieren den Kontext, der sie erst bedeutungsvoll machte – eine strukturbewusste Zerlegung (nach Überschrift, Absatz, Codeblock) schlägt feste Größen meist (die Strategien zählen). Hybrides Retrieval: kombinieren Sie Stichwortsuche (exakte Begriffe, Namen, IDs) mit Vektorsuche (Bedeutung) und lassen Sie die zusammengeführten Kandidaten dann von einem stärkeren Relevanzmodell neu ordnen, bevor der Prompt gebaut wird – Recall von beiden Seiten, Präzision vom Reranking. Und messen Sie die beiden Hälften getrennt, im Vokabular von RAGAS: Retrieval-Metriken (haben wir die richtigen Chunks geholt?) gegenüber Treue (ist jede Aussage durch das Geholte gedeckt?) – denn sie scheitern unabhängig voneinander und werden unterschiedlich behoben.

Die Sicherheitslücke, die niemand erwähnt

Vektorähnlichkeit ordnet nach Bedeutung und weiß nichts über Berechtigungen – was naives RAG zu einer Datenleck-Maschine macht. Betten Sie die Dokumente eines Unternehmens ohne Zugriffsmetadaten in einen einzigen Index ein, und die Frage jedes beliebigen Benutzers kann jedes beliebige Dokument abrufen, weil der Finanzbericht und die Frage des Praktikanten bloß benachbarte Punkte im Vektorraum sind. Nachgelagertes Filtern ist ebenfalls nicht die Lösung: Verbotene Chunks nach der Top-k-Auswahl zu verwerfen verrät ihre Existenz und bricht zugleich den Top-k-Vertrag (Sie haben sechs verlangt und zwei bekommen). Das richtige Muster: ACL-Metadaten bei jedem Chunk speichern und das Retrieval vor der Ähnlichkeitsbewertung auf die erlaubte Menge des fragenden Benutzers beschränken – berechtigungsgefiltertes Retrieval, nicht berechtigungsgefilterte Anzeige. Der Parameter aclUser in den Code-Tabs ist genau das, und er ist der Unterschied zwischen einer Demo und einem System, das Sie ausliefern können.

Typische Anwendungsfälle

• Support- und Wissens-Chat – aus der tatsächlichen Dokumentation eines Unternehmens antworten, mit Quellenangaben, aktuell bis zur letzten Ingestion.
• Suche über private Korpora – Recht, Medizin, interne Wikis: bedeutungsbasiertes Retrieval, das Ihnen das Stichwortfeld nie gegeben hat.
• Kundenspezifische Assistenten – die eigenen Daten jedes Benutzers, ACL-gefiltert, damit das Retrieval nie eine Tenant-Grenze überschreitet.
• Verankerte Auswertungen – Fragen, die aus lebenden Datensätzen beantwortet werden statt aus der veralteten Vermutung eines Modells.
• Dokumentation und Onboarding – ein Modell, das das Handbuch zitiert, statt es zu erfinden.

Brauchen Sie überhaupt RAG? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• RAG verringert Halluzination; es beseitigt sie nicht. Treue muss gemessen und darf nicht unterstellt werden – das Modell kann auch guten Kontext falsch lesen.
• Die Qualität lebt im Retrieval. Der Großteil der Ingenieurarbeit – Chunking, hybride Suche, Reranking – liegt vor dem Modell, dort wo die Gewinne sind.
• Embeddings haben eine Version. Wechseln Sie das Einbettungsmodell, muss jeder gespeicherte Vektor neu erzeugt werden; ein großes Korpus neu einzubetten ist eine echte Migration.
• Es kommen bewegliche Teile hinzu. Ingestion-Pipelines, ein zu pflegender Index, zusätzliche Tokens und Latenz pro Anfrage – reale Kosten, die ein kleines, stabiles Korpus womöglich nicht rechtfertigt.
• Berechtigungen gibt es nicht umsonst. ACL-gefiltertes Retrieval ist die tragende Sicherheitsarbeit, und es ist der Teil, den Demos überspringen und Vorfälle wiederentdecken.

RAG mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Behauptung “RAG ist eine for-Schleife” ist hier wörtlich zu nehmen: Dokumente sind gewöhnliche Objekte mit Dateispeicher für die Originale; die Chunk-Vektoren liegen als Array-Felder daneben, indiziert für die Ähnlichkeitssuche; die ACLs, die ohnehin jede Abfrage regeln, werden gratis zum Berechtigungsfilter des Retrievals – dieselbe Regel, die einen Benutzer daran hindert, die Datensätze eines anderen zu lesen, hindert den Retriever daran, sie zu holen; und die Orchestrierung – einbetten, abrufen, erweitern, erzeugen – ist eine Cloud-Code-Funktion, die die API des Modells mit serverseitig gehaltenem Schlüssel aufruft, genau wie die Code-Tabs es zeigen. Kein Framework, kein separater Vektordienst, der abgesichert werden müsste, kein LLM-Schlüssel auf dem Gerät – RAG hört auf, ein KI-Projekt zu sein, und wird zu Backend-Entwicklung, die Sie längst beherrschen.