Mei 2026 · 10 min leestijd · Fran Olivares, oprichter van OlivaresAI
Een permanente geheugenopslag op zichzelf doet niets. De opslag moet worden bevraagd, gescoord en gevormd tot een systeemprompt die in het contextvenster van het model past voordat het volgende gebruikersbericht binnenkomt. Die stap — contextsamenstelling — is het verschil tussen „we hebben een geheugendatabase" en „de AI onthoudt". Deze gids is de lange-vorm metgezel bij de technische referentie op /docs/context-assembly en doorloopt elke fase van de pipeline, de getallen die Alma standaard gebruikt, en de afwegingen die u kunt afstemmen.
Omdat het model alleen ziet wat in de prompt staat. Een geheugenopslag met tienduizend items is onzichtbaar voor het model tenzij iets de juiste dertig voor deze beurt selecteert. Als de selectie verkeerd is, mist het model het relevante feit en produceert een generiek antwoord. Als de selectie te breed is, blaast de prompt voorbij het contextvenster of verspilt tokens aan ruis. Samenstelling is de poortwachter — een stille stap die de gebruiker nooit ziet, maar de hele beleving van „de AI onthoudt" zit op de kwaliteit ervan.
Samenstelling raakt ook een harde latentiebegroting. De gebruiker wacht; alles boven ~100 ms begint sloom te voelen voordat een enkel modeltoken is gestreamd. Daarom leunt samenstelling op geïndexeerd zoeken in plaats van volledige scans, daarom is scoring een gewogen som (geen LLM-aanroep), en daarom worden de per-tier tokenbudgetten vooraf berekend in plaats van dynamisch onderhandeld.
Hybride zoeken over alle drie de geheugenlagen — memories, episodes, procedures — met zowel keyword- als semantische signalen. De query van de gebruiker wordt geëmbed met hetzelfde model dat de opslag heeft geïndexeerd (bge-m3 1024-dim in Alma's standaardconfiguratie), en de embedding loopt tegen de vector-index om semantisch vergelijkbare items naar boven te halen. Parallel raakt een keyword-zoekopdracht de relationele index voor exacte-term matches die semantisch zoeken soms mist (eigennamen, code-identifiers, zeldzame technische termen).
Beide resultaatsets worden samengevoegd, gededupliceerd en begrensd tot het kandidatenbudget (standaard 100 per laag — het maximum dat de onderliggende vector-index per query ondersteunt). De kandidatenpool is wat de scoring instroomt; niets voorbij deze fase redt een item dat het zoeken niet naar boven heeft gehaald.
Vijf signalen, gewogen als volgt in de productiescoring-functie:
De gewichten zijn bewust afgestemd: relevantie domineert, maar de secundaire signalen tellen wanneer relevantie gelijk is (wat vaak gebeurt in dichte geheugenopslagen). De gewichten zijn onschendbare invarianten in de codebase — wijzigingen vereisen een A/B-benchmark omdat de door de gebruiker gevoelde kwaliteit van „heeft de AI het juiste ding onthouden" afhangt van deze exacte mix.
Elke tier (memories, episodes, procedures, Soul-blokken) heeft zijn eigen tokenbudget. Standaarden: memories ~2 K tokens, episodes ~1 K, procedures ~500, Soul-blokken ~500. Totaal ~4 K — ruim onder het contextvenster van elk modern model, en klein genoeg om cache-vriendelijk te blijven. Binnen elke tier worden gescoorde items toegevoegd in rangschikkingsvolgorde totdat het budget is bereikt.
Het budget bestaat om twee redenen. Ten eerste krimpt de effectieve context van het model als u het voorbij een bepaalde dichtheid stopt — relevante dingen onderaan een prompt van 100K-tokens zijn de facto onzichtbaar voor het aandachtspatroon. Ten tweede werkt prompt-caching alleen als de gecachte prefix stabiel is; de prompt opblazen met herinneringen met laag signaal blaast de cache en maakt elke beurt volle-prijs tokens betalen. Strakke budgetten houden zowel kwaliteit als economie in lijn.
Een gestructureerde systeemprompt met vijf secties (in deze volgorde): identiteit (actieve Soul-blokken gerenderd als XML), voorkeuren (hoog-belangrijkheid geheugen-items gemarkeerd als voorkeuren), relevante feiten (top-gescoorde memories voor deze query), recente context (top-gescoorde episodes), workflows (top-gescoorde procedures). De structuur telt: identiteit bovenaan plaatsen betekent dat het volledige aandacht krijgt; workflows onderaan plaatsen betekent dat ze alleen worden geraadpleegd als het model beslist dat de query procedureel is.
Het gebruikersbericht wordt vervolgens als volgende beurt toegevoegd. Het model ontvangt de samengestelde prompt + gebruikersbericht en produceert een reactie. Vanuit het perspectief van de gebruiker antwoordde de AI gewoon. Onder de motorkap raadpleegde de samenstelling stilletjes duizenden geheugenrecords en toonde het model de juiste dertig.
In de productieomgeving van Alma zit de end-to-end samenstellingslatentie in het bereik van 30-80 ms voor een typische gebruiker (een paar honderd memories, een dozijn episodes). Vectorzoeken domineert (~20-40 ms), keyword-zoeken loopt parallel (~5-10 ms), scoring is enkele cijfers ms, en de prompt-bouw is in feite gratis. Het doel van 100 ms wordt bereikt met comfortabele speling, zelfs voor gebruikers met duizenden memories — de kandidaat-cap en tier-budgetten houden het werk begrensd naarmate de opslag groeit.
Voor de scoring vlagt een contradictiedetectie-pass over de kandidatenpool paren in het 0,75-0,92 similariteitsbereik die semantisch conflicteren. Het nieuwere item wint standaard; het oudere wordt als opgevolgd gemarkeerd en uit de kandidatenset voor deze beurt verwijderd (en globaal, bij de volgende consolidatie-pass). Dit voorkomt dat het model „u zei X" naast „u zei niet-X" ontvangt en een synthese improviseert waarmee de gebruiker nooit heeft ingestemd.
De volledige levenscyclus (deduplicatie, supersessie, verval) wordt gedocumenteerd in de complete gids voor permanent geheugen; samenstelling is precies waar die levenscyclus-beslissingen op querytijd verschijnen.
Architecturaal vergelijkbaar (beide halen op, beide rangschikken, beide injecteren in de prompt), maar het corpus en de levenscyclus zijn anders. RAG haalt op uit een extern documentcorpus dat eenmaal is opgesteld en op een schema opnieuw wordt geïndexeerd; de items evolueren meestal niet. Geheugen-samenstelling haalt op uit de continu-groeiende eigen opslag van de gebruiker, met items die elkaar tegenspreken, samenvoegen en vervallen. De scoringsgewichten verschillen ook — RAG rangschikt voornamelijk op similariteit en documentauthority; geheugen-samenstelling weegt belangrijkheid, recentheid en frequentie omdat die signalen meer tellen wanneer de opslag persoonlijk is. Zie de diepere vergelijking in Permanent geheugen vs RAG.
Ja. Het POST /api/v1/context/assemble eindpunt accepteert overrides voor de per-tier budgetten, de minimum scoredrempel, de kandidaat-cap en de boost-gewichten voor categorietags (zodat een PM-agent beslissingen kan boosten, een schrijfagent stemregels kan boosten). De meeste teams blijven bij standaarden — ze zijn afgestemd om kant-en-klaar nuttig te zijn — maar de hendels bestaan voor gespecialiseerde verticals.
Begin op alma.olivares.ai, vul twintig of dertig memories in over een project dat u belangrijk vindt, en start vervolgens een chat. De eerste reactie van het model in het nieuwe gesprek zal verwijzen naar specifieke feiten uit uw geheugenopslag — dat is samenstelling, alleen verborgen achter de voor de gebruiker zichtbare chat. Voor ontwikkelaars die rechtstreeks integreren: de REST API stelt de rauwe samengestelde prompt beschikbaar zodat u precies kunt inspecteren wat is geselecteerd voor elke query.
Verwante lectuur: Contextsamenstelling technische referentie · Drielaagse geheugenarchitectuur · Permanent geheugen voor AI: complete gids 2026 · Permanent geheugen vs RAG · Soul Engine uitgelegd.