# Best practice per la memoria SUMMARY: Come strutturare le memorie per richiamo efficace — categorie, chiavi, tag, priorità. Best practice per la memoria Come struttura le memorie determina quanto sono utili. Questa guida copre modelli per categorizzare, taggare e dare priorità alle memorie così l'LLM può richiamare l'informazione giusta al momento giusto. Categorie: scelga la più specifica | Categoria | Usi per | Esempio | |----------|---------|---------| | | Nome utente, ruolo, info contatto | | | | Piaceri, dispiaceri, stile di lavoro | | | | Fatti verificabili | | | | Stato del progetto, decisioni | | | | Competenze dell'utente | | | | Errori passati da evitare | | | | Contesto rilevante per la sessione | | | | Note varie | | > [!TIP] > In caso di dubbio, usi per informazioni verificabili e per > tutto il resto. Non ecceda con le categorie — meglio un chiaro che un > confusionario. Chiavi: identificatori significativi Il campo è l'identificatore della memoria. Usi chiavi significative e stabili: Chiavi buone: - - - - Chiavi cattive: - (non significativa) - (non descrittiva) - (la data non aiuta il richiamo) Convenzioni per i nomi delle chiavi - (minuscolo con underscore) - Prefisso con categoria: , , - Usi sostantivi descrittivi, non verbi - Meno di 50 caratteri Tag: per ricerca e filtraggio I tag abilitano filtraggio e ricerca veloce. Aggiunga 2-5 tag per memoria: [CODE BLOCK] Modelli di tag - Nomi di progetto: , , - Argomenti: , , , - Stato: , , - Indicatori di priorità: , > [!NOTE] > I tag sono case-insensitive. Usi minuscolo per consistenza. Priorità: sia realistico | Priorità | Usi per | % delle memorie | |----------|---------|---------------| | | Identità utente, info legali, decisioni irreversibili | 5% | | | Progetti attivi, preferenze importanti | 20% | | | Maggior parte dei fatti, note, contesto | 65% | | | Effimero, piace-da-sapere | 10% | > [!WARNING] > Non contrassegni tutto come . Se tutto è critical, nulla lo è. > Riservi per cose che causerebbero danno reale se dimenticate. Quando memorizzare vs non memorizzare Memorizzi sempre - Identità utente (nome, email, ruolo) - Preferenze long-term - Decisioni di progetto e ragionamento - Errori passati e lezioni apprese - Impegni presi con l'utente Non memorizzi - Stato transiente (usi variabili invece) - Cronologia conversazione verbatim (la gestisce il sistema chat) - Dati sensibili (password, API key) - Fatti facilmente derivabili (data corrente, contenuto file) - Contesto effimero (usi categoria con priorità bassa) Aggiornare le memorie POST con la stessa + aggiorna la memoria esistente: [CODE BLOCK] > [!TIP] > Usi chiavi stabili così può aggiornare senza creare duplicati. L'LLM > dovrebbe fare nuovamente POST della stessa chiave quando le info cambiano, > non creare nuove memorie. Ciclo di vita della memoria [CODE BLOCK] - Create: POST /memory con contesto completo - Active: Richiama frequentemente, aggiorna come necessario - Stale: Ancora rilevante ma non attivamente usata (priorità più bassa?) - Archive: Imposti priorità a , mantenga per riferimento storico - Delete: DELETE /memory/:id quando non più rilevante Pulizia periodica [CODE BLOCK] Modello: ereditarietà della memoria Per contesto gerarchico (progetto → sottoprogetto → attività): [CODE BLOCK] L'LLM può poi cercare per trovare tutte le memorie correlate. Modello: log delle decisioni Memorizzi le decisioni con il ragionamento così l'LLM non le ridiscute: [CODE BLOCK] Modello: evitamento degli errori Memorizzi gli errori con istruzioni specifiche di evitamento: [CODE BLOCK] Anti-pattern da evitare > [!WARNING] > - Memorizzare log di conversazione — il sistema chat lo gestisce > - Memorizzare file interi — usi lo script store o storage esterno > - Memorizzare stato effimero — usi variabili > - Memorizzare segreti — usi variabili di ambiente > - Duplicare memorie — usi chiavi stabili > - Eccesso di tag — 2-5 tag per memoria è ideale > - Tutto è critical — sia realistico con le priorità Prossimi passi - Memory API - Agente LLM persistente - Strategia di tagging della memoria