
Peta perjalanan saya merombak sistem memori AI Agent Nouva dari yang tadinya berisik dan bikin RAG dilusi, menjadi skema Two-Tier Hybrid RAG + NAS Markdown yang 95% mengcover semua kebutuhan.
Di tulisan gw sebelumnya tentang Jebakan GraphRAG: Kenapa Gw Uninstall Neo4j dari Asisten Pribadi Gw, gw sempet cerita panjang lebar soal kenapa gw mutusin buat ngebuang Neo4j dan Graphitti dari stack asisten AI gw, Nouva. Intinya: overkill, nyusahin diri sendiri, dan bikin boros token LLM cuma buat nge-traversal graph yang sebenernya ga rumit-rumit amat buat skala personal.
Tapi, setelah Neo4j di-uninstall, gw kebentur masalah baru: Gimana cara ngelola memori jangka panjang (chat logs & history) Nouva biar tetep rapi, cepet, tapi ga bikin RAG-nya "mabok"?
Kalau kita asal nge-dump semua file chat logs harian mentah (YYYY-MM-DD-HHMM.md) langsung ke database vector AnythingLLM, kita bakal masuk ke jebakan baru: Dilusi Vektor & Noise.
Hari ini gw mau share cara gw nge-desain sistem memori hybrid yang super simpel, zero-dependency tambahan, tapi 95% udah mengcover semua kebutuhan asisten pribadi gw.
Pas awal-awal transisi ke RAG konvensional (AnythingLLM), gw nge-sync semua file log harian mentah ke database vector. Hasilnya? Berantakan.
Satu file chat log harian itu isinya campur aduk. Ada bahasan arsitektur Kubernetes, diskusi santai soal waifu Tifa di FF7 Rebirth, log error system, sampai reminder skincare titipan istri. Pas file ini di-chunk (dipecah per 1000 karakter) dan di-embed, nilai vektornya jadi terdelusi.
Efek sampingnya kocak sekaligus nyusahin. Pas gw nanya: "Va, inget ga diskusi kita soal ESG kemarin?", RAG-nya malah nge-return chunk skincare reminder karena skor semantiknya mirip secara acak di dalam database. Konteks yang gw cari malah tenggelam.
Sebelum gw ceritain solusinya, gw mau pertegas lagi kenapa gw tetep 95% ga butuh memory stack canggih di luar sana untuk skala personal:
MEMORY.md statis di workspace lokal yang isinya curated facts (spek PC, info keluarga, project aktif). Dan file markdown ini jauh lebih gampang di-debug dan di-edit manual dibanding lu harus nge-delete node graph yang salah tangkep di database tersembunyi.Sisa 5% kebutuhan itu cuma kalau lu pengen bikin analisis abstrak jangka panjang (misal: "Tolong petakan mood gw selama 1 tahun terakhir"). Buat usecase harian software engineer? Ga kepake.
TL;DR: RAG di sini gw bikin sebagai memory index doang. Setiap keyword yang masuk bakal me-return beberapa kandidat tanggal log harian (format YYYY-MM-DD). Memory aslinya cuma berbasis file markdown, dengan nama file = tanggal itu tadi. Jadi setelah LLM dapet kandidat tanggal dari index, dia baru akses langsung file markdown-nya buat baca isi aslinya.
Sebagai gantinya, gw nerapin arsitektur Two-Tier Hybrid Memory yang ngebagi tugas pencarian secara jelas dan efisien:
[User Query]
│
▼
[Unified query-memory.py]
│
├─► Step 1: Semantic Search (RAG via AnythingLLM)
│ Mencari di MEMORY_INDEX.md (Peta Navigasi)
│ Hasil: Nemu Tanggal Bahasan (e.g., 2026-06-24)
│
├─► Step 2: Direct Read (NAS Zip Archive)
│ Membaca transkrip mentah langsung dari file zip di NAS
│
└─► Fallback: Fast Keyword Search (Grep di NAS Zip)
Jika RAG ragu atau tidak menemukan hasil
Kita ga lagi nge-sync chat log mentah yang panjang dan berisik ke database vector. Yang kita upload ke AnythingLLM cuma dua file:
MEMORY.md (Curated long-term facts).MEMORY_INDEX.md (Peta navigasi).File MEMORY_INDEX.md ini di-generate otomatis via script sync mingguan. Isinya cuma ringkasan super singkat per tanggal. Contoh:
### 📅 Wednesday, June 24, 2026 (2026-06-24)
- **🚀 AnythingLLM Migration & Configuration**
- **🛠️ Proxmox & Terraform State Alignment**
- **Discussions (Chat)**
- tapi gw penasaran apa sih yg dikejar esg ini? apa isinya orang woke semua?
Karena filenya bersih dari log error dan chat berisik, RAG bisa nge-embed ini dengan akurat pake model bge-m3 secara lokal lewat Ollama di server homelab (Ryzen 7 5825U).
Semua chat log mentah per sesi (YYYY-MM-DD-HHMM.md) otomatis di-zip dan ditransfer ke NAS (virtual-nas) setelah grace period H-2, lalu file lokalnya dihapus biar disk agent-host ga penuh.
Gw bikin script wrapper query-memory.py. Alurnya begini:
MEMORY_INDEX.md dan mengembalikan potongan teks yang berisi tanggal target: 2026-06-24.2026-06-24.md langsung ke RAM, dan menyajikan transkrip full-nya ke AI Agent.zipfile & requests). Ga perlu install database graph baru atau library aneh-aneh.agent-host gw yang cuma dapet jatah 4GB RAM di Proxmox tetep enteng jalannya karena beban berat embedding model bge-m3 dititipin ke Ollama di backend..zip, datanya aman dan gampang banget dipindahin kalau suatu saat gw mau migrasi asisten AI ini ke platform lain (tinggal import folder zip NAS ke Claude Project, kelar)..md mentah dan .zip standar ini, datanya 100% milik gw. Kalau besok gw mau ganti LLM provider atau migrasi dari OpenClaw ke framework lain, gw tinggal copy-paste folder zip-nya aja tanpa pusing mikirin kompatibilitas..md-nya dan edit baris yang salah. Ga perlu pusing nyari cara nge-wipe database vector/graph.Keep it simple. Kadang solusi terbaik buat masalah AI modern bukanlah dengan nambah teknologi baru yang makin kompleks, tapi dengan balik ke dasar: file teks terstruktur dan script automasi yang presisi.
Dari eksperimen bongkar-pasang memory stack ini, ada satu pelajaran mahal yang bisa diambil: Jangan gampang silau sama teknologi yang lagi hype.
Dunia AI sekarang itu cepet banget berubah, dan hampir tiap minggu ada library atau framework baru yang janjinya muluk-muluk (GraphRAG lah, mem0 lah, autonomous memory layer lah). Gampang banget buat kita terjebak "mabok teori" dan langsung install ini-itu karena keliatan keren di kertas atau di timeline Threads.
Tapi sebelum install, coba tanya dulu ke diri sendiri:
Kembali ke dasar (back to basics) dan memahami core concept dari masalah yang mau diselesaikan itu jauh lebih penting dibanding numpuk dependency baru. Kadang, solusi terbaik cuma butuh file teks terstruktur (Markdown), sedikit regex, dan script automasi sederhana yang presisi. Lebih hemat token, hemat RAM, dan ga bikin pusing pas maintenance jangka panjang.
Skema flat RAG + NAS ini adalah fondasi awal yang solid. Namun, ketika jumlah catatan harian mulai menumpuk hingga ratusan hari, tantangan berikutnya adalah bagaimana kita mengatasi index bloating, vector dilution, dan melakukan graph traversal (menghubungkan chat yang bersambung antar hari) tanpa mengorbankan performa.
Di tulisan selanjutnya, yaitu Membangun Agent Memory dengan Vendor Lock-in Resistance (Part 2), gw bakal bedah kelanjutan dari arsitektur ini. Kita akan bahas bagaimana merombak sistem memori Nouva menggunakan pendekatan Hierarchical Summary dan rumus Hybrid Scoring sederhana agar pencarian memori tetap instan, rapi, dan tentu saja, tetap 100% bebas dari vendor lock-in.
Biar dapet gambaran utuh kenapa gue sampai pada arsitektur memori lokal di tulisan ini, lu bisa baca perjalanan eksperimen gue sebelumnya:
Gimana cara lu ngelola memori asisten AI lu? Yuk diskusi di Threads.