LLMOps auf SAP BTP — Monitoring, Logging und Drift für produktive AI-Core-Workloads
Stand 2026-09-25
LLMOps-Modul auf Expertenniveau, das produktives Monitoring, Logging und Drift-Erkennung für generative KI-Workloads auf SAP AI Core aus dokumentierten Bausteinen statt aus einem einzigen Produkt aufbaut: Resource Groups (Isolation, das Tenant-Quota von 50 Gruppen und die feinste native Kostenebene), Inference Observability (genaue Header, die Grenzen von 16 Labels/64 Zeichen, die Anforderungen des erweiterten Plans und nur-S3, sowie die dokumentierte Warnung, dass Payloads unmaskiert gespeichert werden), die Weiterleitung von Applikationslogs an SAP Cloud Logging, den Auditing-und-Logging-Feed von Plattform-Sicherheitsereignissen (einschließlich der vier grep-fähigen Authentifizierungsfehler-Zeichenketten), die Metrics-Erweiterung, sowie ein Drift-Erkennungsmuster, gebaut aus periodischen M366-Evaluations-Neuausführungen plus SHA256-Prompt-Hash-Versionsverfolgung. Schließt mit einem feldbewährten Drei-Schichten-Observability-Muster für produktive Agenten und Kosten als Betriebssignal, entnommen aus der SAP-AI-Core-Dokumentation und veröffentlichten Feldleitfäden namentlich genannter SAP-Praktiker.
Was Sie lernen
- Erklären, warum die Observability von SAP AI Core aus dokumentierten Bausteinen (Resource Groups, Inference Observability, Applikationslogging, Audit-Logs, Metrics, Evaluations) zusammengesetzt ist statt aus einem Produkt
- Eine Resource-Group-Landschaft für Isolation, Kostenverfolgung und Sicherheit entwerfen und das Tenant-Quota von 50 Resource Groups benennen
- Inference Observability korrekt konfigurieren (Persistenzmodus, Labels, Object-Store-Secret) und erklären, warum es mit Datenmaskierung gepaart werden muss
- AI-Core-Applikationslogs an SAP Cloud Logging weiterleiten und den Auditing-und-Logging-Feed für Plattform- und Sicherheitsereignisse lesen
- Ein Drift-Erkennungsmuster aus periodischen Evaluations-Neuausführungen, Prompt-Hash-Versionsverfolgung und nachverfolgten Metriken bauen, in Ermangelung eines nativen Drift-Alarms
- Einen dreischichtigen Observability-Stack (Schritt-Trace, Audit-Tabelle für Geschäftsentscheidungen, Infrastruktur-Logging) für einen produktiven Agenten entwerfen, Kosten als Betriebssignal eingeschlossen
Modulüberblick
Für wen dieses Modul gedacht ist. Sie haben einen generativen KI-Anwendungsfall auf SAP AI Core produktiv gesetzt — ein Orchestrierungs-Deployment, vielleicht einen Agenten — und die Frage hat sich gerade geändert: von „funktioniert es“ zu „woher wissen wir, ob es aufhört zu funktionieren, still, um 3 Uhr morgens“. Dieses Modul baut die Antwort aus dem, was SAP AI Core tatsächlich dokumentiert (Resource Groups, Inference Observability, Applikationslogging, Audit-Logs, die Metrics-Erweiterung) sowie aus feldbewährten Mustern von SAP-Praktikern für die Teile, die SAP nicht als ein einziges Produkt liefert: Drift-Erkennung und schichtübergreifende Observability. Es setzt M325, M333 und idealerweise M366 (den Evaluationsharnisch, den dieses Modul für Drift wiederverwendet) voraus.
Voraussetzungen
- M333 (KI- und LLM-Grundlagen für SAP-Berater) und M325 (SAP Generative AI Hub in der Praxis)
- M366 (Generative KI auf SAP-Daten evaluieren) dringend empfohlen — dieses Modul nutzt dessen Evaluationsharnisch für die Drift-Erkennung weiter
- Sicherheit mit dem Resource-Group- und Multitenancy-Modell von SAP AI Core, REST-APIs und dem Lesen von JSON-Logs
- Grundlegende Vertrautheit mit einem Log-Analyse-Tool (OpenSearch, Kibana oder gleichwertig) ist hilfreich, aber nicht erforderlich
Lernergebnisse
- Eine Resource-Group-Landschaft aufbauen, die Dev/QA/Produktion trennt, und ihre doppelte Rolle als Kosten- und Sicherheitsgrenze erklären.
- Inference Observability auf einem produktiven Endpunkt korrekt konfigurieren, mit auf den tatsächlichen Bedarf abgestimmten Labels und Persistenzmodus.
- Ein Drift-Erkennungs-Runbook erstellen, das ein Produktions-Support-Team ohne den ursprünglichen Berater ausführen kann.
- Gegenüber einem Operations-Stakeholder begründen, warum kein einziges SAP-Produkt LLM-Monitoring durchgängig abdeckt, und was das ausgleicht.
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.