SAP Datasphere als Grounding-Schicht für Joule
Stand 2026-09-25
Für Beraterinnen und Berater, die Datasphere bereits produktiv betreiben und es nun zur Grounding-Schicht von Joule oder eines eigenen Agenten machen müssen. Behandelt die von BDC beschriebene Knowledge-Core-Architektur, die zwei Wege, auf denen Daten in die gesteuerte Schicht gelangen (SAP-verwaltete Data Products vs. Datasphere-Replikationsflüsse, mit Ladetypen und Thread-Grenzen), den Datasphere Knowledge Graph (auto-generierte Ontologie, was ein Steward weiterhin kuratieren muss, die Verbindung zu Joule), Katalog-Hygiene als das, was ein LLM tatsächlich liest, den Anschluss von Datasphere-Inhalten an das Grounding-Modul des Generative AI Hub (verwaltete Pipelines vs. Vector API, die 8.000-Dokumente-Grenze), Data Access Controls als die vom Agenten geerbte Autorisierungsgrenze, sowie vier wiederkehrende Fehlerbilder. Schließt mit der Zertifizierungslandschaft (C_BW4H_2404, C_BCBDC_2505, C_BDCDA) und drei Übungen, die einen echten Grounding-Pfad vollständig nachverfolgen.
Was Sie lernen
- Die Rolle erklären, die Datasphere im KI-Grounding-Stack von SAP spielt, im Verhältnis zum Knowledge Core, zu HANA Cloud und zum Orchestrierungsdienst des Generative AI Hub
- SAP-verwaltete Data Products von Datasphere-Replikationsflüssen als Grounding-Quellen unterscheiden und Ladetyp sowie Überwachung eines Replikationsflusses für KI-Aktualität entwerfen
- Den Knowledge Graph von SAP Datasphere korrekt einsetzen: was er automatisch generiert, was ein Steward weiterhin kuratieren muss, und wie er offene Fragen in Joule speist
- Katalog-Hygiene-Lücken (Geschäftsbegriffe, Beschreibungen, Klassifizierungen) diagnostizieren, die die Fähigkeit eines LLM verschlechtern, aus Datasphere-gesteuerten Daten korrekt zu antworten
- Aus Datasphere stammenden Inhalt über das richtige Muster in das Grounding-Modul des Generative AI Hub einbinden — verwaltete Repository-Pipeline oder Vector API
- Data Access Controls als die vom Agenten geerbte Autorisierungsgrenze prüfen und die vier wiederkehrenden Fehlerbilder einer auf Datasphere geerdeten Einführung erkennen
Modulüberblick
Für wen dieses Modul gedacht ist. Sie haben M333 (LLM-Grundlagen) abgeschlossen und betreiben bereits Datasphere-Spaces produktiv. Die nächste Frage Ihres Kunden lautet nicht „was ist Grounding“ — sondern „wir bauen Joule-Agenten und eigene Agenten auf unseren Daten; ist unsere Datasphere-Landschaft bereit, deren Grounding-Schicht zu sein, und was müssen wir zuerst reparieren?“. Dieses Modul beantwortet das auf Architekturebene: was Datasphere tatsächlich zu einer geerdeten Antwort beiträgt, was nicht, und die konkreten Prüfungen, die eine Landschaft, der ein Agent vertrauen kann, von einer unterscheiden, die ihn still in die Irre führt.
Voraussetzungen
- M333 (KI- und LLM-Grundlagen für SAP-Berater) oder gleichwertiges praktisches Wissen zu Tokens, Embeddings, Kontext und RAG
- Produktionserfahrung im Aufbau und Betrieb von SAP-Datasphere-Spaces, -Modellen und -Replikationsflüssen
- Praktische Vertrautheit mit den Data-Product- und Katalog-Konzepten von SAP Business Data Cloud (C009, C011)
Lernergebnisse
- Beurteilen, ob die Datasphere-Landschaft eines Kunden geeignet ist, einen Joule- oder eigenen Agenten zu erden, und die konkreten zuerst zu schließenden Lücken benennen.
- Ladetyp, Delta-Zeitplan und Überwachung entwerfen, die eine Agent-Grounding-Quelle per Replikationsfluss benötigt.
- Einen Katalog-Sanierungsplan (Geschäftsbegriffe, Beschreibungen, Klassifizierungen) schreiben, der auf die Objekte zielt, die ein Agent tatsächlich abfragen wird.
- Das richtige Grounding-Modul-Anbindung (verwaltete Pipeline vs. Vector API) für einen gemischten Anwendungsfall aus Richtliniendokument und strukturierter Daten wählen und den DAC-Geltungsbereich vor Produktivstart bestätigen.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.