Observability und Governance sind hier kein Zusatz, sondern Pflicht. In ML haben Sie Metriken wie AUC und Latenz. Bei LLMs brauchen Sie zusätzlich:

  • Prompt-/Kontext-Versionierung mit Hashes.

  • Tool-Call-Tracing: Welche Funktionen wurden wann mit welchen Parametern gerufen? Welche Rückgaben flossen in die nächste Entscheidung?

  • Policy-Checks: Darf diese Anfrage überhaupt verarbeitet werden? Sind Datenklassen erlaubt? Wurde eine Content-Policy verletzt?

  • Halluzinationsindikatoren: Abdeckungsgrad der Quellen, Zitationsrate, Antwortkonsistenz über Re-Runs (bei T=0), Out-of-Policy-Token.

  • Human-in-the-Loop-Prozesse: Freigaben, Eskalationspfade, Feedbackschleifen.

Genau an dieser Stelle setzen wir mit Alpi-M an: Eine on-premise Observability- und Governance-Schicht für LLM-Features und -Agenten. Technisch wird der LLM-Pfad instrumentiert (z. B. über OpenTelemetry-kompatible Spans für Prompt, Retrieval, Tool-Calls). Policies werden vor der Ausführung geprüft, PII wird vor Persistenz maskiert, und jede Entscheidung ist auditierbar. Wichtig: Alpi-M ist kein “netter Graph”. Es erzwingt Richtlinien, schlägt Rollbacks vor, ermöglicht A/B-Tests in abgeschlossenen Umgebungen und liefert reproduzierbare Traces – DSGVO-konform, ohne US-Cloud.

Testing und QA für KI-erweiterte Software
“Wie teste ich etwas, das nicht deterministisch ist?” Die Antwort: Sie kapseln, frieren, simulieren und testen Verträge.

Techniken, die sich bewähren:

  • Contract-Tests an den Integrationsgrenzen: gRPC-Schemas, Feature-Schemata, Tool-Signaturen. Versioniert, rückwärtskompatibel, mit Migrationspfaden.

  • Golden-Datasets: Festgeschriebene Eingabemengen mit erwarteten Ausgabeklassen/-bereichen. Für LLMs zusätzlich Golden-Dialoge mit zulässigen Varianzen.

  • Metamorphes Testen: Wenn Eingabe X zu Y führt, muss eine semantisch äquivalente Eingabe X’ zu Y’ führen, das bestimmte Invarianten erfüllt (z. B. gleiche Entscheidungsklasse).

  • Property-based- und Fuzz-Tests: Systematisch Eingaben variieren (z. B. OCR-Rauschen, Encoding, Prompt-Noise), um Robustheitsgrenzen zu entdecken.

  • Shadow Mode: ML/LLM läuft mit, trifft aber keine Produktentscheidung. Logging und Telemetrie zeigen Lücken, bevor irgendwas “scharf” geht.

  • Canary Releases: Aktivierung für 1–5 % der Fälle/Standorte, Metriken und Alarme klar definiert, Rollback in Sekunden.

  • Budget-Wächter: Laufzeit, Speicher, File-Deskriptoren, Thread-Anzahl. “Nicht über 40 ms, nicht mehr als 500 MB” sind testbare Anforderungen.

  • Modellfreigaben wie Firmware: Semver, Artefakt-Hashes, SBOM, Change-Logs, reproduzierbare Builds.

Für Vision-Modelle: Testsets mit Beleuchtungsvarianten, Kompressionsartefakten, Perspektivwechseln. Für LLMs: Prompt-Templates einfrieren, Tool-Risiken isolieren (Dry-Run-Tools im Test), Regelsätze (z. B. keine externen URLs) erzwingen und mit Negativtests belegen.

Schrittweise Migration: Von Regeln zu Hybrid-Architekturen
Regelsysteme sind nicht “falsch”. In regulierten Umgebungen sind sie oft unverzichtbar. Der pragmatische Weg:
1) Beobachten: Alle Entscheidungen und ihre Eingangsfaktoren loggen. Damit entsteht die Trainings- und Evaluationsbasis – ohne Produktionsänderung.
2) Schattenvorhersagen: ML rechnet mit, aber entscheidet nicht. Abweichungen werden aggregiert, Ursachen analysiert.
3) Hybridbetrieb: Regeln bleiben Gatekeeper. ML schlägt Entscheidungen vor, die bei hoher Konfidenz automatisch akzeptiert werden; bei Unsicherheit bleibt die Regel dominant.
4) Selektive Aktivierung: Stück für Stück nach Linie/Anlage/Standort aktivieren. Jedes Segment bekommt eigenes Monitoring.
5) Human-in-the-Loop: Grenzfälle werden an Menschen geroutet; deren Entscheidungen fließen als etiket­tierte Daten zurück.
6) Drift-Überwachung: Eingabe- und Label-Verteilungen verfolgen. Automatisierte Alarme und (halb-)automatisches Retraining in definierten Fenstern.
7) Hardening: Wenn ML stabil ist, werden einzelne Regelblöcke außer Kraft gesetzt – mit dokumentierten Begründungen, Messwerten und Rückfallebene.

MLOps on-prem bedeutet: GitLab/Argo für Pipelines, selbstgehostetes MLflow oder klare Artefakt-Registries, Modelle als OCI-Images. Keine “pip install auf der Produktionsbox”. Reproduzierbare Umgebungen, signierte Releases, Rollback-Strategien.

Sicherheit und Souveränität als Architekturprinzip

  • Datenklassifizierung: PII, Betriebsgeheimnisse, Sensordaten – jede Klasse mit klarer Policy (Speicherung, Transport, Berechtigungen).

  • Minimierung: Nur sammeln, was nötig ist. Pseudonymisierung an den Rändern, Entschlüsselung erst im Trust-Bereich.

  • Schlüsselverwaltung: On-prem KMS, getrennte Rollen für Verwahrung/Verwendung, Auditpflichten.

  • Netzwerksegmentierung: LLM/ML-Dienste in eigenem Segment, nur notwendige Ports, ausgehende Verbindungen standardmäßig blockiert.

  • Lieferkette: Signierte Container, SBOM-Prüfung, reproduzierbare Builds, keine Blackbox-Binaries ohne Herkunft.

  • Policy-as-Code: Zugriffs- und Ausführungspolitiken als Code (z. B. OPA-Patterns), CI-validiert, versioniert.

  • Modelllizenzierung: Klarheit über kommerzielle Nutzung, Redistribution, Fine-Tuning-Rechte, Exportkontrollen.

Fallnahe Muster aus Projekten

  • Visuelle Fehlererkennung in C++/Qt-Anwendungen: Sidecar-Inferenz via gRPC, Shared-Memory-Beschleunigung für Bildpuffer, harte 30-ms-Targets. Modelle als ONNX mit INT8-Quantisierung, Warmup auf Linienstart, Fallback auf Regeln bei Timeout.

  • Flottenintelligenz im Bahnumfeld: Asynchrones Event-Scoring, Feature-Materialisierung in TimescaleDB, Retraining im Nightly-Fenster. Canary-Prozesse pro Depot, Rollbacks in <1 Minute.

  • Air-gapped Defense-Systeme: In-Process-Inferenz mit C++-Bindings, deterministische Allocator-Strategien, Offline-Updates via signierte Artefakte.

  • LLM-gestützte Wissenssuche in der Luftfahrt-Ausbildung: On-prem RAG, Tool-Whitelist (nur Dokumentensuche, Zitatabruf), Alpi-M-gestütztes Prompt- und Tool-Tracing, PII-Maskierung, Freigabe-Workflow für neue Dokumentensätze.

Referenz-Blueprints (minimal, aber praxistauglich)
Blueprint A: Realtime-Vision am Edge (30 ms Budget)

  • Host-App (C++/Qt) ruft In-Process-ONNX-Runtime mit vorallokierten Tensoren.

  • Bildpuffer in Shared Memory, Zero-Copy Preprocessing.

  • Watchdog-Thread, Hard-Timeout 20 ms, Fallback auf Regelprüfung.

  • Telemetrie: Latenz, Konfidenz, Dropped Frames; Log-Persistenz lokal, Batch-Upload in Wartungsfenstern.

  • Deployment: Signiertes OCI-Bundle, Testsuite mit synthetischem Rauschen.

Blueprint B: Fleet-Scoring asynchron

  • Sensor-Events -> Kafka; Feature-Build-Jobs -> TimescaleDB; Inferenz-Consumer -> Ergebnis-Topic.

  • Modellartefakte über Registry; Canary-Flag pro Topic-Partition.

  • Drift-Detektion über Feature-Statistiken; automatisches Zurückfallen auf Vorversion.

  • Auditing: Event- und Score-IDs querverlinkt; Reprocessing-Pipeline reproduzierbar.