तो मैंने सोचा कि अब समय आ गया है कि मैं दस्तावेजीकृत करूं कि कैसे पहले से ज्ञात डेटाबेस का उपयोग करके AI एजेंट्स के लिए पर्सिस्टेंट मेमोरी बनाई जाए। वेक्टर डेटाबेस नहीं - MySQL और Neo4j।
यह सैद्धांतिक नहीं है। मैं इस आर्किटेक्चर का रोजाना उपयोग करता हूं, कई प्रोजेक्ट्स में AI एजेंट मेमोरी को हैंडल करने के लिए। यह रहा वास्तव में काम करने वाला स्कीमा और क्वेरी पैटर्न।
द आर्किटेक्चर
AI एजेंट्स को दो प्रकार की मेमोरी की आवश्यकता होती है:
- संरचित मेमोरी - क्या हुआ, कब, क्यों (MySQL)
- पैटर्न मेमोरी - क्या किससे जुड़ा है (Neo4j)
वेक्टर डेटाबेस समानता खोज के लिए होते हैं। वे वर्कफ्लो स्टेट या निर्णय इतिहास को ट्रैक करने के लिए नहीं हैं। इसके लिए आपको ACID ट्रांजेक्शन्स और उचित रिलेशनशिप्स की आवश्यकता होती है।
MySQL स्कीमा
यह रहा AI एजेंट पर्सिस्टेंट मेमोरी के लिए वास्तविक स्कीमा:
-- Architecture decisions the AI made
CREATE TABLE architecture_decisions (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
title VARCHAR(255) NOT NULL,
decision TEXT NOT NULL,
rationale TEXT,
alternatives_considered TEXT,
status ENUM('accepted', 'rejected', 'pending') DEFAULT 'accepted',
decided_at DATETIME DEFAULT CURRENT_TIMESTAMP,
tags JSON,
INDEX idx_project_date (project_id, decided_at),
INDEX idx_status (status)
) ENGINE=InnoDB;
-- Code patterns the AI learned
CREATE TABLE code_patterns (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
category VARCHAR(50) NOT NULL,
name VARCHAR(255) NOT NULL,
description TEXT,
code_example TEXT,
language VARCHAR(50),
confidence_score FLOAT DEFAULT 0.5,
usage_count INT DEFAULT 0,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_project_category (project_id, category),
INDEX idx_confidence (confidence_score)
) ENGINE=InnoDB;
-- Work session tracking
CREATE TABLE work_sessions (
id INT AUTO_INCREMENT PRIMARY KEY,
session_id VARCHAR(255) UNIQUE NOT NULL,
project_id INT NOT NULL,
started_at DATETIME DEFAULT CURRENT_TIMESTAMP,
ended_at DATETIME,
summary TEXT,
context JSON,
INDEX idx_project_session (project_id, started_at)
) ENGINE=InnoDB;
-- Pitfalls to avoid (learned from mistakes)
CREATE TABLE pitfalls (
id INT AUTO_INCREMENT PRIMARY KEY,
project_id INT NOT NULL,
category VARCHAR(50),
title VARCHAR(255) NOT NULL,
description TEXT,
how_to_avoid TEXT,
severity ENUM('critical', 'high', 'medium', 'low'),
encountered_count INT DEFAULT 1,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_project_severity (project_id, severity)
) ENGINE=InnoDB;फॉरेन कीज। चेक कंस्ट्रेंट्स। उचित इंडेक्सिंग। यही रिलेशनल डेटाबेस की ताकत है।
क्वेरी पैटर्न्स
यह रहा AI एजेंट मेमोरी के लिए इसे वास्तव में कैसे क्वेरी करें:
-- Get recent decisions for context
SELECT title, decision, rationale, decided_at
FROM architecture_decisions
WHERE project_id = ?
AND decided_at > DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY decided_at DESC
LIMIT 10;
-- Find high-confidence patterns
SELECT category, name, description, code_example
FROM code_patterns
WHERE project_id = ?
AND confidence_score >= 0.80
ORDER BY usage_count DESC, confidence_score DESC
LIMIT 20;
-- Check for known pitfalls before implementing
SELECT title, description, how_to_avoid
FROM pitfalls
WHERE project_id = ?
AND category = ?
AND severity IN ('critical', 'high')
ORDER BY encountered_count DESC;
-- Track session context across interactions
SELECT context
FROM work_sessions
WHERE session_id = ?
ORDER BY started_at DESC
LIMIT 1;ये सीधे-सादे SQL क्वेरीज़ हैं। EXPLAIN सटीक रूप से अपेक्षित इंडेक्स उपयोग दिखाता है। कोई सरप्राइज नहीं।
Neo4j लेयर
MySQL संरचित डेटा को हैंडल करता है। Neo4j रिलेशनशिप्स को हैंडल करता है:
// Create nodes for decisions
CREATE (d:Decision {
id: 'dec_123',
title: 'Use FastAPI',
project_id: 1,
embedding: [0.23, -0.45, ...] // Vector for similarity
})
// Create relationships
CREATE (d1:Decision {id: 'dec_123', title: 'Use FastAPI'})
CREATE (d2:Decision {id: 'dec_45', title: 'Used Flask before'})
CREATE (d1)-[:SIMILAR_TO {score: 0.85}]->(d2)
CREATE (d1)-[:CONTRADICTS]->(d3:Decision {title: 'Avoid frameworks'})
// Query: Find similar past decisions
MATCH (current:Decision {id: $decision_id})
MATCH (current)-[r:SIMILAR_TO]-(similar:Decision)
WHERE r.score > 0.80
RETURN similar.title, r.score
ORDER BY r.score DESC
// Query: What outcomes followed this pattern?
MATCH (d:Decision)-[:LEADS_TO]->(o:Outcome)
WHERE d.title CONTAINS 'Redis'
RETURN d.title, o.type, o.success_rateवे एक साथ कैसे काम करते हैं
फ्लो कुछ इस तरह दिखता है:
- AI एजेंट कंटेंट जेनरेट करता है या निर्णय लेता है
- MySQL में संरचित डेटा स्टोर करें (क्या, कब, क्यों, पूरा संदर्भ)
- एम्बेडिंग जेनरेट करें, Neo4j में समान आइटम्स के साथ रिलेशनशिप्स के साथ स्टोर करें
- अगली सेशन: Neo4j प्रासंगिक समान निर्णय ढूंढता है
- MySQL उन निर्णयों का पूरा विवरण प्रदान करता है
MySQL सत्य का स्रोत है। Neo4j पैटर्न फाइंडर है।
क्यों सिर्फ वेक्टर डेटाबेस नहीं?
मैंने टीम्स को सिर्फ Pinecone या Weaviate से AI एजेंट मेमोरी बनाने की कोशिश करते देखा है। यह अच्छा काम नहीं करता क्योंकि:
वेक्टर DBs अच्छे हैं:
- क्वेरी से समान दस्तावेज ढूंढने के लिए
- सीमांटिक सर्च (RAG)
- "इस तरह की चीजें"
वेक्टर DBs बुरे हैं:
- "15 मार्च को हमने क्या निर्णय लिया?"
- "मुझे वे निर्णय दिखाएं जो आउटेज का कारण बने"
- "इस वर्कफ्लो की वर्तमान स्थिति क्या है?"
- "किन पैटर्न्स का कॉन्फिडेंस > 0.8 AND usage_count > 10 है?"
ये क्वेरीज़ को संरचित फिल्टरिंग, जॉइन्स, और ट्रांजेक्शन्स की आवश्यकता होती है। यह रिलेशनल डेटाबेस का क्षेत्र है।
MCP और भविष्य
मॉडल कॉन्टेक्स्ट प्रोटोकॉल (MCP) AI सिस्टम्स द्वारा कॉन्टेक्स्ट को हैंडल करने के तरीके को स्टैंडर्डाइज कर रहा है। शुरुआती MCP इम्प्लीमेंटेशन्स वो खोज रही हैं जो हम पहले से जानते थे: आपको संरचित स्टोरेज और ग्राफ रिलेशनशिप्स दोनों की आवश्यकता है।
``````htmlMySQL MCP "resources" और "tools" कैटलॉग को हैंडल करता है। Neo4j संदर्भ आइटम्स के बीच "relationships" को हैंडल करता है। Vector embeddings सिर्फ पहेली का एक टुकड़ा हैं।
Production Notes
वर्तमान सिस्टम जो इस आर्किटेक्चर को चला रहा है:
- MySQL 8.0, 48 tables, ~2GB data
- Neo4j Community, ~50k nodes, ~200k relationships
- Query latency: MySQL <10ms, Neo4j <50ms
- Backup: Standard mysqldump + neo4j-admin dump
- Monitoring: Same Percona tools I've used for years
परिचालन जटिलता कम है क्योंकि ये परिपक्व databases हैं जिनके ऑपरेशनल पैटर्न अच्छी तरह समझे जाते हैं।
When to Use What
| Use Case | Database |
|---|---|
| Workflow state, decisions, audit trail | MySQL/PostgreSQL |
| Pattern detection, similarity, relationships | Neo4j |
| Semantic document search (RAG) | Vector DB (optional) |
State के लिए MySQL से शुरू करें। Pattern recognition की जरूरत हो तो Neo4j जोड़ें। केवल semantic document retrieval कर रहे हों तो ही vector DBs जोड़ें।
Summary
AI agents को persistent memory की जरूरत है। सिर्फ vector database में embeddings नहीं - structured, relational, temporal memory जिसमें pattern recognition हो।
MySQL structured state को हैंडल करता है। Neo4j graph relationships को हैंडल करता है। साथ में ये वही प्रदान करते हैं जो vector databases अकेले नहीं कर सकते।
AI workloads के लिए relational databases को न छोड़ें। हर काम के लिए सही tool इस्तेमाल करें, जो दोनों को साथ में इस्तेमाल करना है।
इस आर्किटेक्चर के AI agent perspective पर और जानने के लिए, 3k1o पर companion post देखें।
