ohamlab's picture
|
download
raw
5.07 kB
## Mind Memory Architecture
Overview
The Mind system uses three complementary storage layers:
mind.db ← Source of Truth
knowledge.pt ← Portable Export
knowledge.faiss ← Vector Search Index
Each component has a specific responsibility.
Component Responsibilities
1. mind.db
Purpose: Permanent storage of all memory data.
SQLite is the authoritative database and contains the complete memory graph.
Stores
• Captures
• Events
• Concepts
• Metadata
• Tags
• URLs
• Related IDs
• Lifecycle State
• Enrichment Data
Example
{
"id": "capture_123",
"title": "SQLite Optimization",
"url": "https://example.com",
"tags": ["sqlite", "database"],
"related_ids": ["capture_456"],
"content": "Full article text..."
}
Characteristics
• Human-readable data
• Structured metadata
• Editable
• Persistent
• Source of truth
2. knowledge.pt
Purpose: Portable snapshot of embeddings and lookup information.
Generated from mind.db.
Stores
{
"version": 1,
"embed_model": "BAAI/bge-base-en-v1.5",
"count": 1234,
"ids": [...],
"embeddings": tensor(...)
}
Future versions may also contain:
{
"records": [...],
"texts": [...],
"metadata": [...]
}
Characteristics
• Fast to load
• Portable
• Easy to share
• Useful for backups
• Useful for debugging
Does NOT Replace SQLite
knowledge.pt is an export.
If deleted, it can be regenerated from mind.db.
3. knowledge.faiss
Purpose: High-speed semantic search.
Generated from embeddings.
Stores
Vector 0
Vector 1
Vector 2
...
Vector N
Characteristics
• Extremely fast similarity search
• Optimized for vector retrieval
• Contains no business data
• Contains no content text
• Contains no metadata
Does NOT Store
• Titles
• URLs
• Tags
• Concepts
• Content
It stores vectors only.
Retrieval Flow
User Query
Example:
How do I convert Gemma models to GGUF?
Step 1
Generate query embedding.
Question
Embedding Model
Query Vector
Step 2
Search FAISS.
Query Vector
knowledge.faiss
Top Matching Vectors
Example:
Vector 42 Score 0.95
Vector 17 Score 0.88
Vector 88 Score 0.81
Step 3
Resolve IDs using knowledge.pt.
Vector 42
knowledge.pt
capture_123
Step 4
Retrieve full memory.
capture_123
mind.db
Full Record
Example:
{
"id": "capture_123",
"title": "Gemma GGUF Conversion",
"content": "Detailed conversion instructions..."
}
Why Three Layers?
SQLite
Best for:
• Storage
• Metadata
• Updates
• Relationships
PT
Best for:
• Portability
• Snapshots
• Backup
• Debugging
FAISS
Best for:
• Semantic Search
• Similarity Matching
• Fast Retrieval
Architecture Diagram
┌──────────────────┐
│ User Question │
└─────────┬────────┘
┌──────────────────┐
│ BGE Embedding │
└─────────┬────────┘
┌──────────────────┐
│ knowledge.faiss │
│ Vector Search │
└─────────┬────────┘
┌──────────────────┐
│ knowledge.pt │
│ Vector → ID Map │
└─────────┬────────┘
┌──────────────────┐
│ mind.db │
│ Full Memory Data │
└──────────────────┘
Current State
mind.db
✓ Full Memory Storage
knowledge.pt
✓ Embeddings
✓ IDs
knowledge.faiss
✓ Semantic Search
Future Enhancements
Possible upgrades:
• Store metadata inside knowledge.pt
• Store content snapshots inside knowledge.pt
• Incremental FAISS updates
• HNSW FAISS indexes for larger datasets
• Hybrid keyword + vector search
• Multi-model embedding support
• Automatic synchronization between SQLite and exports
Summary
The architecture separates responsibilities:
• mind.db stores the memories.
• knowledge.faiss finds similar memories.
• knowledge.pt maps vectors back to memory IDs.
This design keeps storage, retrieval, and search independent while allowing fast semantic memory lookup at

Xet Storage Details

Size:
5.07 kB
·
Xet hash:
cbc6a4fca5bdfa7e58b5cd5eebe1f5964848109cb5a18b375a21ceda5e516dfe

Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.