Mai 2026 · 10 Min. Lesezeit · Fran Olivares, Gründer von OlivaresAI
Ein persistenter Speicher allein tut nichts. Der Speicher muss abgefragt, bewertet und in einen System-Prompt geformt werden, der in das Kontextfenster des Modells passt, bevor die nächste Nutzernachricht eintrifft. Dieser Schritt — Kontext-Assemblierung — ist der Unterschied zwischen „wir haben eine Speicherdatenbank" und „die KI erinnert sich". Dieser Leitfaden ist der Langform-Begleiter zur technischen Referenz unter /docs/context-assembly und führt durch jede Stufe der Pipeline, die Zahlen, die Alma standardmäßig verwendet, und die Trade-offs, die Sie tunen können.
Weil das Modell nur sieht, was im Prompt steht. Ein Speicher mit zehntausend Einträgen ist für das Modell unsichtbar, es sei denn, etwas wählt die richtigen dreißig für diesen Zug aus. Wenn die Auswahl falsch ist, übersieht das Modell die relevante Tatsache und produziert eine generische Antwort. Wenn die Auswahl zu breit ist, sprengt der Prompt das Kontextfenster oder verschwendet Tokens an Rauschen. Die Assemblierung ist der Türsteher — ein stiller Schritt, den der Nutzer nie sieht, aber das gesamte Gefühl von „die KI erinnert sich" hängt von seiner Qualität ab.
Die Assemblierung trifft auch ein hartes Latenz-Budget. Der Nutzer wartet; alles über ~100 ms beginnt träge zu wirken, bevor ein einziger Modell-Token gestreamt wurde. Deshalb stützt sich die Assemblierung auf indizierte Suche statt auf vollständige Scans, deshalb ist das Scoring eine gewichtete Summe (kein LLM-Aufruf), und deshalb werden die Token-Budgets pro Stufe vorab berechnet, statt dynamisch verhandelt zu werden.
Hybride Suche über alle drei Speicher-Schichten — Memories, Episodes, Procedures — mit sowohl Keyword- als auch semantischen Signalen. Die Anfrage des Nutzers wird mit demselben Modell embeddet, das den Speicher indexiert hat (bge-m3 1024-dim in Almas Standardkonfiguration), und das Embedding läuft gegen den Vektor-Index, um semantisch ähnliche Einträge zu Tage zu fördern. Parallel dazu trifft eine Keyword-Suche den relationalen Index für exakte Begriffstreffer, die die semantische Suche manchmal verfehlt (Eigennamen, Code-Bezeichner, seltene technische Begriffe).
Beide Ergebnismengen werden zusammengeführt, dedupliziert und auf das Kandidaten-Budget begrenzt (standardmäßig 100 pro Schicht — das Maximum, das der zugrundeliegende Vektor-Index pro Anfrage unterstützt). Der Kandidaten-Pool ist das, was in das Scoring fließt; nichts nach diesem Schritt rettet einen Eintrag, den die Suche nicht zu Tage gefördert hat.
Fünf Signale, gewichtet wie folgt in der produktiven Scoring-Funktion:
Die Gewichte sind bewusst abgestimmt: Relevanz dominiert, aber die sekundären Signale zählen bei Relevanz-Gleichständen (was in dichten Speichern oft passiert). Die Gewichte sind unverletzliche Invarianten in der Codebasis — Änderungen erfordern eine A/B-Benchmark, weil die nutzergefühlte Qualität von „hat sich die KI an das Richtige erinnert" von genau dieser Mischung abhängt.
Jede Stufe (Memories, Episodes, Procedures, Soul-Blöcke) hat ihr eigenes Token-Budget. Standardwerte: Memories ~2 K Tokens, Episodes ~1 K, Procedures ~500, Soul-Blöcke ~500. Insgesamt ~4 K — gut unter dem Kontextfenster jedes modernen Modells und klein genug, um cache-freundlich zu bleiben. Innerhalb jeder Stufe werden bewertete Einträge in Rangfolge hinzugefügt, bis das Budget erreicht ist.
Das Budget existiert aus zwei Gründen. Erstens schrumpft der effektive Kontext des Modells, wenn Sie es über eine bestimmte Dichte hinaus vollstopfen — relevante Dinge am Boden eines 100K-Token-Prompts sind für das Attention-Pattern de facto unsichtbar. Zweitens funktioniert Prompt-Caching nur, wenn das gecachte Präfix stabil ist; ein Aufblasen des Prompts mit signal-armen Erinnerungen sprengt den Cache und lässt jeden Zug volle Token-Preise zahlen. Enge Budgets halten sowohl Qualität als auch Ökonomie in Einklang.
Ein strukturierter System-Prompt mit fünf Abschnitten (in dieser Reihenfolge): Identität (aktive Soul-Blöcke als XML gerendert), Präferenzen (hochwichtige Memory-Einträge, die als Präferenzen markiert sind), relevante Fakten (top-bewertete Memories für diese Anfrage), jüngster Kontext (top-bewertete Episodes), Workflows (top-bewertete Procedures). Die Struktur zählt: Identität an den Anfang zu setzen bedeutet, dass sie volle Aufmerksamkeit erhält; Workflows ans Ende zu setzen bedeutet, dass sie nur konsultiert werden, wenn das Modell die Anfrage als prozedural einstuft.
Die Nutzernachricht wird dann als nächster Zug angehängt. Das Modell empfängt den assemblierten Prompt + die Nutzernachricht und produziert eine Antwort. Aus Sicht des Nutzers hat die KI einfach geantwortet. Unter der Haube hat die Assemblierung still tausende Memory-Einträge konsultiert und dem Modell die richtigen dreißig gezeigt.
In Almas Produktivumgebung liegt die End-to-End-Latenz der Assemblierung im Bereich von 30-80 ms für einen typischen Nutzer (einige hundert Memories, ein Dutzend Episodes). Vektor-Suche dominiert (~20-40 ms), Keyword-Suche läuft parallel (~5-10 ms), Scoring dauert einstellige ms, und der Prompt-Build ist im Wesentlichen kostenlos. Das 100-ms-Ziel wird mit komfortablem Spielraum auch für Nutzer mit Tausenden von Memories erreicht — der Kandidaten-Cap und die Stufen-Budgets halten die Arbeit beschränkt, während der Speicher wächst.
Vor dem Scoring kennzeichnet ein Widerspruchserkennungs-Durchgang über den Kandidaten-Pool Paare im Ähnlichkeitsbereich von 0,75-0,92, die semantisch in Konflikt stehen. Der neuere Eintrag gewinnt standardmäßig; der ältere wird als abgelöst markiert und für diesen Zug aus dem Kandidatenset entfernt (und global, beim nächsten Konsolidierungs-Durchgang). Das verhindert, dass das Modell „du hast X gesagt" neben „du hast nicht-X gesagt" empfängt und eine Synthese improvisiert, der der Nutzer nie zugestimmt hat.
Der vollständige Lifecycle (Deduplizierung, Ablösung, Abklingen) ist in dem vollständigen Leitfaden zu persistentem Speicher dokumentiert; die Assemblierung ist lediglich der Ort, an dem diese Lifecycle-Entscheidungen zur Anfragezeit sichtbar werden.
Architektonisch ähnlich (beide rufen ab, beide ranken, beide speisen in den Prompt ein), aber der Korpus und der Lifecycle sind unterschiedlich. RAG ruft aus einem externen Dokumenten-Korpus ab, der einmal verfasst und nach Plan re-indexiert wird; die Einträge entwickeln sich normalerweise nicht weiter. Memory-Assemblierung ruft aus dem eigenen, kontinuierlich wachsenden Speicher des Nutzers ab, mit Einträgen, die sich widersprechen, zusammengeführt und ablaufen. Die Scoring-Gewichte unterscheiden sich ebenfalls — RAG rankt überwiegend nach Ähnlichkeit und Dokument-Autorität; Memory-Assemblierung gewichtet Wichtigkeit, Aktualität und Häufigkeit, weil diese Signale mehr zählen, wenn der Speicher persönlich ist. Siehe den tieferen Vergleich in Persistenter Speicher vs. RAG.
Ja. Der Endpunkt POST /api/v1/context/assemble akzeptiert Overrides für die Budgets pro Stufe, die Mindest-Score-Schwelle, den Kandidaten-Cap und die Boost-Gewichte für Kategorie-Tags (sodass ein PM-Agent Entscheidungen verstärken kann, ein Autoren-Agent Stimm-Regeln). Die meisten Teams bleiben bei den Standards — sie wurden so abgestimmt, dass sie out of the box nützlich sind — aber die Hebel existieren für spezialisierte Vertikalen.
Starten Sie unter alma.olivares.ai, befüllen Sie zwanzig oder dreißig Erinnerungen über ein Projekt, das Ihnen wichtig ist, und starten Sie dann einen Chat. Die erste Antwort des Modells in der neuen Konversation wird spezifische Fakten aus Ihrem Speicher referenzieren — das ist die Assemblierung, nur versteckt hinter dem nutzerorientierten Chat. Für Entwickler, die direkt integrieren: Die REST API stellt den rohen assemblierten Prompt bereit, sodass Sie genau prüfen können, was für jede Anfrage ausgewählt wurde.
Verwandte Lektüre: Kontext-Assemblierung Technische Referenz · Dreistufige Speicherarchitektur · Persistenter Speicher für KI: Vollständiger Leitfaden 2026 · Persistenter Speicher vs. RAG · Soul Engine erklärt.