System Design

System Design #3: Vector DB & Memory Patterns , So Your AI Agent Doesn't Forget

Pembahasan mendalam tentang vector database dan memory pattern untuk AI Agent: dari pgvector sampai knowledge graph, dari RAG basic sampai hybrid memory. Biar agent lo ingat, bukan cuma chatbot.

Muhammad Amien·Jun 26, 2026·10 min read

System Design #3: Vector DB & Memory Patterns , So Your AI Agent Doesn't Forget

Bayangkan skenario: minggu ketiga setelah deploy AI Agent buat customer support. Semua lancar , response time di bawah 3 detik, customer puas, Slack channel sepi dari komplain. Sampai suatu pagi client WA: "customer komplain: agent kayaknya lupa semua conversation kemarin. Dia nanya nama customer yang udah 4x chat minggu ini."

Saat dicek log, ternyata conversation history udah overload context window model. Begitu conversation kepotong, informasi kustomer lama hilang. Agent balik jadi chatbot amnesia , nyapa semua orang kayak baru pertama ketemu.

Dari situ jelas: AI Agent tanpa memori itu cuma ChatGPT pake kostum bisnis. Dan bikin memori yang bener itu bukan cuma soal pilih database , tapi soal arsitektur. Artikel ini breakdown semua yang dipelajari tentang vector database dan memory patterns buat AI Agent yang bisa Anda terapin besok.

Kenapa Agent Anda Perlu Memori yang Bener , Bukan Sekadar Chat History

Kebanyakan developer mikir memori agent = simpan chat history di array. Teknisnya bener , tapi mindset-nya salah.

Coba bayangin: Anda lagi ngerjain task complex yang butuh 14 langkah. Anda ngumpulin data dari 5 sumber, analisis, bikin draft, kirim ke 2 orang buat review. Di langkah ke-8, Anda lupa apa yang Anda lakuin di langkah ke-3. Gimana? Gak mungkin kan.

Tapi itu yang terjadi ke agent Anda kalo memorinya cuma chat buffer. Setiap kali context window penuh, informasi lama ilang. Agent mulai ngulang pertanyaan. Nanya hal yang udah dijawab 3 turn lalu. Atau lebih parah: hallucinate fakta karena konteksnya udah gak lengkap.

AI Agent butuh tiga jenis memori, dan ini bukan metafora , ini arsitektur yang beda-beda cara kerjanya:

Contoh konkret working memory state , JSON yang di-update tiap langkah:

Diagram 1: Arsitektur 3-Tier Memori AI Agent

Vector DB Showdown 2026 , Mana yang Cocok Buat Anda?

Ini pertanyaan yang pertanyaan yang paling sering dapet paling sering: "Vector DB apa yang harus pake?" Jawaban singkatnya: tergantung skala dan budget Anda.

Tapi sebelum Anda scroll ke tabel perbandingan, satu hal penting: kebanyakan developer overestimate kebutuhan mereka. Kecuali Anda bangun agent buat jutaan user, kemungkinan besar PostgreSQL + pgvector udah cukup. (Angka stars per Juli 2026, bisa berubah.)

The Lightweight Tier , Buat Solo Dev & Prototyping

PostgreSQL + pgvector (⭐ 22K). Anda udah pake Postgres? Install extension-nya, bikin table dengan kolom vector, beres. Anda bisa query semantic similarity dengan SQL biasa. Support IVFFlat dan HNSW indexing. Cukup buat jutaan vector. Gak perlu infrastructure tambahan.

Setup dasarnya simpel banget , cuma butuh 4 langkah:

saya pake ini buat production agent saya sendiri. Reason? Satu database buat semua , business data, user auth, sama vector memory , simplify everything. Debugging juga lebih gampang karena semuanya di satu tempat.

Chroma (⭐ 28.6K). Open-source, Python-native, jalan embedded dalam aplikasi Anda. Gak perlu server terpisah. Perfect buat prototyping dan proyek kecil-menengah. Banyak tutorial dan komunitas aktif karena integrasi erat dengan LangChain.

LanceDB (⭐ 10.7K). Developer-friendly, serverless, jalan di-disk tanpa server terpisah. Support multimodal (text, image, video). Cocok buat agent yang perlu handle berbagai tipe data , misal agent yang bisa ingat gambar, PDF, dan teks sekaligus.

The Production Tier , Buat Skala Besar

Qdrant (⭐ 32.6K). Performance-oriented, written in Rust. Support filtering kompleks, payload indexing, quantization. Recommended buat agent yang perlu query kompleks , misal "cari conversation mirip topik X dari user yang pernah komplain bulan lalu".

Milvus (⭐ 45K). Yang paling mature, cloud-native. Dibangun buat skala miliaran vector. Digunakan sama perusahaan besar: Walmart, eBay, Tencent. Tapi ops-nya berat , Anda butuh dedicated DevOps, minimal 4 node Kubernetes. Jangan pake ini buat side project.

Weaviate (⭐ 16.4K). Hybrid search (vector + keyword) built-in. Support GraphQL out of the box. Bagus buat agent yang perlu combine semantic search dengan filtering terstruktur , misal agent legal yang perlu cari dokumen dengan keyword spesifik + konteks semantik.

Pinecone Managed service. Anda gak mikirin infrastructure. Mahal di tier berbayar (mulai $70/bulan), tapi ada Starter tier gratis. Reliable. Startup-funded teams biasanya pilih ini karena gak mau hire DevOps khusus vector DB.

Decision Framework , Kapan Pake Apa

saya simplify jadi tiga skenario:

Skenario 1 , Solo Dev / Indie Hacker: Start with pgvector. Anda udah pake Postgres, gak perlu belajar tool baru. Kalo butuh performa lebih, Chroma embedded. Kalo butuh multimodal, LanceDB.

Skenario 2 , Startup Early Stage: pgvector masih oke. Tapi kalo team Anda 3+ engineer dan mulai ngeliat perf issue , Qdrant self-hosted. Performa bagus, ops manageable.

Skenario 3 , Scale-up / Enterprise: Pinecone (managed, zero ops) atau Milvus (self-hosted, full control). Pilih berdasarkan budget vs control yang Anda mau.

Diagram 2: Decision Framework , Memilih Vector Database

Empat Pola Memori , Lebih dari Sekadar Simpan dan Cari

Setelah Anda pilih database-nya, pertanyaan selanjutnya: gimana cara makenya? Memory pattern menentukan seberapa efektif agent Anda memanfaatkan informasi yang disimpan.

Pola 1: RAG as Memory , Paling Sederhana

Simpan setiap interaksi sebagai document di vector DB. Sebelum agent nge-response, retrieve top-K dokumen paling relevan via semantic search. Inject hasilnya ke context.

Implementasi dasarnya di Go cuma 30 baris:

Kelebihan: Simpel. Anda cuma butuh vector DB + embedding model. Bisa jalan dalam 1 jam.

Kekurangan: Static retrieval. Agent gak bisa decide kapan dia perlu retrieve atau apa yang perlu di-retrieve. Semua retrieval terjadi setiap turn , boros token. Dan gak ada mekanisme untuk update, merge, atau delete memory yang udah stale.

Pola 2: MemGPT / Letta , Virtual Context Management

Ini yang paling mature secara akademis. Konsepnya: memperlakukan context window LLM kayak RAM, dan vector database kayak disk. Agent secara otomatis memindahkan data dari "disk" ke "RAM" saat dibutuhkan , mirip hierarchical memory di OS.

Letta (dulu MemGPT) punya tiga tier:

Cocok untuk: agent yang perlu long-running conversations , customer support, personal assistant, therapist AI.

Pola 3: Temporal Knowledge Graph , Fakta yang Berubah Seiring Waktu

Ini approach yang dipake Zep. Vector DB bagus buat similarity search, tapi jelek buat tracking fakta yang berubah. Contoh: user Anda pindah dari Jakarta ke Bandung. Vector search masih bisa return informasi lama tentang Jakarta , agent Anda nyasar.

Zep pake knowledge graph dengan temporal awareness. Setiap fakta punya timestamp. Saat user update lokasi ke Bandung, fakta lama tentang Jakarta gak dihapus , ditandai sebagai historical. Ini penting buat agent yang perlu reasoning tentang perubahan seiring waktu.

Cocok untuk: CRM agent, health tracking agent, financial advisor agent , semua yang melibatkan fakta user yang berubah seiring waktu.

Pola 4: Hybrid , Gabungan Vector + Graph + Rules

Ini tren 2026. Paper terbaru dari Juni 2026 ("Are We Ready For An Agent-Native Memory System?") ngetes 12 sistem memori berbeda , dan kesimpulannya jelas: gak ada arsitektur tunggal yang dominan di semua skenario.

Hybrid approach menggabungkan:

Paper DMF (Juni 2026) nunjukin sesuatu yang mengejutkan: pendekatan deterministic , pake classical NLP + mathematical scoring , bisa menyamai akurasi Mem0 (LLM-based) tapi dengan 0 token untuk memory management. 5x sampai 242x lebih hemat token sepanjang percakapan , dalam benchmark paper, bukan production.

Diagram 3: Hybrid Memory Pattern , Vector DB + Knowledge Graph + Rules

Production Checklist , Dari Prototype ke Production

Berikut checklist yang pake sendiri setelah beberapa kali gagal deployment:

1. Mulai dengan pgvector. Selalu.

Jangan overengineer dari awal. Anda belum tau pola query Anda kayak apa, berapa banyak data yang bakal numpuk, atau bottleneck di mana. pgvector kasih Anda fleksibilitas untuk eksperimen tanpa lock-in ke vendor tertentu.

2. Budget Memory Anda , Jangan Biarin Membengkak

Memory store yang gak di-manage bakal tumbuh tanpa batas. Setiap interaksi baru ditambahin, gak ada yang dihapus. Hasilnya: storage cost bengkak, retrieval makin lambat, kualitas hasil turun karena terlalu banyak noise.

Paper MemRefine (Juni 2026) propose solusi simpel: tetapkan hard budget untuk jumlah entries. LLM judge (atau deterministic scoring) memutuskan setiap entry baru: simpan, merge dengan entry existing, atau delete.

3. Jangan Inject Seluruh History ke Context

Godaan terbesar: "Ah, context window model sekarang 128K token, inject aja semua memory." Jangan. Selain boros biaya, kualitas reasoning LLM menurun pas context makin panjang (lost-in-the-middle problem). Retrieve top 5-10 items paling relevan aja.

Lost-in-the-middle adalah fenomena dimana LLM cenderung mengabaikan informasi di tengah context window yang panjang , hanya bagian awal dan akhir yang efektif diproses.

4. Monitor Retrieval Quality , Bukan Cuma Uptime

Kebanyakan monitoring cuma ngecek: agent online gak? Response time berapa? Itu gak cukup. Anda perlu monitor: berapa persen retrieval yang bener-bener relevan? Ada fakta yang dijawab bener di satu query tapi salah di query lain? Paper MemTrace (Juni 2026) nunjukin bahwa evaluasi tradisional menyesatkan , fakta yang sama bisa bener dalam satu kondisi dan salah di kondisi lain.

5. Siapkan Fallback When Retrieval Fails

Gak semua query bisa dijawab dari memory. Agent Anda harus tau kapan bilang "tidak tau" daripada hallucinate. Implementasi gampang: kasih threshold similarity score. Kalo semua hasil retrieval di bawah threshold, trigger clarification question ke user.

Yang Belum Anda Tau: Masalah yang Belum Ada Solusinya

Jujur aja: memory untuk AI Agent masih nascent. Ada beberapa masalah yang belum ada solusi elegan-nya:

Closing: Start Simple, Grow When Needed

saya tutup dengan prinsip yang sama dari artikel sebelumnya: arsitektur AI Agent itu soal fondasi, bukan fitur. Anda gak perlu vector DB canggih di hari pertama. Anda perlu memori yang konsisten , walau simpel.

Start dengan pgvector. Implement RAG basic. Monitor. Kalo Anda liat retrieval quality menurun atau latency mulai naik , baru pertimbangin dedicated vector DB. Kalo Anda mulai perlu tracking fakta yang berubah seiring waktu , baru tambahin knowledge graph.

Agent yang bisa ingat itu beda kelas dengan chatbot. Dan di 2026, perbedaan itu bukan lagi nice-to-have , itu ekspektasi minimum.

Artikel berikutnya: bakal bahas AI Agent Production Deployment , monitoring, cost optimization, dan gimana caranya agent Anda gak bangkrutin Anda di production. Stay tuned.