7 Min. Lesezeit

Die meisten Enterprise-KI-Stacks sind überingenieurte Maschinen: Tausende Token Systemprompt, mehrstufige RAG-Pipelines, hartcodierte Geschäftsregeln und manuelles Code-Review als Bottleneck. Das funktionierte, als Modelle bei 85 Prozent Genauigkeit lagen. Mit jeder neuen Modellgeneration verschiebt sich das Gleichgewicht – und die Komplexität wird zur Bremse. Vier konkrete Audit-Punkte zeigen, wo IT-Teams jetzt vereinfachen müssen.

Das Wichtigste in Kürze

• Rich Suttons „Bitter Lesson“ (2019) gilt auch für KI-Stacks: Menschlich designtes Scaffolding verliert gegen Modell-Intelligenz, sobald die Skalierung greift (Sutton, University of Alberta).
• Kontextfenster sind von 4.000 Token (GPT-3, 2020) auf über 1 Million Token (2025/26) gewachsen – ein Faktor 250 in fünf Jahren. Das verändert Retrieval-Architekturen grundlegend.
• Prozedurale Systemprompts mit 3.000+ Token lassen sich bei leistungsfähigeren Modellen oft um 30 bis 50 Prozent kürzen – ohne Qualitätsverlust (Anthropic Prompt Engineering Guide, 2025).
• Google Big Sleep (Project Zero + DeepMind) fand im Oktober 2024 eine echte Zero-Day-Schwachstelle in SQLite – der erste öffentlich dokumentierte Fall eines KI-Agenten, der eine unbekannte Sicherheitslücke in produktiv eingesetzter Software entdeckte.
• Frontier-Modelle kosten das 5- bis 10-Fache pro Token gegenüber Vorgängergenerationen. Effiziente Prompts sind nicht nur eine Frage der Qualität, sondern auch der Kosten.

Warum Skalierung Simplifikation erzwingt

Im März 2019 veröffentlichte Rich Sutton, Professor an der University of Alberta und Mitbegründer der modernen Reinforcement-Learning-Forschung, einen Essay mit dem Titel „The Bitter Lesson“. Seine These: Über 70 Jahre KI-Geschichte hinweg haben Methoden, die auf rohe Rechenleistung setzen, konsistent gegen Methoden gewonnen, die menschliches Domänenwissen einbauen. Nicht weil menschliches Wissen wertlos wäre – sondern weil es nicht mit der Skalierung Schritt hält.

Sechs Jahre später zeigt sich dasselbe Muster bei der Arbeit mit Large Language Models. Teams bauen Systeme um Modelle herum: mehrstufige Prompt-Ketten, hartcodierte Entscheidungsbäume, manuell kuratierte Retrieval-Pipelines. Das war sinnvoll, als GPT-3 mit 4.000 Token Kontext operierte und bei jeder dritten Abfrage halluzinierte. Aber die Modelle haben sich schneller verbessert als die Systeme drum herum.

Die Scaling Laws von Kaplan et al. (2020, arXiv:2001.08361) und die Chinchilla-Ergebnisse von Hoffmann et al. (2022, arXiv:2203.15556) haben gezeigt: Modellleistung steigt vorhersagbar mit Compute, Daten und Parameterzahl. Was das für die Praxis bedeutet: Jede neue Modellgeneration macht einen Teil der menschlich designten Komplexität überflüssig. Nicht alles. Aber genug, um bestehende Architekturen regelmäßig zu hinterfragen.

Audit 1: Prompt-Scaffolding entschlacken

Die erste Frage an jeden produktiven KI-Stack: Wie viel vom Systemprompt beschreibt das gewünschte Ergebnis – und wie viel beschreibt den Weg dorthin? Bei den meisten Produktionssystemen liegt das Verhältnis bei 20 zu 80. Zwanzig Prozent Ziel, achtzig Prozent Prozedur.

Ein typisches Beispiel aus dem Customer-Support: Ein 3.000-Token-Systemprompt, der Intent-Klassifikation in 14 Kategorien vorschreibt, Retrieval-Schritte definiert, Halluzinations-Checks erzwingt und Response-Formate festlegt. Diese prozedurale Spezifikation war notwendig, weil frühere Modelle ohne explizite Anleitung Schritte übersprangen. Bei leistungsfähigeren Modellen wird sie zur Fessel: Das Modell folgt dem vorgeschriebenen Pfad, obwohl es einen besseren kennt.

Anthropics Prompt Engineering Guide formuliert es klar: Komplexität nur dann hinzufügen, wenn sie nachweisbar bessere Ergebnisse liefert. OpenAIs Codex-Dokumentation geht in dieselbe Richtung: Das Ziel beschreiben, nicht den Weg.

Die Empfehlung: Jeden Prompt zeilenweise durchgehen. Bei jeder Instruktion fragen: Steht das hier, weil das Modell es braucht – oder weil ich dachte, es braucht es? Wer seinen Developer-Experience-Stack auf die nächste Modellgeneration vorbereiten will, fängt hier an.

Audit 2: Retrieval-Architektur vereinfachen

RAG ist nicht tot. Aber die Frage, wer die Retrieval-Logik steuert, verschiebt sich. Bei einem Kontextfenster von 4.000 Token war präzises Chunking, Re-Ranking und Filterung überlebensnotwendig. Bei einer Million Token sieht die Kalkulation anders aus.

Wenn ein Modell 500 Seiten Text gleichzeitig verarbeiten kann, verliert die Frage „Welche 5 Chunks sind relevant?“ an Bedeutung. Stattdessen wird die Frage „Welches Repo oder welche Dokumentensammlung bekommt das Modell?“ zur entscheidenden Architekturentscheidung. Die Retrieval-Intelligenz verlagert sich vom Pipeline-Code ins Modell.

Die Entwicklung der Kontextfenster illustriert das: GPT-3 startete 2020 mit 4.096 Token. GPT-4 kam 2023 mit 128.000 Token. Googles Gemini erreichte 2024 eine Million Token. Anfang 2026 arbeiten mehrere Modelle mit Kontextfenstern jenseits der Millionengrenze. Das ist kein lineares Wachstum – es ist ein Faktor 250 in fünf Jahren. Jede Verzehnfachung des Kontextfensters macht einen Teil der Retrieval-Pipeline überflüssig, weil das Modell mehr Rohdaten direkt verarbeiten kann.

Das heißt nicht, dass Vector-Datenbanken verschwinden. Für Korpora jenseits des Kontextfensters bleibt Retrieval notwendig. Aber die Logik vereinfacht sich: Statt mehrstufiger Re-Ranking-Pipelines mit manuell getunten Schwellenwerten reicht es zunehmend, dem Modell ein gut organisiertes und durchsuchbares Repository zu präsentieren und die Selektion dem Modell zu überlassen. Der Aufwand verschiebt sich von der Pipeline zur Dokumentenstruktur.

Für Platform-Engineering-Teams, die interne Developer-Plattformen mit KI-Assistenten ausstatten, hat das eine praktische Konsequenz: Investiert in die Qualität und Struktur eurer Dokumentation statt in die Komplexität eurer Retrieval-Pipeline. Ein sauber organisiertes Confluence-Wiki oder ein gut strukturiertes Git-Repository bringt mehr als ein ausgefeiltes Re-Ranking-Modell.

Audit 3: Hardcoded Domain Knowledge vs. Modell-Inferenz

Wie viele Geschäftsregeln habt ihr in Systemprompts hartcodiert? Zählt sie. Dann fragt euch bei jeder einzelnen: Kann das Modell diese Regel aus dem Kontext ableiten, wenn es Zugang zu den relevanten Dokumenten hat?

Ein Beispiel: Ein Reporting-System, das den Hausstil für Kundenberichte als 15-Zeilen-Anweisung im Prompt definiert. Stil, Struktur, Formulierungsregeln, Formatierung. Ein leistungsfähiges Modell inferiert all das aus einem einzigen Beispielbericht mit höherer Treffsicherheit als aus einer abstrakten Regelbeschreibung. Das ist exakt der Mechanismus, den Sutton beschreibt: Die Scaling Laws machen menschlich kodiertes Wissen nicht wertlos, aber zunehmend redundant, weil das Modell es selbst ableiten kann.

„Wer 2024 einen 3.000-Token-Systemprompt brauchte, kommt 2026 mit 800 Token auf bessere Ergebnisse – vorausgesetzt, er beschreibt das Ziel statt den Weg und gibt dem Modell Zugang statt Vorschriften.“
– cloudmagazin Redaktionsbewertung

Was hartcodiert bleiben muss: Compliance-Regeln, die nicht verletzt werden dürfen (Rückgabe-Policies, regulatorische Vorgaben). Sicherheitsgrenzen, bei denen eine Verletzung inakzeptabel ist. Alles andere verdient einen Test: Prompt mit Regel vs. Prompt ohne Regel. Wenn die Ergebnisse gleich gut sind, kann die Regel raus.

Audit 4: Ein Eval-Gate statt vieler Checkpoints

Intermediate Evaluierungsschritte in KI-Pipelines waren eine Reaktion auf unzuverlässige Modelle: Nach jedem Schritt prüfen, ob das Zwischenergebnis stimmt, bevor der nächste Schritt startet. Intent klassifiziert? Check. Retrieval relevant? Check. Response halluzinierungsfrei? Check.

Bei Modellen, die in 99 Prozent der Fälle korrekt arbeiten, verschiebt sich die Kosten-Nutzen-Rechnung. Jeder Zwischencheck kostet Latenz, Token und Komplexität. Wenn das Endergebnis in der überwiegenden Mehrheit der Fälle stimmt, ist ein einzelnes umfassendes Eval-Gate am Ende effizienter als fünf partielle Checks unterwegs.

Für Software-Entwicklung ist das besonders relevant. Googles Big Sleep (eine Kollaboration zwischen Project Zero und DeepMind) hat im Oktober 2024 eine bisher unbekannte Stack-Buffer-Underflow-Schwachstelle in SQLite gefunden – der erste öffentlich dokumentierte Fall eines KI-Agenten, der eine echte Zero-Day-Lücke in weit verbreiteter Open-Source-Software entdeckte. Wenn KI-Modelle Schwachstellen finden können, die erfahrene Security-Researcher übersehen haben, dann können sie auch Code-Reviews und Regressionstests übernehmen.

Die praktische Empfehlung: Ein Eval-Script am Ende der Pipeline, das funktionale Anforderungen, nicht-funktionale Anforderungen und Edge Cases umfassend prüft. Wenn alle Tests bestehen, ist das Ergebnis freigegeben. Wenn nicht, geht es zurück ans Modell. Keine manuellen Zwischenschritte, kein menschliches Review als Bottleneck.

Kosten und Multi-Modell-Routing

Frontier-Modelle sind teuer. NVIDIAs GB200-Plattform (Blackwell-Architektur, vorgestellt auf der GTC im März 2024) und die GB300-Nachfolger (Blackwell Ultra, GTC März 2025) treiben die Trainingskosten auf Hunderte Millionen Euro pro Modell. Das schlägt auf die Inferenz-Kosten durch: Frontier-Modelle kosten das 5- bis 10-Fache pro Token im Vergleich zur Vorgängergeneration. Wer seinen gesamten Traffic durch ein Frontier-Modell schickt, verbrennt Budget. Wer alles an das günstigste Modell delegiert, verliert Qualität bei komplexen Aufgaben.

Die Lösung ist Multi-Modell-Routing: Einfache Aufgaben (Klassifikation, Extraktion, Formatierung) an günstige Modelle delegieren, komplexe Aufgaben (Reasoning, Code-Generierung, Security-Audits) an Frontier-Modelle weiterleiten. Die Fähigkeit, Probleme korrekt zu routen, wird 2026 zu einer der wichtigsten Kompetenzen in API-First-Architekturen.

Die Vereinfachung der Prompts ist dabei nicht nur eine Frage der Qualität, sondern auch der Kosten. Ein 3.000-Token-Systemprompt, der auf 800 Token reduziert wird, spart bei tausend API-Calls pro Tag 2,2 Millionen Token. Bei Frontier-Preisen von 15 Euro pro Million Token Input sind das 33 Euro am Tag – knapp 1.000 Euro im Monat. Simplifikation und Kosteneffizienz gehen Hand in Hand.

Fazit

Die Bitter Lesson gilt nicht nur für KI-Forscher. Sie gilt für jedes Team, das KI-Modelle in Produktion betreibt. Vier Audits – Prompt-Scaffolding, Retrieval-Architektur, hartcodiertes Domänenwissen und Evaluierungs-Pipelines – zeigen konkret, wo Komplexität zur Bremse wird. Die Modelle werden schneller besser, als die meisten Systeme drum herum angepasst werden. Wer jetzt vereinfacht, ist bereit, wenn die nächste Generation kommt. Wer an seinem über Jahre gewachsenen 5.000-Token-Prompt hängt, wird feststellen, dass ein Einzeiler bessere Ergebnisse liefert.

Häufige Fragen

Was genau besagt die „Bitter Lesson“ von Rich Sutton?

Rich Sutton argumentierte 2019, dass über 70 Jahre KI-Geschichte hinweg Methoden, die auf Skalierung von Rechenleistung setzen, konsistent gegen Methoden gewonnen haben, die menschliches Domänenwissen einbauen. Für KI-Stacks bedeutet das: Statt immer mehr Regeln und Scaffolding hinzuzufügen, sollte man dem Modell mehr Freiheit geben und die Ergebnisse messen.

Soll ich meinen gesamten Systemprompt löschen?

Nein. Compliance-Regeln, Sicherheitsgrenzen und nicht-verhandelbare Geschäftslogik bleiben im Prompt. Was raus kann: prozedurale Schrittfolgen, die dem Modell den Lösungsweg vorschreiben, statt das Ziel zu definieren. Der Test ist einfach: Prompt mit vs. ohne Regel vergleichen. Kein Qualitätsunterschied? Regel entfernen.

Ist RAG mit großen Kontextfenstern überflüssig?

Nicht grundsätzlich. Für Korpora, die das Kontextfenster übersteigen, bleibt Retrieval notwendig. Aber die Retrieval-Logik vereinfacht sich: Statt mehrstufiger Re-Ranking-Pipelines reicht es zunehmend, dem Modell ein gut strukturiertes Repository zu geben und die Selektion dem Modell zu überlassen. Die Investition verschiebt sich von Pipeline-Komplexität zu Dokumentenqualität.

Wie hat Google Big Sleep die SQLite-Schwachstelle gefunden?

Big Sleep ist eine Kollaboration zwischen Google Project Zero und Google DeepMind. Im Oktober 2024 identifizierte der KI-Agent einen Stack-Buffer-Underflow in SQLite – eine Schwachstelle, die in einem Entwicklungszweig existierte und vor einem offiziellen Release gefunden wurde. Es war der erste öffentlich dokumentierte Fall, in dem ein KI-Agent eine unbekannte Sicherheitslücke in weit verbreiteter Software entdeckte.

Wie starte ich ein Prompt-Audit für meinen bestehenden KI-Stack?

Drei Schritte: Erstens, jeden Systemprompt zeilenweise durchgehen und jede Instruktion als „Ziel“ oder „Prozess“ markieren. Zweitens, alle Prozess-Instruktionen einzeln entfernen und die Ergebnisqualität mit einem Eval-Set messen. Drittens, nur die Instruktionen zurückfügen, deren Entfernung messbar schlechtere Ergebnisse liefert. Die meisten Teams stellen fest, dass 30 bis 50 Prozent der Prozess-Instruktionen keine messbare Auswirkung mehr haben.

Quelle Titelbild: KI-generiert via Cloudflare FLUX.2 / cloudmagazin Redaktion