Skip to main content

Minnesbästa praxis

Hur man strukturerar minnen för effektiv återkallning — kategorier, nycklar, taggar, prioriteringar.


Minnesbästa praxis

Hur ni strukturerar minnen avgör hur användbara de är. Den här guiden täcker mönster för kategorisering, taggning och prioritering av minnen så att LLM:en kan återkalla rätt information vid rätt tidpunkt.

Kategorier: välj den mest specifika

Kategori Använd för Exempel
identity Användarnamn, roll, kontaktinfo "user_name": "Michael Schäfer"
preference Tycker om, ogillar, arbetsstil "communication": "Prefers concise responses"
fact Verifierbara fakta "office_location": "Berlin, Germany"
project Projektstatus, beslut "project_synapse": "v1.5.0 deployed"
skill Användarens färdigheter "skill_python": "Advanced, 10+ years"
mistake Tidigare fel att undvika "mistake_npm_version": "Always bump version"
context Sessionsrelevant kontext "current_focus": "Working on docs system"
note Diverse anteckningar "note_idea": "Try Redis for caching"
Vid tveksamhet, använd `fact` för verifierbar info och `note` för allt annat. Överkategorisera inte — bättre med en tydlig `fact` än en förvirrande `context`.

Nycklar: meningsfulla identifierare

Fältet key är minnets identifierare. Använd meningsfulla, stabila nycklar:

Bra nycklar:

  • user_name
  • project_synapse_status
  • preference_communication_style
  • mistake_npm_version_bump

Dåliga nycklar:

  • mem_001 (inte meningsfull)
  • temp (inte beskrivande)
  • 2026-06-27-note (datum hjälper inte återkallning)

Namngivningskonventioner för nycklar

  • snake_case (gemener med understreck)
  • Prefixa med kategori: preference_*, project_*, mistake_*
  • Använd beskrivande substantiv, inte verb
  • Håll under 50 tecken

Taggar: för sökning och filtrering

Taggar möjliggör snabb filtrering och sökning. Lägg till 2–5 taggar per minne:

{
  "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"]
}

Taggmönster

  • Projektnamn: synapse, synapse-mcp, synapse-chat
  • Ämnen: deployment, ci, database, auth
  • Status: active, completed, blocked
  • Prioriteringsindikatorer: urgent, long-term
Taggar är skiftesokänsliga. Använd gemener för konsekvens.

Prioriteringar: var realistisk

Prioritering Använd för % av minnen
critical Användaridentitet, juridisk info, oåterkalleliga beslut ~5%
high Aktiva projekt, viktiga inställningar ~20%
normal De flesta fakta, anteckningar, kontext ~65%
low Efemärt, trevligt att veta ~10%
Markera inte allt som `critical`. Om allt är kritiskt är inget det. Reservera `critical` för saker som skulle orsaka verklig skada om de glöms.

När man ska lagra vs inte lagra

Lagra alltid

  • Användaridentitet (namn, e-post, roll)
  • Långsiktiga inställningar
  • Projektbeslut och motivering
  • Tidigare misstag och lärdomar
  • Åtaganden gentemot användaren

Lagra inte

  • Övergående tillstånd (använd variabler istället)
  • Ordagrant konversationshistorik (chattsystemet hanterar detta)
  • Känslig data (lösenord, API-nycklar)
  • Lätt härledbara fakta (aktuellt datum, filinnehåll)
  • Efemär kontext (använd context-kategori med låg prioritet)

Uppdatera minnen

POST /memory med samma category + key uppdaterar det befintliga minnet:

# 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")
Använd stabila nycklar så att ni kan uppdatera utan att skapa dubbletter. LLM:en bör åter-POSTa samma nyckel när information ändras, inte skapa nya minnen.

Minneslivscykel

Create → Active → Stale → Archive → Delete
  • Create: POST /memory med full kontext
  • Active: Återkalla ofta, uppdatera vid behov
  • Stale: Fortfarande relevant men inte aktivt använd (lägre prioritet?)
  • Archive: Sätt prioritet till low, behåll för historisk referens
  • Delete: DELETE /memory/:id när inte längre relevant

Periodisk rensning

# 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")

Mönster: Minnesarv

För hierarkisk kontext (projekt → delprojekt → uppgift):

# 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")

LLM:en kan sedan söka q=synapse+docs för att hitta alla relaterade minnen.

Mönster: Beslutslogg

Lagra beslut med motivering så att LLM:en inte återupprättar dem:

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")

Mönster: Misstag undvikande

Lagra misstag med specifika undvikandeinstruktioner:

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")

Antimönster att undvika

Nästa steg