Zuverlässige Systeme aus unzuverlässigen Komponenten bauen
Wie man zuverlässige Systeme aus unzuverlässigen Komponenten baut – und warum das nicht so neu ist, wie es sich anfühlt.
Das Unbehagen
Jeder Entwickler kennt diesen Vertrag:
Gleiche Eingabe → gleiche Logik → gleiche Ausgabe. Jedes Mal.
KI bricht diesen Vertrag. Derselbe Prompt, dasselbe Modell, dieselbe Eingabe können bei aufeinanderfolgenden Ausführungen unterschiedliche Outputs produzieren. Für Ingenieure, die auf deterministische Systeme trainiert wurden, fühlt sich das grundlegend kaputt an.
Der Widerstand ist nicht rein intellektuell. Er ist emotional. Ingenieure bauen ihre Identität auf die Qualität ihrer Outputs, auf die Kontrolle über das Verhalten des Systems. Wenn eine Komponente inkonsistente Ergebnisse produziert, stellt das nicht nur eine technische Annahme in Frage. Es stellt das Gefühl von Meisterschaft in Frage, das die Arbeit bedeutungsvoll macht. Das zu erkennen ist der erste Schritt darüber hinaus.
Es ist nicht kaputt. Es ist eine andere Art von System. Und es erfordert eine andere Art von Zuverlässigkeits-Engineering.
Sie tun das schon
Das Unbehagen ist real, aber das Problem ist nicht neu. Entwickler arbeiten bereits täglich mit unzuverlässigen Komponenten:
- Netzwerke versagen. Sie wiederholen. Sie fügen Timeouts hinzu. Sie designen für Teilausfälle.
- Drittanbieter-APIs ändern sich. Sie versionieren. Sie schreiben Contract-Tests. Sie fügen Fallbacks hinzu.
- Race Conditions existieren. Sie verwenden Locks, Queues und Idempotenz.
- Benutzer liefern fehlerhafte Eingaben. Sie validieren, bereinigen und lehnen ab.
Keines dieser Systeme ist auf Komponentenebene deterministisch. Sie sind auf System-Ebene zuverlässig – weil Sie Zuverlässigkeit um unzuverlässige Teile herum konstruiert haben.
KI ist dasselbe Muster. Das Modell ist eine unzuverlässige Komponente. Ihre Aufgabe ist es, ein zuverlässiges System darum herum zu bauen.
Das Umdenken
Traditionelle Software fragt: Funktioniert es?
KI-Systeme fragen: Wie oft funktioniert es?
Das ist kein niedrigerer Standard. Es ist ein ehrlicherer. Traditionelle Software scheitert auch – sie scheitert nur auf Weisen, die wir gelernt haben zu verstecken (Fehlerbehandlung, Wiederholungen, graceful degradation). KI macht die Unzuverlässigkeit sichtbar statt sie zu vergraben.
Zuverlässigkeit ist nicht „es gibt immer dieselbe Antwort." Zuverlässigkeit ist „das System funktioniert konsistent innerhalb akzeptabler Grenzen." Die Grenzen definieren Sie.
Das Toolkit
Der Wechsel von deterministischen zu probabilistischen Systemen erfordert spezifische Engineering-Praktiken. Keine davon ist exotisch – es ist dieselbe Disziplin, die Sie bereits auf verteilte Systeme anwenden, angewandt auf eine neue Art von Komponente.
Evaluation ersetzt Unit-Testing
In traditioneller Software verifizieren Tests genaue Outputs. In KI-Systemen evaluieren Sie Verteilungen.
Jedes KI-System sollte haben:
- Einen Evaluationsdatensatz, der das erwartete Verhalten repräsentiert
- Automatisierte Evaluationsläufe bei jeder Änderung
- Regressionsprüfungen, die Degradierung erkennen
Das spielt dieselbe Rolle wie eine Test-Suite. Ohne sie degradieren KI-Systeme still – nicht weil sich der Code geändert hat, sondern weil sich das Modell geändert hat.
Leitplanken ersetzen Vertrauen
LLM-Output sollte fast nie direkt vertraut werden. Das Modell liefert Argumentation. Das System liefert Zuverlässigkeit.
Produktionssysteme müssen Validierungsschichten enthalten:
- Strukturierte Outputs oder Schemas, die Format erzwingen
- Deterministische Geschäftsregeln, die Modellurteil wo angemessen überschreiben
- Output-Validierung, die Halluzinationen und Verletzungen von Rahmenbedingungen erfasst
- Wiederholungs- und Reparaturschleifen für behebbare Fehler
- Agent als Prüfer – ein separater Evaluator-Agent prüft den Output des primären Agenten (siehe unten)
- Risikoabgestufte menschliche Überprüfung, wo die Fehlerkosten hoch sind – siehe risikoabgestufte Validierungs-Gates für die Zuordnung HITL / HOTL / HOOTL
Die Leitplanken sind kein Eingeständnis, dass die KI schlecht ist. Sie sind das Engineering, das die KI nützlich macht.
Agent als Prüfer ist der Produktionsstandard
Für nicht-triviale Arbeit den Generator mit einem separaten Evaluator-Agenten paaren – anderer Kontext, manchmal ein anderes Modell. Das Muster ist jetzt der Produktionsstandard für Code-Review (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot Review) und wird in Kundendienst (Ton- + Richtlinien-Prüfung), Dokumentenverarbeitung und anderen Domänen diskreter Aufgaben übernommen.
Warum es wichtig ist: Menschen, die Output schnell bewerten, sind unzuverlässige Bewerter von selbstbewusst präsentiertem fehlerhaftem Output. Agenten-Prüfer, die in anderen Kontexten laufen, legen offen, was müde Menschen übersehen. Die PoLL-Forschung („Panel of LLM Judges") findet, dass Jurys kleinerer Modelle oft einen einzelnen großen Richter übertreffen (Verga et al., 2024) – und das zu geringeren Kosten.
Kostenstruktur: Ein separater Prüfer-Agent auf jedem Artefakt verdoppelt ungefähr die Inferenzausgaben pro Aufgabe. Auf Sprosse 5 wird das nun als lohnend angesehen – die Kosten-pro-gemergter-Einheit-Mathematik funktioniert, weil menschliche Prüfung im großen Maßstab nicht funktioniert.
Kleinere Schritte ersetzen große Prompts
Große Prompts, die alles auf einmal lösen wollen, sind fragil. Sie kombinieren zu viele Fehlermodi in einem einzelnen Aufruf.
Zuverlässige KI-Systeme zerlegen Aufgaben:
- Eingabe klassifizieren
- Relevanten Kontext abrufen
- Output generieren
- Struktur und Qualität validieren
- Bei Bedarf reparieren
Jeder Schritt kann unabhängig evaluiert, überwacht und verbessert werden. Kleinere Reasoning-Einheiten erhöhen die Zuverlässigkeit aus demselben Grund, aus dem kleine Funktionen zuverlässiger sind als monolithische.
Observability ersetzt Annahmen
Produktive KI-Systeme müssen exponieren:
- Prompt-Logs – was hineinging
- Modellantworten – was herauskam
- Evaluationswerte – wie gut es war
- Fehlerfälle – was schiefging
- Kosten- und Latenzmetriken – was es kostet
Sie können nicht verbessern, was Sie nicht sehen. Und KI-Systeme scheitern auf Weisen, die ohne Instrumentierung unsichtbar sind – der Output sieht plausibel aus, ist aber falsch.
Versionierung ersetzt Stabilität
KI-Modelle entwickeln sich kontinuierlich. Ein Modell-Update kann das Verhalten auf Weisen ändern, die keine Code-Änderung erklären würde.
Engineering-Praktiken müssen einschließen:
- Modell-Versionierung – Die Modellversion in der Produktion festhalten. Bewusst upgraden.
- Prompt-Versionierung – Prompts wie Code behandeln. Änderungen verfolgen. Diffs überprüfen.
- Evaluation beim Upgrade – Ihre Evaluations-Suite vor und nach jeder Modell-Änderung ausführen, genauso wie Sie Tests vor dem Deployment einer neuen Abhängigkeit ausführen.
- Schnelle Iteration – Wenn etwas bricht, schnell iterieren. Der Fix liegt meist im Prompt, den Leitplanken oder der Evaluation – nicht im Modell.
Modell-Änderungen wie Abhängigkeits-Upgrades behandeln. Sie wissen bereits, wie man diese verwaltet.
Fehlermodi und Wiederherstellung bei hoher Reife
Das Toolkit handhabt bekannte Fehlermodi. Auf Tier-3- / Sprosse-5-Reife werden drei zusätzliche Anliegen dominant: zwei neue Fehlermodi (Sycophancy, subjektive Randfälle) und ein Antwortmuster (Rekalibrierung vs. Debugging), das hochreife Praxis von niedrigreifer Praxis unterscheidet. Keines wird von Tests oder Monitoring erfasst; Ingenieure müssen sie erkennen.
Sycophancy: ein strukturelles Anliegen
LLMs verteidigen zuverlässig falsche Positionen mit Selbstvertrauen. Das ist in mehreren Studien gemessen (Sharma et al., 2023; Wen et al., 2024; OpenAI zu Halluzinationen, 2025). Wen et al. fanden heraus, dass RLHF Modelle besser darin macht, Menschen zu überzeugen, dass sie recht haben, ohne sie besser darin zu machen, recht zu haben (False-Positive-Rate +24 % bei QA, +18 % bei Programmieren).
Die Literatur ist sich genuin uneinig darüber, ob Sycophancy ein behandelbarer Trainingsfix oder ein strukturelles Artefakt von RLHF ist.
Die Haltung des Rahmenwerks: Sycophancy für Engineering-Zwecke als strukturelles Anliegen behandeln, unabhängig von der Trainingsentwicklung.
Prozesssicherungen (externes Signal, Agent als Prüfer, Ground-Truth-Retrieval, ausführbare Tests) in jede Schleife einbauen. Vertrauen Sie Modell-Selbstvertrauen nicht als Signal für Korrektheit.
Wenn das Training es später verbessert, bleiben die Sicherungen nützliche Infrastruktur. Wenn nicht, sind die Sicherungen essentiell.
Subjektive Randfälle
Bei niedriger Reife sind Randfälle technisch: Tests fangen sie nicht ab, Monitoring zeigt sie als Anomalien, der Fix liegt im Code. Bei höherer Reife verschiebt sich der dominante Randfall: er ist subjektiv. Ein Nutzer meldet, die KI habe etwas falsch gemacht – aber die Tests bestehen, das Monitoring ist grün und der Fehler ist qualitativ.
Beispiele:
- Engineering – ein PR ist technisch korrekt, aber der Agent hat einen falschen Implementierungspfad eingeschlagen; der Nutzer bemerkt „das ist nicht, was ich meinte"
- Kundendienst – ein KI-gelöstes Ticket hat korrekte Fakten, aber der Ton passt nicht zum emotionalen Zustand des Kunden
- Finanzen – eine Transaktion ist nach der Regel korrekt kategorisiert, aber die Regel selbst stellt die Geschäftsabsicht falsch dar
- Content / Marketing – ein Text ist grammatikalisch korrekt und spec-konform, verliert aber die Stimme der Marke
Die Wiederherstellung ist Gespräch, nicht Patchen. Mit dem Nutzer sprechen. Verstehen, was er tatsächlich erreichen wollte. Die Spezifikation oder den Kontext aktualisieren – nicht den Code.
Dieser Fehlermodus ist gut dokumentiert, aber unzureichend benannt. Praktiker-Quellen verweisen darauf unter unterschiedlichem Vokabular: Addy Osmanis 70-%-Problem (die letzten 30 % sind menschliche Arbeit), NN/g UX-Forschung, das PAIR Guidebook. Das Rahmenwerk benennt es explizit, weil die operative Antwort sich strukturell von einem technischen Bugfix unterscheidet.
Rekalibrierung vs. Debugging
Wenn die KI falsch liegt, sind zwei Antworten möglich:
Das Artefakt (Code, Antwort, Dokument), das der Agent produziert hat, beheben. Behandelt das Scheitern als Code-Problem.
Das Verständnis des Agenten über frischen Kontext, neu artikulierte Spezifikation, Multi-Perspektiven-Brainstorm wieder aufbauen. Behandelt das Scheitern als Spezifikations- oder Kontext-Problem.
Diese sind operativ unterschiedlich.
Die Literatur zur intrinsischen Selbstkorrektur ist einstimmig: Ein Modell, das sich auf eine falsche Richtung festgelegt hat, wird dies nicht zuverlässig von selbst bemerken; Reflexion im selben Kontextfenster nach einer falschen Antwort verstärkt den Fehler, statt ihn zu beheben (Huang et al., 2023; Kamoi et al., 2024). Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) stellten fest, dass 41,8 % der Multi-Agenten-Fehlschläge Spezifikations- oder Designprobleme sind, die Neu-Spezifikation brauchen, nicht Wiederholung.
Praktische Heuristik: Wenn dieselbe Spezifikation in zwei frischen Durchläufen denselben falschen Output produziert, die Spezifikation debuggen, nicht das Artefakt. Die meisten nicht-trivialen Fehler bei hoher Reife sind als Debugging-Probleme getarnte Rekalibrierungsprobleme.
Siehe KI-Labor § Stuck-State-Protokoll für das operative Muster.
Die Rollenverschiebung
In diesem Modell schreiben Ingenieure nicht primär Logik. Sie entwerfen Systeme, die Intelligenz beaufsichtigen. Das ist strukturell Management: Intent einem unvollkommenen Ausführer spezifizieren, Output statt Prozess evaluieren und auf die eigene Kommunikation iterieren, wenn das Ergebnis nicht der Absicht entspricht. Manager haben immer in einer probabilistischen Welt operiert. Ingenieure gesellen sich zu ihnen.
- •Geschäftslogik schreiben
- •Bekannte Algorithmen implementieren
- •Zeile für Zeile debuggen
- •Ausführungspfade optimieren
- •Prompts und Tool-Interfaces designen
- •Validierungs- und Evaluationsschichten bauen
- •Wiederholungs- und Korrekturschleifen designen
- •Systemweite Performance überwachen
Das ist keine Herabstufung. Es ist eine Verschiebung auf eine höhere Abstraktionsebene, dieselbe Verschiebung, die geschah, als Ingenieure von Assembly zu Hochsprachen wechselten, oder von Bare Metal zu Cloud-Infrastruktur. Jeder Übergang fühlte sich wie Kontrollverlust an. Jeder bedeutete tatsächlich mehr Hebelwirkung gewinnen.
Das Kernprinzip
Wir programmieren keine Intelligenz. Wir gestalten Umgebungen, in denen Intelligenz zuverlässig funktioniert.
Die Unzuverlässigkeit ist nicht das Problem. Sie ist die Natur der Komponente. Das Engineering ist das, was eine unzuverlässige Komponente in ein zuverlässiges System verwandelt.
Das ist nicht neu. Das ist das, was Ingenieure schon immer getan haben.
Verwandt: Codereife behandelt das inverse Problem: nicht wie man zuverlässige Systeme aus unzuverlässigem KI-Output baut, sondern wie man KI-Agenten eine Codebasis gibt, die lesbar genug ist, um zuverlässige Arbeit zu produzieren. Dieselbe Unsicherheit, gespiegelt.
← Zurück zur Startseite · Das KI-Labor · KI-Ausführungsstandards · Das Referenzrahmenwerk