{"title":"Memory-Best-Practices","slug":"memory-best-practices","category":"guides","summary":"Wie du Memories für effektives Recall strukturierst — Kategorien, Keys, Tags, Prioritäten.","audience":["human","llm"],"tags":["guide","memory","best-practices","patterns"],"difficulty":"intermediate","updated":"2026-06-27","word_count":582,"read_minutes":3,"lang":"de","translated":true,"requested_lang":"de","content_markdown":"\n# Memory-Best-Practices\n\nWie du Memories strukturierst, bestimmt ihren Nutzen. Dieser Guide behandelt\nPatterns zum Kategorisieren, Taggen und Prioritisieren, damit das LLM zur\nrichtigen Zeit die richtigen Informationen abrufen kann.\n\n## Kategorien: Wähle die spezifischste\n\n| Kategorie | Verwende für | Beispiel |\n|-----------|--------------|----------|\n| `identity` | Nutzername, Rolle, Kontaktinfo | `\"user_name\": \"Michael Schäfer\"` |\n| `preference` | Vorlieben, Abneigungen, Arbeitsstil | `\"communication\": \"Prefers concise responses\"` |\n| `fact` | Überprüfbare Fakten | `\"office_location\": \"Berlin, Germany\"` |\n| `project` | Projektstatus, Entscheidungen | `\"project_synapse\": \"v1.5.0 deployed\"` |\n| `skill` | Fähigkeiten des Nutzers | `\"skill_python\": \"Advanced, 10+ years\"` |\n| `mistake` | Frühere Fehler, die es zu vermeiden gilt | `\"mistake_npm_version\": \"Always bump version\"` |\n| `context` | Session-relevanter Kontext | `\"current_focus\": \"Working on docs system\"` |\n| `note` | Sonstige Notizen | `\"note_idea\": \"Try Redis for caching\"` |\n\n> [!TIP]\n> Im Zweifel: `fact` für überprüfbare Infos und `note` für alles andere.\n> Nicht überkategorisieren — besser ein klarer `fact` als ein verwirrender\n> `context`.\n\n## Keys: Aussagekräftige Bezeichner\n\nDas Feld `key` ist der Bezeichner des Memories. Verwende aussagekräftige,\nstabile Keys:\n\n**Gute Keys:**\n- `user_name`\n- `project_synapse_status`\n- `preference_communication_style`\n- `mistake_npm_version_bump`\n\n**Schlechte Keys:**\n- `mem_001` (nicht aussagekräftig)\n- `temp` (nicht beschreibend)\n- `2026-06-27-note` (Datum hilft beim Recall nicht)\n\n### Key-Namenskonventionen\n\n- `snake_case` (Kleinschreibung mit Unterstrichen)\n- Präfix mit Kategorie: `preference_*`, `project_*`, `mistake_*`\n- Beschreibende Substantive, keine Verben\n- Unter 50 Zeichen halten\n\n## Tags: Für Suche und Filterung\n\nTags ermöglichen schnelle Filterung und Suche. 2-5 Tags pro Memory hinzufügen:\n\n```json\n{\n \"category\": \"project\",\n \"key\": \"project_synapse_status\",\n \"content\": \"Synapse v1.5.0 deployed. Next: v1.6.0 with docs system.\",\n \"tags\": [\"synapse\", \"deployment\", \"status\", \"v1.5.0\"]\n}\n```\n\n### Tag-Patterns\n\n- **Projektnamen**: `synapse`, `synapse-mcp`, `synapse-chat`\n- **Themen**: `deployment`, `ci`, `database`, `auth`\n- **Status**: `active`, `completed`, `blocked`\n- **Prioritäts-Indikatoren**: `urgent`, `long-term`\n\n> [!NOTE]\n> Tags sind Case-insensitive. Verwende für Konsistenz Kleinschreibung.\n\n## Prioritäten: Sei realistisch\n\n| Priorität | Verwende für | % der Memories |\n|-----------|--------------|----------------|\n| `critical` | Nutzeridentität, rechtliche Infos, unumkehrbare Entscheidungen | ~5% |\n| `high` | Aktive Projekte, wichtige Präferenzen | ~20% |\n| `normal` | Die meisten Fakten, Notizen, Kontext | ~65% |\n| `low` | Flüchtig, nett zu wissen | ~10% |\n\n> [!WARNING]\n> Markiere nicht alles als `critical`. Wenn alles critical ist, ist nichts\n> critical. Reserviere `critical` für Dinge, die echten Schaden anrichten, wenn\n> sie vergessen werden.\n\n## Wann speichern, wann nicht?\n\n### Immer speichern\n\n- Nutzeridentität (Name, E-Mail, Rolle)\n- Langfristige Präferenzen\n- Projektentscheidungen und Begründungen\n- Frühere Fehler und gelernte Lektionen\n- Zugesagte Zusagen an den Nutzer\n\n### Nicht speichern\n\n- Flüchtigen Status (verwende stattdessen Variablen)\n- Wörtlichen Konversationsverlauf (Chat-System übernimmt das)\n- Sensible Daten (Passwörter, API-Keys)\n- Leicht ableitbare Fakten (aktuelles Datum, Dateiinhalte)\n- Flüchtigen Kontext (verwende `context`-Kategorie mit niedriger Priorität)\n\n## Memories aktualisieren\n\nPOST `/memory` mit derselben `category` + `key` aktualisiert den bestehenden\nMemory:\n\n```python\n# Initial store\nstore(\"project\", \"project_synapse_status\", \"v1.4.0 deployed\", priority=\"high\")\n\n# Later: update with same key\nstore(\"project\", \"project_synapse_status\", \"v1.5.0 deployed. CI green.\", priority=\"high\")\n```\n\n> [!TIP]\n> Verwende stabile Keys, damit du aktualisieren kannst, ohne Duplikate zu\n> erzeugen. Das LLM sollte denselben Key erneut posten, wenn sich Infos ändern,\n> nicht neue Memories anlegen.\n\n## Memory-Lebenszyklus\n\n```\nCreate → Active → Stale → Archive → Delete\n```\n\n- **Create**: POST /memory mit vollem Kontext\n- **Active**: Häufig abrufen, bei Bedarf aktualisieren\n- **Stale**: Noch relevant, aber nicht aktiv genutzt (niedrigere Priorität?)\n- **Archive**: Priorität auf `low` setzen, für historische Referenz behalten\n- **Delete**: DELETE /memory/:id, wenn nicht mehr relevant\n\n### Periodische Bereinigung\n\n```python\n# Find memories not updated in 90 days\nold_memories = requests.get(\n f\"{URL}/memory/search?q=*\",\n headers={\"Authorization\": f\"Bearer {KEY}\"}\n)\n\nfor mem in old_memories[\"results\"]:\n if is_stale(mem, days=90):\n # Either delete or lower priority\n if is_obsolete(mem):\n delete_memory(mem[\"id\"])\n else:\n update_memory(mem[\"id\"], priority=\"low\")\n```\n\n## Pattern: Memory-Vererbung\n\nFür hierarchischen Kontext (Projekt → Subprojekt → Task):\n\n```python\n# Parent project\nstore(\"project\", \"project_synapse\", \"Main Synapse project\", \n tags=[\"synapse\", \"parent\"], priority=\"high\")\n\n# Sub-project (tags link to parent)\nstore(\"project\", \"project_synapse_docs\", \"Docs system for Synapse\",\n tags=[\"synapse\", \"docs\", \"synapse-parent\"], priority=\"high\")\n\n# Specific task (tags link to sub-project)\nstore(\"project\", \"task_docs_loader\", \"Implement docs-loader.ts\",\n tags=[\"synapse\", \"docs\", \"task\"], priority=\"normal\")\n```\n\nDas LLM kann dann `q=synapse+docs` suchen, um alle verwandten Memories zu\nfinden.\n\n## Pattern: Entscheidungs-Log\n\nEntscheidungen mit Begründung speichern, damit das LLM sie nicht neu verhandelt:\n\n```python\nstore(\"fact\", \"decision_postgres_over_sqlite\",\n \"Chose PostgreSQL over SQLite for production. Reason: concurrent writes, \"\n \"FTS5 native support, better backup story. Date: 2026-06-15. Decided by: Michael.\",\n tags=[\"decision\", \"database\", \"postgres\", \"sqlite\"],\n priority=\"high\")\n```\n\n## Pattern: Fehler-Vermeidung\n\nFehler mit spezifischen Vermeidungs-Anweisungen speichern:\n\n```python\nstore(\"mistake\", \"mistake_forget_version_bump\",\n \"Forgot to bump package.json version after changes. npm publish failed. \"\n \"FIX: Always run `npm version patch` before pushing. \"\n \"CI fails with 'version already exists' if you forget.\",\n tags=[\"npm\", \"ci\", \"publish\", \"version\"],\n priority=\"high\")\n```\n\n## Anti-Patterns, die du vermeiden solltest\n\n> [!WARNING]\n> - **Konversations-Logs speichern** — Chat-System übernimmt das\n> - **Ganze Dateien speichern** — Script-Speicher oder externen Speicher verwenden\n> - **Flüchtigen Status speichern** — Variablen verwenden\n> - **Secrets speichern** — Environment-Variablen verwenden\n> - **Memories duplizieren** — stabile Keys verwenden\n> - **Übertrieben taggen** — 2-5 Tags pro Memory sind ideal\n> - **Alles ist critical** — sei realistisch mit Prioritäten\n\n## Nächste Schritte\n\n- [Memory-API](/docs/api/memory)\n- [Persistenter LLM-Agent](/docs/guides/persistent-llm-agent)\n- [Memory-Tagging-Strategie](/docs/llm-cookbook/memory-tagging-strategy)\n","content_html":"

Memory-Best-Practices

\n

Wie du Memories strukturierst, bestimmt ihren Nutzen. Dieser Guide behandelt\nPatterns zum Kategorisieren, Taggen und Prioritisieren, damit das LLM zur\nrichtigen Zeit die richtigen Informationen abrufen kann.

\n

Kategorien: Wähle die spezifischste

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
KategorieVerwende fürBeispiel
identityNutzername, Rolle, Kontaktinfo"user_name": "Michael Schäfer"
preferenceVorlieben, Abneigungen, Arbeitsstil"communication": "Prefers concise responses"
factÜberprüfbare Fakten"office_location": "Berlin, Germany"
projectProjektstatus, Entscheidungen"project_synapse": "v1.5.0 deployed"
skillFähigkeiten des Nutzers"skill_python": "Advanced, 10+ years"
mistakeFrühere Fehler, die es zu vermeiden gilt"mistake_npm_version": "Always bump version"
contextSession-relevanter Kontext"current_focus": "Working on docs system"
noteSonstige Notizen"note_idea": "Try Redis for caching"
\n
Im Zweifel: `fact` für überprüfbare Infos und `note` für alles andere.\nNicht überkategorisieren — besser ein klarer `fact` als ein verwirrender\n`context`.

Keys: Aussagekräftige Bezeichner

\n

Das Feld key ist der Bezeichner des Memories. Verwende aussagekräftige,\nstabile Keys:

\n

Gute Keys:

\n\n

Schlechte Keys:

\n\n

Key-Namenskonventionen

\n\n

Tags: Für Suche und Filterung

\n

Tags ermöglichen schnelle Filterung und Suche. 2-5 Tags pro Memory hinzufügen:

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

Tag-Patterns

\n\n
Tags sind Case-insensitive. Verwende für Konsistenz Kleinschreibung.

Prioritäten: Sei realistisch

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
PrioritätVerwende für% der Memories
criticalNutzeridentität, rechtliche Infos, unumkehrbare Entscheidungen~5%
highAktive Projekte, wichtige Präferenzen~20%
normalDie meisten Fakten, Notizen, Kontext~65%
lowFlüchtig, nett zu wissen~10%
\n
Markiere nicht alles als `critical`. Wenn alles critical ist, ist nichts\ncritical. Reserviere `critical` für Dinge, die echten Schaden anrichten, wenn\nsie vergessen werden.

Wann speichern, wann nicht?

\n

Immer speichern

\n\n

Nicht speichern

\n\n

Memories aktualisieren

\n

POST /memory mit derselben category + key aktualisiert den bestehenden\nMemory:

\n
# Initial store\nstore("project", "project_synapse_status", "v1.4.0 deployed", priority="high")\n\n# Later: update with same key\nstore("project", "project_synapse_status", "v1.5.0 deployed. CI green.", priority="high")
Verwende stabile Keys, damit du aktualisieren kannst, ohne Duplikate zu\nerzeugen. Das LLM sollte denselben Key erneut posten, wenn sich Infos ändern,\nnicht neue Memories anlegen.

Memory-Lebenszyklus

\n
Create → Active → Stale → Archive → Delete
\n

Periodische Bereinigung

\n
# Find memories not updated in 90 days\nold_memories = requests.get(\n    f"{URL}/memory/search?q=*",\n    headers={"Authorization": f"Bearer {KEY}"}\n)\n\nfor mem in old_memories["results"]:\n    if is_stale(mem, days=90):\n        # Either delete or lower priority\n        if is_obsolete(mem):\n            delete_memory(mem["id"])\n        else:\n            update_memory(mem["id"], priority="low")

Pattern: Memory-Vererbung

\n

Für hierarchischen Kontext (Projekt → Subprojekt → Task):

\n
# Parent project\nstore("project", "project_synapse", "Main Synapse project", \n      tags=["synapse", "parent"], priority="high")\n\n# Sub-project (tags link to parent)\nstore("project", "project_synapse_docs", "Docs system for Synapse",\n      tags=["synapse", "docs", "synapse-parent"], priority="high")\n\n# Specific task (tags link to sub-project)\nstore("project", "task_docs_loader", "Implement docs-loader.ts",\n      tags=["synapse", "docs", "task"], priority="normal")

Das LLM kann dann q=synapse+docs suchen, um alle verwandten Memories zu\nfinden.

\n

Pattern: Entscheidungs-Log

\n

Entscheidungen mit Begründung speichern, damit das LLM sie nicht neu verhandelt:

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

Pattern: Fehler-Vermeidung

\n

Fehler mit spezifischen Vermeidungs-Anweisungen speichern:

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

Anti-Patterns, die du vermeiden solltest

\n

Nächste Schritte

\n\n","urls":{"html":"/docs/guides/memory-best-practices","text":"/docs/guides/memory-best-practices?format=text","json":"/docs/guides/memory-best-practices?format=json","llm":"/docs/guides/memory-best-practices?format=llm"},"translations_available":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"]}