• Golden Datasets: Kuratierte, stabile Testmengen mit erwarteten Vorhersagen. Vor jedem Release wird gegen die Golden Sets validiert, inklusive Nicht-Regression auf Randfällen.
  • Shadow Mode: Inferenz parallel zum operativen Pfad mitgeloggt, aber ohne Einfluss auf Entscheidungen. Erst wenn Stabilität und Nutzen belegt sind, Umschaltung auf „impacting“.
  • Canary und Rollback: Prozentuale Aktivierung, automatische Zurückschaltung bei SLO-Verletzung (z. B. zu viele Low-Confidence-Fälle).
  • Contract-Tests für die Inferenz-API: Forward-/Backward-Kompatibilität bei Schemaänderungen. Feste Error Codes, kein „Exception-Text-Parsing“.
  • Kalibrierung: Konfidenzen kalibrieren (z. B. Platt/Isotonic bei Klassifikation), dokumentierte Schwellenwerte je Use Case.
  • Erklärbarkeit passend zum Bediener: Feature-Contributions, Heatmaps, Regelverweise. Ziel: Vertrauen ohne „Pseudo-Magie“.
  • Sicherheits- und Policy-Tests: PII-Leakage-Checks, Prompt- und Output-Filter (LLM), Tool-Aufruf-Whitelists, Red-Team-Szenarien.

Für LLMs gilt zusätzlich:

  • Deterministische Moduswahl, wo möglich: Temperatur 0, Top-k/Top-p konservativ, strukturierte Ausgaben (JSON-Schema), Validierung vor Weiterverarbeitung.

  • Tool-/Function-Calling nur über geprüfte Schnittstellen mit strengen Contracts und Rate Limits. Kein Freitext-Aufruf von gefährlichen Aktionen.

  • Prompt-/Kontext-Versionierung als Artefakte. Änderungen laufen durch Review und Tests, nicht per Live-Edit.

7) Schrittweise Migration: Von Regeln zu ML ohne Big Bang

Eine praxistaugliche Migrationsleiter:

  • Stufe 0 — Telemetrie: Regeln bleiben führend. Wir instrumentieren, welche Daten/Entscheidungen anfallen, um eine Ground-Truth-Basis aufzubauen.

  • Stufe 1 — Vorschlagsmodus: ML schlägt Entscheidungen vor, Bediener bestätigt. Ziel: Nutzen und Fehlermuster verstehen, UI anpassen, Erklärungen verproben.

  • Stufe 2 — Hybrid: Regel- und ML-Entscheidung werden kombiniert. Konfliktauflösung folgt einer Policy (z. B. „ML nur bei High-Confidence überschreibt Regel“).

  • Stufe 3 — ML-führend mit Fallback: Regeln bleiben als Safety-Net. Kill-Switch erlaubt Sofortdeaktivierung.

  • Stufe 4 — Konsolidierung: Obsolete Regeln entfernen, Policies aktualisieren, Dokumentation und Schulungen nachziehen.

Wichtig: Jede Stufe hat explizite Exit-Kriterien (z. B. „ X“). So bleibt das Projekt steuerbar.

8) LLM-Integration unter Souveränitätsbedingungen

LLMs sind in der Industrie vor allem als Wissens- und Arbeitsfluss-Beschleuniger interessant: Dokumentationssuche (RAG), Störungsanalyse mit Tool-Aufrufen, Protokollzusammenfassungen, Assistenz für Instandhaltung. Unter On-Prem-Randbedingungen gelten besondere Regeln:

  • Retrieval on-prem: Dokumente werden lokal indiziert (Chunking, Embeddings), PII-Redaktion vor dem Index, Zugriff pro Tenant/Role. Kein Internetzugriff.
  • Agenten nur mit sicheren Tools: Whitelist von Funktionen (Ticket erstellen, Ersatzteil suchen), strenge Schemas, Quoten und Rate Limits. Aktionen mit Impact erfordern „two-man rule“ oder explizite Bestätigung.
  • Plan-Execute-Audit: Jeder Agentenlauf erzeugt ein Audit-Log mit Prompt, Kontext, Tools, Ergebnissen, Modell-/Prompt-Version. Reproduzierbarkeit ist Pflicht.
  • Ausgabekontrolle: JSON-Response nach Schema, Validierung, bei Fehlern definierte Recovery (Re-Prompt mit Korrektur, Fallback auf fixe Templates).
  • Prompt-Governance: Prompts als versionierte Artefakte im Repo, Code-Review, Tests (halluzinationsgefährdete Queries, Safety-Cases), Freigabeprozess.

Für LLM-bezogene Observability und Governance setzen wir auf eine dedizierte Ebene. Unser Ansatz ist Alpi-M: eine on-prem Plattform, die LLM-Aufrufe, Agentenschritte, Kontext und Tooling überwacht, versioniert und auditiert. Damit lassen sich:

  • Prompts/Policies versionieren und rückverfolgen

  • Drift und Anomalien in Antworten erkennen

  • Sessions reproduzieren und „what-if“-Replays fahren

  • Block-/Allow-Listen und Sensitivitätsregeln durchsetzen

  • Mandanten und Datenzugriffe trennen, DSGVO-konform protokollieren

Kurz: Ohne Observability ist ein LLM-Feature in der Produktion eine Blackbox. In regulierten Umgebungen ist das inakzeptabel.

9) Anti-Patterns aus der Praxis

  • Notebook-to-Prod: Ein Jupyter-Skript wird als Service „deployt“. Ergebnis: keine Reproduzierbarkeit, keine Resilienz, keine Security.
  • Direktzugriff auf US-Cloud-LLM vom HMI: Bequem, aber Compliance- und Verfügbarkeitsrisiko. Netztrennung und Datenschutz werden unterlaufen.
  • Kein Fallback: ML entscheidet, aber bei Ausfall oder Low-Confidence gibt es keinen definierten Pfad. In Safety-Umgebungen fatal.
  • Unversionierte Prompts: Irgendwer ändert „mal schnell“ die System-Prompt. Später sind Ergebnisse nicht mehr erklärbar.
  • Feature-Schema-Diskrepanz: Training nutzt andere Preprocessing-Pfade als Produktion. Die Online-Performance fällt ab, aber niemand merkt es wegen fehlender Telemetrie.
  • Ein riesiges „Generalmodell“ für alle Use Cases: Statt klarer, wartbarer Capabilities entsteht ein untestbares Monster.
  • Datenhaltung „irgendwo“: Vektorindizes mit PII ohne Verschlüsselung und Löschkonzepten. Spätestens beim Audit wird’s teuer.

10) Mini-Beispiele: Wie Integration konkret aussieht

  • Visuelle Qualitätsprüfung in der Fertigung:
  • Ausgangslage: Bestehendes Prüfmodul mit festen Bildregeln (Kanten, Schwellen).
  • Integration: Sidecar-Inference-Service mit standardisiertem Bild-Preprocessing, GPU-fähig. Die HMI ruft synchron „/inspect“ auf und erhält „OK/NOK + Heatmap + Confidence“.
  • Betrieb: Shadow-Phase über zwei Wochen, dann Hybrid mit Schwellen. Fallback: Regelset übernimmt, wenn Confidence < 0,7 oder Service down.
  • Nutzen: Geringere False-Negatives, Erklärbarkeit via Overlay. Keine Änderung am Kern der HMI-Applikation nötig.
  • Flottenintelligenz im Bahnsektor:
  • Ausgangslage: Telemetrie-Events, Batch-Reports nach 24 h.
  • Integration: Event-getriebene Pipeline (on-prem), Feature-Build in Near-Real-Time, asynchrone Inferenz für Anomalie-Scorings. Ergebnisse als Events zurück in das Instandhaltungs-System.
  • Betrieb: Canary auf definierten Fahrzeuggruppen, Kalibrierung je Fahrzeugtyp. SLA: p95 < 5 s reicht, Fokus auf Präzision und Alarmmüdigkeit.
  • Dokumentenassistent in sicherer Umgebung:
  • Ausgangslage: Air-gapped Doku-Bestand, strenge Audits.
  • Integration: On-prem LLM mit RAG. Embedding-Index pro Mandant, signierte Dokument-Pipelines. Agent hat nur lesende Tools und generiert strukturierte Antworten (z. B. JSON mit Zitaten).
  • Governance: Überwachung und Audit über eine LLM-Observability-Plattform, Versionierung von Prompts und Policies.
  • Vorhersage in der Textilproduktion:
  • Ausgangslage: Regelbasierte Alarme aus Sensorgrenzen.
  • Integration: ML sagt Ausfallwahrscheinlichkeiten voraus; Stufenmodell: Vorschlagsmodus → Hybrid → ML-führend. Regeln bleiben als Safety-Net.
  • Qualität: Kalibrierte Scores, Bedienerfeedback wird als Label genutzt, monatliche Re-Trainingsfenster.