Bonnes pratiques mémoire

La façon dont vous structurez les mémoires détermine leur utilité. Ce guide couvre les schémas pour catégoriser, tagger et prioriser les mémoires afin que le LLM puisse rappeler la bonne information au bon moment.

Catégories : choisissez la plus spécifique

Clés : identifiants significatifs

Le champ key est l'identifiant de la mémoire. Utilisez des clés significatives et stables :

Bonnes clés :

• user_name
• project_synapse_status
• preference_communication_style
• mistake_npm_version_bump

Mauvaises clés :

• mem_001 (non significative)
• temp (non descriptive)
• 2026-06-27-note (la date n'aide pas le rappel)

Conventions de nommage des clés

• snake_case (minuscules avec tirets bas)
• Préfixez avec la catégorie : preference_*, project_*, mistake_*
• Utilisez des noms descriptifs, pas des verbes
• Gardez en dessous de 50 caractères

Tags : pour la recherche et le filtrage

Les tags permettent le filtrage et la recherche rapides. Ajoutez 2-5 tags par mémoire :

{
  "category": "project",
  "key": "project_synapse_status",
  "content": "Synapse v1.5.0 deployed. Next: v1.6.0 with docs system.",
  "tags": ["synapse", "deployment", "status", "v1.5.0"]
}

Schémas de tags

• Noms de projet : synapse, synapse-mcp, synapse-chat
• Sujets : deployment, ci, database, auth
• Statut : active, completed, blocked
• Indicateurs de priorité : urgent, long-term

Priorités : soyez réaliste

Quand stocker ou non

Toujours stocker

• Identité utilisateur (nom, email, rôle)
• Préférences longue durée
• Décisions de projet et justification
• Erreurs passées et leçons apprises
• Engagements pris envers l'utilisateur

Ne pas stocker

• État transitoire (utilisez plutôt des variables)
• Historique de conversation verbatim (le système chat gère cela)
• Données sensibles (mots de passe, clés API)
• Faits facilement dérivables (date actuelle, contenu de fichiers)
• Contexte éphémère (utilisez la catégorie context avec priorité basse)

Mettre à jour les mémoires

POST /memory avec la même category + key met à jour la mémoire existante :

# Stockage initial
store("project", "project_synapse_status", "v1.4.0 deployed", priority="high")

# Plus tard : mise à jour avec la même clé
store("project", "project_synapse_status", "v1.5.0 deployed. CI green.", priority="high")

Cycle de vie d'une mémoire

Create → Active → Stale → Archive → Delete

• Create : POST /memory avec contexte complet
• Active : Rappeler fréquemment, mettre à jour au besoin
• Stale : Toujours pertinent mais pas activement utilisé (priorité plus basse ?)
• Archive : Définir la priorité sur low, conserver pour référence historique
• Delete : DELETE /memory/:id quand plus pertinent

Nettoyage périodique

# Trouver les mémoires non mises à jour depuis 90 jours
old_memories = requests.get(
    f"{URL}/memory/search?q=*",
    headers={"Authorization": f"Bearer {KEY}"}
)

for mem in old_memories["results"]:
    if is_stale(mem, days=90):
        # Soit supprimer, soit abaisser la priorité
        if is_obsolete(mem):
            delete_memory(mem["id"])
        else:
            update_memory(mem["id"], priority="low")

Schéma : héritage de mémoire

Pour un contexte hiérarchique (projet → sous-projet → tâche) :

# Projet parent
store("project", "project_synapse", "Main Synapse project", 
      tags=["synapse", "parent"], priority="high")

# Sous-projet (les tags lient au parent)
store("project", "project_synapse_docs", "Docs system for Synapse",
      tags=["synapse", "docs", "synapse-parent"], priority="high")

# Tâche spécifique (les tags lient au sous-projet)
store("project", "task_docs_loader", "Implement docs-loader.ts",
      tags=["synapse", "docs", "task"], priority="normal")

Le LLM peut alors chercher q=synapse+docs pour trouver toutes les mémoires liées.

Schéma : journal de décisions

Stockez les décisions avec leur justification pour que le LLM ne les re-questionne pas :

store("fact", "decision_postgres_over_sqlite",
      "Chose PostgreSQL over SQLite for production. Reason: concurrent writes, "
      "FTS5 native support, better backup story. Date: 2026-06-15. Decided by: Michael.",
      tags=["decision", "database", "postgres", "sqlite"],
      priority="high")

Schéma : évitement des erreurs

Stockez les erreurs avec des instructions d'évitement spécifiques :

store("mistake", "mistake_forget_version_bump",
      "Forgot to bump package.json version after changes. npm publish failed. "
      "FIX: Always run `npm version patch` before pushing. "
      "CI fails with 'version already exists' if you forget.",
      tags=["npm", "ci", "publish", "version"],
      priority="high")

Anti-schémas à éviter

Prochaines étapes

• API Memory
• Agent LLM persistant
• Stratégie de tagging mémoire