Mejores prácticas de memoria
Cómo estructurar memorias para un recall efectivo — categorías, claves, etiquetas, prioridades.
Mejores prácticas de memoria
La forma en que estructure las memorias determina cuán útiles son. Esta guía cubre patrones para categorizar, etiquetar y priorizar memorias para que el LLM pueda recuperar la información correcta en el momento adecuado.
Categorías: elija la más específica
| Categoría | Usar para | Ejemplo |
|---|---|---|
identity |
Nombre, rol, info de contacto | "user_name": "Michael Schäfer" |
preference |
Gustos, disgustos, estilo de trabajo | "communication": "Prefers concise responses" |
fact |
Hechos verificables | "office_location": "Berlin, Germany" |
project |
Estado del proyecto, decisiones | "project_synapse": "v1.5.0 deployed" |
skill |
Habilidades del usuario | "skill_python": "Advanced, 10+ years" |
mistake |
Errores pasados a evitar | "mistake_npm_version": "Always bump version" |
context |
Contexto relevante para la sesión | "current_focus": "Working on docs system" |
note |
Notas varias | "note_idea": "Try Redis for caching" |
Claves: identificadores significativos
El campo key es el identificador de la memoria. Use claves significativas y
estables:
Buenas claves:
user_nameproject_synapse_statuspreference_communication_stylemistake_npm_version_bump
Malas claves:
mem_001(no significativa)temp(no descriptiva)2026-06-27-note(la fecha no ayuda al recall)
Convenciones de nomenclatura de claves
snake_case(minúsculas con guiones bajos)- Prefije con la categoría:
preference_*,project_*,mistake_* - Use sustantivos descriptivos, no verbos
- Mantenga por debajo de 50 caracteres
Etiquetas: para búsqueda y filtrado
Las etiquetas permiten filtrado y búsqueda rápida. Añada 2-5 etiquetas por memoria:
{
"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"]
}Patrones de etiquetado
- Nombres de proyecto:
synapse,synapse-mcp,synapse-chat - Temas:
deployment,ci,database,auth - Estado:
active,completed,blocked - Indicadores de prioridad:
urgent,long-term
Prioridades: sea realista
| Prioridad | Usar para | % de memorias |
|---|---|---|
critical |
Identidad del usuario, info legal, decisiones irreversibles | ~5% |
high |
Proyectos activos, preferencias importantes | ~20% |
normal |
La mayoría de hechos, notas, contexto | ~65% |
low |
Efímera, bueno saberlo | ~10% |
Cuándo almacenar y cuándo no
Almacene siempre
- Identidad del usuario (nombre, email, rol)
- Preferencias a largo plazo
- Decisiones del proyecto y su justificación
- Errores pasados y lecciones aprendidas
- Compromisos adquiridos con el usuario
No almacene
- Estado transitorio (use variables en su lugar)
- Historial de conversación literal (lo gestiona el sistema de chat)
- Datos sensibles (contraseñas, API keys)
- Hechos fácilmente derivables (fecha actual, contenidos de archivos)
- Contexto efímero (use la categoría
contextcon prioridad baja)
Actualizar memorias
POST /memory con la misma category + key actualiza la memoria existente:
# Initial store
store("project", "project_synapse_status", "v1.4.0 deployed", priority="high")
# Later: update with same key
store("project", "project_synapse_status", "v1.5.0 deployed. CI green.", priority="high")Ciclo de vida de la memoria
Create → Active → Stale → Archive → Delete- Create: POST /memory con contexto completo
- Active: Recall frecuente, actualizar según sea necesario
- Stale: Aún relevante pero no usado activamente (¿bajar prioridad?)
- Archive: Establecer prioridad a
low, conservar como referencia histórica - Delete: DELETE /memory/:id cuando ya no sea relevante
Limpieza periódica
# Find memories not updated in 90 days
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):
# Either delete or lower priority
if is_obsolete(mem):
delete_memory(mem["id"])
else:
update_memory(mem["id"], priority="low")Patrón: herencia de memoria
Para contexto jerárquico (proyecto → subproyecto → tarea):
# Parent project
store("project", "project_synapse", "Main Synapse project",
tags=["synapse", "parent"], priority="high")
# Sub-project (tags link to parent)
store("project", "project_synapse_docs", "Docs system for Synapse",
tags=["synapse", "docs", "synapse-parent"], priority="high")
# Specific task (tags link to sub-project)
store("project", "task_docs_loader", "Implement docs-loader.ts",
tags=["synapse", "docs", "task"], priority="normal")El LLM puede entonces buscar q=synapse+docs para encontrar todas las memorias
relacionadas.
Patrón: log de decisiones
Almacene decisiones con su justificación para que el LLM no las vuelva a cuestionar:
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")Patrón: evitar errores
Almacene errores con instrucciones específicas de prevención:
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")