Ihre KI-Agenten haben kein Speicherproblem. Sie haben ein Auswahlproblem

@eng_khairallah1
ENGLISCHvor 4 Wochen · 17. Juni 2026
427K
257
28
67
480

TL;DR

KI-Agenten scheitern bei komplexen Aufgaben, da große Kontextfenster zu kumulativen Fehlern und Rauschen fĂŒhren. Dieser Artikel argumentiert, dass der eigentliche Engpass die Auswahl ist – also die Entscheidung, worauf das Modell achten sollte – und nicht die reine SpeicherkapazitĂ€t.

Wir haben Agenten eine Million Tokens in den Kontext gegeben, aber sie funktionieren immer noch nicht.

Speicher dir das :)

Du gibst einem leistungsfĂ€higen Modell ein paar Werkzeuge und eine lange Aufgabe. In den ersten fĂŒnfzehn Schritten ist es brillant. Fokussiert und prĂ€zise. Beantwortet die Fragen und befragt den Nutzer grĂŒndlich.

Doch sobald die GesprĂ€che an Umfang zunehmen, fĂ€ngt der Agent an abzudriften. Er beginnt, seinen eigenen Entscheidungen von vor zehn Schritten zu widersprechen. Er verschmutzt das Kontextfenster mit erfundenen Informationen. Er weiß, dass es Benutzereinstellungen gibt, kann sie aber nicht zuverlĂ€ssig abrufen. Und du versuchst verzweifelt herauszufinden, warum etwas schiefgelaufen ist.

Also greifst du nach mehr. Einem Modell mit einem grĂ¶ĂŸeren Kontextfenster, um die Aufgabe lĂ€nger zu halten. Du versuchst, die RAG-Pipeline zu optimieren. Durchsuchst das Internet nach Agent-GedĂ€chtnis-Lösungen.

Und nichts funktioniert so, wie du es erwartest.

Das VerstĂ€ndnis des „Warum“ dahinter fĂŒhrt uns direkt zu der wertvollsten, am wenigsten verstandenen Schicht im gesamten Agentenstapel.

Der Fehler ist eine Schleife

Der Grund, warum Agenten nachlassen, ist kein Mangel an FĂ€higkeiten. Es ist eine RĂŒckkopplungsschleife, und sie hat vier Glieder. Sobald du alle vier siehst, wirken die ĂŒblichen Lösungen nicht mehr wie Lösungen.

Khairallah AL-Awady - inline image

Glied eins: Ein Modell kann seinen gesamten Kontext nicht gleichmĂ€ĂŸig nutzen, und das wird schlimmer, je mehr Kontext hineingepackt wird.

Das ist der Teil, den die meisten nie verinnerlichen. Die FĂ€higkeit eines Modells, Informationen zu nutzen, ist nicht gleichmĂ€ĂŸig ĂŒber sein Kontextfenster verteilt. Modelle nutzen zuverlĂ€ssig das, was ganz am Anfang und ganz am Ende steht, und sie schenken der Mitte systematisch weniger Aufmerksamkeit, selbst wenn sie speziell fĂŒr lange Eingaben gebaut wurden. Pack mehr hinein, und die ZuverlĂ€ssigkeit sinkt weiter. Das zeigt sich sogar bei trivialen Aufgaben wie dem Wiederholen einer Liste von Wörtern. FĂŒge einen einzigen Störfaktor hinzu, und die Leistung sinkt messbar. FĂŒge mehrere zusammenhĂ€ngende Dinge hinzu – noch schlimmer.

Der effektive Kontext, also der Teil, ĂŒber den das Modell tatsĂ€chlich zuverlĂ€ssig nachdenken kann, ist also viel kleiner als die Zahl auf der Verpackung. Und er schrumpft, je mehr du hineinstopfst.

Denk jetzt darĂŒber nach, was ein Agent tut. Er hĂ€uft an. Jedes Tool-Ergebnis, jeder Schritt der Geschichte, jede Notiz an sich selbst wird an den Kontext angehĂ€ngt. Das bedeutet, der Agent senkt stetig die QualitĂ€t jedes einzelnen Schrittes, den er unternimmt. Der wachsende Kontext produziert Schritt-fĂŒr-Schritt-Fehler.

Glied zwei: Diese Schritt-fĂŒr-Schritt-Fehler addieren sich nicht. Sie multiplizieren sich.

Ein kleiner Schrittfehler wĂ€re in Ordnung, wenn Agenten nur eine Handvoll Schritte machen wĂŒrden. Sie machen Dutzende. Und die Fehler potenzieren sich, statt sich zu summieren. Ein Agent, der bei fĂŒnf Schritten zu 95 Prozent zuverlĂ€ssig ist, bleibt bei einer Aufgabe mit 20 Schritten nicht zu 95 Prozent zuverlĂ€ssig. FĂŒhre genug Schritte aus, und du nĂ€herst dich immer mehr einem MĂŒnzwurf an.

Es ist noch schlimmer, weil sich die Fehler selbst verstĂ€rken. Ein Tool-Aufruf, der leicht von der Spur abkommt, macht den nĂ€chsten noch wahrscheinlicher, dass er ebenfalls abweicht. Kombiniere das mit Glied eins, wo die grundlegende Fehlerrate selbst steigt, wĂ€hrend das Fenster voller wird, und du erhĂ€ltst die charakteristische Fehlerart von Langzeit-Agenten. Sie verschlechtern sich nicht allmĂ€hlich. Sie halten durch und dann stĂŒrzen sie plötzlich ab.

Glied drei: Die Aufgabe ist lang, das Modell ist zustandslos, also legst du den Zustand außerhalb des Modells ab.

Sprachmodelle behalten nichts zwischen den Aufrufen. Jeder Aufruf beginnt von Null. Das einzige, was ein Modell weiß, ist das, was du ihm wieder zufĂŒhrst. FĂŒr jede lange Aufgabe musst du den Zustand also externalisieren. Notizblöcke. Fortschrittsdateien. PrĂŒfpunkte. Vektorspeicher. Dedizierte GedĂ€chtnisschichten, die Fakten extrahieren und sitzungsĂŒbergreifend wieder bereitstellen.

Das ist richtig und notwendig. Und es sieht nach einer sauberen Lösung aus. Der Agent vergisst nichts Wichtiges, weil alles Wichtige in einem dauerhaften Speicher lebt.

Glied vier: Gespeichertes GedĂ€chtnis ist trĂ€ge, und es zurĂŒckzuholen fĂŒttert genau das Problem, das es lösen sollte.

Hier schließt sich die Schleife. Ein Modell kann nicht ĂŒber eine Datenbank nachdenken. Es kann nur ĂŒber das nachdenken, was in seinem Kontextfenster ist. GedĂ€chtnis hilft also nur in dem Moment, in dem es zurĂŒckgeholt wird. Und jeder Abruf fĂŒgt Tokens hinzu. Jede Zusammenfassung, die der Agent schreibt, um den Fortschritt zu verfolgen, ist ein Token, den er spĂ€ter erneut lesen muss. Jeder Komprimierungsschritt, der die Geschichte verdichtet, um Platz zu schaffen, ist verlustbehaftet, und das Detail, das er wegwirft, ist oft das subtile, dessen Bedeutung erst spĂ€ter klar wird.

Das GedĂ€chtnissystem, das du gebaut hast, um die Kontextbegrenzung zu ĂŒberwinden, fĂŒttert diese also letztlich. Mehr GedĂ€chtnis bedeutet mehr Abruf, was mehr Rauschen im Fenster bedeutet, was mehr Schritt-fĂŒr-Schritt-Fehler bedeutet, die sich potenzieren – genau das, warum du ĂŒberhaupt nach GedĂ€chtnis gesucht hast.

Die Schleife ist real. Und es ist ihr egal, wie groß dein Kontextfenster ist.

KapazitÀt war nie die entscheidende Achse

Sobald du die Schleife siehst, wird die Sinnlosigkeit der ĂŒblichen Lösungen offensichtlich.

Khairallah AL-Awady - inline image

Ein grĂ¶ĂŸeres Kontextfenster durchbricht sie nicht. Es erhöht nur die Obergrenze dafĂŒr, wie viel Verfall sich ansammeln kann, bevor der Absturz kommt. WĂ€hrenddessen zeigt jede Studie zum effektiven Kontext immer wieder dasselbe: Der zuverlĂ€ssig nutzbare Anteil wĂ€chst viel langsamer als die angegebene Zahl. Du kaufst KapazitĂ€t, die du nicht wirklich nutzen kannst.

Mehr GedÀchtnis durchbricht sie nicht. Es erhöht die Menge an Material, das darum konkurriert, wieder in ein Fenster einzutreten, das ohnehin schon nicht alles enthalten kann.

Auch die nĂ€chste Architektur wird sie nicht durchbrechen. Die Herausforderer, die gegen Attention antreten – State-Space-Modelle wie Mamba und seine Hybriden – gewinnen, indem sie die Vergangenheit in einen festen Zustand komprimieren, anstatt jedes Token adressierbar zu halten. Das bringt lineare Inferenzzeit und einen Speicherverbrauch, der nicht mit der SequenzlĂ€nge wĂ€chst. Es kann keine Erinnerung erkaufen. Ein fester Zustand kann nicht alles halten, also vergisst er mit Absicht. Im großen Maßstab hinken reine State-Space-Modelle bei genau dem hinter Transformern her, wofĂŒr externes GedĂ€chtnis existiert: ein bestimmtes Faktum von einem beliebigen Punkt frĂŒher in der Sequenz zurĂŒckzuholen. Deshalb sind die ernsthaften Post-Attention-BemĂŒhungen Hybriden, die eine Minderheit von Attention-Layern behalten, um das Abrufen zu ermöglichen, das ein State-Modell nicht kann. Die Mauer verschiebt sich nicht, wenn du die Architektur Ă€nderst. Du erreichst sie nur von der anderen Seite.

Die Lektion ist also nicht „nimm eine grĂ¶ĂŸere Zahl“. Sondern dass KapazitĂ€t nie der begrenzende Faktor war.

Der begrenzende Faktor ist die QualitĂ€t der Entscheidung darĂŒber, welche Tokens das Fenster zu jedem Schritt besetzen.

Das ist das ganze Spiel. Nicht der grĂ¶ĂŸte verfĂŒgbare Kontext, sondern der kleinste ausreichende. Relevanz statt Abruf. Bewusstes Vergessen als erstklassige Operation statt als Unfall durch Abschneiden. Die Forschung unterstĂŒtzt dies direkt: Das ordnungserhaltende Abrufen einiger tausend gut ausgewĂ€hlter Tokens schlĂ€gt das Auskippen eines vollen 128K-Fensters in das Modell. Der Vorteil liegt darin, was hereinkommt, nicht darin, wie viel.

Und das ist die Falle, in die die meisten Teams tappen, weil das Werkzeug, zu dem sie greifen, um die Auswahl zu treffen, die falsche Form hat.

Ähnlichkeit ist nicht Relevanz

Die Standardmethode, um zu entscheiden, welchen Kontext man zurĂŒckholt, ist die Ähnlichkeitssuche. Embedde alles, und wenn der Agent Kontext braucht, rufe die Vektoren ab, die der aktuellen Abfrage am nĂ€chsten sind.

Aber Ähnlichkeit beantwortet die falsche Frage. Sie gibt zurĂŒck, was nah ist, nicht was relevant ist. Und das sind zwei sehr unterschiedliche Dinge.

Die Frage, die ein Agent tatsĂ€chlich beantworten muss, ist niemals „Was ist dem Ă€hnlich.“ Es ist „Was ist bei dieser Aufgabe und diesem Zustand jetzt wichtig und hĂ€ngt damit zusammen.“ Das ist eine relationale Frage. Es geht um AbhĂ€ngigkeiten, Herkunft, was was ersetzt hat und welche Entscheidung zu welchem Ergebnis gefĂŒhrt hat. Ein Speicher, der darauf ausgelegt ist, Ă€hnliche Vektoren zu liefern, gibt dem Modell einen Haufen Beinahe-Treffer. Und Beinahe-Treffer sind genau die Störfaktoren aus Glied eins – diejenigen, die den Schritt-fĂŒr-Schritt-Fehler antreiben, der sich zum Absturz multipliziert.

Deshalb kann die Lösung kein dĂŒnner Cache vor einem Embedding-Speicher sein. Die Intelligenz liegt nicht im Nachschlagen. Sie liegt in der Struktur.

Die Schicht, die niemand einpreist

Die wichtigste Schicht im Agentenstapel ist nicht das Modell und nicht der Speicher. Es ist die Schicht dazwischen. Diejenige, die entscheidet, worauf das Modell achtet.

Khairallah AL-Awady - inline image

Und um diese Aufgabe tatsĂ€chlich zu erfĂŒllen, muss sie drei Dinge sein.

Sie muss neutral sein. Die Interna Ă€ndern sich stĂ€ndig unter den FĂŒĂŸen aller. Von Transformer zu State Space zu Hybrid. Ein Frontier-Modell nach dem nĂ€chsten, mit einem neuen Preis-Leistungs-FĂŒhrer alle paar Monate. Eine Kontextstrategie, die an ein einzelnes Modell geschweißt ist, ist eine Wette auf ein sich bewegendes Ziel. Das, worin deine Organisation tatsĂ€chlich Wert anhĂ€uft, ist ihr Kontext – die mĂŒhsam erarbeitete strukturierte Aufzeichnung dessen, was deine Agenten wissen und getan haben. Kette das an die GedĂ€chtnisfunktionen eines einzigen Anbieters, und du machst dein wertvollstes Asset zur Geisel einer Roadmap, die nicht deine ist. Eine Auswahlschicht, die außerhalb jedes einzelnen Modells lebt, lĂ€sst denselben organisierten Kontext fĂŒr jedes Modell dienen, das du betreibst – und fĂŒr das nĂ€chste, das du noch nicht ĂŒbernommen hast.

Sie muss horizontal sein. Ein Framework-PrĂŒfpunkt weiß von einem Durchlauf. Der eingebaute Speicher eines Modells weiß von den GesprĂ€chen eines Modells. Ein Vektorindex weiß von einem Korpus. Keiner von ihnen hat das Bild, das tatsĂ€chlich zĂ€hlt, sobald du echte Workloads betreibst: viele Agenten, viele Sitzungen, viele Modelle, die alle eine kohĂ€rente, abfragbare Sicht auf den Kontext brauchen. Diese System-of-Record-Rolle ist etwas, fĂŒr das eine App, ein Framework oder ein Labor nicht gemacht ist, weil jeder nur seinen eigenen Ausschnitt sieht. Es ist eine eigene Schicht, die horizontal ĂŒber all ihnen liegt.

Sie muss strukturiert sein. Das unterscheidet sie von „nur einer besseren Datenbank.“ Auswahl ist ein Relevanzproblem, und Relevanz ist relational. Struktur ĂŒber den Kontext – die Beziehungen und AbhĂ€ngigkeiten, Herkunft und Ablösung – macht aus dem Abruf eine Auswahl. Das ist ein grundlegend anderer Baustein als Speicherung, und es ist der, den die Schleife erfordert.

„Werden die Labs das nicht einfach ausliefern?“

Der naheliegende Einwand ist, dass die Modell-Labs das absorbieren werden. Sie liefern stÀndig GedÀchtnis- und Kontextfunktionen aus, und sie haben privilegierten Zugriff auf die eigene Attention des Modells.

Das werden sie, und der Einwand ist zur HĂ€lfte richtig. FĂŒr ein einzelnes Modell, das eine einzelne App umschließt, reicht es oft, wenn das Labor das ĂŒbernimmt. Das ist in Ordnung.

Aber der Anreiz der Labs ist, ihr eigenes Modell klebriger zu machen. Das ist das Gegenteil von PortabilitĂ€t. Eine Zusammenstellung, die mit den Interna eines Modells verschmolzen ist, kann nicht den Multi-Modell-, organisationsweiten Fall bedienen. Ein echter Kontext-Grundstoff konkurriert nicht direkt mit diesen Funktionen. Er existiert fĂŒr die Situation, der die Labs strukturell nicht geneigt sind zu dienen: die, in der du mehrere Modelle ĂŒber viele Agenten und Teams hinweg betreibst und dich weigerst, die Schicht, die entscheidet, worĂŒber deine Agenten nachdenken, dem Anbieter zu ĂŒberlassen, dessen Modell sie gerade zufĂ€llig ausfĂŒhren.

Und der Trend verschÀrft das nur. Je leistungsfÀhiger die Modelle werden, desto mehr werden sie genutzt. Je mehr sie genutzt werden, desto mehr Agenten betreibt eine Organisation. Je mehr Agenten sie betreibt, desto wertvoller ist eine neutrale, horizontale, strukturierte Auswahlschicht.

Wer baut das?

Hier kommt Hydradb ins Spiel. Neutral, horizontal und strukturiert. Es hĂ€lt die Beziehungen, AbhĂ€ngigkeiten, Herkunft und Ablösung, die die Ähnlichkeitssuche einebnet. Es ist zeitlich versioniert und prĂ€ferenzbewusst und weiß daher nicht nur, was wahr ist, sondern was es ersetzt hat. Es schafft Transparenz darĂŒber, was ein bestimmter Agent im Laufe der Zeit gelernt hat. Diese Struktur ist es, die den Abruf in eine Auswahl verwandelt.

Darunter lĂ€uft HydraDB auf abgestuften Speichern: einem heißen In-Memory-Cache fĂŒr aktiven Kontext, NVMe fĂŒr warmen, Objektspeicher fĂŒr kalten. Kontext wird nach AktualitĂ€t und Wichtigkeit hoch- und heruntergestuft, sodass der Arbeitssatz, ĂŒber den das Modell nachdenkt, mit Absicht klein bleibt. Zwischen dem Modell und allem, was es wissen könnte.

Die Frage, die jeder Agent beantworten muss

Streif die Architekturdebatten ab, die GedĂ€chtnisprodukte, das WettrĂŒsten der Kontextfenster. Darunter beantwortet jeder langlebige Agent bei jedem Schritt dieselbe Frage.

Von allem, was es weiß – worĂŒber sollte es gerade jetzt nachdenken?

Ein grĂ¶ĂŸeres Fenster beantwortet das nicht. Es gibt dem Agenten nur mehr zu ignorieren. Die Schleife ist real, sie ist dauerhaft, und keine Menge an KapazitĂ€t schließt sie.

Die Branche versucht immer noch, sich mit KapazitÀt freizukaufen. Das wird nicht funktionieren. Die Teams, die verinnerlichen, dass es immer ein Auswahlproblem war, werden Agenten ausliefern, die funktionieren, wÀhrend alle anderen Agenten ausliefern, die es fast tun.

Das war nie eine reine EinschrĂ€nkung der Modelle. Alles, was unter einem begrenzten Budget arbeitet, muss auswĂ€hlen, worauf es achtet. Auswahl ist kein Workaround fĂŒr heutige Grenzen. Es ist das, was Nachdenken unter Grenzen schon immer erforderte.

Wenn dir das gefallen hat, folge mir @eng_khairallah1 fĂŒr weitere KI-Inhalte dieser Art. Ich poste wöchentlich Analysen, Kurse und Tools.

hoffe das war hilfreich fĂŒr dich, Khairallah ❀

Mit einem Klick speichern

Virale Artikel mit YouMind per KI tief lesen

Speichere die Quelle, stelle gezielte Fragen, fasse die Argumentation zusammen und verwandle einen viralen Artikel in wiederverwendbare Notizen in einem einzigen KI-Arbeitsbereich.

YouMind entdecken
FĂŒr Creator

Verwandle dein Markdown in einen sauberen 𝕏-Artikel

Wenn du eigene Langtexte veröffentlichst, wird die 𝕏-Formatierung von Bildern, Tabellen und Codeblöcken mĂŒhsam. YouMind macht aus einem ganzen Markdown-Entwurf einen sauberen, sofort postbaren 𝕏-Artikel.

Markdown zu 𝕏 testen

Mehr Muster zum EntschlĂŒsseln

Aktuelle virale Artikel

Mehr virale Artikel entdecken