Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions src/contents/posts/en/building-agent-memory-free-vendor.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,7 @@ projects: [Nouverse Core, Homelab]
tags: [Kubernetes, Docker, RAG]
importance: 7
mood: excited
related_dates: [2026-07-01]
uncategorized:
technologies: []
libraries: [Pydantic]
Expand Down Expand Up @@ -90,15 +91,17 @@ With this math, a critical system design discussion from 3 months ago (high impo

---

### 3. Keep it Simple: Dropping Graph Traversal & BFS
### 3. Keep it Simple: Replacing BFS Traversal with Programmatic 1-Hop Expansion

Initially, when designing this system, I went all-in on writing a graph traversal algorithm using **Breadth-First Search (BFS)** with a strict depth limit (`max_depth = 2`) to crawl the `continue_of` and `related_dates` fields in the YAML header. The goal was to automatically pull threaded daily notes.
Initially, when designing this system, I wrote a complex graph traversal algorithm using **Breadth-First Search (BFS)** with a strict depth limit (`max_depth = 2`) to automatically crawl and pull threaded daily notes.

However, after testing it in production, I realized this approach was *overkill* and highly prone to **date hallucination** by the LLM (the LLM frequently hallucinated past dates that didn't actually have logs).
However, after testing it in production, I realized this recursive BFS traversal was slow and highly prone to **date hallucination** by the LLM (the LLM frequently hallucinated past dates that didn't actually have logs).

Ultimately, I decided to **completely drop the graph traversal logic**. Why? Because the task of connecting related topics is **already handled naturally and automatically by Semantic RAG (pgvector/AnythingLLM)**.
Ultimately, I refactored this approach to make it much simpler and deterministic:
1. **Programmatic Topic Detection (Sync-time):** During the daily sync process, our Python script automatically scans the new summary's metadata and matches it against keywords in the local `MEMORY_INDEX.md` file. The top 2 most relevant dates are injected into the YAML metadata as `related_dates`. This has *zero* LLM token cost and guarantees 100% valid dates.
2. **1-Hop Expansion (Retrieval-time):** When the AI agent queries memory (`query-memory.py`), we no longer run a recursive BFS traversal. We simply take the candidate dates from the Semantic RAG and perform a **1-hop expansion** to their `related_dates`, decaying their semantic score by 30% (`score * 0.7`).

If I ask *"How was the Docker setup yesterday?"*, the RAG automatically retrieves all daily summaries relevant to the keyword "Docker" without requiring manual wikilinks inside the markdown files. We don't need a complex graph database traversal for a personal assistant. *Keep it simple!*
With this approach, we still get the benefits of document relationships (topic clusters), but the code remains lightweight, fast, and free from complex traversal bugs. *Keep it simple!*

---

Expand Down
13 changes: 8 additions & 5 deletions src/contents/posts/id/membangun-agent-memory-bebas-vendor.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,7 @@ projects: [Nouverse Core, Homelab]
tags: [Kubernetes, Docker, RAG]
importance: 7
mood: excited
related_dates: [2026-07-01]
uncategorized:
technologies: []
libraries: [Pydantic]
Expand Down Expand Up @@ -90,15 +91,17 @@ Dengan skema ini, diskusi penting 3 bulan lalu (importance tinggi) gak akan kala

---

### 3. Keep it Simple: Membuang Graph Traversal & BFS
### 3. Keep it Simple: Mengganti BFS Traversal dengan 1-Hop Expansion Programmatik

Awalnya, pas merancang sistem ini, gw sempat all-in menulis kode traversal graf menggunakan algoritma **Breadth-First Search (BFS)** dengan batas kedalaman (`max_depth = 2`) untuk menelusuri field `continue_of` dan `related_dates` di YAML metadata. Idenya biar asisten AI bisa narik riwayat chat yang nyambung secara otomatis.
Awalnya, pas merancang sistem ini, gw sempat menulis kode traversal graf yang kompleks menggunakan algoritma **Breadth-First Search (BFS)** dengan batas kedalaman (`max_depth = 2`) untuk menelusuri hubungan antar tanggal. Idenya biar asisten AI bisa narik riwayat chat yang nyambung secara otomatis.

Tapi setelah diuji coba, gw sadar kalau pendekatan ini *overkill* dan rawan **halusinasi tanggal** dari LLM (LLM sering ngasal nebak tanggal masa lalu yang gak beneran ada lognya).
Tapi setelah diuji coba, gw sadar kalau BFS traversal rekursif ini lambat dan rawan **halusinasi tanggal** dari LLM (LLM sering ngasal nebak tanggal masa lalu yang gak beneran ada lognya).

Akhirnya, gw ambil keputusan buat **ngebuang seluruh logika graph traversal tersebut**. Kenapa? Karena fungsi menghubungkan topik yang sama itu **sudah ditangani secara alami dan otomatis oleh RAG Semantik (pgvector/AnythingLLM)**.
Akhirnya, gw merombak pendekatan ini menjadi jauh lebih simpel dan deterministik:
1. **Deteksi Topik Pas Sync (Programmatik):** Pas proses sinkronisasi harian, script Python kita bakal nge-scan metadata summary baru dan mencocokkannya dengan keyword di file `MEMORY_INDEX.md` lokal secara otomatis. Top 2 tanggal yang paling relevan disuntikkan ke YAML metadata `related_dates`. Ini *zero cost* token LLM dan dijamin 100% tanggalnya valid.
2. **Ekspansi 1-Hop (Retrieval):** Pas asisten AI nyari memori (`query-memory.py`), kita gak pake BFS traversal rekursif lagi. Kita cuma ngambil tanggal kandidat hasil RAG Semantik, lalu melakukan ekspansi **1-hop** ke tanggal-tanggal yang ada di `related_dates` dengan memotong skor semantiknya sebesar 30% (`score * 0.7`).

Kalau gw nanya *"Setup Docker kemarin gimana?"*, RAG bakal otomatis narik semua tanggal summary yang relevan dengan keyword "Docker" tanpa perlu kita link secara manual di file markdown. Kita gak butuh traversal graph database yang kompleks cuma buat asisten personal. *Keep it simple!*
Dengan cara ini, kita tetep dapet keuntungan relasi antar dokumen (graf topik), tapi kodenya super enteng, cepat, dan bebas dari bug traversal yang rumit. *Keep it simple!*

---

Expand Down
Loading