Integrationsansatz:

  • Side-by-Side-Inferenzdienst: Ein containerisierter Vision-Server (z. B. mit TensorRT/Triton) erhält Bilder über Zero-Copy-Sharing vom Grabber oder per gRPC-Streaming. Er liefert Prognosen inkl. Konfidenz und erklärenden Overlays (BBoxes).

  • Schnittstellenvertrag: Protobuf-Messages mit Feldern für Kamera-ID, Timestamps (PTP-synchronisiert), Produkttyp, Bild-Hash. Antwort: Klassen, Scores, optional Heatmaps/Masken als Referenz.

  • Betriebsmodi:

  • Phase 1 – Shadow: Altes System entscheidet, ML rechnet parallel. Ergebnisse werden verglichen und geloggt.

  • Phase 2 – Canary: 5–10 % der Teile laufen über ML-Entscheidung, Gate mit Grenzwerten (Confidence > X, nur bestimmte Defektklassen).

  • Phase 3 – Hybrid: Regelwerk als „Guardrail“, ML entscheidet innerhalb definierter Freiheitsgrade, bei Unsicherheit Rückfall auf Regeln oder manuelle Sichtprüfung.

  • Latenzoptimierung:

  • Batching bei 1–4 Bildern per Inferenz, nur wenn es das Taktzeitbudget erlaubt.

  • TensorRT-Optimierung (INT8/FP16) mit Kalibrierung, Fixierung der Input-Resolution.

  • GPU-Pinning, dedizierte NIC, kein Overcommit auf dem Inferenzknoten.

  • OT-Anbindung:

  • Ergebnisse und Qualitätscodes werden über bestehende OPC-UA-Nodes zurückgemeldet; keine Direktzugriffe des ML-Servers auf das MES-Schema.

  • Qualitätssicherung:

  • Golden Dataset aus realen Produktionsbildern, annotiert mit dem bestehenden QS-Prozess.

  • Metriken: False-Reject-Rate (PPM), False-Accept-Rate (Sicherheitsfaktor), Drift-Indikatoren (Veränderung der Score-Verteilungen).

  • Abnahme: Grenzwerte pro Variante/Anlage, dokumentierte Reproduzierbarkeit (fixierter RNG-Seed, deterministische Preprocessing-Pipeline).

  • Betrieb:

  • Updates nur signiert, in Wartungsfenstern, mit Rollback-Plan. Modellwechsel über Registry-Flag, Blue/Green auf Inferenzpod-Ebene.

  • Audit: Jede Entscheidung wird mit Bild-Hash, Modellversion, Feature-Checksumme protokolliert.

Ergebnis:

  • Reduktion von Pseudoausschüssen ohne Eingriff in bestehende MES/PLC-Logik. KI als eigenständige, nachvollziehbare Komponente, die sich in die vorhandenen Qualitätsworkflows einfügt.

Szenario 2: LLM-gestützte Wartungsassistenz in einer Intranet-Fachanwendung

Ausgangslage:

  • Ein bestehendes Instandhaltungsportal (Web) enthält Störmeldungen, Ersatzteilkataloge, PDF-Handbücher. Suche ist Keyword-basiert, Qualität mäßig. Daten dürfen das Werk nicht verlassen.

Integrationsansatz:

  • RAG-Pipeline on-prem:

  • Dokumentenaufnahme über bestehende DMS/SharePoint-APIs. Vorindizierung als Hintergrundjob: Extraktion (Text + Strukturelemente), Chunking mit Semantik-Grenzen, Embedding-Generation lokal (z. B. über ein deutschsprachiges Embedding-Modell).

  • Vektorindex: pgvector in Postgres-Cluster (einfaches Backup, bekannte Betriebsprozesse) oder Qdrant. Zusätzlich klassische Invertierte Indizes für Hybrid-Retrieval.

  • LLM-Inferenz:

  • On-prem betriebenes LLM (z. B. kleiner, feinabgestimmter 7–13B-Parameter-Decoder), quantisiert für CPU/GPU-Effizienz. Keine Internetabhängigkeit.

  • Anwendungsintegration als „/assist“-Befehl im bestehenden Ticket-Editor. Der Benutzerkontext (Anlage, Rolle) fließt in Retrieval-Filter ein (ABAC).

  • Governance mit Alpi-M:

  • Prompt- und Antwortüberwachung: Versionierte Systemprompts, Ketten von Werkzeugaufrufen (Retrieval, Tabellenabfragen) als nachvollziehbare Trace.

  • Guardrails: Zulässigkeitsregeln (z. B. keine Handlungsanweisungen ohne Quelle), PII-Redaktion im Logging, Schwellen für automatische Antwort-Vervollständigung vs. Vorschlag.

  • Freigaben: Für risikobehaftete Aktionen (z. B. Änderung einer Wartungsprozedur) zwingende menschliche Freigabe mit Audit-Trail.

  • Sicherheit:

  • Keine direkte Datenbankverbindung des LLM-Prozesses zu Produktionssystemen. Nur wohldefinierte, least-privilege Read-APIs.

  • mTLS, Service Mesh optional, Secrets in Vault, Signaturprüfung aller Containerimages.

  • Qualität:

  • Offline-Evaluationssuites: „Needle-in-Haystack“-Fragen aus realen Tickets, Bewertung nach Antwortvollständigkeit und Quellenbezug.

  • Online-Feedback: Daumen hoch/runter und „Quelle fehlt“-Marker, die als Priorisierung in den Improvement-Backlog fließen.

Ergebnis:

  • Kontextualisierte, nachvollziehbare Assistenz innerhalb der bestehenden Anwendung. Kein Vendor-Lock-in, vollständige Datenhoheit, klare Auditierbarkeit der LLM-Interaktionen durch Alpi-M.

Testen und Qualitätssicherung für KI-erweiterte Software

Die Metriken eines ML-Papers helfen im Betrieb wenig. Entscheidend sind runtime-nahe, reproduzierbare Tests und klare Abnahmekriterien:

  • Vertragstests (Contract Tests): Für jede Inferenz-API definieren wir feste Schemas, zulässige Wertebereiche, Versionskompatibilität. CI bricht beim Bruch eines Schemas ab.
  • Golden Datasets: Kuratierte Datensätze mit bekannten Soll-Ausgaben, die jede Modell-/Pipeline-Änderung passieren muss. Wichtig: Versionierung, rechtssichere Speicherung, Repräsentativität pro Anlage/Variante.
  • Metamorphe Tests: Eingaben werden systematisch variiert (Rauschen, Rotation, Format), erwartete Invarianzen werden geprüft (z. B. Klassenergebnis stabil, Score-Band).
  • Differential-Tests: Parallelbetrieb alter Regelwerke und neuer ML-Pipeline; Flaggen signifikanter Abweichungen, insbesondere bei kritischen Klassen.
  • Performance- und Lasttests: Realistische Eingangsverteilungen, Worst-Case-Latenzen, Ressourcenkonflikte (I/O, GPU). Testen von Batching-Strategien gegen Latenzbudgets.
  • Sicherheits- und Robustheitstests: Adversariale Prompts bei LLM, Prompt-Injection-Szenarien, Abwehrmechanismen validieren. Input-Validierung und Timeouts.
  • Drift-Monitoring: Statistische Überwachung der Eingangs- und Score-Verteilungen über Zeit; Alarmierung bei Daten- oder Konzeptdrift. Maßnahmenkatalog (Re-Training, Schwellenanpassung, Rollback).
  • Reproduzierbarkeit: Build-Pipelines erzeugen SBOMs, deterministische Containerimages, nachvollziehbare Artefaktketten. Modellversionen sind explizit im Betrieb sichtbar.

Schrittweise Migration: Von regelbasiert zu ML-basiert

Eine tragfähige Migrationslinie vermeidet Big Bang und verringert Risiko:

  • Phase 0 – Beobachten: Shadow Mode. ML rechnet, entscheidet aber nichts. Gap-Analyse vs. Regelwerk. Definition von Abnahmekriterien.
  • Phase 1 – Assist: ML liefert Vorschläge, menschliche Entscheidung bleibt maßgeblich. Sammeln von Feedbackdaten.
  • Phase 2 – Gate: ML übernimmt Entscheidungen in Niedrigrisiko-Fällen (hohe Konfidenz, klare Klassen). Regeln fungieren als Safety-Net.
  • Phase 3 – Automate: ML trifft Entscheidungen innerhalb definierter Leitplanken. Ausstiegsszenario (Circuit Breaker) bleibt vorhanden.
  • Strangler-Pattern: Schnittweise Herauslösen von Funktionsbereichen; alte und neue Pfade koexistieren, bis die Umschaltung abgeschlossen ist.
  • Governance und Kommunikation: Risk Register pro Entscheidung, definierte SLOs, Fehlerbudgets, Ownership im Betriebsteam. Dokumentierte Decommission-Kriterien für alte Regeln.