Bagaimana Saya Membangun Agent Memory yang Bebas Vendor Lock-in

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.

Jul 05, 2026
7 min read

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.


Masalah RAG Klasik: "Dilusi Vektor"

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.


Kenapa Kita Tetep GAK Butuh mem0 atau GraphRAG?

Sebelum gw ceritain solusinya, gw mau pertegas lagi kenapa gw tetep 95% ga butuh memory stack canggih di luar sana untuk skala personal:

  1. GraphRAG (99% Ga Butuh): Proses indexing-nya rakus token LLM dan bikin CPU/GPU lokal teriak-teriak. Lu ga butuh AI buat nyimpulkan hubungan grafis yang rumit cuma buat nyari tahu diskusi server downtime minggu lalu.
  2. mem0 (90% Ga Butuh): mem0 itu nyimpen fakta dinamis ke database vector/graph terpisah. Masalahnya, kita udah punya file 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.


Solusinya: Two-Tier Hybrid RAG + NAS Markdown

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

Tier 1: Semantic Index Map (MEMORY_INDEX.md)

Kita ga lagi nge-sync chat log mentah yang panjang dan berisik ke database vector. Yang kita upload ke AnythingLLM cuma dua file:

  1. MEMORY.md (Curated long-term facts).
  2. 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).

Tier 2: Raw Archive (NAS Zip)

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.

Tier 3: The Glue (Unified Script)

Gw bikin script wrapper query-memory.py. Alurnya begini:

  1. Pas gw nanya "Inget ga bahasan ESG kita?", script bakal nanya ke RAG (AnythingLLM).
  2. RAG bakal nemu kecocokan di file MEMORY_INDEX.md dan mengembalikan potongan teks yang berisi tanggal target: 2026-06-24.
  3. Script secara otomatis langsung ngebuka file zip di NAS yang meng-cover tanggal tersebut, membaca file 2026-06-24.md langsung ke RAM, dan menyajikan transkrip full-nya ke AI Agent.
  4. Fallback: Kalau RAG gagal nemu secara semantik, script otomatis nge-run keyword search cepat (grep-like) langsung ke seluruh arsip ZIP di NAS.

Kenapa Skema Ini Indah Banget?

  • Zero Extra Dependencies: Cuma modal script Python standar bawaan (zipfile & requests). Ga perlu install database graph baru atau library aneh-aneh.
  • Resource-Friendly: 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.
  • 100% Portable: Karena formatnya cuma Markdown mentah dan file .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).
  • Bebas Vendor Lock-in (Jujur, Gw Udah Capek): Banyak framework memory sekarang yang maksa kita pake database cloud mereka, API berbayar mereka, atau format proprietary yang bikin data kita tersandera. Gw udah capek dikunci sama satu ekosistem. Dengan format .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.
  • Transparan & Mudah Di-debug: Kalau AI salah inget fakta, gw tinggal buka file .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.

Lesson Learned: Kembali ke Dasar

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:

  • Apa beneran butuh? (Usecase personal vs corporate itu beda jauh).
  • Paham ga konsep dasarnya? (Apakah kita cuma butuh mapping tanggal dan keyword, atau beneran butuh traversal graph database yang kompleks?).

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.

What's Next?

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.

Blog Terkait

Biar dapet gambaran utuh kenapa gue sampai pada arsitektur memori lokal di tulisan ini, lu bisa baca perjalanan eksperimen gue sebelumnya:

  1. Membangun GraphRAG untuk Agen Otonom dengan Neo4J and Graphitti (Fase awal nyoba GraphRAG)
  2. Jebakan GraphRAG: Kenapa Gue Akhirnya Uninstall Neo4j (Fase tersadar kalau ini overkill)

Gimana cara lu ngelola memori asisten AI lu? Yuk diskusi di Threads.