Skip to main content

मेमोरी सर्वोत्तम अभ्यास

प्रभावी रिकॉल के लिए मेमोरीज़ को कैसे संरचित करें — श्रेणियाँ, कुंजी, टैग, प्राथमिकताएँ।


मेमोरी सर्वोत्तम अभ्यास

आप मेमोरीज़ को जैसे संरचित करते हैं, वे उतनी ही उपयोगी होती हैं। यह गाइड श्रेणीबद्ध करने, टैग करने और प्राथमिकता देने के पैटर्न को कवर करती है ताकि LLM सही समय पर सही जानकारी को रिकॉल कर सके।

श्रेणियाँ: सबसे विशिष्ट चुनें

श्रेणी उपयोग उदाहरण
identity उपयोगकर्ता नाम, भूमिका, संपर्क जानकारी "user_name": "Michael Schäfer"
preference पसंद, नापसंद, कार्य शैली "communication": "Prefers concise responses"
fact सत्यापित योग्य तथ्य "office_location": "Berlin, Germany"
project प्रोजेक्ट स्थिति, निर्णय "project_synapse": "v1.5.0 deployed"
skill उपयोगकर्ता के कौशल "skill_python": "Advanced, 10+ years"
mistake टालने योग्य पिछली त्रुटियाँ "mistake_npm_version": "Always bump version"
context सत्र-संबंधित संदर्भ "current_focus": "Working on docs system"
note विविध नोट्स "note_idea": "Try Redis for caching"
संदेह होने पर, सत्यापित योग्य जानकारी के लिए `fact` का उपयोग करें और बाकी सब के लिए `note` का उपयोग करें। अति-श्रेणीबद्ध न करें — एक भ्रमित करने वाले `context` से एक स्पष्ट `fact` बेहतर है।

कुंजी: सार्थक पहचानकर्ता

key फ़ील्ड मेमोरी का पहचानकर्ता है। सार्थक, स्थिर कुंजी का उपयोग करें:

अच्छी कुंजी:

  • user_name
  • project_synapse_status
  • preference_communication_style
  • mistake_npm_version_bump

खराब कुंजी:

  • mem_001 (सार्थक नहीं)
  • temp (वर्णनात्मक नहीं)
  • 2026-06-27-note (तारीख रिकॉल में मदद नहीं करती)

कुंजी नामकरण सम्मेलन

  • snake_case (अंडरस्कोर के साथ लोअरकेस)
  • श्रेणी के साथ उपसर्ग करें: preference_*, project_*, mistake_*
  • वर्णनात्मक संज्ञाओं का उपयोग करें, क्रियाओं का नहीं
  • 50 अक्षरों के भीतर रखें

टैग: खोज और फ़िल्टरिंग के लिए

टैग तेज़ फ़िल्टरिंग और खोज सक्षम करते हैं। प्रत्येक मेमोरी में 2-5 टैग जोड़ें:

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

टैग पैटर्न

  • प्रोजेक्ट नाम: synapse, synapse-mcp, synapse-chat
  • विषय: deployment, ci, database, auth
  • स्थिति: active, completed, blocked
  • प्राथमिकता संकेतक: urgent, long-term
टैग केस-असंवेदनशील होते हैं। सुसंगतता के लिए लोअरकेस का उपयोग करें।

प्राथमिकताएँ: यथार्थवादी बनें

प्राथमिकता उपयोग % मेमोरीज़
critical उपयोगकर्ता पहचान, कानूनी जानकारी, अपरिवर्तनीय निर्णय ~5%
high सक्रिय प्रोजेक्ट, महत्वपूर्ण प्राथमिकताएँ ~20%
normal अधिकांश तथ्य, नोट्स, संदर्भ ~65%
low क्षणिक, जानना-अच्छा-लगता-है ~10%
सब कुछ `critical` चिह्नित न करें। यदि सब कुछ महत्वपूर्ण है, तो कुछ भी महत्वपूर्ण नहीं है। `critical` को उन चीज़ों के लिए आरक्षित रखें जिन्हें भूलने पर वास्तविक नुक़सान हो।

कब स्टोर करें और कब नहीं

हमेशा स्टोर करें

  • उपयोगकर्ता पहचान (नाम, ईमेल, भूमिका)
  • दीर्घकालिक प्राथमिकताएँ
  • प्रोजेक्ट निर्णय और तर्क
  • पिछली गलतियाँ और सीखे गए सबक
  • उपयोगकर्ता को दी गई प्रतिबद्धताएँ

स्टोर न करें

  • क्षणिक स्थिति (इसके बजाय वेरिएबल का उपयोग करें)
  • शब्दशः वार्तालाप इतिहास (चैट सिस्टम इसे संभालता है)
  • संवेदनशील डेटा (पासवर्ड, API कुंजी)
  • आसानी से प्राप्त होने वाले तथ्य (वर्तमान तारीख, फ़ाइल सामग्री)
  • क्षणिक संदर्भ (context श्रेणी का निम्न प्राथमिकता के साथ उपयोग करें)

मेमोरीज़ अपडेट करना

समान category + key के साथ POST /memory मौजूदा मेमोरी को अपडेट करता है:

# 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")
स्थिर कुंजी का उपयोग करें ताकि आप डुप्लिकेट बनाए बिना अपडेट कर सकें। LLM को जानकारी बदलने पर नई मेमोरी बनाने के बजाय समान कुंजी को पुनः POST करना चाहिए।

मेमोरी जीवनचक्र

Create → Active → Stale → Archive → Delete
  • Create: पूर्ण संदर्भ के साथ POST /memory
  • Active: बार-बार रिकॉल करें, आवश्यकतानुसार अपडेट करें
  • Stale: अभी भी प्रासंगिक लेकिन सक्रिय रूप से उपयोग नहीं (कम प्राथमिकता?)
  • Archive: प्राथमिकता low पर सेट करें, ऐतिहासिक संदर्भ के लिए रखें
  • Delete: अब प्रासंगिक न होने पर DELETE /memory/:id

आवधिक सफ़ाई

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

पैटर्न: मेमोरी इनहेरिटेंस

पदानुक्रमित संदर्भ के लिए (प्रोजेक्ट → उप-प्रोजेक्ट → कार्य):

# 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 सभी संबंधित मेमोरीज़ खोजने के लिए q=synapse+docs सर्च कर सकता है।

पैटर्न: निर्णय लॉग

तर्क के साथ निर्णय स्टोर करें ताकि LLM उन्हें पुनः विवादित न करे:

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

पैटर्न: गलती से बचाव

विशिष्ट बचाव निर्देशों के साथ गलतियाँ स्टोर करें:

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

बचने योग्य एंटी-पैटर्न

अगले कदम