Data Engineering
Datenquellen anbinden, Datensätze versionieren, Qualität prüfen und wiederverwendbare Features erzeugen.
Orthevs Engineering Lab · AMEL
AI-Systeme als beherrschbares Engineering-Produkt.
Das AI & ML Engineering Lab verbindet Daten, Modelle, Experimente, Deployments und Governance zu einem reproduzierbaren Lebenszyklus. Es ist die fachliche Control Plane zwischen AI-Idee und belastbarem Betrieb.
Dokumentiertes Zielbild · Concept / Architecture Baseline
AI / ML Lifecycle
Input
Daten
Anforderungen
Hypothesen
Orthevs Lab
AMEL
Control Plane
Outcome
Modelle
Endpoints
Evidence
Monitoring, Drift und kontrolliertes Retraining
Auftrag und Anspruch
Von einzelnen ML-Werkzeugen zu einem durchgängigen Engineering-System.
AI- und ML-Vorhaben scheitern selten an einem fehlenden Algorithmus allein. Die schwierige Arbeit liegt in den Übergängen: Daten müssen auffindbar und zulässig sein, Experimente reproduzierbar bleiben, Modelle nachvollziehbar bewertet, sicher paketiert, kontrolliert freigegeben und im Betrieb beobachtet werden. Genau diese Übergänge macht AMEL zu expliziten, prüfbaren Abläufen.
AMEL ersetzt keine etablierten Frameworks, Trainingslaufzeiten oder Cloud-Dienste. Das Lab legt eine fachliche Steuerungsschicht darüber: Es beschreibt Ressourcen, koordiniert Jobs und Workflows, verwaltet Factory-Capabilities und hält Referenzen auf Artefakte, Zustände und Nachweise zusammen. Anbieter und Backends werden über Adapter angebunden, damit fachliche Prozesse portabel bleiben.
Das Ergebnis ist kein einzelnes „AI-Tool“, sondern ein erweiterbares Betriebs- und Entwicklungsmodell. Teams können mit einer kleinen Dataset-to-Model-Strecke beginnen und dieselben Verträge später um Serving, Monitoring, generative AI, Agenten oder Governance ergänzen.
Capability-Landkarte
Acht Domänen decken den vollständigen AI-/ML-Lebenszyklus ab.
Die Domänen ordnen Verantwortung, nicht Toolnamen. Jede Capability soll eigenständig versioniert und über standardisierte Verträge in Workflows kombiniert werden können.
Model Engineering
Algorithmen und Architekturen entwerfen, Modellbausteine kombinieren, optimieren und freigegebene Versionen registrieren.
Training & Research
Trainingsläufe, Experimente, Suchräume, Benchmarks und Forschungsfragen reproduzierbar bearbeiten.
Generative AI & LLM
LLMs, Prompts, Retrieval, Agenten und multimodale Systeme als testbare Engineering-Artefakte behandeln.
Deployment & Operations
Modelle paketieren, Inferenz ausführen, Endpoints betreiben, Verhalten überwachen und Lifecycle-Entscheidungen steuern.
Quality, Security & Governance
Qualität, Robustheit, Erklärbarkeit, Sicherheitsrisiken, Freigaben und Evidence zusammenführen.
Automation & Integration
Capabilities in Pipelines und freigabepflichtige Workflows überführen und bestehende Systeme integrieren.
Advanced AI Engineering
Reinforcement Learning und föderiertes Lernen mit besonderen Runtime-, Simulations- und Datenschutzanforderungen abbilden.
Einsatzmöglichkeiten
AMEL beginnt beim konkreten Engineering-Problem.
Die folgenden Szenarien zeigen, wie sich die Factory-Capabilities zu fachlichen Strecken kombinieren lassen. Sie beschreiben das Zielbild, keine bereits zugesicherte Produktfunktion.
01Model Development
Reproduzierbare Modellentwicklung
Ein Team überführt Rohdaten in eine versionierte Trainingsgrundlage, dokumentiert Architektur und Parameter und vergleicht Runs unter denselben Bewertungsregeln. Aus einem vielversprechenden Experiment wird erst dann eine Modellversion, wenn Datenherkunft, Laufzeitumgebung, Metriken und Checkpoints nachvollziehbar verknüpft sind.
- Dataset- und Feature-Versionen
- Trainings- und Experiment-Runs
- Evaluation und Model Registry
02Production ML
Vom freigegebenen Modell zum überwachten Endpoint
Eine freigegebene Modellversion wird mit ihren Abhängigkeiten und Integritätsnachweisen paketiert, als Batch- oder Online-Inferenz bereitgestellt und über definierte Rollout- und Rückfallregeln betrieben. Monitoring verbindet Latenz, Ressourcen, Qualität und Drift mit einer kontrollierten Lifecycle-Entscheidung.
- Signierte Modellpakete
- Canary, Rollback und Traffic-Steuerung
- Drift- und Qualitätsfeedback
03Enterprise GenAI
RAG-Anwendungen mit prüfbarer Wissensbasis
Dokumentquellen werden kontrolliert aufgenommen, segmentiert, eingebettet und indexiert. Prompts, Retrieval-Strategien und Reranking werden versioniert getestet; die Evaluation trennt Antwortqualität, Quellenbezug und unerwünschtes Verhalten. So bleibt eine RAG-Anwendung auch nach Daten- oder Modellwechseln vergleichbar.
- Versionierte Quellen und Indizes
- Prompt- und Retrieval-Tests
- Qualitäts- und Security-Gates
04Agentic Systems
Kontrollierte Agenten und Tool-Nutzung
Agenten erhalten nur explizit erlaubte Tools und kurzlebige, zweckgebundene Identitäten. Planung, Tool-Aufrufe, Ergebnisse und Freigaben werden als nachvollziehbare Runs behandelt. Cross-Lab-Aktionen laufen nicht direkt, sondern über Capability Discovery, Policy-Prüfung und die API des Ziel-Labs.
- Tool-Allowlisting und Scopes
- Human-in-the-loop-Freigaben
- Durchgängiger Audit-Trail
05Governed AI
Nachweisfähige AI für sensible Kontexte
Model Cards, Data Provenance, Testresultate, Risikoklassifizierung und Freigabeentscheidungen werden entlang einer Modellversion gebündelt. Fachliche und technische Prüfer sehen, welche Daten, Tests, Policies und Verantwortlichen zu einer Freigabe geführt haben und welche Bedingungen für den weiteren Betrieb gelten.
- Evidence und Model Cards
- Erklärbarkeit und Robustheit
- Review- und Approval-Gates
06Private & Distributed AI
Lernen über verteilte oder geschützte Datenräume
Wenn Daten einen Standort oder eine Organisation nicht verlassen dürfen, kann AMEL föderierte Trainingsabläufe, Aggregation und standortspezifische Policies koordinieren. Dedizierte Worker- oder GPU-Pools, getrennte Berechtigungen und explizite Artefaktflüsse bilden dafür die technische Grenze.
- Multi-Site-Training
- Isolierte Compute-Kontexte
- Kontrollierte Aggregation
End-to-End-Lebenszyklus
Jede Übergabe wird zu einem überprüfbaren Vertrag.
AMEL koordiniert nicht nur die Happy Path-Ausführung. Zustände, Fehler, Retries, Freigaben, Artefakte und Verantwortlichkeiten gehören zum fachlichen Ablauf.
- 01Discover
Problem und Kontext
Ziel, Nutzer, Risiken, Akzeptanzkriterien und zulässige Datenquellen definieren.
- 02Acquire
Daten aufnehmen
Quellen anbinden, Daten klassifizieren und eine unveränderliche Dataset-Version erzeugen.
- 03Design
Lösung entwerfen
Algorithmus, Architektur, Features, Runtime und Evaluationsstrategie versionieren.
- 04Train
Runs ausführen
Isolierte Jobs mit Seeds, Parametern, Code-Digest, Compute-Profil und Checkpoints starten.
- 05Evaluate
Qualität belegen
Metriken, Robustheit, Sicherheit, Erklärbarkeit und domänenspezifische Kriterien prüfen.
- 06Approve
Freigabe entscheiden
Evidence, Risiken, Model Card und Verantwortlichkeiten in einem Gate zusammenführen.
- 07Deliver
Paketieren und signieren
Modell, Abhängigkeiten, Konfiguration und Provenance als überprüfbares Bundle ausliefern.
- 08Operate
Serving betreiben
Batch- oder Online-Inferenz mit Limits, Rollout, Routing, Observability und Rollback steuern.
- 09Evolve
Beobachten und verbessern
Drift, Qualitätsverlust, Kosten oder neue Anforderungen lösen kontrollierte Änderungen aus.
Geschlossener Regelkreis
Monitoring beendet den Lebenszyklus nicht. Signale aus dem Betrieb werden mit Dataset-, Modell- und Deployment-Versionen korreliert und können einen geprüften neuen Trainings- oder Freigabezyklus auslösen.
Referenzarchitektur
Eigenständig in der Domäne. Klar verbunden mit der Plattform.
Die Microservice-Grenze liegt beim Lab, nicht bei jeder Factory. Das hält den fachlichen Zusammenhang stabil und erlaubt dennoch unterschiedliche Ausführungsmodelle für Plugins und Jobs.
Orthevs Platform
Identity & IAM · Lab- und Capability Registry · Secrets · Policy · Audit · Event Bus · Resource Management
AMEL Lab Microservice
Workbench / BFF · versionierte AMEL API · Core · Factory Manager · Job- und Workflow-Koordination · Metadaten und Artefaktreferenzen
Factory-Plugins
Installierte Capability-Pakete mit Manifest, Lifecycle, Permissions, typisierten Ein- und Ausgaben, Health und UI-Erweiterungspunkten
Runtime & Infrastructure
In-Process Plugin · isolierter Worker · Container-/Kubernetes-Job · verteilte GPU Worker · externe Backend-Adapter · Object Storage
API-first
Workbench, Clients und andere Labs greifen ausschließlich über versionierte APIs, Events und Capability Contracts zu.
Asynchron, wenn nötig
Training, Pipelines und Deployments liefern Job-Ressourcen mit Status, Attempts, Fehlern, Retries und Korrelations-ID.
Adapter statt Bindung
Compute, Storage, Frameworks und externe Dienste bleiben austauschbar, soweit ihre Fähigkeiten den Vertrag erfüllen.
Keine versteckte Kopplung
Andere Labs greifen weder direkt auf die AMEL-Datenbank noch auf interne Plugin-Zustände oder Dateisysteme zu.
Factory Contract
Erweiterbarkeit braucht verbindliche Spielregeln.
Eine Factory gilt erst dann als integrierbare AMEL-Capability, wenn sie nicht nur Funktionen, sondern auch Betrieb, Sicherheit und Kompatibilität beschreibt.
Identity & Manifest
ID, Name, Version, Typ, Maintainer, Lizenz und Vertrauensherkunft.
Lifecycle
Install, Initialize, Start, Stop, Upgrade, Uninstall sowie Health und Readiness.
Capability & API
Versionierte Operationen, Fehlercodes, Timeouts, Idempotenz und Kompatibilität.
Artifacts
Typisierte Ein- und Ausgaben, Schemas, Checksums, Versionen und Provenance.
Execution
Runtime, CPU, RAM, GPU, Storage, Job-Modell, Skalierung und Ressourcenlimits.
Security
Permissions, Secret-Scopes, Netzwerkzugriff, Isolation und Audit Events.
Observability
Logs, Metriken, Traces, Job-Status, Health und gemeinsame Korrelations-IDs.
Frontend
UI-Erweiterungspunkte, Routen, Berechtigungen und unterstützte AMEL-Versionen.
Dependencies
Benötigte Lab-, Plattform- und Backend-Versionen sowie andere Capabilities.
Daten, Modelle und Evidence
Lineage macht aus einem Modell ein erklärbares Ergebnis.
Eine Modellversion ist mehr als eine Gewichtsdatei. AMEL verknüpft sie mit der verwendeten Dataset-Version, Algorithmus- und Architekturspezifikation, dem konkreten Trainingslauf, Code- oder Container-Digests, Parametern, Seeds, Compute-Profilen, Metriken, Evaluationsreports und dem freigegebenen Deployment-Paket.
Große Daten und Modellgewichte liegen außerhalb der relationalen Metadatenhaltung in geeigneten Artefakt- oder Object-Stores. AMEL hält referenzierte, integritätsgeprüfte Metadaten und Zugriffsregeln zusammen. So können Storage-Backends wechseln, ohne die fachliche Identität einer Ressource zu verlieren.
DatasetVersionAlgorithmVersionArchitectureSpecCode / Image DigestParameters & SeedsCompute Profile
Traceable ResourceModelVersionimmutable identity
EvaluationReportModel CardPackage & SignatureDeploymentMonitoring Signals
Security, Governance und Betrieb
Vertrauen entsteht entlang des gesamten Systems.
AI-spezifische Risiken werden mit Plattformkontrollen, isolierter Ausführung und fachlichen Freigaben verbunden. Governance ist ein ausführbarer Teil des Lebenszyklus, kein Dokument am Ende.
Daten und Artefakte
Klassifizierung, Zweckbindung, Retention, Löschung und kontrollierte Exporte schützen sensible oder lizenzgebundene Inhalte.
- Keine Secrets in Manifesten, Logs oder Artefakten
- Prüfsummen, Signaturen und Provenance
- Trennung von Trainings- und Evaluationsdaten
Ausführung und Identitäten
Jeder Job und jede Capability arbeitet mit minimalen Rechten, begrenzten Ressourcen und explizitem Netzwerkzugriff.
- Kurzlebige Credentials und Secret-Injection
- Nichtprivilegierte Container und isolierte Worker
- Scopes pro Lab, Factory, Projekt und Aktion
Qualität und AI Security
Evaluation umfasst neben fachlicher Qualität auch Robustheit, Supply Chain und unerwünschte Systemverhalten.
- Prompt Injection und Tool Abuse
- Data Exfiltration und Leakage
- Modell-, Dataset- und Dependency-Risiken
Entscheidungen und Evidence
Freigaben verbinden technische Prüfergebnisse mit Eigentümerschaft, Risikoakzeptanz und Betriebsauflagen.
- Model Cards und Risikoklassifizierung
- Auditierbare Approval- und Policy-Ergebnisse
- Rollback-Plan und benannte Verantwortliche
Zusammenspiel im Orthevs-System
AMEL nutzt andere Labs über freigegebene Capabilities.
Cross-Lab-Zusammenarbeit bedeutet nicht direkten Zugriff. Eine Anfrage wird entdeckt, autorisiert, als Job übergeben und über Status oder Events nachvollziehbar zurückgeführt.
AMEL Factory→AMEL API→Capability Registry→Identity & Policy→Ziel-Lab API→Job & Event
Platform Engineering
Golden Paths, Cluster- und Runtime-Angebote können reproduzierbare Ausführungsumgebungen für AMEL-Workloads bereitstellen.
Infrastructure Engineering
Compute-, Storage-, Netzwerk- und Beschleunigerressourcen werden über kontrollierte Infrastruktur-Capabilities angebunden.
Operating System Engineering
Validierte Images, Hardening-Profile und Fleet-Zustände bilden die Systembasis für Worker und Appliances.
Security Engineering
Threat Modeling, Findings, Controls, Evidence und Response ergänzen AI-spezifische Sicherheitsprüfungen.
Blockchain Engineering
Überprüfbare Herkunfts-, Signatur- oder Governance-Modelle können bei passenden Anwendungsfällen als Capability integriert werden.
Roadmap-Zielbild
Erst Verträge und Vertical Slice. Dann Breite und Skalierung.
Die Phasen beschreiben die fachliche Entwicklungsreihenfolge des Architekturkonzepts. Sie sind bewusst ohne verbindliche Liefertermine dargestellt.
-
Phase 0Foundation
Architektur und Plattformgrundlagen
Lab-Grenzen, Factory Manifest, Lifecycle, Job-Modell, API-, Event- und Artifact Contracts sowie IAM, Secrets, Policy, Registry, Threat Model und grundlegende ADRs werden verbindlich.
Ergebnis: testbare Verträge und ein belastbares Sicherheitsfundament. -
Phase 1Engineering
Erste AI-/ML-Engineering-Strecke
Dataset, Algorithmic, Model Architecture, Training, Experimentation und Model Registry bilden einen durchgängigen Dataset-to-Model-Vertical-Slice.
Ergebnis: ein reproduzierbarer Run mit registrierter Modellversion und Lineage. -
Phase 2Production
Production Readiness
Pipeline, Data Quality, Evaluation, Packaging, Serving und Monitoring erweitern den Vertical Slice um Freigaben, Rollout, Betrieb, Recovery und Qualitätsfeedback.
Ergebnis: ein überwachter Endpoint mit Rollback- und Betriebsnachweis. -
Phase 3Generative AI
LLM-, RAG- und Agent-Engineering
LLM, Prompt Engineering, RAG, Agent und Multimodal werden mit Evaluation, Security, Tool-Freigaben und kontrollierten Wissensquellen integriert.
Ergebnis: nachvollziehbare generative Anwendungen statt unversionierter Prompts. -
Phase 4Enterprise
Advanced AI und organisationsweiter Betrieb
Verbleibende Spezialisierungen, föderiertes Lernen, Reinforcement Learning, Cross-Lab-Integration, Mandantentrennung, skalierbare Worker und fortgeschrittene Governance folgen.
Ergebnis: ein erweiterbares AI-Engineering-System für unterschiedliche Betriebsmodelle.
MVP-Szenario
Projekt → Dataset → Training → registriertes Modell
Ein Nutzer erstellt einen Projektkontext, importiert ein Dataset, definiert eine einfache Trainingskonfiguration, startet einen isolierten Job, verfolgt Logs und Metriken und registriert das resultierende Modell samt Lineage. Der Pfad gilt erst als abgeschlossen, wenn Berechtigungen, Verträge, Fehlerbehandlung, Lifecycle und Recovery dokumentiert und getestet sind.
Bewusste Grenzen
Was die erste Ausbaustufe ausdrücklich nicht verspricht.
Eine belastbare Roadmap benennt neben Zielen auch Nicht-Ziele. Das schützt AMEL vor einem breiten, aber nicht integrierten Toolkatalog.
- Nicht alle 32 Factories werden gleichzeitig umgesetzt; priorisiert wird ein kleiner, vollständiger End-to-End-Pfad.
- Factories sind Plugins des AMEL-Microservice und werden nicht pauschal als eigene Microservices betrieben.
- AMEL baut keine eigenen Alternativen zu etablierten ML-Frameworks, Laufzeiten oder Storage-Systemen, wenn Adapter ausreichen.
- Das Frontend verdrahtet Factory-Funktionen nicht fest, sondern lädt freigegebene Erweiterungen über versionierte UI Contracts.
- Forschungsfunktionen gelangen nicht ohne Evaluation, Security-Gates und benannte Verantwortliche in produktionskritische Dienste.
- Konkrete SLIs, SLOs, Durchsatz-, GPU-, RPO/RTO- und Kostenwerte werden erst mit den jeweiligen Betriebsprofilen verbindlich festgelegt.
AMEL Factory Portfolio
32 Capabilities in 8 fachlichen Domänen.
Jede Factory besitzt eine eigene Detailseite mit Verantwortung, Einsatzmöglichkeiten, Artefakten und Contract. Der Katalog bildet die geplante Capability-Landkarte des Labs ab.
Advanced AI Engineering
2 FactoriesAutomation & Integration
3 FactoriesIntegration Factory
Framework-, SDK-, Service- und Lab-übergreifende Integrationsadapter.
Detailseite öffnen ↗Pipeline Factory
AI/ML-Pipelines, DAGs, Abhängigkeiten, Wiederanlauf und Artefaktflüsse definieren.
Detailseite öffnen ↗Workflow Automation Factory
Schedules, Ereignis-Trigger, Genehmigungsschritte und Automatisierungsregeln.
Detailseite öffnen ↗Data Engineering
4 FactoriesData Ingestion Factory
Datenquellen anbinden: Datenbanken, APIs, Files, Streams, Object Storage; Batch und Streaming.
Detailseite öffnen ↗Data Quality Factory
Datenprofiling, Validierung, Schema-Checks, Duplikate, Missing Values, Qualitätsregeln.
Detailseite öffnen ↗Dataset Factory
Datensätze erstellen, importieren, bereinigen, labeln, augmentieren, versionieren; synthetische Daten; strukturierte und multimodale Datasets.
Detailseite öffnen ↗Feature Engineering Factory
Feature Extraction, Transformation, Selection und Integration mit Feature Stores.
Detailseite öffnen ↗Deployment & Operations
5 FactoriesAI Monitoring Factory
Drift, Qualität, Latenz, Ressourcen, Token-Verbrauch und Kosten überwachen.
Detailseite öffnen ↗Inference Factory
Batch/Online Inference, Inference Engines, Hardware-Optimierung und Batching.
Detailseite öffnen ↗Model Lifecycle Factory
Promotion, Freigaben, Retirement, Rollback und Retraining-Anstöße orchestrieren.
Detailseite öffnen ↗Model Packaging Factory
Runtime-Bundles, Container Images, Abhängigkeiten, Modellpakete, Signaturen.
Detailseite öffnen ↗Model Serving Factory
API-Endpoints, Rollouts, Autoscaling, Canary, Rollback, Traffic Routing.
Detailseite öffnen ↗Generative AI & LLM Engineering
5 FactoriesAgent Factory
Agenten, Tool-Use, Memory, Planungs-/Ausführungsmechanismen und kontrollierte Agent-Workflows.
Detailseite öffnen ↗LLM Factory
LLM-Integration, Konfiguration, Adaption und Fine-Tuning-Rezepte.
Detailseite öffnen ↗Multimodal Factory
Text-, Bild-, Audio-, Video- und kombinierte multimodale Anwendungen.
Detailseite öffnen ↗Prompt Engineering Factory
Prompt Templates, Versionierung, Tests und Prompt-Optimierung.
Detailseite öffnen ↗RAG Factory
Chunking, Embeddings, Indexierung, Retrieval, Reranking und RAG-Evaluation.
Detailseite öffnen ↗Model Engineering
5 FactoriesAlgorithmic Factory
Algorithmen, Lernverfahren, Loss Functions, Optimierer und spezielle Methoden entwickeln und pflegen.
Detailseite öffnen ↗Model Architecture Factory
CNN-, Transformer-, GNN- und hybride Architekturen entwerfen und konfigurieren.
Detailseite öffnen ↗Model Assembly Factory
Modellbausteine, Layer, Encoder/Decoder sowie Pre-/Postprocessing komponieren.
Detailseite öffnen ↗Model Optimization Factory
Quantisierung, Pruning, Distillation, Sparsity und Performance-Optimierung.
Detailseite öffnen ↗Model Registry Factory
Versionierte Modelle, Artefakte, Provenance, Metadaten und Freigabestati verwalten.
Detailseite öffnen ↗Quality, Security & Governance
4 FactoriesAI Governance Factory
Model Cards, Freigabeprozesse, Compliance-Evidence, Risiken und Policy-Kontrollen.
Detailseite öffnen ↗AI Security Factory
Adversarial Testing, Prompt Injection, Modell-/Artefakt-Scanning und AI Supply-Chain-Sicherheit.
Detailseite öffnen ↗Explainability Factory
Explainability, Feature Attribution, Interpretierbarkeit und Ergebnisbegründung.
Detailseite öffnen ↗Model Evaluation Factory
Qualität, Robustheit, Benchmarks, Regression und domänenspezifische Evaluierungen.
Detailseite öffnen ↗Training & Research
4 FactoriesExperimentation Factory
Tracking von Runs, Parametern, Metriken, Ergebnissen, Artefakten und Reproduzierbarkeit.
Detailseite öffnen ↗Hyperparameter Factory
HPO, Grid/Random Search, Bayesian Optimization und AutoML-Suchstrategien.
Detailseite öffnen ↗Research Factory
Forschungsprojekte, Hypothesen, Benchmarks, Paper-Reproduktionen und Prototyping.
Detailseite öffnen ↗Training Factory
Training, Fine-Tuning, verteiltes Training, Checkpoints, Hardware- und Runtime-Profile.
Detailseite öffnen ↗AMEL gemeinsam konkretisieren
Welcher AI-/ML-Lebenszyklus soll zuerst belastbar werden?
Ob Dataset-to-Model, RAG, Model Serving oder Governance: Der sinnvollste Einstieg ist ein klar abgegrenzter Vertical Slice mit realen Artefakten, messbaren Gates und dokumentiertem Betrieb.