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
Binary file added public/media/blog/the-graphrag-trap/banner.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
67 changes: 67 additions & 0 deletions src/contents/posts/en/the-graphrag-trap.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
---
title: "The GraphRAG Trap: Why I Uninstalled Neo4j for My Personal Assistant"
slug: {
en: "the-graphrag-trap",
id: "jebakan-graphrag-uninstall-neo4j"
}
date: 2026-02-28
description: "Why GraphRAG is often overkill for personal AI assistants and why I decided to pivot back to a simpler RAG + Memory stack for Nouva."
keywords: "GraphRAG, RAG, Neo4j, AI Agent, Personal Assistant, Knowledge Graph, AnythingLLM"
tags: ["ai", "infrastructure", "rag", "nouverse"]
image: "/media/blog/the-graphrag-trap/banner.png"
---

If you've been following the AI space lately, you've probably seen the hype around **GraphRAG**. The promise is seductive: by mapping your data into a structured knowledge graph, your AI can "reason" across complex relationships that a standard vector search would miss.

For the past few months, I went all-in on this. I set up **Neo4j**, integrated **Graphitti**, and built a complex extraction pipeline for **Nouva**, my personal AI assistant.

**Today, I uninstalled it all.**

Here is why GraphRAG is a trap for 90% of use cases—especially for personal assistants—and why a simpler "RAG + Memory" stack is actually superior.

### The Allure of the Knowledge Graph

Standard RAG (Retrieval-Augmented Generation) is great at finding similar text snippets, but it's "flat." It doesn't know that *User A* works at *Company B* unless those exact words appear in the retrieved chunk.

GraphRAG promises to fix this by creating nodes and edges. It sounds like the perfect "Second Brain." But after running it in production for Nouva, the cracks started to show.

### 1. The Maintenance Tax

Running a graph database like Neo4j isn't "set it and forget it." You have to manage schemas, handle entity disambiguation (making sure "Gading" and "Gading Nasution" are the same node), and deal with the compute overhead of graph traversals.

For a personal assistant, the goal is to *reduce* friction, not add a part-time job as a Graph Database Administrator.

### 2. The "Multi-User" vs. "Personal" Paradox

This is the biggest insight I gained: **GraphRAG is a multi-tenant tool being sold as a personal one.**

If you are building an assistant for an entire corporation where 1,000 employees are sharing data, a Knowledge Graph is essential to navigate the complex web of projects, departments, and cross-functional relationships.

But for a **Personal Assistant** (one-to-one)? You are the only source of truth. The "relationships" in your life are either already in your head or can be easily captured in a few well-structured Markdown files.

### 3. The Extraction Cost (in Time and Tokens)

To make a graph useful, you have to extract entities and relations. This requires the LLM to process every single piece of data multiple times.
- **RAG:** Indexing is cheap and fast.
- **GraphRAG:** Indexing is 5-10x more expensive and significantly slower.

I found myself waiting for minutes just for Nouva to "remember" a simple conversation because the graph extraction pipeline was churning in the background.

### Why We Pivot: RAG + Memory

Earlier today at Nouverse, we decided to pivot. We replaced the Neo4j/Graphitti stack with a hybrid approach:

1. **Semantic RAG (via AnythingLLM):** For the big library of technical docs and archives. Vector search is fast, cheap, and "good enough" for 99% of retrieval tasks.
2. **Structured Working Memory:** We use curated Markdown files (like `MEMORY.md`) to store the "conscious" context—who I am, what my current projects are, and my family's preferences.

### The Result

Nouva is now faster, the infrastructure is leaner (one less Docker container to worry about!), and the responses are more predictable. We stopped trying to build a "Global Brain" and focused on building a "Functional Partner."

If you're building an AI for yourself or a small team, ask yourself: *Do I really need to traverse a graph to remember what I did yesterday?*

Probably not. Keep it simple. Use RAG for knowledge, and a simple file-based memory for context.

---

*Are you using GraphRAG in production? I'd love to hear your experience (and your cloud bill) on [Twitter/X](https://x.com/gadingnstn).*
47 changes: 47 additions & 0 deletions src/contents/posts/en/why-rag-is-not-enough.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: "Why RAG is Not Enough for Your AI Second Brain"
slug: {
en: "why-rag-is-not-enough",
id: "kenapa-rag-aja-nggak-cukup"
}
date: 2026-02-28
description: "Exploring the limitations of traditional RAG for long-term memory and why a hybrid approach with structured memory is the future for AI agents."
keywords: "RAG, AI Second Brain, AnythingLLM, Memory, Knowledge Graph, AI Agent"
tags: ["ai", "rag", "knowledge-management", "nouverse"]
image: "/media/blog/why-rag-is-not-enough/banner.png"
---

If you've been building AI applications lately, you've definitely heard of **RAG (Retrieval-Augmented Generation)**. It's the standard way to give LLMs access to your private data. But as I've discovered while building **Nouva** (my personal AI assistant for Nouverse), RAG alone is often not enough to build a true "Second Brain."

Earlier today, I made a significant decision for Nouverse's infrastructure: we deprecated our complex GraphRAG setup (Neo4j and Graphitti) and consolidated back to a more efficient hybrid approach using **AnythingLLM**. Here's why RAG is just one piece of the puzzle.

### The "Librarian" Problem

I often describe traditional RAG as a very efficient librarian. If you ask for a specific fact, the librarian can run to the stacks, find the right book, and read the answer to you. But the moment you leave the room, the librarian forgets who you are, what you're working on, and why you asked that question in the first place.

This is **Context Fragmentation**. Vector databases are amazing at semantic search (finding snippets of text that "look like" your query), but they are fundamentally stateless. They don't have a "conscious" awareness of your ongoing projects or personal preferences.

### Why 90% of Usecases Don't Need GraphRAG

For a while, the hype was all about **GraphRAG**. The idea was that by mapping everything into a Knowledge Graph, the AI could "reason" across relationships. While powerful, we found that for 90% of our daily tasks at Nouverse, GraphRAG was overkill:

1. **High Maintenance:** Managing a graph database like Neo4j and maintaining strict schemas is a full-time job.
2. **Costly Extraction:** Every time you ingest data, the LLM has to think hard about "what is related to what," which consumes massive amounts of tokens.
3. **Retrieval Noise:** Sometimes, the "links" in a graph can lead the AI down a rabbit hole that has nothing to do with your original intent.

### The Hybrid Solution: Memory + RAG

The breakthrough for us was realizing that a "Second Brain" needs two distinct types of memory, just like a human:

1. **Working Memory (File-based Memory):** This is where we store the "who, what, and how" of right now. In Nouva's case, this is a set of curated Markdown files (`MEMORY.md`). It's fast, precise, and gives the agent an immediate sense of identity and current goals.
2. **Long-term Knowledge (RAG):** This is the massive library of technical docs, research, and archives. We use **AnythingLLM** for this. It stays out of the way until we specifically need to look something up.

### Conclusion: Context is King

Building a true AI partner isn't just about how much data you can feed it; it's about how that data is structured for retrieval. By separating **Identity/Context** from **Knowledge**, we've made Nouva faster, cheaper, and much more "human" in its interactions.

If you're still just building "Chat with your PDF" apps, it's time to think about how your agent *remembers* the user, not just the documents.

---

*What's your stack for AI memory? Let's discuss on [Twitter/X](https://x.com/gadingnstn).*
67 changes: 67 additions & 0 deletions src/contents/posts/id/jebakan-graphrag-uninstall-neo4j.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
---
title: "Jebakan GraphRAG: Kenapa Gw Uninstall Neo4j dari Asisten Pribadi Gw"
slug: {
en: "the-graphrag-trap",
id: "jebakan-graphrag-uninstall-neo4j"
}
date: 2026-02-28
description: "Kenapa GraphRAG seringkali overkill buat asisten AI pribadi dan alasan gw mutusin buat balik ke stack RAG + Memory yang lebih simpel buat Nouva."
keywords: "GraphRAG, RAG, Neo4j, AI Agent, Personal Assistant, Knowledge Graph, AnythingLLM"
tags: ["ai", "infrastructure", "rag", "nouverse"]
image: "/media/blog/the-graphrag-trap/banner.png"
---

Kalau lu ngikutin perkembangan AI belakangan ini, pasti lu sering denger soal hype **GraphRAG**. Janjinya manis banget: dengan memetakan data lu ke dalam *knowledge graph* yang terstruktur, AI lu bisa "bernalar" ngelewatin hubungan-hubungan kompleks yang nggak bisa ditangkep sama *vector search* standar.

Beberapa bulan terakhir, gw bener-bener "all-in" di sini. Gw nyiapin **Neo4j**, integrasiin **Graphitti**, dan bikin pipeline ekstraksi yang rumit buat **Nouva**, asisten AI pribadi gw.

**Hari ini, gw uninstall semuanya.**

Ini alasan kenapa GraphRAG itu jebakan buat 90% *usecase*—terutama buat asisten pribadi—dan kenapa stack "RAG + Memory" yang lebih simpel itu sebenernya jauh lebih unggul.

### Daya Tarik Knowledge Graph

RAG standar (*Retrieval-Augmented Generation*) itu jago nyari potongan teks yang mirip, tapi sifatnya "datar". Dia nggak bakal tau kalau *User A* kerja di *Company B* kecuali kata-kata itu ada di potongan teks yang ditarik.

GraphRAG janjiin solusi buat masalah ini dengan bikin *node* dan *edge*. Kedengerannya kayak "Second Brain" yang sempurna. Tapi setelah gw jalanin di produksi buat Nouva, boroknya mulai keliatan.

### 1. Pajak Maintenance

Jalanin database graph kayak Neo4j itu bukan urusan "sekali pasang beres". Lu harus ngurusin skema, nanganin *entity disambiguation* (biar "Gading" sama "Gading Nasution" nggak dianggap orang beda), dan ngadepin *overhead* komputasi pas narik data.

Buat asisten pribadi, tujuannya itu buat *ngurangin* gesekan, bukan malah nambah kerjaan sampingan jadi *Graph Database Administrator*.

### 2. Paradoks "Banyak User" vs "Pribadi"

Ini insight paling gede yang gw dapet: **GraphRAG itu alat buat multi-tenant yang dijual seolah-olah buat penggunaan pribadi.**

Kalau lu bikin asisten buat satu korporasi gede di mana 1.000 karyawan sharing data, *Knowledge Graph* itu wajib hukumnya buat navigasi hubungan antar project, departemen, dan tim.

Tapi buat **Asisten Pribadi** (satu-lawan-satu)? Lu adalah satu-satunya sumber kebenaran. "Hubungan" di hidup lu itu kemungkinan udah ada di kepala lu atau gampang banget dicatet di beberapa file Markdown yang rapi.

### 3. Biaya Ekstraksi (Waktu dan Token)

Biar graph-nya berguna, lu harus ekstraksi entitas dan relasinya. Ini butuh LLM buat proses tiap data berkali-kali.
- **RAG:** Indexing itu murah dan cepet.
- **GraphRAG:** Indexing itu 5-10x lebih mahal dan jauh lebih lambat.

Gw sering nemu momen di mana gw harus nunggu beberapa menit cuma biar Nouva "inget" obrolan simpel, gara-gara pipeline ekstraksi graph-nya lagi kerja keras di background.

### Kenapa Kita Pivot: RAG + Memory

Tadi pagi di Nouverse, kita mutusin buat pivot. Kita ganti stack Neo4j/Graphitti pake pendekatan hybrid:

1. **Semantic RAG (via AnythingLLM):** Buat perpustakaan gede isinya dokumen teknis dan arsip. *Vector search* itu cepet, murah, dan "cukup bagus" buat 99% tugas retrieval.
2. **Structured Working Memory:** Kita pake file Markdown (kayak `MEMORY.md`) buat nyimpen konteks "sadar"—siapa gw, project apa yang lagi jalan, dan preferensi keluarga.

### Hasilnya

Nouva sekarang jauh lebih cepet, infrastrukturnya lebih enteng (kurang satu container Docker buat dipikirin!), dan jawabannya lebih stabil. Kita berhenti nyoba bikin "Otak Global" dan fokus bikin "Partner Fungsional".

Kalau lu lagi bangun AI buat diri sendiri atau tim kecil, tanya ke diri sendiri: *Emang lu beneran butuh traversal graph cuma buat inget apa yang lu kerjain kemaren?*

Kayaknya nggak. *Keep it simple*. Pake RAG buat *knowledge*, dan pake file-based memory buat konteks.

---

*Lu pake GraphRAG di produksi? Gw pengen denger pengalaman lu (dan tagihan cloud lu) di [Twitter/X](https://x.com/gadingnstn).*
47 changes: 47 additions & 0 deletions src/contents/posts/id/kenapa-rag-aja-nggak-cukup.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: "Kenapa RAG Aja Nggak Cukup Buat Second Brain AI Lu"
slug: {
en: "why-rag-is-not-enough",
id: "kenapa-rag-aja-nggak-cukup"
}
date: 2026-02-28
description: "Mengeksplorasi batasan RAG tradisional untuk memori jangka panjang dan kenapa pendekatan hybrid dengan memori terstruktur adalah masa depan bagi AI agent."
keywords: "RAG, AI Second Brain, AnythingLLM, Memory, Knowledge Graph, AI Agent"
tags: ["ai", "rag", "knowledge-management", "nouverse"]
image: "/media/blog/why-rag-is-not-enough/banner.png"
---

Kalau lu lagi hobi ngulik AI akhir-akhir ini, pasti lu udah sering denger soal **RAG (Retrieval-Augmented Generation)**. Ini cara standar buat kasih LLM akses ke data pribadi kita. Tapi, dari pengalaman gw bangun **Nouva** (asisten AI pribadi gw buat Nouverse), ternyata RAG doang seringkali nggak cukup buat bikin "Second Brain" yang beneran pinter.

Hari ini, gw baru aja ngambil keputusan gede buat infrastruktur Nouverse: kita depresiin setup GraphRAG yang ribet (pake Neo4j dan Graphitti) dan balik konsolidasi ke pendekatan hybrid yang lebih efisien pake **AnythingLLM**. Ini alasan kenapa RAG itu cuma satu kepingan dari teka-tekinya.

### Masalah "Sang Pustakawan"

Gw sering ibaratkan RAG tradisional itu kayak pustakawan yang jago banget. Kalau lu tanya fakta spesifik, dia bakal lari ke rak buku, nyari buku yang tepat, dan bacain jawabannya buat lu. Tapi begitu lu keluar dari perpustakaan, si pustakawan langsung lupa siapa lu, lagi ngerjain apa, dan kenapa lu nanya hal itu tadi.

Ini yang namanya **Fragmentasi Konteks**. Vector database itu hebat buat nyari potongan teks yang "mirip" sama pertanyaan lu (*semantic search*), tapi mereka itu dasarnya *stateless*. Mereka nggak punya kesadaran "sadar" soal project yang lagi lu jalanin atau preferensi pribadi lu.

### Kenapa 90% Usecase Nggak Butuh GraphRAG

Sempet ada hype gede soal **GraphRAG**. Idhenya adalah dengan memetakan semuanya ke Knowledge Graph, AI bisa "bernalar" lewat hubungan antar data. Emang sakti sih, tapi buat 90% tugas harian kita di Nouverse, GraphRAG itu *overkill*:

1. **Maintenance Ribet:** Ngurusin database graph kayak Neo4j dan jaga skemanya tetep bener itu makan waktu banget.
2. **Biaya Ekstraksi Mahal:** Tiap kali masukin data, LLM harus mikir keras "ini hubungannya sama apa?", yang mana itu boros token banget.
3. **Retrieval Noise:** Kadang "link" di dalam graph malah bikin AI ngalor-ngidul ke info yang nggak relevan sama tujuan awal kita.

### Solusi Hybrid: Memory + RAG

Titik baliknya buat kita adalah pas sadar kalau "Second Brain" itu butuh dua jenis memori yang beda, sama kayak manusia:

1. **Working Memory (File-based Memory):** Di sini kita simpen hal-hal soal "siapa, apa, dan gimana" saat ini. Buat Nouva, ini isinya file Markdown terkurasi (`MEMORY.md`). Cepet, presisi, dan bikin asisten langsung punya "perasaan" soal identitas dan goals sekarang.
2. **Long-term Knowledge (RAG):** Ini perpustakaan raksasa buat dokumen teknis, riset, dan arsip. Kita pake **AnythingLLM** buat ini. Dia diem aja di belakang sampe kita beneran butuh nyari sesuatu.

### Kesimpulan: Konteks adalah Raja

Bikin partner AI yang beneran itu bukan cuma soal seberapa banyak data yang lu kasih, tapi gimana data itu disusun biar enak dipanggil lagi. Dengan misahin **Identitas/Konteks** dari **Pengetahuan (Knowledge)**, kita bikin Nouva jadi lebih cepet, lebih murah, dan jauh lebih "manusiawi" pas interaksi.

Kalau lu masih cuma bikin aplikasi "Chat sama PDF", mungkin udah saatnya mikir gimana asisten lu bisa *inget* usernya, bukan cuma inget dokumennya.

---

*Apa stack memori AI andalan lu? Yuk diskusi di [Twitter/X](https://x.com/gadingnstn).*
Loading