Memory Engineering: Warum Kontextfenster kein Gedächtnis sind

X-Postwast3Meinung

Ein Entwickler stellt eine speicherbasierte Architektur für Kimi K3 vor, die Vektordatenbanken und riesige Kontextfenster durch ein Vier-Knoten-Modell mit automatischem Verfall ersetzt. Statt Informationen unbegrenzt aufzubewahren, müssen Fakten ihre Relevanz durch tatsächliche Weiternutzung verdienen.

Das Wichtigste

  1. Große Kontextfenster wie das 1M-Token-Fenster von Kimi K3 leeren sich bei jeder Sitzung und stellen kein persistentes Gedächtnis dar.
  2. Vektordatenbanken liefern Ergebnisse auf Basis von Ähnlichkeit, nicht nach Richtigkeit oder Nutzen; in einem Testlauf mit 90.000 Fakten wurden 71.000 nie aktiv gebraucht.
  3. Das vorgestellte System nutzt vier Knoten: WRITER (speichert Fakten mit Begründung), DECAY (lässt ungenutzte Daten verfallen), RENEWER (verlängert nur aktiv genutzte Fakten) und GRAVE (archiviert gelöschte Fakten zur Analyse).
  4. Kimi-spezifische Bausteine für Memory Engineering umfassen Skills (persistierte Arbeitsabläufe in Markdown), Constraint-Dateien (dokumentierte frühere Fehler) und Kontextgraphen für Beziehungen zwischen Entitäten.
  5. Daten aus dem Kontextgraphen von Kimi Agent Swarm lassen sich in Markdown mit Wikilinks exportieren und in Obsidian visualisieren.

Warum das relevant ist

Das bloße Erhöhen von Kontextfenstern oder das Auffüllen riesiger Vektor-Datenbanken führt oft zu hohen Kosten und veraltetem Ballast bei Agenten. Ein Ansatz, der auf kontrolliertem Informationsverfall, Fehlerprotokollen und persistierten Workflows basiert, trennt nutzbare Essenz von ungenutztem Rauschen.

Einordnung

wast3 argumentiert gegen den Ansatz, das Kontextfenster oder reine Vektor-Ähnlichkeitssuchen als Gedächtnis zu betrachten. Standard-Vektorabfragen gewichten irrelevante oder veraltete Daten oft genauso stark wie essenzielle Vorgaben. Durch den Einsatz von Verfallsregeln und strukturierten Artefakten – wie dokumentierten Constraints und Graph-Beziehungen – lässt sich das Verhalten von KI-Agenten über Sitzungen hinweg gezielter steuern, ohne den Kontext mit Rohdaten zu überfrachten.

Original-Post

wast3

@0xWast3 · 28. August 2026

Engineer runs a Kimi K3 memory layer that costs $11 a month and remembers what a $500,000 vector database keeps losing. No embeddings. Four nodes and one rule about what's allowed to be forgotten. He published the whole schema. His version starts from the opposite idea. Memory t.co/bsVCiPV70Z t.co/yGHpe9lBU2

442 Likes23 Antworten697 Lesezeichen67.060 Aufrufe

Auf X ansehen
Ausgewählte Antworten (5)
  • @shmidtqq @0xWast3 strong build system
  • @gippp69 @0xWast3 letting memory expire feels way more human imo
  • @KuzkaaKuzkaa888 @0xWast3 Useful design: claims, clocks, decay, audit of the dead. Use it as a memory policy on top of whatever store you already have. Don’t throw out retrieval until the graveyard has a week of honest logs.
  • @PolyDekos @0xWast3 The benefit here is obvious
  • @mywcard @0xWast3 He knows that the subscription can be paid for with stablecoins, right?

Erwähnte Links

Zusammenfassung von KI erstellt (Gemini 3.8 Flash, 27. September 2026). Sie kann Fehler enthalten – maßgeblich ist die Originalquelle.

Ähnliche Einträge

Inhaltlich ähnlich, ermittelt über die KI-Suche.

  • Artikel:Devansh

    Stateful Swarms: Persistente Memory-Architektur schlägt traditionelle KI-Agenten

    Devansh beschreibt die Architektur der 'Stateful Swarms', die das Problem flüchtiger Kontexte und wiederholter Dokumentenverarbeitung durch eine persistente Blackboard-Architektur löst. Anstatt Dokumente mehrfach einzulesen oder Kontext per Prompt-Zusammenfassung zu übergeben, schreiben spezialisierte Agenten strukturierte, auditierbare Einträge in einen gemeinsamen Zustand. Im Harvey Legal Agent Benchmark erreichte dieser Ansatz höhere Erfolgsraten bei drastisch reduzierten Kosten im Vergleich zu traditionellen Systemen.

    KI & AI· Meinung

  • X-Post:Kirill

    Vom Agenten-Loop zum Graph Engineering: Deterministische KI-Architekturen

    Kirill beschreibt den Architekturwandel im Agenten-Design weg von fehleranfälligen Einzelschleifen (Loop Engineering) hin zu Graph Engineering. Der Erfolg komplexer KI-Systeme hänge nicht von der Modellgröße oder einer höheren Agentenzahl ab, sondern von deterministischer Strukturierung durch Knoten, Kanten, Verifizierer und Wissensgraphen.

    27.340Lesezeichen2,7 Mio.Aufrufe

    KI & AI· Meinung

  • X-Post:vartekx

    Context Engineering: Warum Prompts verblassen und Kontext-Loops übernehmen

    In einem Beitrag und Leitfaden skizziert vartekx den Wechsel von einfachem Prompt Engineering zu Context- und Loop-Engineering. Gestützt auf Konzepte von Andrej Karpathy und Boris Cherny sowie eine Demonstration zweier Anthropic-Entwickler wird dargelegt, wie die gezielte Steuerung des Kontextfensters robuste, selbstkorrigierende Agenten ermöglicht.

    59Lesezeichen6458Aufrufe

    KI & AI· Sammlung

  • X-Post:Kun Chen

    AGENTS.md wie ein neuronales Netz trainieren: Kun Chens Methode für Agent-Konfigurationsdateien

    Kun Chen schlägt ein neues Paradigma zur Pflege von AGENTS.md- und CLAUDE.md-Dateien vor: Während benutzerweite Dateien mit persönlichen Präferenzen manuell geschrieben werden sollten, seien projektbezogene Konfigurationen wie neuronale Netze zu behandeln – mit Token-Budget und Gradientenabstieg auf Basis echter Session-Logs.

    2756Lesezeichen93.549Aufrufe

    KI & AI· Meinung

  • X-Post:Mr. Buzzoni

    Append-Only-Architektur für Knowledge Graphen mit Multi-Agenten

    Mr. Buzzoni (@polydao) stellt ein Graph-Engineering-System vor, bei dem strukturierte Agenten Fakten und Verknüpfungen extrahieren, ohne bestehende Datensätze zu überschreiben. Über tägliche Logfiles, DuckDB und strikte menschliche Freigaben für Merges entsteht eine unveränderliche Wissensbasis.

    1091Lesezeichen75.797Aufrufe

    KI & AI· Meinung

Zurück zur Wissensbasis

Lassen Sie uns über Ihr Projekt sprechen

Kontakt aufnehmen

Standorte

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Wien
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Dieser Inhalt wurde teilweise mithilfe von KI erstellt.