Retrieval-Augmented Generation (RAG)
Retrieval-Augmented Generation ist ein Architekturmuster, bei dem ein LLM nicht auf seinem statischen Trainingswissen allein antwortet, sondern vor jeder Antwort relevante Informationen aus angebundenen Datenquellen abgerufen bekommt — und nur diese, nicht den kompletten Datenbestand. Das Ergebnis sind Antworten, die in nachvollziehbaren Unternehmensinhalten verankert sind, mit deutlich reduzierter Halluzinationsrate und kleinerem Datenschutzrisiko.
Im Wiki taucht der Begriff im Kontext der SAP GenAI Hub-Quelle erstmals eigenständig auf; bisher wurde er vor allem aus Produktsicht als Grounding behandelt.
So funktioniert RAG im Kern
Nutzerfrage
│
▼
[Retriever] ─→ fragt Datenquellen (Vektor-Index, Suchindex,
│ SAP-Systeme, Dokumentenablagen) ab und liefert
│ die relevantesten Ausschnitte zurück
▼
[Augmentation] ─→ hängt diese Ausschnitte an den Prompt
│
▼
[LLM] ─→ antwortet auf Basis von Frage + abgerufenen Ausschnitten
│
▼
Antwort mit Quellenbezug
Entscheidend: Nicht der ganze Datensatz wandert ins LLM, sondern nur ein zur konkreten Frage passender Ausschnitt. Das macht die Methode sowohl wirtschaftlich (weniger Tokens) als auch datenschutzfreundlich (weniger Exposure) nutzbar.
RAG im SAP-GenAI-Hub-Kontext
Die Hartig-Quelle beschreibt RAG als einen von drei Mechanismen, mit denen der GenAI Hub das Risiko einer Datenexposition minimiert:
„Anstatt ganze Dokumente an ein LLM zu senden, nutzt der GenAI Hub Techniken wie Retrieval-Augmented Generation (RAG). […] Lediglich dieser kleine, kontextbezogene Ausschnitt wird zusammen mit der Anfrage (dem Prompt) an das LLM gesendet.”
Kombiniert mit dem Orchestration Service (Anonymisierung personenbezogener Daten) und dem LLM-Routing bis in die Private Cloud ergibt das die SAP-Antwort auf die typische Unternehmensfrage: „Wie bekommen wir LLM-Antworten auf unseren echten Daten, ohne dass diese unkontrolliert nach außen gehen?”
RAG vs. Grounding — warum beide Seiten
Beide Begriffe werden in der SAP-Kommunikation fast synonym verwendet. Für dieses Wiki halten wir sie bewusst getrennt:
| Begriff | Blickwinkel | Beispiel |
|---|---|---|
| RAG | Technisches Architekturmuster, LLM-Welt allgemein | „Wir benutzen RAG, um aus dem Vertrags-Archiv relevante Klauseln in den Prompt zu holen.” |
| Grounding | SAP-Produktsicht; Joule an strukturierte Geschäftsobjekte binden | „Joule groundet die Antwort auf die konkrete Bestellung BS-12345 in S/4HANA.” |
Grounding nutzt RAG (neben direkten Zugriffen auf Geschäftsobjekte), ist aber breiter: es umfasst auch strukturierte API-Aufrufe, Berechtigungsprüfungen und die konkrete Verankerung in SAP-Datenmodellen.
Worauf wir bei Kunden achten
- Qualität des Retrievers schlägt Qualität des LLMs. Wenn der Retriever die falschen Ausschnitte liefert, bringt auch das beste Modell keine korrekten Antworten — und umgekehrt.
- Dokumente vs. Geschäftsobjekte: Klassische RAG-Architekturen (Vektor-Index über PDFs) sind das eine; Joule bringt zusätzlich den direkten Zugriff auf strukturierte SAP-Objekte mit. Beide Pfade muss eine Lösung bedienen.
- Berechtigungen im Retriever: Der Retriever muss die Leseberechtigungen des anfragenden Users bereits beim Suchen berücksichtigen — sonst landen gesperrte Inhalte im Prompt und damit im LLM-Kontext.
- Aktualität: Stand des Vektor-Index / der Retrieval-Quelle muss überwacht werden; veraltete Einbettungen sind eine typische Fehlerquelle.
Offene Fragen
- Technische Umsetzung im GenAI Hub: Nutzt SAP einen eigenen Vector-Store, integriert externe (Qdrant, pgvector, Pinecone)? Primärquelle fehlt.
- Integration mit SAP Datasphere: Wie spielt RAG mit Datasphere zusammen — ist Datasphere eine der kanonischen Retrieval-Quellen?
- Re-Ranking und Hybrid-Search: Liefert SAP vorgefertigte Re-Ranker und Hybrid-Suchmethoden (Dense + BM25) oder bleibt das kundenseitige Engineering-Aufgabe im Joule Studio?
- Evaluations-Pattern: Welche SAP-Vorlagen gibt es, um RAG-Qualität in Kundenprojekten messbar zu machen?