Kategorie: Erklärer

Suchmaschinen liefern oft Dutzende Ergebnisse, die nicht genau treffen, weil sie nur nach Wortübereinstimmungen suchen. Semantische Suche versteht die Bedeutung. HubSpot hat eine Infrastruktur aufgebaut, die für über zwanzig Milliarden Vektoren semantische Suche ermöglicht. Dieser Artikel beschreibt ihre Entscheidungen und Skalierung, von der Machbarkeitsstudie bis zur automatisierten Großanlage.

Eine Vektordatenbank ordnet jedes Objekt in einem mehrdimensionalen Raum an, sodass ähnliche Inhalte nahe beieinander liegen. Die Suche findet die nächsten Nachbarn zur Anfrage. Qdrant, das HubSpot einsetzt, ist ein zentraler Baustein moderner KI-Anwendungen, von Chatbots über RAG-Systeme bis zur Dubletten-Erkennung von Kontakten.

Warum eine zentrale Vektor-Plattform?

HubSpot begann vor einigen Jahren mit einem Proof of Concept. Damals reichte eine Handvoll Cluster, die mit Helm verwaltet wurden. Mit dem Wachstum der KI-Nutzung – heute nutzen über 38 Teams die semantische Suche – wurde eine zentrale, verwaltete Plattform notwendig. So entstand VaaS – Vector as a Service. Es ist die Schicht zwischen den Anwendungen und der Vektordatenbank. Sie übernimmt Zugriffskontrolle, generiert Embeddings, verwaltet Versionen und sammelt Feedback. Die Anwendungen rufen eine API auf und müssen sich nicht um die Komplexität kümmern. Schreiboperationen laufen asynchron, Leseanfragen synchron.

Warum Qdrant und warum selbst betrieben?

Die Wahl fiel auf Qdrant, eine quelloffene Vektordatenbank, die sich auf eigenen Servern betreiben lässt. Qdrant bietet eine umfangreiche API: benannte Vektoren, Hybridsuche, mehrstufige Abfragen und gewichtetes Ranking. Als ANN-Algorithmus verwendet es HNSW, das geringe Latenzen ermöglicht, aber mehr Arbeitsspeicher benötigt. Die HubSpot-Ingenieure nutzen Optimierungen wie Quantisierung und plattenbasierte Optionen, um Qualität und Kosten auszugleichen. Der Betrieb im eigenen Haus bietet volle Kontrolle über die Daten, Integration in die bestehende Infrastruktur (Tracing, Kostenverfolgung, Rate Limiting, Auto-Scaling) und Nutzung der eigenen AWS-Konditionen. Die Sicherheitsstandards von HubSpot lassen sich direkt anwenden.

Die aktuelle Dimension: Zahlen

VaaS verwaltet heute über 200 Indizes, verteilt auf mehr als 140 Qdrant-Cluster in fünf Rechenzentren und zwei Umgebungen. Insgesamt sind das über 20 Milliarden Vektoren – der größte einzelne Index umfasst 9,5 Milliarden Vektoren, der Durchschnitt liegt bei 95 Millionen. Die Plattform verarbeitet regelmäßig über 5.000 Schreiboperationen pro Sekunde, mit Spitzen bis zu 100.000. Leseanfragen liegen bei über 1.000 RPS. Besonders herausfordernd sind Traffic-Spitzen, wenn große Backfills gleichzeitig mit Live-Traffic laufen. Die Infrastruktur muss skalieren und zuverlässig bleiben. Eine Cluster-Isolation nach Produktteams stellt sicher, dass ein Ausfall nicht die gesamte Plattform lahmlegt.

Vom Helm-Proof-of-Concept zum Kubernetes Operator

2023 startete man mit Helm und einer Handvoll Cluster. Jeder Cluster bekam eine eigene Konfiguration, die manuell per YAML und Skripten angelegt wurde. Für zehn Cluster war das machbar, aber mit dem Wachstum wurde der Aufwand enorm. Jeder neue Cluster brauchte nicht nur die Qdrant-StatefulSets, sondern auch Kafka-Themen, Worker-Pods und Monitoring-Komponenten. Helm kann keine API-Aufrufe tätigen, kein automatisches Scaling basierend auf externen Metriken durchführen und keine komplexen Lebenszyklus-Management-Schritte ausführen. Deshalb entschied man sich für den Umstieg auf ein hauseigenes Kubernetes-Operator-Framework namens „Kube-operators“. Ein Operator überwacht ständig den gewünschten Zustand des Systems und bringt die Realität dorthin – automatisch.

Die Migration brachte eine wichtige Änderung: Statt eines gemeinsamen Namespace für alle Cluster gibt es jetzt einen Namespace pro Cluster. Das erhöht die Isolation, vereinfacht das Kosten-Tracking auf Teamebene und reduziert den Blast Radius bei Fehlern. Die Konfiguration eines neuen Clusters besteht heute aus genau einer Custom Resource (CR). Ein Translator (eine Komponente des Operators) überwacht diese CR und erzeugt oder aktualisiert daraus alle notwendigen Ressourcen: Namespace, StatefulSet für Qdrant, Indexer-Pods, Kafka-Themen und benutzerdefinierte Ressourcen für die Metadaten der Cluster. Die Plattform entdeckt neue Cluster automatisch, indem sie die entsprechenden CRs beobachtet. Ein zusätzlicher Translator kümmert sich um die Qdrant-Knoten selbst, ein dritter um die Indexer – die Arbeiter, die eingehende Schreiblast puffern und in Qdrant indizieren. Das alles läuft in einem 60-Sekunden-Zyklus, so dass Änderungen schnell wirksam werden.

Automatisierte Wartung – Shard-Evakuierung aus einem Guss

Ein besonders kniffliger Vorgang ist das horizontale Herunterskalieren eines Clusters. Früher waren mehrere manuelle Schritte nötig: zuerst einen Job ausführen, der die Shards von den zu entfernenden Knoten transferiert und diese aus dem Konsens entfernt; dann die Helm-Chart aktualisieren, die Pod-Anzahl reduzieren, und schließlich die PVCs der gelöschten Pods manuell löschen. Bei über hundert Clustern ein unhaltbarer Zustand. Mit dem Operator ist das heute ein einziger Schritt: einfach die Replica-Anzahl in der Cluster-CR reduzieren. Der Translator erkennt die Abweichung, startet automatisch die Evakuierung aller Shards von den zu entfernenden Peers, wartet auf erfolgreichen Transfer und entfernt die Peers dann aus dem Konsens – und zwar in einer strikten Reihenfolge, die Datenverlust und Verletzung der Replikationsfaktoren verhindert. Erst wenn alle Shards sicher umgezogen sind, werden die Pods heruntergefahren und die PVCs gelöscht. Diese Automatisierung ist entscheidend, um bei der Größenordnung von 140+ Clustern operativ effizient zu bleiben.

Die Architektur zeigt, wie Unternehmen KI-Infrastruktur als Dienst für interne Teams bereitstellen können. Die Teams müssen sich nicht um die Datenbank kümmern, sondern können sich auf die Geschäftslogik konzentrieren. Der Schlüssel liegt in der Automatisierung: Ein Kubernetes-Operator, der nicht nur Pods startet, sondern auch die Shard-Verwaltung von Qdrant übernimmt. Ein zentraler Dienst besteht aus mehr als nur einer API vor einer Datenbank. Es sind Komponenten wie Namespace-Isolation, dynamische Cluster-Entdeckung und automatisierte Skalierung mit Sicherheitsgarantien, die den Unterschied zwischen einer Labordemo und einer produktiven Umgebung mit Milliarden von Vektoren ausmachen. Die Zukunft der KI-Suche liegt nicht nur in besseren Algorithmen, sondern auch in der robusten, wartbaren Infrastruktur, die sie trägt.

Quelle: product.hubspot.com

Du arbeitest an einer Data Pipeline. Nach einem nächtlichen Lauf stellen die Zahlen, aber nur auf den ersten Blick. Irgendwo hat sich ein Fehler eingeschlichen: eine doppelte Zeile, ein falscher Join, der nicht auffällt, weil das Ergebnis nicht abstürzt. Ein Fehler, der nicht bricht, sondern leise falsche Werte liefert, kann in Berichten und Entscheidungen unbemerkt verheerend wirken. In der Datentechnik geht es nicht nur darum, Code zu produzieren, sondern Code, dem wir vertrauen können.

KI-Agenten sollen dabei helfen. Aber wie viel Vertrauen darf man ihnen schenken? Ein aktueller Artikel beschäftigt sich mit dieser Frage und stellt die Korrektheitsschicht vor – ein Sicherheitsnetz, das die Zuverlässigkeit von KI-generierten Datenpipelines erhöht. Der Artikel untersucht drei Ebenen von KI-Agenten in der Datentechnik, die Rolle deterministischer Validierung und wie sich Token-Kosten kontrollieren lassen. Fazit: Die Struktur eines Projekts und die richtigen Werkzeuge sind wichtiger als das neueste Sprachmodell.

Die drei Ebenen der KI-Agenten in der Datentechnik

Warum Agenten für die Datentechnik einsetzen? Und auf welchen Ebenen können sie produktiv helfen? Sprachmodelle haben, wie Menschen, eine gewisse Fehlertoleranz. Wir brauchen eine Möglichkeit, sicherer zu sein, dass der produzierte Code korrekt ist. Der Artikel unterscheidet drei Stufen.

Erste Ebene: die reine Chat-Phase. Hier prompten wir Claude oder ChatGPT. Das Modell versucht, den Kontext zu verstehen, basierend auf dem, worauf es Zugriff hat. Das verbraucht viele Tokens, weil es alles von Grund auf scannen muss. Das Ergebnis ist brauchbar, aber selten produktionsreif.

Zweite Ebene: der autonome Ansatz. Hier haben Agenten wie Claude Code oder Codex Zugriff auf dieselben Werkzeuge wie ein Mensch – die Kommandozeile. Sie können Postgres mit psql abfragen, mit DuckDB aus S3 oder Parquet lesen und so Daten und Queries direkt verifizieren. Die Qualität der Ergebnisse ist höher, weil der Agent nicht nur rät, sondern überprüft.

Dritte Ebene: dedizierte Agenten für die spezifische Aufgabe. Für die Datentechnik kennen diese Agenten dbt oder können SQL-Code deterministisch transpilieren – nicht aus Trainingsdaten, sondern mit einem Werkzeug, das schneller und zuverlässiger arbeitet. Sie haben eingebaute Prüfungen und Funktionen, die ein allgemeiner Agent nicht bietet. Ideal sind immer dedizierte Werkzeuge – aber es gibt nicht für jede Aufgabe ein solches.

Wo im Datenlebenszyklus jede Ebene wirklich hilft

Die Frage ist nicht nur, ob es dedizierte Agenten gibt, sondern in welchem Teil des Datenlebenszyklus sie den größten Nutzen bringen. Geht es um BI-Dashboards, Datenleitungen, Quell-Ingestionen oder Wartung? Der Lebenszyklus umfasst Extraktion, Transformation und Laden, das Verständnis der Geschäftslogik, die Visualisierung der Ergebnisse und die Fehlerbehebung bei nächtlichen Läufen. Grundsätzlich können Agenten im gesamten Zyklus helfen, aber die Antwort hängt stark von der Rolle und Erfahrung des Anwenders ab. Ohne Vorwissen oder Seniorität ist es gefährlich, von Grund auf etwas zu bauen. Man kann nicht überprüfen, ob der Code korrekt ist. Für Nebenprojekte oder Proof-of-Concepts ist das okay, aber nicht für die Produktion.

Die Ingenieursdisziplin im Umgang mit KI

Es gibt auch einen weniger technischen Teil: die Agenten in die richtige Richtung lenken. Wenn wir KI sicher in großen Projekten oder Organisationen einsetzen wollen, können wir sie nicht ohne Führung laufen lassen. Vier Punkte helfen dabei.

Erstens: eine klare Projektstruktur, in der die Agenten sich entfalten können. Je mehr vorgegeben ist, desto weniger Tokens werden verbraucht, desto einheitlicher wird das Projekt. Ein deterministischer Workflow wie uv init ist optimal, weil er immer gleich abläuft.

Zweitens: baue mit klaren Anweisungen – Agenten-Fähigkeiten oder Superkräfte – wie die Werkzeuge verwendet werden. Das bedeutet, dem Agenten CLI- und API-Dokumentationen bereitzustellen. Das ist der Hauptteil der Arbeit. Es geht um die Datenarchitektur, das Brainstorming mit Kollegen, bevor man etwas baut, damit man keine entscheidende Einsicht verpasst und den Agenten in die falsche Richtung laufen lässt. Ein Prompt wie „sei korrekt“ oder „verwende den neuesten Stand der Technik“ macht den Code nicht korrekter oder moderner, als das Modell trainiert wurde. Bei relativ neuen Architekturen muss man dem Agenten die entsprechenden Links und Hinweise geben.

Drittens: gestalte das Projekt modular, sodass die Agenten nicht das gesamte Projekt zerstören können, wenn sie eine kleine Änderung vornehmen. Kein Abhängigkeits-Chaos, bei dem alles von allem abhängt.

Viertens: verwende einen deklarativen Ansatz mit beschreibender Konfiguration, der das „Was“ und nicht das „Wie“ festlegt. So kannst du mit den Agenten an diesen Konfigurationen zusammenarbeiten, sie versionieren, leicht zurücksetzen oder ändern und die Implementierungslogik von der Geschäftslogik entkoppeln. Das Modell spielt eine geringere Rolle. Struktur und Workflow sind entscheidend. Plane ausgiebig, bevor du eine einzige Zeile schreibst, und korrigiere das Modell, bevor es in die falsche Richtung läuft. Ziel ist Nutzen aus der KI, nicht mehr Arbeit. Früher dachten die meisten Entwickler über das Problem nach. Heute ertrinken viele in Pull-Requests. Bessere KI-Werkzeuge können qualitativ hochwertigeren Code liefern, der weniger Überprüfung und weniger Iterationen erfordert – also weniger PRs und weniger Arbeit.

Die Korrektheitsschicht für Dateningenieure

KI-Agenten sollten den Menschen für Korrektheit unterstützen – oder eine Korrektheitsschicht. Statt mehr Arbeit zu verursachen, um mehr Code zu verifizieren, sollten wir Vertrauen in den Prozess haben und wissen, dass der produzierte Code verifiziert und korrekt ist. Eine deterministische Validierungsarchitektur ist dafür zentral. Der Artikel führt Altimate Code als Beispiel an. Dieses Tool teilt den Agenten in eine probabilistische Schicht oben und eine deterministische Rust/TS-Schicht unten auf, die die eigentlichen SQL-Operationen wie Parsen, Validieren und Äquivalenzprüfungen übernimmt. Der Agent selbst muss bei diesen Fragen nie vertraut werden.

Konkret: Der probabilistische Agent mit dem LLM übernimmt die kreative Arbeit – Intention lesen, Strategie wählen, SQL entwerfen, Ergebnisse zusammenfassen, sich von Fehlern erholen. Unter dieser Grenze liegt das deterministische Geschirr (deterministic harness), eine TypeScript-Schicht, die jeden Werkzeugaufruf abfängt. Ein Dispatcher prüft, ob ein nativer Handler existiert, und leitet den Aufruf entweder an einen nativen, deterministischen Handler oder zurück an das Modell. Diese Handler rufen die Logik nicht selbst auf, sondern ein deterministisches Core-Modul in Rust (altimate-core), das SQL-Operationen als reine Funktionen über ASTs und Schemata bereitstellt. Parsen, Validieren, Transpilieren, Query-Äquivalenz prüfen, Schema-Diffs, Column-Lineage extrahieren, Zeilen-Diffs über Data Warehouses hinweg – all das läuft sub-Millisekunde und liefert bei gleichem Input immer die gleiche Antwort. Wie ein Compiler: Der Agent entscheidet nie, ob zwei Queries äquivalent sind oder eine Spalte upstream existiert. Stattdessen ruft er eine Funktion auf, die es am geparsten AST und Schema beweist – so wie ein Type-Checker beweist, dass ein Programm kompiliert, anstatt zu raten.

Das macht die Ausgabe leichter überprüfbar: Faktische Prüfungen wurden ausgeführt, und die Ausgabe ist entweder korrekt, oder es gibt einen Bug, den der Agent direkt beheben kann. Den Rest kann ein Mensch verifizieren. Das Dilemma: Code wird schneller genehmigt, als geprüft werden kann. Dazu gibt es einen separaten Beitrag. Ein weiterer Faktor: Reiner Agenteneinsatz mag günstig erscheinen – aber nur, bis er falsch liegt. Dann sind die Kosten unbegrenzt.

Verbesserungen für eine bessere Token-Nutzung

Altimate Code oder ähnliche Agenten mit deterministischen Funktionen helfen, Tokens zu sparen und token-effizient zu arbeiten – das Gegenteil von Tokenmaxxing, einem Trend auf Social Media, bei dem möglichst viele Tokens verbraucht werden und Agenten rund um die Uhr laufen. In großen Unternehmen sind Token-Kosten ein echtes Budget-Thema. Ein einfacher Trick: Weist das Modell an, selbst weniger Tokens und Wörter zu verwenden – „Höhlenmensch-Stil“ ist ein Beispiel. Du kannst auch einen einzelnen Prompt in deine CLAUDE.md oder in Codex einfügen, in Kombination mit Altimate Code.

Es gibt einen zweiten, weniger offensichtlichen Kostenpunkt: Der Token selbst ist keine stabile Einheit. Als Anthropic Opus 4.7 auslieferte, kostete derselbe Prompt, der auf 4.6 X Tokens verbrauchte, auf 4.7 plötzlich etwa 1,4X – gleicher Input, gleiche Antwort, mehr Tokens, gleicher Preis pro Token. Der Artikel verweist auf einen Beitrag, der argumentiert, dass „Kosten pro Token“ die falsche Kennzahl sei, denn der Zähler selbst kann sich mit dem nächsten Modell-Update des Anbieters verschieben. Was wir stattdessen verfolgen sollten, sind Kosten pro Aufgabe. Deterministische Funktionsaufrufe umgehen diese Volatilität, indem sie für viele Aufgaben gar kein Modell und keine Tokens benötigen – das macht die Sache günstiger.

Typische Anwendungsfälle

Welche konkreten Einsatzmöglichkeiten gibt es für KI-Agenten in der Datentechnik? Die Liste ist lang. Du kannst sie nutzen, um dich oder dein Team weiterzubilden, produktive Datenpipelines zu bauen, Daten-Apps zu entwickeln und Daten auf innovative Weise zu visualisieren – meistens als HTML-Seiten mit React und anderen JavaScript-Frameworks. Die Anwendungsfälle lassen sich in verschiedene Ansätze gliedern: von der Unterstützung bei der Codeerstellung über die Automatisierung von Tests bis hin zur Generierung von Dokumentation. Der entscheidende Punkt bleibt: Ohne eine Korrektheitsschicht und eine durchdachte Projektstruktur wirst du auf Dauer keine verlässlichen Ergebnisse erzielen. Die Werkzeuge sind da, aber du musst wissen, wie du sie einsetzt.

Was bedeutet das für den Dateningenieuralltag? Vertraue nicht blind, sondern baue eine deterministische Validierung ein. So werden KI-Agenten von einer Blackbox zu einem verlässlichen Partner. Je besser die Werkzeuge, desto unabhängiger wirst du von jedem einzelnen Modell. Der deterministische Rahmen – die Korrektheitsschicht – ermöglicht es, Ergebnisse zu reproduzieren und ihre Herkunft nachzuverfolgen, unabhängig vom Modell. Das gilt besonders bei Wartungsarbeiten oder Erweiterungen, bei denen die Überprüfung die eigentliche Arbeit ist. Die Gefahr liegt nicht im Absturz, sondern in einer falschen Zahl, die nicht auffällt. Es mag eine saubere Query sein, aber sie führt zu doppelten Zeilen. Mit der richtigen Architektur kannst du solche stillen Fehler eliminieren. Hier liegt der Schwerpunkt: menschliche Expertise, Projektstruktur und Korrektheitsschicht machen den Unterschied.

Quelle: ssp.sh

Ein hochbegabter Mitarbeiter hat brillante Ideen, aber keinen Schreibtisch, keine Werkzeuge, keine klaren Anweisungen. Er scheitert an seiner Arbeitsumgebung, nicht an seiner Intelligenz. Diese Erkenntnis treibt einen Forschungszweig: Harness Engineering. Es geht nicht mehr nur um ein schlaues Modell, sondern um die Bühne, auf der es seine Fähigkeiten entfaltet.

Das Prinzip ist alltäglich. Jedes komplexe System braucht eine Hülle. Ein Betriebssystem verwaltet Hardware, eine IDE hilft beim Codieren, gutes Projektmanagement verhindert Chaos. In der KI heißt diese Hülle Harness – das Gerüst, das Modellen erlaubt zu planen, Werkzeuge zu nutzen, sich zu erinnern, Ergebnisse zu prüfen. Ohne dieses Gerüst bleibt selbst das beste Modell ein Denker ohne Hände.

Die Wiederentdeckung einer alten Idee

Die Vision einer sich selbst verbessernden Maschine ist nicht neu. Bereits 1965 skizzierte I. J. Good die ultraintelligente Maschine. Eliezer Yudkowsky prägte 2008 den Begriff der rekursiven Selbstverbesserung (RSI). Lange dachte man, RSI geschehe durch Umschreiben der eigenen Gewichte. Die aktuelle Forschung zeigt einen pragmatischeren Weg: Ein Modell verbessert seine Trainingspipeline und die Einsatzumgebung – also den Harness. Die Schnelligkeit, mit der KI-Labore wie Anthropic oder OpenAI Durchbrüche erzielen, spricht dafür: Die Optimierung des Gesamtsystems ist mindestens so wichtig wie rohe Rechenleistung.

Drei architektonische Muster für den idealen Harness

Die erste Lektion aus der Praxis: Ein Harness muss einfach und generisch sein. Ein Betriebssystem verbirgt Hardware hinter einer Schnittstelle – das soll auch ein Harness leisten. Drei Muster haben sich herauskristallisiert.

1. Automatisierung des Arbeitsablaufs. Der Kern jedes agentischen Systems ist ein Kreislauf: Modell plant eine Aktion, führt sie aus, beobachtet das Ergebnis, bewertet es, iteriert. André Karpathys öffentliches Repository „autoresearch“ zeigt einen eleganten Loop. Das Modell startet mit einer Aufgabe, generiert einen Plan, führt Experimente durch, analysiert Fehler und wiederholt den Prozess – ohne menschlichen Eingriff. Der Workflow steckt nicht in einer statischen Prompt-Vorlage, sondern existiert als dynamische Laufzeitumgebung, die das Modell selbst steuert.

2. Das Dateisystem als persistentes Gedächtnis. Ein Problem bei längeren Agenten-Einsätzen: Der Kontext wächst schnell über das Fenster hinaus, das das Modell verarbeiten kann. Die Lösung: Der Harness speichert Zustände in Dateien, auf die das Modell mit Bash-Befehlen wie grep oder cat zugreift. Das klingt banal, nutzt aber die Stärke moderner Sprachmodelle, die mit Dateisystemen umgehen können. Statt alles in den Kontext zu stopfen, managt der Harness Informationen wie ein Betriebssystem: auslagern, bei Bedarf laden, in überschaubaren Portionen präsentieren.

3. Sub-Agenten und Hintergrund-Jobs. Manchmal muss ein Hauptagent mehrere Hypothesen gleichzeitig prüfen. Ein guter Harness erlaubt, Tochteragenten zu starten, ihnen isolierte Aufgaben zu geben und Ergebnisse später einzusammeln. Die parallelen Arbeiten verschwinden nicht im Chat-Kontext, sondern bleiben als Dateien, Logs und Statusberichte persistent. So kann der Hauptagent auch nach einem Crash seinen Fortschritt rekonstruieren – eine Eigenschaft, die man von jedem soliden Betriebssystem erwartet.

Der Coding-Agent als Blaupause

Die konkreteste Anwendung dieser Muster sind Coding Agents wie Claude Code, Codex oder OpenCode. Sie arbeiten in einer Schleife: Sie lesen und bearbeiten Dateien, führen Bash-Befehle aus, verwenden Git und durchsuchen bei Bedarf das Web. Die Werkzeuge ähneln denen eines menschlichen Entwicklers: Editor, Terminal, Debugger, Patch-Erstellung. Der Harness stellt sie konsistent und kontrolliert bereit. Interessant ist die Standardisierung der Schnittstellen in den letzten Monaten. Die Toolgruppen sind fast überall gleich: Dateisystem-Operationen, Shell-Kommandos, Sprachserver-Funktionen, Git-Tools, Webzugriff und ein Mechanismus zum Starten und Verwalten von Sub-Agenten. Diese Standardisierung erlaubt, die Harness-Architektur unabhängig vom konkreten Modell zu verbessern – ähnlich wie Betriebssysteme von der Hardware abstrahieren.

Die Optimierung des Optimierers: Context Engineering

Je intelligenter die Modelle werden, desto wichtiger wird die Kunst, den Kontext zu gestalten. Einfach alle bisherigen Interaktionen aneinanderzureihen, funktioniert nur bis zu einer bestimmten Länge. Forscher sprechen von Context Engineering – dem gezielten Aufbereiten des Kontexts als ein sich entwickelndes Handbuch, nicht als endloses Prompt-Scrollen. Ein vielversprechender Ansatz heißt Agentic Context Engineering (ACE), entwickelt von Zhang und Kollegen 2025. ACE zerlegt die Aufgabe in drei Rollen: Ein Generator produziert Handlungsstränge, ein Reflector destilliert Erkenntnisse aus Erfolgen und Misserfolgen, und ein Curator aktualisiert den Kontext in strukturierten, nummerierten Bullet Points – schrittweise, dedupliziert, priorisiert. Das verhindert, dass das Modell den Faden verliert. ACE ist ein erster Schritt Richtung selbstverwaltendes Gedächtnis, aber die Update-Regeln sind noch von Menschen vorgegeben.

Der nächste Schritt heißt Meta Context Engineering (MCE), vorgestellt von Ye und Kollegen 2026. Hier wird nicht nur der konkrete Kontext optimiert, sondern die Methode, wie dieser Kontext erzeugt wird. Ein MCE-System lernt Skills – kleine Programme, die festlegen, welche statischen Komponenten und dynamischen Operatoren verwendet werden. In einer zweistufigen Optimierung sucht die innere Schleife den besten Kontext für eine Aufgabe, die äußere den besten Skill für eine ganze Aufgabenklasse. Das Ergebnis ist keine starre Regel, sondern eine sich selbst verbessernde Kontextfabrik – ein Schritt zur rekursiven Selbstverbesserung.

Die Meta-Ebene: Wenn der Harness sich selbst optimiert

Der radikalste Ansatz kommt von Lee und Kollegen 2026 mit dem Meta-Harness. Hier wird der gesamte Code des Harness zum Optimierungsziel. Ein Meta-Harness ist ein Werkzeug, das bessere Werkzeuge baut. Ein Coding-Agent bekommt die Aufgabe, einen neuen, besseren Harness für eine bestimmte Aufgabe zu entwickeln. Er startet Experimente, analysiert die Ergebnisse und generiert Code für neue Harness-Kandidaten. Die Ausführungshistorie bleibt im Dateisystem zugänglich, sodass der Agent mit Grep und Cat darauf zugreifen kann. Die Ausgabe ist eine Pareto-Front von Harness-Kandidaten mit unterschiedlichen Kompromissen zwischen Effizienz, Skalierbarkeit und Genauigkeit. Das zeigt eine klare Entwicklungslinie: Zuerst optimierten wir die Prompts, dann den Workflow, dann den Harness, dann den Optimierer. Mit jeder Ebene wird das System flexibler und passt sich an neue Anforderungen an, ohne dass ein Mensch jede Schraube neu justieren muss.

Was bedeutet das für die Zukunft?

Der Autor des Artikels zeichnet ein nüchternes Bild: Harness Engineering wird den Pfad zur rekursiven Selbstverbesserung in den nächsten Jahren wahrscheinlich stärker prägen als direkte Änderungen am Modell selbst. Das Modell, das seine eigenen Gewichte umschreibt, bleibt eine Vision. Der praktische Weg führt über die Optimierung der Umgebung: bessere Schleifen, schlauere Kontextverwaltung, selbstlernende Werkzeuge. Vorsicht vor Übertreibungen. Viele der heutigen Harness-Kniffe werden mit der Zeit in das Kernverhalten der Modelle einfließen – so wie frühere Prompt-Tricks durch verbessertes Instruction Tuning überflüssig wurden. Der Bedarf an einer Schnittstelle zur Außenwelt und an einem strukturierten Gedächtnis bleibt jedoch bestehen. Harness Engineering ist eine Brücke. Sie erlaubt, die wachsende Intelligenz der Modelle in geordnete Bahnen zu lenken, sie zu prüfen, zu korrigieren und zu skalieren – ohne den Überblick zu verlieren. Das ist handfeste Ingenieursarbeit, die gerade jetzt in den Laboren Gestalt annimmt.

Für Anwender: Die Werkzeuge von morgen sind heute als Entwürfe sichtbar. Wer versteht, wie ein Coding-Agent seinen Harness nutzt, versteht auch, warum manche KI-Ergebnisse brillant sind und andere scheitern. Nicht allein die Intelligenz des Modells zählt, sondern die Umgebung, in der es arbeitet. Diese Umgebung können wir gestalten.

Quelle: lilianweng.github.io

Ein KI-Modell bekommt eine knifflige Matheaufgabe. Es denkt nach, schreibt „Moment, lass mich nochmal nachdenken“ – und wiederholt diesen Satz. Und noch einmal. Bis der gesamte Textplatz mit dieser Zeile gefüllt ist. Forscher nennen das einen „Doom Loop“. Das Phänomen tritt vor allem bei kleineren Reasoning-Modellen auf, wenn sie an schwierigen Problemen arbeiten. Bisher halfen nur einfache Wiederholungsstrafen im Hintergrund. Das Team um Sam Paech von Liquid AI entwickelte eine präzisere Methode: Antidoom. Sie kombiniert eine Erkennung der Problemstelle mit einem speziell angepassten Training, das nur einen einzigen Token im Wörterbuch korrigiert. Die Schleifen werden drastisch reduziert, die Leistung verbessert sich.

Doom Loops entstehen durch drei ineinandergreifende Mechanismen. Erstens: Die ungleiche Verteilung von Wahrscheinlichkeiten im Vokabular. Manche Wörter – „overtrained tokens“ – sind durch das Training mit synthetischen Daten besonders wahrscheinlich geworden. Bei Reasoning-Modellen sind das oft Diskursmarker wie „Wait“ oder „Alternatively“. Sie sind nützlich, um Strategiewechsel anzuzeigen. Wenn das Modell unsicher ist, werden diese Tokens zu Ausweichrouten. Sie starten immer wieder dasselbe Denkmuster neu.

Zweitens: Eine sich selbst verstärkende Rückkopplung. Sobald ein Token wie „Wait“ auftaucht, steigt die Wahrscheinlichkeit für genau dieses Token weiter. Jede Wiederholung treibt die Wahrscheinlichkeit in Richtung 1. Forscher um Zenghao Duan zeigten, dass dabei ein V-förmiges Aufmerksamkeitsmuster entsteht: Die semantische Wiederholung – das Feststecken auf einer Idee – geht der textuellen Wiederholung voraus. Drittens: Greedy-Sampling. Reasoning-Modelle laufen oft bei sehr niedrigen Temperaturen, um stabile Ergebnisse zu liefern. Bei Temperatur 0 wird immer der wahrscheinlichste Token gewählt. Hat sich eine Schleife erst etabliert, gibt es keinen Ausweg. Selbst bei höheren Temperaturen bleibt die Wahrscheinlichkeit für den Schleifen-Token so dominant, dass Sampling kaum hilft. Die Forscher fanden signifikante Schleifen selbst bei Temperatur 0,67.

Das Antidoom-Team ging das Problem systematisch an. Sie generierten eine große Menge von Antworten auf einen speziell entwickelten Mix aus anspruchsvollen Prompt-Aufgaben (LiquidAI/antidoom-mix-v1.0) bei niedriger Temperatur. Dann suchten sie nach Mustern, die mindestens viermal hintereinander über 60 Zeichen wiederholt wurden. Diese Kriterien vermeiden falsche Alarme und übersehene Fälle. Für jede gefundene Schleife identifizierten sie den ersten Token der ersten Wiederholung. An dieser Position griffen sie auf die Log-Wahrscheinlichkeiten des Basis-Modells zu, sammelten die Top-Alternativen und filterten kurze oder nicht-alphanumerische Rauscher heraus. Übrig blieben bis zu 20 plausible Ersatztoken, die als „chosen tokens“ in das Training einflossen. Jeder Trainingsdatensatz bestand aus einem Prompt-Präfix, einem abgelehnten Token (dem Beginn der Schleife) und einem oder mehreren gewählten Alternativ-Token.

Die Forscher regularisierten die Verteilungen vor dem Training. Einige häufige Schleifen-Übeltäter wie „Wait“, „So“ oder „the“ würden sonst übermäßig unterdrückt und die Reasoning-Fähigkeiten beschädigen. Die Trainingsmethode heißt „Final Token Preference Optimization“ (FTPO), eine Weiterentwicklung von Direct Preference Optimization (DPO). FTPO nimmt nur gezielte Veränderungen an wenigen Token der Verteilung vor. Es unterscheidet sich von DPO in vier Punkten: Erstens wird nur der letzte Token einer Sequenz trainiert, die sich mitten in der Generierung befindet. Zweitens erlaubt es mehrere gewählte Token pro Probe, sodass die Wahrscheinlichkeit auf eine Gruppe von Alternativen verteilt wird. Drittens verwendet es einen KL-ähnlichen Verlust, der direkt im Logit-Raum arbeitet und Gradientendruck auf nicht betroffene Token vermeidet. Viertens gibt es eine zweiteilige Regularisierung: Die Logits der trainierten Token dürfen sich stärker vom Referenzmodell entfernen, während der Rest des Vokabulars stärker eingeschränkt bleibt. Das verbessert die Lernbarkeit, ohne die Gesamtverteilung zu stören.

In der Praxis wird Antidoom in der Regel für eine Epoche mit LoRA trainiert – das passt nur wenige zusätzliche Parameter an. Hohe LoRA-Ränge (128 bis 256) liefern die besten Ergebnisse: mehr Lernfähigkeit bei weniger Verschlechterung. Die Forscher trainierten auf allen Aufmerksamkeits- und MLP-Projektionen sowie auf dem Sprachkopf. Die optimalen Lernraten lagen zwischen 4e-6 und 2e-5. Übermäßiges Training schadet. Daher brachen sie das Training frühzeitig ab, sobald ein bestimmtes Maß erreicht war (chosen_win=0,35). Die Doom-Loop-Rate sank von 20–30 % auf 1–2 % bei minimalen Nebenwirkungen. Längeres Training riskierte neue Schleifen an anderen Stellen im Vokabular.

Die Ergebnisse: Bei einem frühen Checkpoint von LFM2.5-2.6B – einem Reasoning-Modell mit 2,6 Milliarden Parametern – fiel die Doom-Loop-Rate von 10,2 % auf 1,4 %. Die Bewertungsergebnisse in Mathematik und Programmierung verbesserten sich durchweg, allein durch die Beseitigung der Schleifen. Das Modell lernte nichts Neues über die Aufgaben; es konnte endlich abrufen, was es schon wusste. Bei Qwen3.5-4B (4 Milliarden Parameter) sank die Doom-Loop-Rate von 22,9 % auf 1 % unter Greedy-Sampling, auch hier stiegen die Evaluierungswerte. Ein Nebeneffekt: Nach dem Antidoom-Training schnitten die Modelle bei niedrigen Temperaturen besser ab, während die Leistung bei Temperatur 1 leicht abfiel. Das widerlegt die Annahme, dass höhere Temperaturen für Reasoning-Modelle grundsätzlich besser seien. Vermutlich hatten die Doom Loops bei niedrigen Temperaturen die Ergebnisse verfälscht.

In der Praxis kann Antidoom in mehreren Runden angewendet werden. Nach der ersten Runde sinkt die Zahl der Schleifen drastisch, aber es können neue Problemstellen auftauchen. Eine zweite Runde zielt auf diese neuen Fehler. Die Forscher räumen ein, dass Overfitting eine Gefahr ist und das Training sorgfältig überwacht werden muss. Die Methode ist effizient: Die Erstellung des Trainingsdatensatzes für ein Modell wie LFM2.5-2.6B dauert etwa eine Stunde auf 8 GPUs, das eigentliche Training eine bis zwei Stunden auf einer einzigen GPU. Der gesamte Code ist auf GitHub verfügbar.

Wenn du ein Reasoning-Modell genutzt hast, das sich in sinnlosen Wiederholungen verfing, weißt du, wie das ist. Antidoom ist kein Allheilmittel, aber es zeigt, dass man mit einem präzisen Skalpell arbeiten kann. Statt die gesamte Wahrscheinlichkeitsverteilung zu bestrafen, greift es genau an der Stelle ein, die das Problem verursacht. Das verbessert die Effizienz von KI-Modellen, ohne ihre Kreativität zu ersticken. Ob diese Methode auf andere Degenerationsformen übertragbar ist oder den Anfang einer Familie von Reparaturverfahren darstellt, bleibt abzuwarten.

Quelle: liquid.ai

Du hast ein Kommandozeilen-Tool entwickelt, das die tägliche Arbeit erleichtert. Jemand schlägt vor, die Eingabe für KI-Agenten zu optimieren – alles in einen einzigen --json-Block packen, weil Maschinen strukturierte Daten lieben. Klingt plausibel. Waldek Mastykarz, Principal Developer Advocate bei Microsoft, hat diese Annahme getestet. Er wollte wissen, ob der Wechsel von klassischen Argumenten zu JSON wirklich Vorteile bringt. Das Messergebnis ist eindeutig – und überrascht viele.

Der Ansatz hinter JSON

Die Argumentation der Befürworter ist nachvollziehbar: KI-Agenten denken in hierarchischen Strukturen. JSON bildet tiefe Verschachtelungen natürlich ab, während flache Argumente mit mehrfach auftretenden Flags wie --service-name schnell mehrdeutig werden. Der Agent muss mühsam lernen, welcher Wert zu welchem Block gehört. Ein einzelner JSON-Payload verspricht klare Hierarchien: Jedes Service-Objekt steht für sich, Ressourcen sind logisch gruppiert – kein Ratespiel. So elegant die Theorie klingt, die Praxis zeigt etwas anderes.

Waldek Mastykarz hat ein Experiment entworfen, um die Behauptung zu prüfen. Er baute ein synthetisches CLI namens podctl, das ein komplexes Multi-Service-Deployment erzeugt – mit zwei Diensten, drei Verschachtelungsebenen, Arrays, gemischten Typen und Querverweisen. Insgesamt über 30 Einzelwerte. Eine Version des CLIs akzeptiert nur traditionelle Argumente (Flags), die andere nur einen --json-Payload. Beide nutzen denselben Validierungs-Backend und normalisieren zur gleichen kanonischen Struktur. Der Agent kennt das Tool nicht und muss es über die Hilfe entdecken. Fünf gängige Modelle wurden jeweils fünfmal pro Eingabemodus getestet – von Claude Haiku 4.5 bis GPT-5.3-Codex, mit GitHub Copilot Chat als Rahmen.

Die Ergebnisse: Args gewinnen durchgehend

Jedes Modell erreichte mit den klassischen Argumenten eine perfekte Korrektheit in allen fünf Läufen. Selbst das kleinste Modell, Claude Haiku 4.5, erzeugte zuverlässig korrekte Deployments. Bei der JSON-Variante sah es anders aus: Die drei stärksten Modelle hielten mit 5/5 mit, aber die beiden kleineren Modelle fielen ab. Haiku 4.5 schaffte nur 2 von 5 korrekten Aufgaben, MAI-Code-1-Flash immerhin 3 von 5. Argumente begrenzen den Eingaberaum so stark, dass auch schwächere Modelle konsistent korrekte Ausgaben liefern. JSON zwingt das Modell, seine eigene Struktur zu verwalten – eine Fähigkeit, die nicht jedes Modell beherrscht. Der Unterschied liegt in den Randbedingungen beim Generieren.

Noch deutlicher fällt der Kostenvergleich aus. Entwickler bezahlen für Token, nicht für Versuche. Waldek Mastykarz hat den Token-Verbrauch pro Aufgabe detailliert aufgeschlüsselt – Input, gecachte und Output-Token – und mit den Preisen der GitHub-Modelle multipliziert. Das Ergebnis: JSON-Modus kostete 4- bis 11-mal mehr pro Aufgabe als der Args-Modus – je nach Modell. Der rohe Token-Abstand war noch größer (4- bis 14-mal), aber Caching mildert die Wirkung etwas. Caching hilft nicht bei den Output-Token. Bei JSON führt das zu vielen Neuversuchen. Liest das CLI die JSON-Struktur nicht, analysiert der Agent den Fehler, baut einen neuen Payload und startet einen neuen Versuch. Diese Versuche werden kreativ: Piping durch Variablen, Schreiben in temporäre Dateien, verschiedene Escaping-Strategien. All das sind Output-Token – die teuerste Kategorie.

Das Problem mit Shell-Escaping

Die reinen Tokenkosten sind nicht alles. Ein oft übersehener Faktor beim JSON-Umstieg ist das Shell-Escaping. Wenn der Agent einen JSON-Payload auf der Kommandozeile übergibt, muss er die Anführungszeichen für die Shell maskieren. Verschiedene Shells haben unterschiedliche Regeln für verschachtelte Strings, keine ist trivial. Die Modelle produzierten regelmäßig valides JSON, das dann an der Shell scheiterte: doppelte Anführungszeichen in einfachen Anführungszeichen, Escaping, das die Shell anders interpretierte als beabsichtigt. Die Fehler von Haiku 4.5 bei JSON zeigen das Problem besonders deutlich: Drei von fünf Aufrufen erreichten nie eine erfolgreiche Ausführung. Der Agent erzeugte korrekte JSON-Inhalte, kam aber nicht durch die Shell. Er versuchte Base64-Kodierung, Piping, Here-Strings, cmd.exe-Durchleitung – alles vergebens. Die Token wurden verbrannt, ohne dass je ein gültiger Befehl zustande kam.

Um den Einfluss der Shell zu prüfen, führte Waldek Mastykarz denselben Test mit Claude Sonnet 4.6 auf macOS durch, wo standardmäßig Bash läuft. Auf PowerShell betrug der Kostenunterschied zwischen Args und JSON das 9-Fache. Auf Bash schrumpfte er auf das 1,5-Fache. Gleiches Modell, gleicher Payload, gleiche Korrektheit. Der Unterschied lag allein in der Art, wie jede Shell mit zitierten JSON-Strings umgeht. Args verhielten sich stabil über beide Shells hinweg: 0,05 $ auf PowerShell vs. 0,07 $ auf Bash. JSON führt eine Abhängigkeit vom Shell-Zitierverhalten ein, die je nach Umgebung stark variiert. Argumente tun das nicht.

Warum Einschränkungen dem Agenten helfen

Die Daten zeigen einen kognitiven Effekt von Einschränkungen. Bei Args legt der Hilfetext fest, welche Eingaben gültig sind. Jede Option hat einen Namen und einen Typ, manchmal eine Aufzählung erlaubter Werte. Das Modell muss von der Aufgabenbeschreibung auf konkrete Optionsnamen und Werte abbilden. Bei JSON erhält das Modell ein Schema (oder leitet es aus der Hilfe ab) und muss ein freies Objekt konstruieren, das diesem Schema genügt. Die Syntax muss gültig sein, die Verschachtelung korrekt, die Feldnamen und Typen müssen passen – und das Ganze muss das Shell-Escaping überleben. Jeder Punkt ist eine Fehlerquelle. Args vermeiden diese Fehlerquellen von vornherein. Stärkere Modelle lösen die JSON-Aufgabe irgendwann, aber mit Aufwand: Sie leisten sich Shell-Fehler, die sie dann reparieren müssen. Diese Reparatur kostet 4- bis 11-mal mehr als der Args-Pfad, selbst wenn die endgültige Korrektheit identisch ist. Kleinere Modelle scheitern an denselben Hürden und können sie nicht überwinden – dort sinkt die Korrektheit drastisch.

Die Einschränkung des gültigen Eingaberaums gleicht Modellschwächen aus. Das Modell muss kein korrekt verschachteltes JSON erzeugen, weil es gar kein JSON gibt. Es muss keine Shell-Zitierung beherrschen, weil die Argumente ohne Zitierung auskommen. Der kognitive Aufwand sinkt auf das Wesentliche: die Zuordnung von Werten zu Parametern. Selbst die kleinsten getesteten Modelle lösen das zuverlässig.

Was das für dein CLI bedeutet

Wenn du ein CLI baust, das auch von KI-Agenten verwendet werden soll, weisen die Daten in eine klare Richtung: Ersetze deine Argumente nicht durch einen --json-Payload. Behalte die klassischen Args. Sie funktionieren über das gesamte Modellspektrum hinweg, haben keine umgebungsabhängigen Fehlermodi und kosten weniger Token – und damit weniger Geld. Du darfst zusätzlich eine --json-Option anbieten, etwa für programmatische Batch-Aufrufe oder manuelle Nutzung. Aber entferne die Args nicht zugunsten von JSON, und erwarte nicht, dass JSON die Agentenerfahrung verbessert. In diesem Experiment hat JSON die Korrektheit nie erhöht und die Kosten immer gesteigert.

Die intuitive Annahme, dass JSON die Arbeit von Agenten erleichtert, ist auf dem Papier nachvollziehbar. In der Realität – mit tatsächlichen Modellen, die in tatsächlichen Shells auf tatsächlichen Betriebssystemen laufen – hält sie nicht stand. Args sind eingeschränkt und vorhersagbar über Shells hinweg. JSON ist ausdrucksstark, aber zerbrechlich. Für den agentengesteuerten CLI-Einsatz gewinnt das Eingeschränkte.

Waldek Mastykarz gibt eine praktische Empfehlung: Bevor du eine solche Änderung vornimmst, miss nach. Wähle ein Szenario, definiere Bewertungskriterien, wähle das für deine Zielgruppe relevante Modell und Betriebssystem, und führe ein paar Durchläufe mit beiden Ansätzen durch. Nach einem Tag hast du eine Antwort, ohne etwas umschreiben zu müssen, das du gar nicht umschreiben musstest. Die Lektion: Plausible Annahmen und gemessene Ergebnisse sind zwei verschiedene Dinge. Wenn sie auseinanderklaffen, haben die Ergebnisse recht.

Du musst dein bewährtes CLI nicht für Agenten umkrempeln. Es ist gut genug. Wenn du Zweifel hast, mach den Test. Die Antwort wird dich beruhigen – und dein Budget freut sich auch.

Quelle: developer.microsoft.com