ऐसे एजेंट्स बनाएं जो कभी न भूलें

एजेंट मेमोरी का प्रथम-सिद्धांत विश्लेषण: Python सूचियों से Markdown फ़ाइलों, वेक्टर सर्च से ग्राफ-वेक्टर हाइब्रिड, और अंततः इस सबका एक स्वच्छ, ओपन-सोर्स समाधान।

एक LLM डिज़ाइन से ही स्टेटलेस होता है। हर API कॉल एक नई शुरुआत करता है। ChatGPT के साथ चैट करते समय जो "मेमोरी" महसूस होती है, वह हर रिक्वेस्ट के साथ पूरा कन्वर्सेशन हिस्ट्री फिर से भेजने से बनाया गया भ्रम है।

यह तरीका सामान्य चैट के लिए काम करता है। लेकिन जैसे ही आप कोई वास्तविक एजेंट बनाने की कोशिश करते हैं, यह बिखर जाता है।

यहाँ 7 विफलता मोड हैं जो तुरंत सामने आते हैं जब आप मेमोरी को छोड़ देते हैं:

1. संदर्भ विस्मृति (Context amnesia): एजेंट वह जानकारी माँगता है जो आप पहले ही दे चुके हैं।
2. शून्य वैयक्तिकरण (Zero personalization): हर इंटरैक्शन सामान्य और रूखा लगता है।
3. बहु-चरणीय कार्य विफलता (Multi-step task failure): बीच में ही इंटरमीडिएट स्टेट चुपचाप गायब हो जाता है।
4. बार-बार गलतियाँ (Repeated mistakes): एपिसोडिक रिकॉल न होने का मतलब है एक ही गलती बार-बार, हमेशा के लिए।
5. ज्ञान का कोई संचय नहीं (No knowledge accumulation): हर सत्र शून्य से शुरू होता है।
6. अंतराल से मतिभ्रम (Hallucination from gaps): जब कॉन्टेक्स्ट ओवरफ्लो होता है, तो मॉडल कल्पना करने लगता है।
7. पहचान का पतन (Identity collapse): कोई निरंतरता नहीं, कोई विश्वास नहीं।

इसका स्पष्ट जवाब है "इसमें और कॉन्टेक्स्ट डाल दो।" इसीलिए 128K और 200K टोकन विंडो ऐसा लगते हैं जैसे वे सब कुछ हल कर देंगे।

लेकिन वे नहीं करते।

जब प्रासंगिक जानकारी लंबे कॉन्टेक्स्ट के बीच में होती है, तो सटीकता 30% से अधिक गिर जाती है। यह प्रसिद्ध "लॉस्ट इन द मिडल" (Lost in the Middle) प्रभाव है।

कॉन्टेक्स्ट एक साझा बजट है: सिस्टम प्रॉम्प्ट, रिट्रीव किए गए दस्तावेज़, कन्वर्सेशन हिस्ट्री, और आउटपुट सभी एक ही टोकन के लिए प्रतिस्पर्धा करते हैं।

100K टोकन पर भी, दृढ़ता (persistence), प्राथमिकता (prioritization), और सार्थकता (salience) की कमी कच्चे कॉन्टेक्स्ट की लंबाई को अपर्याप्त बना देती है।

मेमोरी का मतलब प्रॉम्प्ट में और टेक्स्ट ठूंसना नहीं है। इसका मतलब है एजेंट जो याद रखता है उसे इस तरह संरचित करना कि वह प्रासंगिक चीज़ें ढूँढ सके।

संज्ञानात्मक विज्ञान का वह ढाँचा जो वास्तव में मदद करता है

लिलियन वेंग (Lilian Weng) का 2023 का सूत्रीकरण डिफ़ॉल्ट ढाँचा बन गया है:

एजेंट = LLM + मेमोरी + प्लानिंग + टूल उपयोग।

ये चार समान-महत्व के स्तंभ हैं।

उनका वर्गीकरण संज्ञानात्मक विज्ञान से उधार लिया गया है, जहाँ मानव स्मृति तीन प्रणालियों में विभाजित होती है:

• संवेदी स्मृति (Sensory memory) कच्चे अवधानात्मक इनपुट को पकड़ती है और इसे एक सेकंड के एक अंश के लिए रखती है। केवल वे हिस्से जिन पर आप ध्यान देते हैं, आगे बढ़ते हैं।
• कार्यशील स्मृति (Working memory) वह जगह है जहाँ सक्रिय सोच होती है। यह एक बार में लगभग 7±2 आइटम रखती है (मिलर 1956 का निष्कर्ष)। ध्यान भटकने पर, सामग्री गायब हो जाती है।
• दीर्घकालिक स्मृति (Long-term memory) स्थायी भंडारण है जिसकी कोई व्यावहारिक सीमा नहीं है। पुनर्प्राप्ति (Retrieval) बाधा है: आप लाखों चीज़ें संग्रहीत कर सकते हैं और फिर भी वह एक चीज़ याद करने में विफल हो सकते हैं जिसकी आपको आवश्यकता है।

इनमें से प्रत्येक सीधे आधुनिक एजेंट आर्किटेक्चर के एक घटक से मैप होता है:

दीर्घकालिक स्मृति आगे और विभाजित होती है:

• एपिसोडिक (Episodic): विशिष्ट पिछली घटनाएँ ("मंगलवार को, PostgreSQL क्लस्टर डाउन हो गया था")
• सिमैंटिक (Semantic): तथ्य और अवधारणाएँ ("PostgreSQL एक रिलेशनल डेटाबेस है")
• प्रक्रियात्मक (Procedural): कौशल और वर्कफ़्लो ("जब कोई उपयोगकर्ता रिफंड माँगता है, तो पहले खरीदारी की तारीख जाँचें")

एपिसोडिक और सिमैंटिक के बीच का पुल मेमोरी कंसोलिडेशन है: बार-बार होने वाली विशिष्ट घटनाओं का सामान्य ज्ञान में बदलना। एक एजेंट जो दर्जनों इंटरैक्शन में "उपयोगकर्ता लगातार एग्जीक्यूटिव सारांश पसंद करते हैं" देखता है, उसे इसे एक पुन: प्रयोज्य नियम में बदलना चाहिए। कंसोलिडेशन के बिना, आपका एजेंट व्यक्तिगत घटनाओं को दोहराता है, उनसे सीखता नहीं है।

न्यूनतम एजेंट, और पहले क्या टूटता है

ढाँचों को हटा दें, तो एक एजेंट एक लूप है: अनुभव करो (perceive), सोचो (think), कार्य करो (act)।

1class Agent:
2    """Minimal AI agent: perceive, think, act"""
3    def __init__(self):
4        self.client = anthropic.Anthropic()
5        self.model = "claude-sonnet-4-20250514"
6
7    def run(self, user_input: str) -> str:
8        response = self.client.messages.create(
9            model=self.model,
10            max_tokens=1024,
11            messages=[{"role": "user", "content": user_input}],
12        )
13        return response.content[0].text

इसे बताएं "मेरे पास 4 सेब हैं," फिर पूछें "मैंने एक खा लिया, कितने बचे?" और इसे पता नहीं होगा कि आप किस सेब की बात कर रहे हैं। हर कॉल अलगाव में मौजूद है।

लेयर 1: Python सूची (The Python list)

पहला सुधार जो हर कोई आज़माता है:

1class Agent:
2    def __init__(self):
3        self.client = anthropic.Anthropic()
4        self.messages = []  # The entire "memory" is a list
5
6    def chat(self, user_input: str) -> str:
7        self.messages.append({"role": "user", "content": user_input})
8        response = self.client.messages.create(
9            model="claude-sonnet-4-20250514",
10            max_tokens=1024,
11            messages=self.messages,  # Full history sent every time
12        )
13        reply = response.content[0].text
14        self.messages.append({"role": "assistant", "content": reply})
15        return reply

अब मल्टी-टर्न काम करता है। सेब वाले प्रश्न का सही उत्तर मिलता है क्योंकि पूरी बातचीत हर कॉल के साथ फिर से भेजी जाती है।

दो समस्याएँ जल्दी सामने आती हैं:

• सूची असीमित रूप से बढ़ती है। लगभग टर्न 200 के आसपास, आप कॉन्टेक्स्ट सीमा तक पहुँच जाते हैं और सबसे पुराने संदेश चुपचाप गिर जाते हैं। टर्न 1 से उपयोगकर्ता का नाम कल के एक फालतू मजाक से बहुत पहले गायब हो जाता है। कोई प्राथमिकता नहीं, केवल सख्त कालानुक्रमिक क्रम।
• सब कुछ RAM में रहता है। जैसे ही Python प्रक्रिया समाप्त होती है, आपके एजेंट को पता नहीं होता कि आप कौन हैं।

लेयर 2: दृढ़ता के लिए Markdown फ़ाइलें

अगला कदम मेमोरी को डिस्क पर लिखना है। Markdown एक स्वाभाविक विकल्प है: मानव-पठनीय, Git के अनुकूल, और एजेंट इसे सादे टेक्स्ट के रूप में वापस पढ़ सकता है। Claude Code बिल्कुल इसी पैटर्न का CLAUDE.md और MEMORY.md फ़ाइलों के साथ उपयोग करता है।

1class MarkdownMemoryAgent:
2    def __init__(self):
3        self.client = anthropic.Anthropic()
4        self.history_file = Path("memory/conversation_history.md")
5        self.facts_file = Path("memory/known_facts.md")
6
7    def save_to_disk(self, role: str, content: str) -> None:
8        with open(self.history_file, "a") as f:
9            f.write(f"### {role} at {datetime.now().isoformat()}\n{content}\n\n")
10
11    def load_history(self) -> str:
12        if self.history_file.exists():
13            return self.history_file.read_text()
14        return ""
15
16    def chat(self, user_input: str) -> str:
17        self.save_to_disk("user", user_input)
18        history = self.load_history()
19        response = self.client.messages.create(
20            model="claude-sonnet-4-20250514",
21            max_tokens=1024,
22            system=f"Previous conversation:\n{history}",
23            messages=[{"role": "user", "content": user_input}],
24        )
25        reply = response.content[0].text
26        self.save_to_disk("assistant", reply)
27        return reply

दृढ़ता हल हो गई है। स्क्रिप्ट को पुनरारंभ करें, और बातचीत अभी भी डिस्क पर है। आप एक अलग facts फ़ाइल भी रख सकते हैं जिसे एजेंट समय के साथ निकालता है:

1- User's name is Sarah
2- Sarah manages the backend team at Acme Corp
3- Acme Corp is a B2B SaaS company
4- Currently migrating production database to a new AWS region

आप किसी भी एडिटर में फ़ाइल खोल सकते हैं, देख सकते हैं कि एजेंट क्या जानता है, और इसे हाथ से ठीक कर सकते हैं। प्रोटोटाइपिंग के लिए वास्तव में उपयोगी।

4 तथ्यों के साथ, यह पूरी तरह से काम करता है। पूरी फ़ाइल को कॉन्टेक्स्ट में लोड करें और LLM सारा, उसकी कंपनी, या उसके उद्योग के बारे में किसी भी प्रश्न को संभाल लेगा।

अब तीन महीने आगे बढ़ें। आपके एजेंट के पास 2,000 निकाले गए तथ्य और 200 कन्वर्सेशन लॉग हैं। डिस्क पर यह 500K+ टोकन का markdown है, और आपकी कॉन्टेक्स्ट विंडो 128K है।

अब आप सब कुछ लोड नहीं कर सकते। आपको केवल वर्तमान क्वेरी से संबंधित तथ्यों को चुनिंदा रूप से पुनर्प्राप्त करने की आवश्यकता है। फ्लैट फ़ाइलों के साथ, आपका एकमात्र विकल्प कीवर्ड सर्च है:

1# User asks: "What's the status of our cloud migration?"
2grep("cloud migration", facts_file)
3# Returns: []
4# The fact on disk says "migrating production database to a new AWS region."
5# The words "cloud migration" appear nowhere.
6
7# User asks: "Which team is handling the database work?"
8grep("database team", facts_file)
9# Returns: []
10# One fact says Sarah "manages the backend team." Another says the team
11# is "migrating production database." But no single line contains
12# both "database" and "team" together.

छोटे पैमाने पर, markdown फ़ाइलें काम करती हैं। वास्तविक पैमाने पर, वे कीवर्ड रिट्रीवल के लिए बाध्य करती हैं, और कीवर्ड पर्यायवाची, व्याख्या, या तथ्यों के बीच संबंधों को संभाल नहीं सकते।

जानकारी डिस्क पर है। लेकिन आप इसे पूरा लोड नहीं कर सकते, और कीवर्ड सर्च सही टुकड़े खोजने के लिए बहुत कमज़ोर है।

यदि आपने OpenClaw का उपयोग किया है, तो आपने इसे होते देखा होगा। यह मेमोरी को markdown चेकपॉइंट फ़ाइलों के रूप में संग्रहीत करता है, और दैनिक उपयोग के हफ्तों में, जैसे-जैसे कॉन्टेक्स्ट जमा होता है और संकुचित होता है, पहले के तथ्य चुपचाप गायब हो जाते हैं। भंडारण मौजूद है। पुनर्प्राप्ति नहीं है।

बुद्धिमान पुनर्प्राप्ति के बिना भंडारण एक ऐसा पुस्तकालय है जिसमें कोई सूची नहीं है।

लेयर 3: वेक्टर सर्च और वह दीवार जिससे वह टकराता है

Embeddings जोड़ें। अपने markdown को चंक करें, चंक embed करें, cosine similarity से खोजें। अब "database" "PostgreSQL" से मेल खाता है क्योंकि उनके वेक्टर embedding स्पेस में एक-दूसरे के करीब रहते हैं। पर्यायवाची की समस्या हल हो जाती है।

फिर आप एक नई दीवार से टकराते हैं। अपने वेक्टर DB में इन तीन तथ्यों पर विचार करें:

1- "Alice is the tech lead on Project Atlas"
2- "Project Atlas uses PostgreSQL for its primary datastore"
3- "The PostgreSQL cluster experienced an outage on Tuesday"

उपयोगकर्ता पूछता है: "क्या मंगलवार के आउटेज से एलिस का प्रोजेक्ट प्रभावित हुआ?"

क्वेरी में एलिस और मंगलवार के आउटेज का उल्लेख है, इसलिए वेक्टर सर्च पहले और तीसरे तथ्य को उच्च रैंक करता है। लेकिन महत्वपूर्ण कड़ी, "Project Atlas uses PostgreSQL," में न तो एलिस और न ही मंगलवार का उल्लेख है। यह जोड़ने वाला टुकड़ा है, और यह वही है जो सामने नहीं आएगा।

प्रत्येक तथ्य embedding स्पेस में एक पृथक बिंदु है। उन्हें जोड़ने वाले संयोजी ऊतक वैक्टर के लिए अदृश्य है।

यह कोई किनारे का मामला नहीं है। यह वास्तविक दुनिया के प्रश्नों का सामान्य आकार है। व्यावसायिक ज्ञान स्वाभाविक रूप से संबंधपरक है: लोग टीमों से संबंधित हैं, टीमें प्रोजेक्ट की मालिक हैं, प्रोजेक्ट सिस्टम पर निर्भर हैं, सिस्टम में घटनाएँ होती हैं। कोई भी प्रश्न जो दो या अधिक हॉप्स को पार करता है, वह फ्लैट वेक्टर रिट्रीवल जो उत्तर दे सकता है उससे परे है।

क्षमता मैट्रिक्स (The capability matrix)

प्रत्येक परत पिछले दर्द को ठीक करती है लेकिन एक गहरा दर्द प्रकट करती है:

आपको एक मेमोरी लेयर में दृढ़ता (persistence), शब्दार्थ समझ (semantic understanding), और संबंधपरक तर्क (relational reasoning) की आवश्यकता है।

इसे स्वयं बनाने का मतलब है एक वेक्टर डेटाबेस, एक ग्राफ डेटाबेस, एक रिलेशनल स्टोर, एक एंटिटी एक्सट्रैक्टर, एक डिडुप्लीकेशन पाइपलाइन, और एक एज-वेटिंग सिस्टम को एक साथ जोड़ना। यह एजेंट लॉजिक की एक भी पंक्ति लिखने से पहले हफ्तों का बुनियादी ढाँचा काम है।

मैं एक ऐसे समाधान का उपयोग कर रहा हूँ जो इस अंतर को साफ-सुथरे तरीके से भरता है। यह पूरी तरह से ओपन-सोर्स है, एक ही छत के नीचे तीनों स्टोरेज प्रतिमानों को संभालता है, और आप इसे मिनटों में चालू कर सकते हैं। आइए Cognee के बारे में बात करते हैं।

Cognee: तीन स्टोर, एक इंजन, चार कॉल

Cognee एक ओपन-सोर्स नॉलेज इंजन है जो एजेंट मेमोरी के लिए बनाया गया है। यह वेक्टर सर्च को नॉलेज ग्राफ और एक रिलेशनल प्रोवेनेंस लेयर के साथ एक ही सिस्टम में जोड़ता है।

संपूर्ण API सतह चार async कॉल है:

1import cognee
2
3await cognee.add("Your document here")   # Ingest anything
4await cognee.cognify()                    # Build knowledge graph + embeddings
5await cognee.memify()                     # Self-improve the memory
6await cognee.search("Your query")         # Retrieve with reasoning

इन चार कॉलों के पीछे एक तीन-स्टोर आर्किटेक्चर बैठता है।

तीन स्टोर क्यों, एक क्यों नहीं?

प्रत्येक स्टोर ज्ञान के एक ऐसे आयाम को कैप्चर करता है जिसे दूसरे नहीं कर सकते:

• रिलेशनल स्टोर → प्रोवेनेंस: डेटा कहाँ से आया, इसे कब इनजेस्ट किया गया, किसके पास एक्सेस है
• वेक्टर स्टोर → शब्दार्थ: सामग्री का क्या अर्थ है, यह किसके समान है
• ग्राफ स्टोर → संबंध: एंटिटी कैसे जुड़ी हैं, क्या किसका कारण बनता है, कौन किसको रिपोर्ट करता है

इनमें से किसी को भी सपाट करने पर आप वह जानकारी खो देंगे जो रिट्रीवल सटीकता के लिए मायने रखती है।

डिफ़ॉल्ट स्टैक SQLite + LanceDB + Kuzu है, जो पूरी तरह से एम्बेडेड और फ़ाइल-आधारित है। pip install cognee और एक LLM API कुंजी के साथ आप चालू हैं।

कोई Docker नहीं, कोई बाहरी सेवा नहीं।

प्रोडक्शन के लिए, SQLite को Postgres से, LanceDB को Qdrant/Pinecone/pgvector से, और Kuzu को Neo4j/FalkorDB/Neptune से बदलें।

दोनों तरह से एक ही चार-कॉल API।

cognify वास्तव में क्या करता है?

cognee.cognify() एक मल्टी-स्टेज पाइपलाइन चलाता है जो कच्चे टेक्स्ट को संरचित, परस्पर जुड़े ज्ञान में बदल देती है:

1. दस्तावेज़ वर्गीकरण प्रकार और डोमेन के अनुसार
2. अनुमति जाँच मल्टी-टेनेंट एक्सेस नियंत्रण के लिए
3. चंक निष्कर्षण जो पैराग्राफ संरचना का सम्मान करता है (निश्चित आकार के कट नहीं)
4. एंटिटी और संबंध निष्कर्षण LLM के माध्यम से, कंटेंट हैशिंग के माध्यम से स्वचालित डिडुप्लीकेशन के साथ
5. सारांश निर्माण कुशल पुनर्प्राप्ति के लिए
6. दोहरा अनुक्रमण वेक्टर स्टोर (embeddings) और ग्राफ स्टोर (edges) में

डिडुप्लीकेशन चरण जितना लगता है उससे कहीं अधिक महत्वपूर्ण है। यदि एक ही एंटिटी 50 दस्तावेज़ों में दिखाई देती है, तो Cognee इसे 50 इनबाउंड एजेज़ के साथ एक एकल ग्राफ नोड में मिला देता है। आपका एजेंट अब "एलिस" को 50 अलग-अलग अजनबियों के रूप में नहीं देखता। और पाइपलाइन डिफ़ॉल्ट रूप से वृद्धिशील है: केवल नई या संशोधित फ़ाइलों को पुन: संसाधित किया जाता है।

प्रत्येक ग्राफ नोड का एक संगत embedding होता है। यह दोहरा प्रतिनिधित्व मुख्य तरकीब है: वैक्टर के माध्यम से प्रवेश करें (शब्दार्थ रूप से समान सामग्री खोजें) और ग्राफ के माध्यम से बाहर निकलें (जुड़ी हुई एंटिटी के लिए संबंधों का अनुसरण करें), या इसका उल्टा करें। यही वह चीज़ है जो शब्दार्थ खोज का त्याग किए बिना मल्टी-हॉप क्वेरी को काम करने योग्य बनाती है।

Memify: मेमोरी जो सीखती है

memify() वह चीज़ है जो Cognee को हर "इनजेस्ट और सर्च" टूल से अलग करती है। यह ग्राफ पर एक RL-प्रेरित ऑप्टिमाइज़ेशन पास चलाता है:

• उपयोगी पथों को मजबूत करना जो अच्छी रिट्रीवल की ओर ले गए
• अप्रयुक्त नोड्स को प्रून करना जिन्हें छुआ नहीं गया है
• वास्तविक उपयोग के आधार पर एज वेट को ऑटो-ट्यून करना
• अंतर्निहित संबंधों की पहचान करके व्युत्पन्न तथ्य (derived facts) जोड़ना

एक ग्राहक सहायता एजेंट का ग्राफ स्वाभाविक रूप से उत्पाद दस्तावेज़ों और रिफंड नीतियों के माध्यम से पथों को मजबूत करता है, जबकि शायद ही कभी पूछे जाने वाले HR एजेज़ को क्षय होने देता है। ग्राफ समय के साथ प्रासंगिकता की अपनी भावना विकसित करता है।

चौदह रिट्रीवल मोड

Cognee 14 सर्च मोड के साथ आता है। वे जिन्हें आप वास्तव में उपयोग करेंगे:

Cognee मेमोरी के साथ एक वास्तविक एजेंट बनाना

यहाँ पूरा पैटर्न है जो Cognee को perceive-think-act लूप में वायर करता है:

1import cognee
2from cognee import SearchType
3
4class CogneeMemoryAgent:
5    """Agent with graph-vector hybrid persistent memory."""
6
7    def __init__(self, session_id: str = "default"):
8        self.llm_client = OpenAI()
9        self.session_id = session_id
10
11    async def ingest(self, text: str, dataset: str = "main"):
12        await cognee.add(text, dataset)
13        await cognee.cognify([dataset])
14
15    async def recall(self, query: str) -> str:
16        results = await cognee.search(
17            query_text=query,
18            query_type=SearchType.GRAPH_COMPLETION,
19            session_id=self.session_id,
20        )
21        return results[0] if results else ""
22
23    async def chat(self, user_input: str) -> str:
24        context = await self.recall(user_input)
25        messages = [
26            {"role": "system", "content": "You are helpful. Use memory context."},
27            {"role": "system", "content": f"Memory context:\n{context}"},
28            {"role": "user", "content": user_input},
29        ]
30        response = self.llm_client.chat.completions.create(
31            model="gpt-4o-mini", messages=messages
32        )
33        reply = response.choices[0].message.content
34        await cognee.add(
35            f"User: {user_input}\nAssistant: {reply}",
36            "conversations"
37        )
38        await cognee.cognify(["conversations"])
39        return reply

मेमोरी चक्र: इनजेस्ट करें, निकालें, संग्रहीत करें, पुनर्प्राप्त करें, उत्तर दें, फिर से संग्रहीत करें। प्रत्येक टर्न नॉलेज ग्राफ को समृद्ध करता है, और वृद्धिशील प्रसंस्करण का मतलब है कि आप केवल नई सामग्री को अनुक्रमित करने के लिए भुगतान करते हैं।

सेशन मेमोरी स्वचालित रूप से सर्वनाम समाधान को संभालती है:

1await cognee.search(query_text="Where does Alice live?", session_id="conv_1")
2await cognee.search(query_text="What does she do for work?", session_id="conv_1")
3# "she" resolves to Alice from session context

मल्टी-टेनेंसी ग्राफ स्तर पर प्रति-डेटासेट अनुमतियों (पढ़ना, लिखना, हटाना, साझा करना) के साथ अंतर्निहित है। नेमस्पेस अलगाव नहीं, बल्कि वास्तविक ग्राफ-स्तरीय अलगाव।

व्यावहारिक आगे का रास्ता

यदि आप आज एक एजेंट बना रहे हैं, तो वास्तविक शुरुआती प्रश्न यह है: "मेरे एजेंट को क्या याद रखने की आवश्यकता है, और वह किस तरह के प्रश्नों का उत्तर देगा?"

यदि आपकी क्वेरी को केवल समानता खोज की आवश्यकता है ("इसके जैसी बातचीत खोजें"), तो केवल-वेक्टर मेमोरी काम करती है। जैसे ही क्वेरी एंटिटी सीमाओं को पार करती है ("क्या मंगलवार के आउटेज से एलिस का प्रोजेक्ट प्रभावित हुआ?"), आपको ग्राफ ट्रैवर्सल की आवश्यकता होती है।

आप अलग-अलग वेक्टर, ग्राफ और रिलेशनल स्टोर को स्वयं जोड़ सकते हैं। जो टीमें इस रास्ते पर जाती हैं, वे आमतौर पर एक मेमोरी लेयर के लिए बुनियादी ढाँचे पर हफ्ते बिताती हैं जो अभी भी अपने स्वयं के उपयोग से नहीं सीखती है।

Cognee इसे चार API कॉल में समेट देता है। एम्बेडेड डिफ़ॉल्ट आपको मिनटों में चालू कर देते हैं। स्वैप करने योग्य बैकएंड (Postgres, Qdrant, Neo4j) आपको अपना एजेंट कोड बदले बिना प्रोडक्शन में ले जाते हैं।

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

अगली चीज़ क्या है जो आप चाहते हैं कि आपका एजेंट कल याद रखे जो आज वह भूल गया? वहीं से शुरू करें।

👉 GitHub पर Cognee देखें →, इसे एक स्टार दें, और इसे अपने अगले एजेंट में वायर करने का प्रयास करें।

चार async कॉल, एक pip install, और आप चालू हैं।

बस इतना ही!

अगर आपको यह पढ़कर आनंद आया:

मुझे खोजें →@akshay_pachaar ✔️

हर दिन, मैं AI, Machine Learning, और वाइब कोडिंग की सर्वोत्तम प्रथाओं पर ट्यूटोरियल और अंतर्दृष्टि साझा करता हूँ।