• Kürzere Entscheidungswege. Die Person, die das Problem hat, sitzt oft mit am Tisch. Das beschleunigt Datenschnittstellen, Zieldefinition, Abnahmen.
  • Domänenwissen ist verfügbar. Ein Meister mit 20 Jahren Linienerfahrung beschleunigt ein ML‑Projekt mehr als jede zusätzliche GPU.
  • Geringere Legacy‑Trägheit. Weniger Plattform‑Schichten, weniger „Global Standards“, dafür mehr Pragmatismus.
  • Souverän statt abhängiger Baukasten. Wer nicht in zentralen Cloud‑Policies verfangen ist, kann on‑prem schneller liefern – wenn Security sauber umgesetzt wird.

Referenzarchitektur: On‑prem RAG‑Assistent für Instandhaltung

Problem
Störungssuche dauert zu lange; Wissen steckt in PDF‑Handbüchern, alten Tickets und Köpfen. Ziel: Zeit bis zur Erstdiagnose um 30 % senken, ohne sicherheitskritische Entscheidungen zu automatisieren.

Architektur

  • Datenquellen: PDF‑Manuals, Wartungsprotokolle, CMMS‑Tickets, Ersatzteillisten. Optional Maschinentelemetrie.

  • Ingest/ETL: Normalisierung (OCR, PDF‑Parsing, Tabellen zu Text), Chunking mit semantikbasierten Grenzen (Überschriften, Abschnitte), Metadaten (Maschinentyp, Firmware, Datum).

  • Embeddings: Domänentaugliches Embedding‑Modell on‑prem; Dimensionalität 384–1024, abhängig von Suchraum und Latenzbudget.

  • Vector Store: On‑prem Vektordatenbank mit HNSW/IVF‑Index, Filterung per Metadaten.

  • Orchestrierung: LLM‑Schicht mit strengem System‑Prompt („Antworte ausschließlich auf Basis der gelieferten Quellen; wenn unklar: ‚Unklar‘“), Tool‑Aufrufe nur für Retrieval und einfache CMMS‑Abfragen.

  • Guardrails: Quellenpflicht, maximale Antwortlänge, Blacklist sensibler Begriffe, Confidence‑Schwellen (z. B. Mindest‑KNN‑Score).

  • Output: Antwort plus Quellenlinks, Vorschlag zu relevanten Ersatzteilen, Button „Ticket anlegen“ mit vorausgefüllten Feldern – nur mit menschlicher Freigabe.

  • Betrieb: Kubernetes on‑prem, getrennte Namespaces (Ingest, Inferenz, UI, Governance), Secrets über Vault, Netzsegmente isoliert.

  • Observability & Governance: End‑to‑End‑Tracing von Prompt → Retrieval → Antwort; Versionierung von Prompts/Policies; Feedback‑Loop („War die Antwort hilfreich?“). Genau hier setzen wir mit Alpi‑M an: Evaluationssuiten, Guardrail‑Policies und Auditlog‑Funktionen für LLM‑Agenten, vollständig on‑prem betreibbar.

Trade‑offs und Feinheiten

  • Chunking: Zu groß verschlechtert Recall, zu klein fragmentiert Kontext. Praxis: 200–500 Token plus Overlap, domänenspezifische Abschnittslogik schlägt naive Fenster.

  • Ranking: Hybrid (BM25 + Embedding‑Score) liefert oft stabilere Ergebnisse als rein vektorbasierte Suche.

  • Halluzinationen: Konsequent abbrechen, wenn kein ausreichender Retrieval‑Score; lieber „Unklar“ plus Eskalation als unsichere Anweisung.

  • PII/Geheimhaltung: Personenbezug in Protokollen maskieren; strikte Trennung zwischen personenbezogenen Daten und technischen Inhalten; Zugriff nur nach Need‑to‑Know.

Qualitätssicherung und Betrieb

Tests

  • Goldstandard‑Set: Repräsentative Fragen/Antworten inkl. Quellen. Jede Änderung läuft dagegen. Metriken: Exact Match/ROUGE für extraktive Teile, „Has‑Citation“-Rate, „Answerability“.

  • Adversarial/Red‑Teaming: Eingaben mit Tippfehlern, seltenen Begriffen, Mehrdeutigkeit; bewusst irreführende Fragen prüfen die Guardrails.

  • Regression: Jede neue Datenladung kann Retrieval verschieben; Nightly‑Eval mit Delta‑Bericht.

Betrieb

  • SLOs: Latenz P95 (z. B. 90 %), Abbruchrate bei Unsicherheit.

  • Canary‑Releases: Prompts und Policies wie Code deployen, 10 % Traffic, Metriken beobachten, dann hochskalieren.

  • Feature Flags: Neue Tools/Aktionen hinter Flags, Freigabe erst nach Evaluations‑Erfolg.

  • Backup/Restore und Air‑Gap‑taugliche Updates: Modelle, Indizes, Datenbank‑Snapshots; Signaturen prüfen; SBOM für Abhängigkeiten.

Security

  • Netzwerksegmentierung: Inferenz ohne ausgehenden Internetzugang; Paketfilter erlauben nur Notwendiges.

  • Secrets/Keys: Zentraler Vault, Rotation, Least Privilege.

  • Supply‑Chain: Modelldateien, Container und Dependencies signiert; reproduzierbare Builds, wo möglich.

Kosten und Ressourcen – ohne Zahlenspielerei

Was kostet das? Kommt auf Scope und Rahmen an, aber die wesentlichen Blöcke sind konstant:

  • Engineering‑Zeit: Requirements, Datenanbindung, Evaluationsaufbau, Integration, Tests, Betrieb.

  • Hardware: Je nach Modellgröße CPU‑/GPU‑Kapazität on‑prem; für viele RAG‑Anwendungen sind schlanke Modelle plus solide CPUs ausreichend, Vision‑Themen profitieren von GPU.

  • Software: Open‑Source‑Stack ist möglich; Governance/Observability spart später teure Firefights. Lizenzmodelle prüfen, aber Cloud‑APIs sind nicht zwingend.

  • Betrieb: Monitoring, Backups, Security‑Patches, Evaluationszyklen. „ML‑ist‑fertig“-Illusion vermeiden – Betrieb ist Teil der Lösung.

Checkliste für den Start

  • Problem klar formuliert, KPI definiert, Erfolgsschwelle festgelegt.
  • Datenzugriff rechtlich und technisch geklärt; Minimal‑ETL spezifiziert.
  • Sicherheitsklasse und DSGVO‑Aspekte bewertet; On‑prem als Default beschlossen.
  • Architekturentwurf mit klarem E2E‑Pfad und Guardrails.
  • Offline‑Evaluationsset angelegt, Abnahmekriterien dokumentiert.
  • Betriebskonzepte für Logging, Monitoring, Backup festgelegt.
  • Rollen und Verantwortlichkeiten benannt (Domäne, Dev, MLOps, QA).
  • Plan für Iteration: Was verbessern wir, wenn Baseline nicht reicht (Chunking, Ranking, Prompt, ggf. Feintuning)?
  • Stoppkriterien definiert: Wann brechen wir ab oder pivotieren?
  • Kommunikationsplan: Wer nutzt das System, wie geben Nutzer Feedback?

Was wir als AlpiType beitragen

Wir bauen produktionsreife KI‑Systeme für Branchen, in denen Datensouveränität nicht verhandelbar ist. Unser Schwerpunkt liegt auf Anforderungsanalyse, technischer Verantwortung, Softwareentwicklung und Qualitätssicherung – kein API‑Reselling, keine generischen Chatbots. Mit Alpi‑M liefern wir eine on‑prem betreibbare Plattform für Observability und Governance von LLM‑Agenten: Guardrails, Ausführungspfade, Evaluationssuites und Auditfähigkeit. Aus Projekten in Defense, Fertigung, Bahn, Bau, Textil und Luftfahrt wissen wir: Ein sauberes, souveränes Setup schlägt jede Hochglanzdemo.

FAQ

Frage: Brauchen wir zwingend eine Cloud, um mit KI zu starten?
Antwort: Nein. Für viele industrielle Use Cases ist ein on‑prem Setup die erste Wahl: volle Datenhoheit, kontrollierte Latenzen, DSGVO‑Konformität ohne Drittland‑Problematik. Cloud kann für unkritische Teile ergänzen, ist aber kein Muss.

Frage: Reichen unsere Daten überhaupt aus?
Antwort: Für Inferenz‑first‑Ansätze wie RAG brauchen Sie vor allem saubere, durchsuchbare Inhalte und ein kleines, kuratiertes Evaluationsset. Für viele Probleme ist Datenqualität wichtiger als Datenmenge. Starten Sie mit dem, was Sie haben, und schließen Sie gezielt Lücken.