Maggio 2026 · lettura 10 min · Fran Olivares, Founder di OlivaresAI
Un archivio di memoria persistente da solo non fa nulla. L'archivio deve essere interrogato, valutato e modellato in un system prompt che si adatti alla finestra di contesto del modello prima che arrivi il prossimo messaggio utente. Quel passaggio — l'assemblaggio del contesto — è la differenza tra «abbiamo un database di memoria» e «l'AI ricorda». Questa guida è il complemento long-form del riferimento tecnico su /docs/context-assembly e illustra ogni fase della pipeline, i numeri che Alma usa per default e i trade-off che può regolare.
Perché il modello vede solo ciò che è nel prompt. Un archivio di memoria con diecimila voci è invisibile al modello a meno che qualcosa non selezioni le trenta giuste per questo turno. Se la selezione è sbagliata, il modello manca il fatto rilevante e produce una risposta generica. Se la selezione è troppo ampia, il prompt supera la finestra di contesto o spreca token su rumore. L'assemblaggio è il guardiano: un passaggio silenzioso che l'utente non vede mai, ma l'intera sensazione di «l'AI ricorda» si basa sulla sua qualità.
L'assemblaggio colpisce anche un budget di latenza rigido. L'utente sta aspettando; qualsiasi cosa sopra ~100 ms inizia a sembrare lenta prima che sia streamato un singolo token del modello. Ecco perché l'assemblaggio si appoggia alla ricerca indicizzata piuttosto che alle scansioni complete, perché lo scoring è una somma pesata (non una chiamata LLM) e perché i budget di token per livello sono calcolati in anticipo invece di essere negoziati dinamicamente.
Ricerca ibrida in tutti e tre i livelli di memoria — memorie, episodi, procedure — usando sia segnali per parole chiave che semantici. La query dell'utente viene incorporata con lo stesso modello che ha indicizzato l'archivio (bge-m3 1024-dim nella configurazione predefinita di Alma) e l'embedding viene eseguito contro l'indice vettoriale per far emergere le voci semanticamente simili. In parallelo, una ricerca per parole chiave colpisce l'indice relazionale per corrispondenze a termine esatto che la ricerca semantica a volte perde (nomi propri, identificatori di codice, termini tecnici rari).
Entrambi i set di risultati vengono uniti, deduplicati e limitati al budget dei candidati (predefinito 100 per livello: il massimo che l'indice vettoriale sottostante supporta per query). Il pool di candidati è ciò che fluisce nello scoring; nulla oltre questo stadio recupera una voce che la ricerca non ha fatto emergere.
Cinque segnali, pesati come segue nella funzione di scoring di produzione:
I pesi sono deliberatamente regolati: la rilevanza domina, ma i segnali secondari contano quando la rilevanza pareggia (cosa che accade spesso negli archivi di memoria densi). I pesi sono invarianti inviolabili nel codice base: le modifiche richiedono un benchmark A/B perché la qualità percepita dall'utente di «l'AI ha ricordato la cosa giusta» dipende da questa esatta combinazione.
Ogni livello (memorie, episodi, procedure, blocchi Soul) ha il proprio budget di token. Predefiniti: memorie ~2 K token, episodi ~1 K, procedure ~500, blocchi Soul ~500. Totale ~4 K — ben al di sotto della finestra di contesto di qualsiasi modello moderno, e abbastanza piccolo da restare cache-friendly. All'interno di ogni livello, le voci valutate vengono aggiunte in ordine di classifica fino al raggiungimento del budget.
Il budget esiste per due ragioni. Primo, il contesto effettivo del modello si restringe se lo riempie oltre una certa densità: le cose rilevanti in fondo a un prompt da 100K token sono de facto invisibili allo schema di attenzione. Secondo, il prompt caching funziona solo se il prefisso memorizzato nella cache è stabile; gonfiare il prompt con memorie a basso segnale rompe la cache e fa pagare a ogni turno i token a prezzo pieno. Budget stretti mantengono in linea sia qualità che economia.
Un system prompt strutturato con cinque sezioni (in questo ordine): identità (blocchi Soul attivi resi come XML), preferenze (voci di memoria ad alta importanza contrassegnate come preferenze), fatti rilevanti (memorie meglio valutate per questa query), contesto recente (episodi meglio valutati), workflow (procedure meglio valutate). La struttura conta: mettere l'identità in cima significa che ottiene piena attenzione; mettere i workflow in fondo significa che vengono consultati solo se il modello decide che la query è procedurale.
Il messaggio dell'utente viene poi accodato come turno successivo. Il modello riceve il prompt assemblato + il messaggio dell'utente e produce una risposta. Dal punto di vista dell'utente, l'AI ha semplicemente risposto. Sotto il cofano, l'assemblaggio ha consultato silenziosamente migliaia di record di memoria e ha mostrato al modello le trenta giuste.
Nel deployment di produzione di Alma, la latenza di assemblaggio end-to-end si colloca nel range 30-80 ms per un utente tipico (poche centinaia di memorie, una dozzina di episodi). La ricerca vettoriale domina (~20-40 ms), la ricerca per parole chiave gira in parallelo (~5-10 ms), lo scoring è di pochi ms a singola cifra e la costruzione del prompt è essenzialmente gratuita. L'obiettivo dei 100 ms viene raggiunto con comodo margine anche per utenti con migliaia di memorie: il limite dei candidati e i budget di livello mantengono il lavoro limitato al crescere dell'archivio.
Pre-scoring, un passaggio di rilevamento delle contraddizioni sul pool di candidati segnala le coppie nel range di similarità 0.75-0.92 che entrano in conflitto semanticamente. La voce più nuova vince per default; quella più vecchia viene marcata come sostituita e rimossa dal set di candidati per questo turno (e globalmente, al prossimo passaggio di consolidamento). Questo impedisce al modello di ricevere «hai detto X» insieme a «hai detto non-X» e di improvvisare una sintesi che l'utente non ha mai concordato.
Il ciclo di vita completo (deduplicazione, sostituzione, decadimento) è documentato nella guida completa alla memoria persistente; l'assemblaggio è semplicemente dove quelle decisioni di ciclo di vita si manifestano al momento della query.
Architettonicamente simile (entrambi recuperano, entrambi classificano, entrambi iniettano nel prompt) ma il corpus e il ciclo di vita sono diversi. Il RAG recupera da un corpus documentale esterno scritto una volta e re-indicizzato secondo un programma; le voci di solito non evolvono. L'assemblaggio della memoria recupera dall'archivio dell'utente stesso in continua crescita, con voci che si contraddicono, si fondono e decadono. Anche i pesi di scoring differiscono: il RAG classifica principalmente per similarità e autorità del documento; l'assemblaggio della memoria pesa importanza, attualità e frequenza perché quei segnali contano di più quando l'archivio è personale. Vedi il confronto più approfondito in Memoria persistente vs RAG.
Sì. L'endpoint POST /api/v1/context/assemble accetta override per i budget per livello, la soglia di punteggio minima, il limite dei candidati e i pesi di boost per i tag di categoria (in modo che un agente PM possa aumentare le decisioni, un agente per scrittori possa aumentare le regole di voce). La maggior parte dei team rimane sui valori predefiniti — sono stati regolati per essere utili fuori dalla scatola — ma le leve esistono per verticali specializzati.
Inizi su alma.olivares.ai, popoli venti o trenta memorie su un progetto a cui tiene, poi avvii una chat. La prima risposta del modello nella nuova conversazione farà riferimento a fatti specifici dal Suo archivio di memoria: questo è l'assemblaggio, semplicemente nascosto dietro la chat rivolta all'utente. Per gli sviluppatori che integrano direttamente: la REST API espone il prompt grezzo assemblato in modo che possa ispezionare esattamente cosa è stato selezionato per ogni query.
Letture correlate: Riferimento tecnico dell'assemblaggio del contesto · Architettura di memoria a tre livelli · Memoria persistente per l'AI: guida completa 2026 · Memoria persistente vs RAG · Soul Engine spiegato.