Mnemo, livello di memoria locale: recall portabile per Ollama e app LLM proprie

Le ricerche su Mnemo nascono di solito da un dolore concreto, non dalla curiosità per l’ennesimo tool LLM locale. Forse Ollama gira già da te. Forse chiami già un modello locale tramite un’API compatibile con OpenAI. La parte scomoda arriva dopo: a sessione finita, il modello perde decisioni di progetto, preferenze utente, vincoli di API e la nota di debug che gli avevi dato ieri. Puoi continuare a incollare quel materiale nel prompt, ma il prompt si allunga, e le informazioni vecchie iniziano a litigare con quelle attuali.

Mnemo si infila in quella fessura. Tiene la memoria a lungo termine sulla tua macchina, salva entità e chunk tramite SQLite e relazioni a grafo, poi restituisce il contesto recuperato a Ollama, OpenAI, Anthropic o un altro backend compatibile. Non dà al modello una memoria nativa, e non è una knowledge base universale. Trattalo come un servizio di memoria locale che puoi sostituire, salvare, ispezionare e rollback.

Quale livello di memoria gestisce Mnemo

La maggior parte dei workflow LLM locali ha tre livelli: il modello genera, l’applicazione coordina il flusso, e il livello di memoria riporta informazioni utili tra le sessioni. Ollama copre il primo livello eseguendo i modelli in locale. Il RAG di solito risponde a «quali chunk di documenti somigliano a questa domanda?». Mnemo punta al livello tra sessioni più fine.

Un assistente di codice locale è un buon esempio. Oggi gli dici: «Questo progetto per ora non usa LangChain; tieni il livello API su FastAPI e SQLite». Domani avvii una nuova sessione e chiedi come aggiungere il retrieval. Un assistente utile dovrebbe recuperare quella decisione invece di proporre uno stack completamente diverso.

Questo rende Mnemo una scelta migliore quando hai già le basi, come chiamare l’API Ollama. Prima fai rispondere il modello in modo affidabile. Poi decidi quali informazioni meritano di diventare memoria. Invertire quest’ordine trasforma una demo fragile in una macchina a stati difficile da debuggare.

Architettura: API Rust, SQLite e traversal del grafo

Il README di Mnemo divide il repository in quattro crate Rust. mnemo-core possiede estrazione di entità, operazioni di grafo, retrieval e livello database. mnemo-api espone un’API REST Axum. mnemo-cli è il client a riga di comando. mnemo-bench contiene le suite di benchmark. Per un tool locale, questa struttura conta, perché mostra che il progetto è più di un prompt che riassume vecchie conversazioni.

SQLite salva lo stato, i link del grafo aggiungono indizi

Molti tool di memoria spezzano ogni turno di conversazione, creano embedding e recuperano per similarità. Funziona per alcuni lavori, ma due problemi emergono presto. La stessa persona, progetto o decisione può comparire in più sessioni. Due fatti possono entrare in conflitto, e la similarità vettoriale non decide quale debba vincere.

Railway - Piattaforma di deploy moderna, senza operazioni complesse, online in pochi minuti

Inizia ora →Pubbl.

La descrizione pubblica di Mnemo dà più peso a deduplicazione di entità e retrieval graph-first. In pratica, estrae entità dal testo, le fonde con quelle esistenti e usa archi di relazione durante il retrieval. Se «API gateway», «auth middleware» e «FastAPI service» compaiono in sessioni diverse, il grafo può collegarli quando chiedi del sistema più tardi.

L’espansione del grafo ha comunque bisogno di un guinzaglio. Il README dice che i risultati espansi via grafo partecipano con uno score più basso, così le corrispondenze dirette stanno davanti al contesto inferito. Un compromesso utile: i link del grafo portano indizi, senza seppellire la prova che ha corrisposto direttamente alla query.

Trattare i numeri di benchmark come misurazioni di progetto

La tabella di benchmark del README è specifica: Apple M2, SQLite WAL, petgraph in memoria e una pipeline di retrieval in debug build attorno a 4,2 ms, con la nota che i release build sono più veloci. Questo mostra che il percorso locale è stato misurato. Non prova che il tuo setup si comporti uguale. Il tuo risultato dipende da volume dei dati, chiamate di estrazione, velocità del disco, backend del modello e politica di retrieval.

Prima della latenza, terrei d’occhio tre cose: se le memorie scritte si possono rigiocare, se i risultati recuperati spiegano la fonte, e se le memorie sbagliate si possono cancellare o correggere. Il codice lento spesso si ottimizza. Una memoria sbagliata senza fonte è molto più difficile da credere.

Eseguire il percorso minimo Docker + Ollama

Non collegare Mnemo al tuo progetto principale il primo giorno. Usa una cartella temporanea, segui la rotta Docker + Ollama del README upstream, e decidi dopo se appartiene alla tua applicazione.

git clone https://github.com/zaydmulani09/mnemo
cd mnemo
docker compose up -d

# Scaricare il modello d'esempio del README la prima volta
docker exec mnemo-ollama ollama pull llama3

# Verificare il servizio API
curl http://localhost:8080/health

Se hai già seguito la guida introduttiva a Ollama, questo flusso ti sembrerà familiare. La differenza: Mnemo avvia un’API di memoria accanto al container di Ollama. Poi la tua app parla con il servizio di memoria invece di infilare ogni decisione passata nel contesto del modello.

Usare il Python SDK per uno smoke test

Il README dà anche un percorso minimo con il Python SDK. Testa una cosa sola: scrivere una memoria, poi porre una domanda in linguaggio naturale e vedere se torna.

from mnemo import MnemoClient

client = MnemoClient()

client.ingest("Sto costruendo un database vettoriale in Rust chiamato vecdb")
print(client.get_context("A quale progetto di database sto lavorando?"))

Quando lo esegui, non giudicare solo la risposta finale del modello. Controlla i log del servizio, i file di database, la struttura della risposta API e se la memoria sopravvive a un riavvio. La soglia minima della memoria a lungo termine non è una formulazione elegante. È uno stato durevole, ispezionabile e recuperabile.

Il percorso binario va bene quando Ollama esiste già

Se Ollama gira già sulla tua macchina, il README descrive anche una rotta binaria:

Vultr - Cloud server NVMe ad alte prestazioni, 32 location globali, deploy Docker con un clic

Vedi prezzi →Pubbl.

cargo install --path crates/mnemo-api
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1
mnemo-api

Questo percorso si adatta a un setup LLM locale esistente. Tieni i tuoi modelli, porte e monitoraggio, e aggiungi Mnemo come servizio separato. Se in seguito passi a un backend cloud, configura invece una base URL compatibile con OpenAI, una chiave API, un modello e un provider.

Controllare l’idoneità prima di adottarlo

Il README di Mnemo dà un confine utile: se usi già un harness di agente gestito che gestisce bene la memoria, forse non ti serve Mnemo. Quell’avvertenza conta. Più livelli di memoria possono significare più stato nascosto.

Il local-first ha un vantaggio chiaro: i dati restano sulla tua macchina, il file SQLite è facile da salvare, e non devi inviare ogni conversazione di progetto a un servizio cloud. Il lavoro di sicurezza resta necessario. Decidi chi può leggere il database, dove vivono i backup, se i log contengono chiavi API e come si rimuovono le memorie sbagliate.

Tre guardrail per il livello di memoria

La memoria a lungo termine è utile solo finché resta governabile. Prima di collegare Mnemo a un agente reale, scriverei tre regole nel progetto stesso.

Ogni memoria ha bisogno di una fonte

Una memoria non dovrebbe finire come una frase di riassunto solitaria. Dovrebbe puntare a una conversazione, un file, un task o un risultato di API. Se un agente dice «Questo progetto usa FastAPI», dovresti poter tracciare da dove viene quell’affermazione.

È anche la lezione principale della guida sulla memoria degli agenti IA. La memoria a lungo termine non è una clipboard più grande. Senza fonte, tempo e validità, le vecchie conclusioni indossano abiti nuovi.

Il contesto recuperato ha bisogno di un budget

Un servizio locale veloce dovrebbe comunque restituire un piccolo set di prove. Per molti task, 5-15 memorie ad alta rilevanza con indizi di fonte bastano. Se il modello ha bisogno di più, lascialo interrogare di nuovo invece di spingere decine di note forse correlate nel prompt.

Questo tiene basso il context rot. Gli agenti spesso falliscono con tanto materiale in mano perché quel materiale è vecchio, duplicato o contraddittorio. Il livello di memoria dovrebbe filtrare prima che il prompt cresca.

Le memorie sbagliate hanno bisogno di un percorso di ritiro

La memoria più pericolosa è sbagliata, non mancante. Supponi che il modello abbia salvato una volta «lo schema di produzione si può cambiare direttamente», e che il team richieda poi una migration review. Se quella vecchia memoria resta attiva, l’agente prima o poi farà un suggerimento rischioso.

🔥 Non sprecare mesi su prodotti senza domanda! Valida i punti di forza del tuo SaaS con Adsterra e un piccolo budget ➡️

Testa ora →Pubbl.

Quindi il pilota ha bisogno di azioni di ritiro: cancellare una memoria, segnalarla scaduta, ri-estrarre un progetto o svuotare uno spazio utente. Senza queste mosse, la memoria a lungo termine diventa debito.

Checklist di troubleshooting

I problemi di un tool come Mnemo vivono di solito tra servizio locale, backend del modello e retrieval. Controllali in quest’ordine:

• curl http://localhost:8080/health fallisce: verifica se i container Docker girano e se la porta è già occupata.
• Ollama non riesce a scaricare il modello: esegui ollama list nel container e conferma che il modello esista; usa un modello più piccolo se la rete è lenta.
• Le chiamate API si bloccano: verifica che MNEMO_LLM_BASE_URL punti a un endpoint compatibile con OpenAI. Ollama ascolta comunemente su 11434.
• La risposta ignora la memoria: conferma che ingest sia andato a buon fine, poi ispeziona il contesto di retrieval invece di giudicare solo la risposta finale.
• La memoria sparisce dopo il riavvio: verifica se il percorso dati SQLite è montato su un volume persistente.
• I risultati diventano confusi: riduci il contesto recuperato, deduplica le entità e fai scadere le decisioni di progetto obsolete.

Questi controlli battono il ritocco del prompt. Un prompt può cambiare come parla il modello. Non può riparare un servizio che non è mai partito o un percorso di database che sparisce con il container.

Letture consigliate e un pilota sicuro

Se non hai ancora eseguito un modello locale, parti dalla guida introduttiva a Ollama. Quando le chiamate al modello sono stabili, passa alle chiamate dell’API Ollama e agli embedding Ollama. Mnemo si inserisce dopo queste basi come pilota di memoria d’agente.

Un pilota di 7 giorni può restare piccolo:

1. Scegli un progetto, non l’intera macchina.
2. Scrivi 30-50 memorie reali su stack, opzioni scartate, errori comuni e vincoli di API.
3. Poni le stesse 10 domande di replay ogni giorno e registra retrieval corretto, mancante ed errato.
4. Cancella o fai scadere le memorie sbagliate, poi verifica se la risposta successiva cambia.
5. Riavvia il container e la macchina, poi conferma che le memorie restano.
6. Aggiungi backup del database, controlli sui permessi e scansione dei segreti.
7. Solo allora decidi se l’agente principale debba usarlo.

L’obiettivo utile di Mnemo è modesto: riportare un piccolo set di contesto importante nel task successivo, lasciando gli umani in grado di ispezionare, modificare, salvare e ritirare quel contesto. Una volta che ci riesci, un LLM locale inizia a sembrare meno una finestra di chat usa e getta e più uno strumento sostenibile.