Kleine vs. große LLMs

  • Kleine/mittlere Modelle mit starkem RAG und gutem Tooling sind oft ausreichend für interne Wissensarbeit. Große Modelle lohnen, wenn komplexe Generierung oder mehrsprachige Tiefenkompetenz nötig ist – aber prüfen Sie TCO und Governance.

Edge‑Inferenz vs. zentrales Rechenzentrum

  • Edge: + Latenz, Robustheit bei Netzwerkausfall, Daten bleiben an der Maschine; – schwierigere Orchestrierung/Updates an vielen Standorten.

  • Zentral: + einfachere Administration; – Netzabhängigkeit, potenziell höhere Latenz. Häufig sinnvoll: Hybrid – Vorverarbeitung an der Kante, Klassifikation/Anomalie zentral.

7) Minimal tragfähige Governance für LLM‑Systeme

Diese Punkte sollten vor jedem Pilot umgesetzt sein:

  • Rollen- und Rechte: Wer darf welche Dokumente in die Wissensbasis bringen? Wer genehmigt neue Quellen?

  • Dokumenten‑Lebenszyklus: Versionierung, De‑Publikation veralteter Inhalte, rechtssichere Aufbewahrung.

  • Prompt‑ und Antwort‑Protokollierung: Pseudonymisiert, mit Modell- und Versionsbezug; Export nur innerhalb des Rechenzentrums.

  • Testkatalog: Faktizität, Quellenpflicht, Sensitive Content, Prompt‑Injection‑Abwehr, Tool‑Use‑Sicherheit.

  • Notfallplan: Rollback auf vorige Version, Isolierung kompromittierter Komponenten, Fallback‑Betrieb (z. B. reine Suche statt Antwortgenerierung).

  • KPI‑Board: Business‑KPIs und System‑KPIs zusammengeführt. Keine Optimierung ohne Zusammenhang zum Prozessnutzen.

8) Beispielhafte 3‑Monats‑Projekte (technische Skizzen)

Visuelle End-of-Line‑Prüfung

  • Daten: 20–50k Bildaufnahmen unterschiedlicher Chargen; Kamera über bestehendes IO gekoppelt.

  • Pipeline: Vorverarbeitung (Belichtung/Weißabgleich), Augmentierung, Zielfunktion pro Defektklasse.

  • Inferenz: Edge‑Box an der Linie; Ergebnis + Heatmap; bei Unsicherheit Umleitung zur manuellen Prüfschleife.

  • Observability: Drift‑Detektion bei Materialänderungen; Heatmaps zur Erklärung; Taktzeit‑Überwachung.

Dokumenten‑Q&A für Service‑Technik

  • Daten: Servicehandbücher, Schaltpläne, Tickets; OCR/PDF‑Normalisierung, Chunking, Metadaten (Baujahr, Baureihe).

  • RAG: On‑prem Vektorspeicher; strenger Indexaufbau mit Qualitätsprüfungen (Duplikate, fehlerhafte OCR).

  • Inferenz: Kleines bis mittleres LLM; Antwort mit Quellenzitaten und „Unsicherheitsflag“, wenn keine ausreichende Grundlage.

  • Governance: Nur freigegebene Dokumente; Protokollierung aller Abfragen; Rollenkontrolle (z. B. Außendienst vs. Innendienst).

Vorgangsklassifikation eingehender E‑Mails

  • Daten: Betreff, Text, Anhänge; PII‑Maskierung (Namen, Telefonnummern).

  • Modell: Leichter Textklassifikator für Routing; optional LLM für strukturierte Extraktion (Bestellnummer, Termin).

  • Integration: Ticket‑System mit Confidence‑Thresholds; Mensch prüft Low‑Confidence.

  • Beobachtbarkeit: Fehlrouten, Korrekturen, Latenz; aktives Lernen aus Korrekturen.

9) Kosten und Betrieb: Realitätscheck

  • Hardware sizing: Starten Sie klein. Eine kompakte On‑prem‑Recheneinheit mit moderater GPU‑Leistung reicht oft für erste Linien/Teams. Skalierung über horizontale Replikation statt „Monster‑Knoten“.
  • Personelle Kapazität: Planen Sie 0,5–1,0 FTE für Betrieb/Monitoring pro ernsthaftem KI‑Use‑Case ein, insbesondere in den ersten Monaten.
  • Wartungsbudget: Re‑Indexierung bei Dokumentenänderungen, Re‑Training bei Prozessdrift, Sicherheitspatches. Legen Sie feste Wartungsfenster fest.
  • TCO‑Transparenz: Rechnen Sie neben den Modellentwicklungstagen auch Betrieb, Monitoring, Sicherheitsmaßnahmen, Labeling und Datenaufbereitung ein.

10) Entscheidungs-Checkliste vor dem Start

  • Problem und Metrik klar? (z. B. -30% Falsch‑Ausschuss, -20% MTTR, +25% Auto‑Routing)
  • Daten vorhanden oder in 4 Wochen organisierbar?
  • On‑prem‑Betrieb möglich, inkl. Rechtemodell und Audit?
  • Minimal‑Architektur definiert? (Datenpfad, Inferenz‑Service, Observability, Fallback)
  • Kill‑Kriterien dokumentiert und akzeptiert?
  • Verantwortlichkeiten auf Fach- und IT‑Seite festgelegt?
  • Datenschutz‑Bausteine vorbereitet? (PII‑Maskierung, Retention, Betroffenenrechte)
  • Shadow‑Mode‑Phase eingeplant, bevor irgendetwas automatisiert wird?
  • Budget für Betrieb/Monitoring berücksichtigt?
  • Plan für Iteration/Skalierung vorhanden?

FAQ

Frage 1: Brauchen wir zwingend GPUs, um zu starten?
Antwort: Nicht zwingend. Für leichte Klassifikation und Anomalieerkennung reichen oft CPUs oder kleine Edge‑Beschleuniger. Für Bildverarbeitung in Taktzeiten und für LLM‑Inferenz ist GPU‑Kapazität in der Regel sinnvoll. Starten Sie mit einer kleinen, lokal betreibbaren Einheit und messen Sie die Auslastung – dann gezielt ausbauen.

Frage 2: Wie adressieren wir DSGVO und sensible Daten bei LLMs?
Antwort: Minimieren und maskieren. Erlauben Sie dem System nur den Zugriff auf freigegebene Inhalte, halten Sie den Vektorspeicher on‑prem, erzeugen Sie Embeddings lokal und protokollieren Sie alle Anfragen pseudonymisiert. Antworten müssen die verwendeten Quellen nennen. Export von Telemetrie nach außen vermeiden; Audits und Löschkonzepte dokumentieren.

Frage 3: Wie messen wir „Erfolg“ jenseits von Modellgenauigkeit?
Antwort: An der Prozessmetrik: Taktzeit, Ausschussquote, Nacharbeitsaufwand, Ticket‑Durchlaufzeit, Eskalationsrate. Ergänzen Sie Systemmetriken (Drift, Latenz, Confidence) und eine Qualitätsmetrik (z. B. Antwort mit Quelle vs. ohne). Ein Projekt ohne belastbare Business‑Metrik sollte nicht starten.

Frage 4: Offene oder proprietäre Modelle für interne Wissensarbeit?
Antwort: Für souveräne, DSGVO‑konforme Lösungen bieten offene Modelle on‑prem klare Vorteile bei Kontrolle und Anpassbarkeit. Entscheidend ist jedoch die Gesamtarchitektur: Ein mittleres, lokal betriebenes Modell mit gutem RAG und Governance schlägt oft jede „Black‑Box“ in Bezug auf Auditierbarkeit und TCO. Prüfen Sie proprietäre Optionen kritisch hinsichtlich Datenflüssen und Rechtsraum.

Frage 5: Wie vermeiden wir Halluzinationen und Fehlschlüsse?
Antwort: Streng kuratierte Wissensbasis, Retrieval‑Only‑Strategie, Antworten mit Quellenpflicht, „Keine ausreichende Grundlage“-Antwort als legitimer Pfad, Tool‑Use mit harten Schemas. Evaluieren Sie systematisch mit realen, anonymisierten Fragen. Prompts allein fixen das Problem nicht – die Architektur tut es.

Abschluss

Der Mittelstand kann KI schneller und robuster produktiv machen als viele Konzerne – wenn Souveränität, Architekturdisziplin und ein klarer 12‑Wochen‑Pfad zusammenkommen. Starten Sie dort, wo Daten und Nutzen nah beieinanderliegen. Bauen Sie minimal, aber richtig: on‑prem, auditierbar, mit harten Guardrails. Und akzeptieren Sie, dass Observability und Governance keine Option sind, sondern die Voraussetzung dafür, dass KI im industriellen Alltag verlässlich arbeitet.