• Daten- und Modellhoheit:
  • Vektorindizes, Dokumente, Telemetrie, Agent-Protokolle verbleiben im Werk oder im Unternehmensrechenzentrum.
  • Keine US-Cloud-Abhängigkeit, keine grauen Datenpfade.
  • Performance und Kostenkontrolle:
  • Für textlastige Wartungs-Assistenten reichen oft quantisierte 7–13B-Modelle auf modernen CPUs/GPU-Light aus, wenn Retrieval gut ist.
  • Größere Modelle nur, wenn notwendig (z. B. komplexe Diagnosen mit heterogenen Quellen). Horizontal skalieren, nicht reflexhaft „größeres Modell“.
  • Betriebsfähigkeit:
  • Containerisierte Laufzeit, reproduzierbare Builds, SBOM, signierte Artefakte.
  • Cluster-Deployment mit Standard-Komponenten, die Ihre IT bereits betreibt.
  • Governance first:
  • Observability und Policy-Engine sind Erstklass-Komponenten, nicht „Add-on“.

AlpiType liefert genau diese Bausteine als Produkt- und Projektleistung (→ alpitype.de/leistungen/). Unser Plattformmodul für LLM-Agenten-Observability und Governance (Alpi-M) adressiert Auditierbarkeit, Reproduzierbarkeit und Richtlinien-Durchsetzung on-prem.

7) Observability: Metriken, die Agenten in die Realität holen
Was wir standardmäßig messen und warum:

  • Retrieval-Metriken:
  • Filter-Hit-Rate, semantische Trefferqualität (Proxy: Anteil Antworten mit ≥1 relevanter Quelle), Re-Ranking-Lift.
  • Generierungs-Metriken:
  • Token-Latenz, Gesamtlatenz, Wiederholungs-/Abbruchraten wegen Policy-Verstößen.
  • Tooling-Metriken:
  • Call-Erfolgsquote, Timeouts, Circuit-Breaker-Open-Events, Idempotenz-Hits.
  • Qualitäts-Signale:
  • Zitierungsabdeckung (Anteil der Sätze mit Quelle), Konfliktdetektion (widersprüchliche Quellen), „I don’t know“-Rate.
  • Nutzungsdaten:
  • Häufigste Intents/Prompts (pseudonymisiert), Fehlversuche, manuelle Überschreibungen.

Wichtig: Metriken ohne Replay bringen wenig. Jede Interaktion ist versioniert (Prompt-, Policy-, Index-Revision, Modell-Checksum). So lässt sich ein Vorfall reproduzieren und ein Fix verifizieren.

8) Evaluation: Offline zuerst, dann Canary, dann Erstnutzung
Ein produktionsnahes Vorgehen:

  • Offline-Evaluation:
  • Gold-Set aus realen Störmeldungen, typischen Fragen und Mischfällen mit Ground-Truth (erfahrene Instandhalter reviewen).
  • Messen mit fixem Index-Stand und fixen Policies. Akzeptanzkriterien definieren (z. B. ≥90% richtige Quellen, ≤5% „sicher falsche“ Vorschläge).
  • Shadow-Mode:
  • Live-Daten, aber keine Nutzerinteraktion: Agent erzeugt Vorschläge im Hintergrund, die wir mit den real getroffenen Maßnahmen vergleichen.
  • Canary-Rollout:
  • 5–10% der Nutzergruppen im Werk, erweiterbar, mit Kill-Switch und rollbarer Policy-/Prompt-Versionierung.

9) Sicherheit, Rollen, DSGVO: „Need-to-know“ ist auch für LLM gültig

  • Rollen- und Werkssicht:

  • Zugriffskontrolle bis auf Dokument-Chunk-Ebene. Ein Instandhalter in Werk A sieht nicht die vertraulichen Passagen aus Werk B.

  • PII- und Betriebsgeheimnis-Minimierung:

  • Log-Pseudonymisierung, Reduktion von Freitextfeldern in Telemetrie.

  • Kein Personaldaten-Retrieval; klare Negativlisten im Prompt und in Policies.

  • Auditierbarkeit:

  • Signierte Release-Pipelines (Prompts, Policies, Agent-Graph), Vier-Augen-Prinzip für Änderungen.

  • IT/OT-Segmentierung:

  • Keine direkten Schreibpfade in OT-Netze. Historian/MES-Zugriff via dedizierter Gateways, nur read oder mit Freigabeworkflow.

10) Integration ins Werksökosystem: Kontext ja, Steuerung nein
Konkrete Pattern, die funktionieren:

  • HMI/Andon-Integration:
  • Statt „Freitext-Chat“ eine Aufgabenmaske: „Störung beschreiben -> Anlage wählen -> Agent schlägt Schritte mit Quellen vor -> optional: Ticket-Entwurf“.
  • Kontext-Autofill:
  • Asset-ID aus HMI oder QR/Barcode einlesen; letzte Alarme aus Historian referenzieren (read-only).
  • EAM-Handshake:
  • Agent erstellt Ticket-Entwurf mit verlinkten Quellen und Evidenzen. Freigabe durch Verantwortliche, dann idempotent anlegen.
  • Offline-Fähigkeit:
  • Caching für Dokumente/Antworten je Werk. Bei fehlender Konnektivität degrade auf Retrieval-only, klare Kennzeichnung.

11) Performance- und Kapazitätsplanung: Latenzbudgets sind Produktanforderungen
Zielgrößen, die sich bewährt haben:

  • Antwortzeit:
  • 500–1200 ms für „Kurzantworten“ (Schritte, Werkzeugliste), 1,5–3 s für längere Diagnosen mit 1–2 Tool-Calls.
  • Durchsatz:
  • Planen Sie Spitzen pro Schichtwechsel; häufig steigen Anfragen beim Morgengang und nach Alarmserien.
  • Caching:
  • Ergebnis-Caches pro Werk und pro Asset-Klasse. Retries hitten Cache statt Tools, wenn Input äquivalent ist.
  • Ressourcen:
  • Retrieval- und Re-Ranking-Services skalieren getrennt von LLM-Inferenz.
  • LLM-Kapazität auf reale Token-Last planen; „größeres Modell“ ist selten der Engpass.

12) Drei Szenarien aus der Praxis

  • Textile Fertigung: Triage statt Mythos „Selbstheilung“

  • Problem: Vibrationsüberwachung detektiert häufige Anomalien; Instandhalter verlieren Zeit mit dem Auswerten heterogener Logs.

  • Lösung: Agent aggregiert Alarme, ruft passende OEM-Anleitungen ab, schlägt Prüfsequenzen und Sicherheits-Hinweise mit Zitaten vor; optionaler EAM-Entwurf.

  • Architektur-Entscheid: Kein direkter Zugriff aufs SPS-Netz, Historian read-only. Idempotente Ticket-Erstellung. Ergebnis: gleichbleibende Qualität, weniger Kontextwechel.

  • Bahn-Flotteninstandhaltung: Variantenvielfalt bändigen

  • Problem: Anleitungen unterscheiden sich je nach Baureihe, Seriennummer und Retrofit-Stand. Falsche Anleitung = Sicherheitsrisiko.

  • Lösung: Strenges Metadaten-Filter vor Retrieval, Inline-Zitieren, Workflow-Graph mit „Gültigkeitscheck“-Knoten. Keine Freitextergänzungen ohne Quelle.

  • Governance: Jede Antwort führt Quelle+Gültigkeitsfenster; bei Ambiguität zwingender „I don’t know“.

  • Fertigungs-Qualitätssicherung: Was LLMs nicht tun sollten

  • Visuelle Gut-/Schlecht-Entscheidungen mit harten Latenz- und Fehlerratenanforderungen gehören nicht in einen textbasierten Agenten.

  • Der Agent kann Protokolle und Abweichungsberichte strukturieren, aber nicht den Detektor ersetzen. Echtzeit-Entscheidungen bleiben am Edge-Computer-Vision-Modul.

13) Lessons learned

  • Retrieval ist die „Modellqualität“: Schlechte Metadaten schlagen jedes größere Sprachmodell.

  • Freiform ist gefährlich: Agenten brauchen Graphen, nicht „Kreativität“.

  • „I don’t know“ ist ein Feature: Erzwingen Sie es in Prompt und Policy. Belohnen Sie Zurückhaltung ohne Quelle.

  • Telemetrie zuerst: Ohne Replay ist jede Verbesserung Bauchgefühl.

  • Aufwände richtig planen: 70% Engineering (Daten, Integrationen, Policies), 20% Observability/Governance, 10% Modelltuning.