Evaluation schlägt Architektur: Die Disziplin, die über produktive KI entscheidet

Auf einen Blick

• Die wichtigste Architekturentscheidung für LLM-Systeme 2026 ist nicht das Modell, sondern die Evaluation.
• Drei Verschiebungen, die in den Talks der PyCon DE & PyData 2026 erkennbar wurden: kontinuierliche statt punktuelle Evaluation, domänenspezifische statt generische Benchmarks, Eval-gekoppelte Governance statt separater Compliance-Schicht.
• Reihenfolge im Aufbau einer LLM-Lösung: erst Baseline im Kontext, dann Retrieval-Augmented Generation, dann Fine-Tuning, dann ggf. Knowledge Graphs — nicht umgekehrt.
• Hire-Profil 2026: Domänenexperte mit Experimentierwillen, nicht ML-PhD mit Architekturplan.

Die unsexy Architekturentscheidung

Die wichtigste Architekturentscheidung für LLM-Systeme 2026 ist nicht das Modell. Es ist die Evaluation.

Das war eine der klarsten Linien aus den Talks der PyCon DE & PyData 2026:

Produktive Teams gewinnen nicht, weil sie das spektakulärste Modell einsetzen. Sie gewinnen, weil sie früher, kontinuierlicher und domänenspezifischer messen.

Wo Eval-Disziplin von Anfang an mitgedacht wurde, gibt es 2026 Systeme, die tragen. Wo Evaluation als nachgelagerte Phase definiert war, sind die Teams oft noch bei ihrer ersten Version. Kein Naturgesetz — aber ein konsistentes Muster über mehrere Talks hinweg.

Evaluation ist 2026 nicht Test-Disziplin. Sie ist Architekturentscheidung — und zwar die, die alle anderen prägt.

Drei Verschiebungen, die 2026 erkennbar wurden

Kontinuierlich statt punktuell

Die Vorstellung, Evaluation sei ein Schritt am Ende ("wir haben das Modell, jetzt evaluieren wir es"), trägt 2026 nicht mehr. In den Talks, die ernsthafte Produktion beschrieben, war Evaluation eine kontinuierliche Pipeline: bei jedem Modellwechsel, bei jeder Prompt-Änderung, bei jedem neuen Datenset. Der Aufwand zahlt sich erst aus, wenn er bereits eingebaut ist. Programme, die das nicht von Anfang an tun, schaffen es später meistens nicht nach.

Domänenspezifisch statt generisch

Public Benchmarks wie MMLU oder HumanEval haben ihren Wert für Modellvergleiche im Kleingedruckten. Für die Frage, ob ein Modell in einer konkreten Anwendung trägt, sind sie nahezu nutzlos.

Frank Rust und Thomas Prexl zeigten in ihrem Talk, wie produktive LLM-Teams vorgehen: Sie starten nicht mit Architektur, sondern mit 100 realen Nutzerfragen, korrekten Antworten und belastbaren Quellen. Erst daran wird gemessen, ob ein System besser wird. Cheuk Ting Ho exerzierte im Eval-Workshop Do you know how well your model is doing? dieselbe Logik methodisch durch — eigene Tasks, eigene Metriken, mit LightEval als Werkzeug.

Diese internen Eval-Sets sind 2026 oft das wertvollste Asset eines KI-Programms — sie überdauern jeden Modellwechsel und definieren, was "gut" konkret bedeutet.

Eval-gekoppelte Governance

Die alte Architektur trennte zwei Schichten: Modell-Evaluation auf der einen Seite, Compliance und Governance auf der anderen. Die produktiven Programme 2026 haben diese Trennung aufgehoben. Audit-Logs, Drift-Detection, regulatorische Anforderungen, Bias-Metriken laufen im selben Eval-Harness.

Andrei Beliankou und Evgeniya Ovchinnikova (E.ON) zeigten, wie konkret das aussieht: drei Beobachtbarkeits-Stacks parallel (Langfuse, Opik, MLflow), Tracing einzelner Spans, Cost-Breakdown auf Prompt-Pfade — und ein typischer Produktionsfehler, in den jedes Programm ohne diese Disziplin läuft: Konkurrierende Eval-Checks (Hallucination versus Faithfulness) schaukeln sich gegenseitig hoch, bis das Retry-Limit greift — und niemand weiß hinterher, warum die Antwort schlechter wurde.

Alejandro Saucedo (Zalando) stellte das in eine breitere Linie: Rund die Hälfte der Organisationen hat laut aktueller Survey zum State of Production Machine Learning Operations bis heute kein produktives ML-Monitoring im Einsatz. Sein Fazit nach zwei Jahrzehnten produktiver ML-Erfahrung: weniger Hype um Modelle, mehr robuste Betriebs-, Monitoring- und Governance-Strukturen. Wer 2026 ein Programm aufsetzt, das diese Disziplin als Beiwerk behandelt, wiederholt die Fehler von 2018 bis 2022 — mit größeren Modellen und höheren Kosten.

In regulierten Branchen ist das nicht Komfort, sondern Voraussetzung dafür, dass ein System überhaupt freigegeben werden kann.

Die Hierarchie der Lösungen — und warum die meisten zu früh komplex werden

Sebastian Raschka beschrieb im Fireside Chat auf der Konferenz eine Reihenfolge, die in vielen Programmen falsch herum begangen wird: Wer eine LLM-basierte Lösung baut, sollte erst die einfachste Form testen — relevante Information in den Kontext laden, ohne weitere Komplexität, und schauen, wie weit man kommt. Das ist die Baseline. Erst wenn sie nicht reicht, lohnt sich Retrieval-Augmented Generation. Erst wenn auch das nicht reicht, lohnt sich Fine-Tuning. Knowledge Graphs kommen, wenn überhaupt, am Ende.

Die meisten Teams machen es umgekehrt. Sie steigen direkt in Fine-Tuning ein, weil das technisch interessant ist. Oder sie bauen Knowledge Graphs auf, weil das nach Kontrolle aussieht. Oder sie diskutieren MCP-Integrationen, ohne je geprüft zu haben, ob ein einfacher CLI-Zugriff dieselbe Aufgabe löst.

Das ist nicht teuer wegen der Mehrarbeit. Es ist teuer, weil die Eval-Disziplin verschwimmt: Wer mit Fine-Tuning beginnt, kann nicht mehr sauber sagen, ob die Verbesserung vom Fine-Tuning kommt oder von etwas, das Kontext-Management auch geleistet hätte. Die Baseline fehlt — und damit die Grundlage, auf der jedes weitere Investment bewertet werden kann.

Hire-Profile: Domänenexperte mit Experimentierwillen

Auf die Frage eines Konferenzteilnehmers, wen ein "Manager mit Budget und Souveränitäts-Anspruch" einstellen solle, antwortete Raschka in einer Weise, die in der DACH-Realität untergeht: Es brauche nicht primär ML-Spezialisten. Es brauche Menschen, die mit den Systemen ausreichend gearbeitet haben, um eine Intuition zu entwickeln — und die bereit sind, auszuprobieren.

"Ein Domänenexperte, der bereit ist, die langweilige Arbeit zu delegieren."

Das ist eine andere Hire-Logik als "Senior ML Engineer mit fünf Jahren PyTorch-Erfahrung". Sie verschiebt den Fokus auf zwei Eigenschaften: tiefes Verständnis des Geschäftsprozesses und die Bereitschaft, ein Werkzeug zur Hand zu nehmen, das man in zwei bis drei Monaten ausreichend gut bedienen lernt. Wer akzeptiert, dass nicht ML-Tiefe, sondern domänenverankerte Eval-Disziplin entscheidend ist, erschließt einen anderen Talentmarkt — einen, der für die meisten Mittelstands- und Konzern-Programme wesentlich besser passt.

Eval-Sets als strategisches Asset

Modelle wechseln — jedes Quartal. Damit ist nicht das aktuelle Modell der strategische Kern eines Programms, sondern das Eval-Set: 200 bis 2000 reale Beispiele aus dem eigenen Geschäftsprozess, mit Antworten, die ein Domänenexperte als richtig freigegeben hat. Wer dieses Set hat, misst jedes neue Modell binnen Stunden gegen die eigene Realität. Wer es nicht hat, verlässt sich auf öffentliche Benchmarks, die für die eigene Frage selten relevant sind.

Measure - not guess erfordert den Aufbau eines eigenen, versionierten Eval-Sets — sonst bleibt jede Modellentscheidung eine Glaubensfrage.

Eine belastbare Aufteilung staffelt nach Charakteristik: typische Standardfälle, Grenzfälle (mehrdeutige Eingaben), historische Schwierigkeiten (Fälle, in denen Fachpersonal sich uneinig war), deliberate Stresstests (manipulierte Eingaben, Edge Cases der Compliance-Anforderung). 200 bis 500 Fälle, etwa zu gleichen Teilen verteilt, decken den Großteil der Realität ab — die genaue Zahl folgt der Domäne, nicht einer Faustregel. Quartalsweise Pflege; die Annotation bleibt menschlich verantwortet.

Aus der Begleitung mehrerer KI-Programme im letzten Jahr: Programme ohne eigenes Eval-Set optimieren in den ersten drei Monaten Dinge, die sich nicht messen lassen — und stellen dann fest, dass sie keinen Bezugspunkt haben, um zu sagen, wann es besser geworden ist. Der Aufbau bindet Domänen-Kapazität und braucht ergänzendes Engineering für Versionierung und Pipeline-Anbindung. Es ist trotzdem die mit Abstand profitabelste Investition in der ersten Phase.

Für Entscheider heißt das

Erstens: Kein KI-Programm ohne eigenes Eval-Set

Eval-Setup gehört in Woche 1 — getragen vom fachlichen Eigentümer, nicht in der Schublade der ML-Engineering-Roadmap.

Zweitens: Kein Fine-Tuning ohne Baseline-Beweis

Sprünge in komplexere Schichten brauchen Eval-Belege, nicht Begeisterung — Baseline, RAG, Fine-Tuning, Knowledge Graph in dieser Reihenfolge.

Drittens: Kein Governance-Konzept ohne technische Audit-Spur

Compliance und Eval gehören in dasselbe Harness; ohne durchgängige Beobachtbarkeit ist Freigabe in regulierten Branchen nicht zu führen.

Viertens: Kein Hiring nur entlang klassischer ML-Profile

Domänenexperte plus Experimentierwillen ist ein verfügbares, oft günstigeres und für die meisten Use Cases passenderes Profil.

Raschkas Schlussrat war drastisch in seiner Einfachheit: ausprobieren statt zu lange planen. Der Talk-Titel — Stop Waiting, Start Shipping — war dabei Programm. Wer 2026 ohne Eval-Disziplin startet, kauft sich 2027 keine Abkürzung mehr ein.

Stop Waiting, Start Shipping!