Tool-Schnittstelle (vereinfachtes JSON-Schema):
{
“tool”: “create_work_order”,
“schema”: {
“type”: “object”,
“properties”: {
“asset_id”: { “type”: “string”, “pattern”: “ASSET-[0-9]{6}” },
“priority”: { “type”: “string”, “enum”: [“low”,”medium”,”high”] },
“description”: { “type”: “string”, “maxLength”: 500 }
},
“required”: [“asset_id”,”description”]
}
}

Validierung geschieht strikt gegen das Schema. Bei Verstoß: Abbruch, keine “kreative” Reparatur durch das Modell. So behalten wir Kontrolle.

Observability und Governance mit Alpi-M
In LLM-Szenarien ist Beobachtbarkeit keine Kür, sondern der Sicherheitsgurt:

  • Tracebarkeit: Vollständige Kette aus Prompt-Template, Füllparametern, Kontext-Dokument-IDs/Offsets, Tool-Calls (Input/Output), Finalantwort.

  • Versionierung: Prompts-as-Code, Testfälle im Repository, reproduzierbare Ausführungen mit fixiertem Modell-Build.

  • Policy Enforcement: Regeln wie “niemals PII in Ausgaben”, “kein Ticket ohne Asset-ID”, “keine Befehle außerhalb Whitelist-Tools”. Enforcement vor Ausführung, nicht im Nachhinein.

  • Qualitätssignale: Token-Latenz, Tool-Fehlerraten, Refusal-Quoten, Halluzinationsindikatoren (z. B. Antwort ohne Quellenverweis).

  • On-prem, DSGVO: Speicherung der Traces im eigenen Stack. Keine externen Log-Senken.

Alpi-M, unsere Observability- und Governance-Plattform, implementiert genau diese Bausteine für LLM-Agenten. Zielgruppe sind CTOs/VP Engineering, die LLM-Funktionen verantwortbar in bestehende Produkte bringen müssen: nachvollziehbar, auditierbar, mit klaren Freigabeprozessen – on-prem und ohne US-Cloud-Abhängigkeit.

Integrationsbeispiel: Wartungstickets in einer bestehenden Instandhaltungssoftware

  • RAG-Pipeline: Dokumente werden werksintern geparst, in Chunks mit Struktur (Kapitel, Nummerierungen, Tabellenzellen) zerlegt, mit Metadaten (Asset-Typ, Revisionsstand) versehen und in einen lokalen Vektorindex geschrieben.

  • Orchestrierung: Eingehende Störungsmeldungen triggern eine Pipeline: normalisieren -> relevante Assets erkennen -> Top-k-Abschnitte holen -> Antwortvorschlag erzeugen -> Validierungsfunktionen prüfen -> strukturierte Ticketdaten serialisieren -> dem Benutzer als Vorschlag anzeigen.

  • Governance: Jeder Schritt ist in Alpi-M tracebar. Prompt-/Policy-Änderungen laufen durch PRs und Test-Suites. Rollback ist eine Versionsumschaltung, nicht ein Ratespiel.

4) Testing und QA für KI-erweiterte Software

Testen bedeutet nicht nur “F1-Score gut”. Wir testen Systemverhalten unter realen Betriebsbedingungen:

Offline-Tests (vor Produktion)

  • Goldene Datensätze: Kuratierte, versionierte, repräsentative Daten mit Edge-Cases (Verschmutzung, Beleuchtung, Rauschen, rare Fehlerbilder).

  • Contract-Tests für Schnittstellen: gRPC/REST/Schema-Validierung, Forward/Backward-Kompatibilität, deterministische Seeds für Repro.

  • Property-based Tests: Invarianzen wie “höhere Kratzentiefe => Score nicht geringer”, “leerer Kontext => keine Tool-Ausführung”.

  • Ressourcen- und Latenztests: Inferenz unter Last (parallelisierte Requests), GPU/CPU contention, P99-Budgets, GC-Pausen. Ziel: kein Jitter-Überraschung im Feld.

  • Prompt-/LLM-Tests: E2E-Testfälle mit erwarteten Aktionen, verbotenen Aktionen und zulässigen Alternativen. Wir messen nicht BLEU, sondern Task-Akzeptanz (z. B. “legt korrekte Ersatzteilnummer an, verweist auf Quelle”).

Online-Tests (in Produktion, kontrolliert)

  • Shadow Mode: ML/LLM läuft mit, hat aber keine Wirkung. Disagreement-Rate zur Regelbasis wird gemessen, Ursachen analysiert.

  • Canary Releases: Kleine Anteilsfreigabe, Metriken streng überwacht (Qualität, Latenz, Fehlerraten, Benutzerinterventionen).

  • A/B über Aufgabenklassen: Nicht zufällig, sondern zielgerichtet (z. B. nur Asset-Klasse X).

  • Drift-Monitoring: Verteilung von Eingaben (Population Stability Index, Feature-Statistiken), Leistung über Zeit, Alarm bei Out-of-Distribution.

SLOs und Error Budgets für KI-Komponenten
Definieren Sie SLOs explizit:

  • Qualitäts-SLO: z. B. “≥ 98% Recall für Fehlerklasse A, gemessen auf validiertem Online-Sample pro Woche”.

  • Latenz-SLO: z. B. “P99 ≤ 120 ms für Inferenzpfad auf Linie 3”.

  • Verfügbarkeits-SLO: z. B. “Sidecar-Dienst 99.9% über 30 Tage”.

  • Sicherheits-SLO: z. B. “0 policy violations pro 10.000 LLM-Aktionen”.

Brechen Sie SLO-Verstöße auf Root-Causes herunter (Modell, Daten, Infrastruktur, Policy). Ohne Observability bleibt das ein Ratespiel.

5) Schrittweise Migration: Von Regeln zu ML

Ein “Big Bang” scheitert in Brownfield-Umgebungen oft. Besser ist eine Strangler-Pattern-Migration:

Phase 1 – Beobachten

  • ML/LLM läuft im Shadow, Disagreement-Rate und Ursachenanalyse.

  • Ergänzen Sie erklärbare Reason-Codes, damit Fachabteilungen Vergleichslogik verstehen.

Phase 2 – Assistieren

  • ML liefert Vorschläge, Mensch entscheidet. Sammeln Sie Interaktionen als Trainingssignale.

  • Regeln bleiben die Gatekeeper. ML steigert Geschwindigkeit, nicht Autonomie.

Phase 3 – Teilautomatisieren

  • Für niedriges Risiko definieren Sie eng begrenzte Autonomie (z. B. unkritische Sortierung). Regeln bleiben harte Schranken.

  • Messen Sie klar: Welche Fälle wurden tatsächlich automatisiert? Welche mussten eskaliert werden?

Phase 4 – Ersetzen/Hybridisieren

  • Wo ML nachweislich stabil überlegen ist, ersetzen Sie Teilregeln.

  • Bewahren Sie deterministische “Envelopes”: Schwellwerte, Monotoniebedingungen, Safety-Checks.

  • Dokumentieren Sie den Safety Case: Wie wird im Fehlerfall reagiert? Welche Kennzahlen rechtfertigen die Migration?

Konkrete Hybridmuster

  • Rule-as-Guard: Regel prüft “Darf diese ML-Entscheidung wirken?” Beispiel: “Nur wenn score ≥ 0.9 und keine kritische Klasse.”

  • Rule-as-Explanation: Regel erzeugt reason_codes aus ML-Merkmalen. Fachlogik bleibt lesbar.

  • Rule-as-Fallback: Bei Timeout/Unsicherheit greift Regel. ML erhöht Durchschnittsleistung, Safety bleibt regelbasiert.

6) Betrieb: On-prem, Edge, Sicherheit, Lifecycle

On-prem ist nicht nur eine Ideologie, sondern eine Betriebsanforderung in der Industrie.

Ressourcen und Scheduling

  • GPU-Pools on-prem: Isolieren Sie Workloads per Kubernetes/Container Runtime mit GPU-Quotas. Kein “One model to hog them all”.

  • Priorisierung: Produktionskritische Inferenz hat Vorrang vor Batch-Training. Preemption kann sinnvoll sein, aber niemals im Echtzeitpfad.

  • Artefakt-Management: Modelle als unveränderliche Artefakte mit Signaturen, Metadaten (Train-Datenstand, Pre-/Postprocessing-Hashes, Eval-Ergebnisse).

Sicherheit

  • Air-Gapped oder streng segmentiert. Keine ausgehenden Verbindungen für Agenten. Paketquellen intern spiegeln.

  • SBOMs und Supply-Chain-Security: Wissen, was in den Containern steckt. Aktualisierungspfad für CUDA/Treiber planen.

  • Secrets-Handling: Keine API-Keys in Prompts oder Config-Files. KMS on-prem, Zugriff minimal halten.