KI-Engineering aus der Praxis

Ein RAG-System nach Benchmark-Listen zu bauen, bedeutet für die Daten von jemand anderem zu optimieren. Vor einiger Zeit sprach ich mit einem potenziellen Kunden. Ihm war ein multimodales RAG-System hingestellt worden — mit aktuellen Technologien, sauber aufgesetzt, alles state of the art. Das Problem: Es hat ihm einfach nicht die Informationen gegeben, die er brauchte. Im Gespräch wurde klarer, was er eigentlich wollte: Fragen wie “Welche Analysen haben wir zu Thema X in Verbindung mit Thema Y gemacht?” — über Hunderte von PowerPoint-Dateien hinweg. Für solche Anfragen braucht man entweder eine relationale Datenbank, Graph-RAG oder Agentic RAG. Klassisches RAG ist die falsche Architektur. ...

In den bisherigen Posts haben wir einen Agenten von Grund auf gebaut, ihm ein Fundament gegeben, Multi-Agent-Koordination untersucht, Evaluation und Guardrails implementiert und den Agenten als lokalen Service exponiert. Jetzt der letzte Schritt: Alles auf eigene Infrastruktur. Kein API-Call verlässt das Netzwerk. Das Szenario: Ein MLflow-Agent im Cluster Der Agent, den wir in dieser Phase bauen, hat einen konkreten Zweck: Er greift direkt auf MLflow zu — Experimente vergleichen, Modell-Deployments prüfen, Alias-Strategien abfragen. Ohne UI-Navigation, ohne manuelle API-Calls. Stattdessen natürliche Sprache: “Welche Modelle sind im Status Live?” — und der Agent ruft die richtigen Tools auf. ...

In den letzten beiden Posts haben wir den Agenten evaluiert und abgesichert. Er liefert gute Ergebnisse und läuft nicht aus dem Ruder. Aber er ist immer noch Code auf einem Laptop. Kein anderes System kann ihn aufrufen. Niemand sieht, was er tut. Und wenn der Prozess abstürzt, ist alles weg. Zwei Dinge fehlen: Sichtbarkeit und Erreichbarkeit. Tracing: Sehen, was der Agent tut Ein klassischer ML-Service hat vorhersagbare Metriken: Latenz, Throughput, Error Rate. Bei einem Agenten ist das anders. Ein Run kann 3 Knoten durchlaufen oder 8. Der Token-Verbrauch wächst mit jedem Schritt, weil jeder Knoten den akkumulierten Kontext aller vorherigen Schritte als Input bekommt. Standard-Monitoring-Metriken zeigen, dass ein Run lange dauerte — aber nicht warum und nicht welcher Knoten das Bottleneck war. ...

Im letzten Post haben wir gemessen, wie gut ein Agent arbeitet. Aber Evaluation beantwortet nur die Frage “wie gut?” — nicht “wie sicher?” Der Unterschied ist fundamental: Ein klassisches ML-Modell macht falsche Vorhersagen. Ein Agent kann falsche Aktionen ausführen — Tool-Calls, Deployments, Datenbankschreibvorgänge. Das eine ist ein Qualitätsproblem. Das andere kann konkreten Schaden anrichten. Deshalb brauchen Agenten Guardrails. Nicht als optionales Feature, sondern als Voraussetzung für den produktiven Einsatz. Fünf Schichten, ein Prinzip Die Guardrails werden von außen um den Agenten gelegt — ohne den Agenten-Code zu ändern. Das ist bewusst so: Je mehr man den Agenten selbst ändern muss, um ihn abzusichern, desto schlechter ist die Architektur. Fachlogik und Sicherheitslogik gehören in getrennte Schichten. ...

Im letzten Post haben wir Agenten auf mehrere Schultern verteilt — Handoff, Supervisor, Swarm. Aber egal ob ein Agent oder zehn: Woher weiß man, ob sie gut arbeiten? Bei einem klassischen ML-Modell gibt es klare Metriken: Accuracy, F1-Score, AUC. Man hat ein Testset, lässt das Modell laufen und bekommt eine Zahl. Besser oder schlechter — eindeutig. Bei Agenten ist das anders. Das LLM als zentrale Komponente ist nicht-deterministisch — derselbe Input kann zu unterschiedlichen Pfaden führen. Die Anzahl der Schritte variiert. Und “richtig” ist oft eine Einschätzung, keine Ja/Nein-Entscheidung. War die Diagnose vollständig? Waren die Maßnahmen umsetzbar? Hat der Agent halluziniert? ...

Im letzten Post haben wir dem Agenten ein Fundament gegeben — LangGraph für Struktur, MCP für standardisierte Tools. Das Ergebnis: ein einzelner Agent, der verschiedene Tool-Quellen kombiniert und dessen Kontrollfluss transparent und testbar ist. Aber irgendwann reicht ein einzelner Agent nicht mehr aus. Nicht weil er zu wenig Tools hat, sondern weil die Aufgabe so komplex wird, dass ein einzelnes LLM zu viele Rollen gleichzeitig übernehmen muss. Es soll analysieren, Maßnahmen ableiten und einen Bericht schreiben — alles in einem Kontext. Je mehr Verantwortung man einem Agent gibt, desto größer wird der Kontext und desto wahrscheinlicher wird Halluzination. ...

Im letzten Post haben wir einen Agenten von Grund auf gebaut — ohne Framework, direkt gegen die Anthropic API. Das Ergebnis: ein funktionierender ReAct-Agent mit Calculator und Wikipedia als Tools. Funktioniert. Aber bei genauerem Hinsehen zeigen sich schnell einige Grenzen: Bei einem Crash startet der Agent von vorne — es gibt kein Checkpointing. Der Loop ist linear — bedingte Verzweigungen lassen sich zwar mit if/else einbauen, werden aber schnell unübersichtlich, intransparent und schwer wartbar. ...

Wenn man über Agenten redet, wird wie selbstverständlich davon ausgegangen, dass man sie mit Tools wie LangChain, LangGraph, CrewAI oder AutoGen baut. Das macht auch absolut Sinn. Wenn man aber gerade erst beginnt, sich mit Agenten zu beschäftigen, dann empfehle ich, zumindest einmal einen Agenten von Hand zu implementieren bzw. seine Komponenten und ihr Zusammenspiel ohne Framework zu betrachten. Ich für meinen Teil habe damit sehr gute Erfahrungen gemacht. Man entwickelt ein tieferes Verständnis davon, was einen Agenten ausmacht und versteht auch die Abstraktionen der Frameworks besser. ...

Most MLflow setups use about 20% of what the platform offers. Teams log metrics, compare a few training runs, maybe register a model. That’s useful for notebooks and early experimentation — but it doesn’t get you to production. The gap between “we track experiments” and “we have a production ML pipeline” is filled with questions that experiment tracking alone can’t answer: Which model is live right now? What data trained it? Why was the previous version replaced? Can we roll back in under a minute? ...

Die Entscheidung für Self-Hosting ist gefallen. Das Unternehmen betreibt ML-Modelle auf eigener Infrastruktur – aus regulatorischen Gründen, zum Schutz von Betriebsgeheimnissen oder weil das Anfragevolumen eine eigene Infrastruktur wirtschaftlich macht. Damit beginnt die eigentliche Arbeit. Denn wer Modelle selbst betreibt, übernimmt die Verantwortung für alles, was Cloud-Anbieter sonst im Hintergrund erledigen: Training, Deployment, Versionierung, Qualitätssicherung, Rollback. Die Frage ist nicht mehr ob man MLOps braucht, sondern wie gut das Setup sein muss, damit Self-Hosting in der Praxis funktioniert. ...